From nobody Fri Jun 1 11:19:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E6A124234 for ; Fri, 1 Jun 2018 11:19:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ME78/X3o; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=JFXxw6Kp 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 ub0NAUqKjqd9 for ; Fri, 1 Jun 2018 11:18:59 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 6908A126B6D for ; Fri, 1 Jun 2018 11:18:59 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w51IIEZn026414; Fri, 1 Jun 2018 11:18:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=vw2gNgHTlzbcYFEQmqzjC8rM4PCetq2Hzsc+khUGXag=; b=ME78/X3o50GVLA1tCiYwgzlzIFKAs931STNDwGWg6mpJQltPv2UNvQV2DFvCV5pKT8jL YJfX/wL6xDg7oavPadzY0y4xNZk9tITaj4/YcLwvKAHIjIH/+d7N/O3wc22SSiN2HwJa 24npbBEqVa8TYDMSc8VYWMs/kZN+FnGdH8I= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2jb86d8kbd-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 01 Jun 2018 11:18:53 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 1 Jun 2018 11:18:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vw2gNgHTlzbcYFEQmqzjC8rM4PCetq2Hzsc+khUGXag=; b=JFXxw6KprUZSPdriWfubNS4RnCn5qgNXIXdEcf8HvWzpM4k6FHZtNGv6HhWl1aQpOHpId/itLMtSehLkk3TNhgtOOId+RQWU3yMUHFX7iv3yMV+UMa3jpE3rrsAs5E7g7YHnJlIKzG9BxRQwHTQhM25y0gnkDrdnDwLHIgaENw8= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2262.namprd15.prod.outlook.com (52.135.197.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.11; Fri, 1 Jun 2018 18:18:50 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0%4]) with mapi id 15.20.0797.020; Fri, 1 Jun 2018 18:18:50 +0000 From: Roberto Peon To: Jana Iyengar CC: Mike Bishop , Martin Thomson , QUIC WG , "Lubashev, Igor" Subject: Re: Partially Reliable Message Stream Thread-Topic: Partially Reliable Message Stream Thread-Index: AdP4Mo3KTicRHsMuS7e4Jrowbk1vdQAMuR2gAAT/n4AAAG2XyQAFL0wgABjGQgcACwyMAAAeyAgA Date: Fri, 1 Jun 2018 18:18:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2262; 7:uBv2ZLi/mF/ExXC0hxoFr1lriXKFb43u2DjJ3T4v23yyLuOfTI6OSJmAV9aoDh4eHv4rsd96wI7NULKOQ4HoEBZudt7/DSRH+DGpNWdGuDn/daXeFb4gK16SXVQHdqFWt7AMZKuCUaQyBX2ATl3cpZ1UbIjmufEmaMOukGGgIcD2Ha4BWSD8vFTy2n1q1mF6T8skfhbSJrFZVK6qso8gNROM04hH79mOY6FFSPZYWMWUkKMv7G+E4r36Ig6oDu4o; 20:zmGxVnZZAwq1wdU41rhGzV0lXGl5Cx6FZOYCvXg+VKRWKEeMgU2lrKHrxAgC7tCHCE/gV6PC/T2MYpyuJWcBqYEMK78QLH3sGztLAPE84k1CKOLw6jYstyOBc19UEhUHReSVKAVry/mmXliKlX43YZi+aW4rNa6toFiXO7D5jrk= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2262; x-ms-traffictypediagnostic: BYAPR15MB2262: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(10436049006162)(85827821059158)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2262; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2262; x-forefront-prvs: 0690E5FF22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39860400002)(376002)(39380400002)(189003)(199004)(76176011)(66066001)(6486002)(229853002)(45080400002)(6506007)(6246003)(476003)(59450400001)(68736007)(2420400007)(11346002)(83716003)(5660300001)(3846002)(39060400002)(2616005)(54906003)(790700001)(6306002)(58126008)(316002)(3480700004)(8936002)(54896002)(82746002)(33656002)(478600001)(6916009)(6512007)(5250100002)(606006)(4326008)(236005)(8676002)(102836004)(3660700001)(6116002)(2900100001)(53546011)(81166006)(81156014)(25786009)(14454004)(2906002)(97736004)(36756003)(6436002)(105586002)(26005)(186003)(7736002)(106356001)(93886005)(99286004)(53936002)(486006)(7110500001)(575784001)(3280700002)(15650500001)(86362001)(446003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2262; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dhvJ1zezbkmAhn3Q7my/suf31nw1UPQmspWI6tF6PUPyXsRafggfTuu0wmOC8k9DY6+Nndko+UEwIc2vvzt31rRlgvh83eBmLeaSmQsveBnfCNt1EBioPdxloaiHrclGkguJ+MnR0QnW7Lc63Q1xQIw+VYH59s4+5A8E0BTy2Scj1PqGdNEeDm/LnbzQ8Ixp spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FFE07B1FB45A4DA6AFA8059F7DAADBE2fbcom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9ff14221-1ae5-4e5f-60cc-08d5c7ec1ff6 X-MS-Exchange-CrossTenant-Network-Message-Id: 9ff14221-1ae5-4e5f-60cc-08d5c7ec1ff6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2018 18:18:50.4305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2262 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-01_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 18:19:03 -0000 --_000_FFE07B1FB45A4DA6AFA8059F7DAADBE2fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFueSBtZXNzYWdlcyBhcmUgbGVzcyBlZmZpY2llbnQgZnJvbSBhIGNhY2hpbmcgcGVyc3BlY3Rp dmUgKGNhY2hlcyBwcmVmZXIgbGFyZ2VyIGZpbGVzIHRoYXQgc3RyZWFtIG92ZXIgbG90cyBvZiBz bWFsbCBzY2F0dGVyL2dhdGhlcikuDQpJZiB3ZSBoYWQgYSBub24tSFRUUCBtYXBwaW5nIG9mIHRo ZSBuZXR3b3JrIGRhdGEtPmRpc2ssIHRoYXQgaXNu4oCZdCBhbiBpc3N1ZSwgYnV0IHRoYXQgd291 bGRu4oCZdCBsZXZlcmFnZSBhbnkgb2YgdGhlIGxlYXJuaW5ncyB3ZeKAmXZlIGhhZCBmcm9tIEhU VFAgY2FjaGluZ+KApg0KLT1SDQoNCkZyb206IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwu Y29tPg0KRGF0ZTogVGh1cnNkYXksIE1heSAzMSwgMjAxOCBhdCAxOjM4IFBNDQpUbzogUm9iZXJ0 byBQZW9uIDxmZW5peEBmYi5jb20+DQpDYzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91 LmJlPiwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4sIFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc+LCAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZT00MGFrYW1haS5jb21A ZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGFydGlhbGx5IFJlbGlhYmxlIE1lc3NhZ2Ug U3RyZWFtDQoNCkknbSBub3Qga2VlbiB0byBnZXQgaW50byB0aGUgd2VlZHMgb2YgdGhpcyBkaXNj dXNzaW9uIGF0IHRoaXMgdGltZSAoYXMgeW91IHNheSwgaXQncyBmb3IgdjIpLCBidXQgSSB1bmRl cnN0YW5kIHRoZSBvdmVyYWxsIGRlc2lnbi4gQSBmZXcgaGlnaGVyLW9yZGVyIHBvaW50cyB3aXRo IHRoaXMgZGVzaWduIGRpcmVjdGlvbjoNCg0KMS4gVGhlcmUncyBjbGVhciBkZW1hcmNhdGlvbiBv ZiBhcHAgbWVzc2FnZXMsIGJ1dCB0aGV5IGFyZW4ndCByZWFsbHkgbWFkZSBmaXJzdCBjbGFzcyBj aXRpemVucy4gSWYgeW91IGRpZCB0aGF0LCBJIGltYWdpbmUgdGhhdCB5b3UgbWlnaHQgaGF2ZSBh IHNpbXBsZXIgZGVzaWduLiBGb3IgaW5zdGFuY2UsIGRlZmluZSBhIE1TR19TVFJFQU0gZnJhbWUs IHdoaWNoIHN1cHBvcnRzIG1lc3NhZ2Ugc3RyZWFtcyAoaW5zdGVhZCBvZiB0aGUgY3VycmVudCBi eXRlIHN0cmVhbXMpLCBhbmQgdGhlbiB5b3UgY2FuIGNhbmNlbCBtZXNzYWdlcyBlYXNpbHkgd2l0 aG91dCBoYXZpbmcgdG8gZG8gc3RyZWFtIG9mZnNldCBzaGVuYW5pZ2Fucy4NCg0KMi4gWW91ciBk ZXNpZ24gaGFzIGV4YWN0bHkgb25lIG9yZGVyaW5nIGNhcGFiaWxpdHksIHdoaWNoIGlzIGxpbWl0 aW5nLiBHZW5lcmFsbHksIGFwcHMgdGhhdCBjYW4gZHJvcCBtZXNzYWdlcyBhbmQgcmVhZCBzdWJz ZXF1ZW50IG9uZXMgYXJlIGFsc28gY2FwYWJsZSBvZiBoYW5kbGluZyBtZXNzYWdlcyBvdXQgb2Yg c2VxdWVuY2UuIFlvdSdsbCB3YW50IHRvIHN1cHBvcnQgcGFydGlhbCBvcmRlcmluZyBhcyB3ZWxs IGFuZCBub3QgY29uc3RyYWluIG1lc3NhZ2VzIHRvIGJlIG9ubHkgZGVsaXZlcmVkIGluIHN0cmlj dGx5IGxpbmVhciBvcmRlci4NCg0KMy4gSSdtIGtlZW4gdG8gc2VlIHdoYXQgd2UgY2FuIGRvIHdp dGggdXNpbmcgc3RyZWFtcyBhcyBtZXNzYWdlcy4gV2UgZG9uJ3QgbmVlZCB0byBwdW50IGV2ZXJ5 dGhpbmcgdG8gdGhlIGFwcCAoYXMgeW91ciB0ZXh0IHN1Z2dlc3RzKSwgYnV0IHdlIGNhbiBzdGFy dCB3aXRoIGEgZ3JvdXBpbmcgb2Ygc3RyZWFtcyAob3IgbWVzc2FnZXMpIGFuZCBidWlsZGluZyBm bG93IGNvbnRyb2wgbWVjaGFuaXNtcyBmb3IgdGhlc2UgZ3JvdXBzLiBJIHN1c3BlY3QgdGhpcyBt aWdodCBiZSBjbGVhbmVyLCBhbmQgaXQgZ2l2ZXMgeW91IGZsZXhpYmlsaXR5IHRvIGNvbnNpZGVy IHZhcmlvdXMgb3JkZXJpbmdzIG9mIG1lc3NhZ2VzLiBXaGVuIHdlJ3JlIGNsb3NlciB0byB2Miwg SSdtIGhhcHB5IHRvIHNwaW4gdXAgYSBkcmFmdCBleHBsb3JpbmcgdGhpcyBkaXJlY3Rpb24uDQoN Ck9uIFRodSwgTWF5IDMxLCAyMDE4IGF0IDg6MjEgQU0sIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIu Y29tPG1haWx0bzpmZW5peEBmYi5jb20+PiB3cm90ZToNClllcy4gWW91IG1heSB3YW50IGEgc2lu Z2xlIHJlc291cmNlIGZvciBhbiBvdXRwdXQgd2hpY2ggeW91IG1heSBiZSBnZW5lcmF0aW5nIGlu IHBhcmFsbGVsLiBFdmVuIGlmIGEgc2luZ2xlIHRocmVhZCAnb3ducycgdGhlIHN0cmVhbSwgeW91 J3ZlIGxvc3QgdGhlIGFiaWxpdHkgdG8gY29vcmRpbmF0ZSB0aGUgZGF0YSBpdCByZWNpZXZlcyBi eSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgb2Zmc2V0Lg0KDQpSZW51bWJlcmluZyB0aGUgb2Zm c2V0cyBicmVha3MgdGhlIGZpbGUtbGlrZSBhYnN0cmFjdGlvbiB3ZSd2ZSBlZmZlY3RpdmVseSB1 c2VkIGZvciBodHRwLg0KDQoNCi09Ug0KDQoNCg0KU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5 IFM3LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lDQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLQ0KRnJvbTogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+DQpEYXRlOiA1LzMwLzE4IDg6MzMgUE0gKEdNVC0w ODowMCkNClRvOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIuY29t Pj4sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbT4+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4+LCAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZT00MGFrYW1haS5jb21A ZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTdWJq ZWN0OiBSRTogUGFydGlhbGx5IFJlbGlhYmxlIE1lc3NhZ2UgU3RyZWFtDQoNCkp1c3QgdG8gYmUg Y2xlYXLigKYuICBZb3XigJlyZSBzdWdnZXN0aW5nIG11bHRpcGxlIHRocmVhZHMgdGhhdCB3b3Vs ZCBiZSB3cml0aW5nIHRvIGEgc2luZ2xlIHN0cmVhbSBpbiBwYXJhbGxlbCwgcmF0aGVyIHRoYW4g YSBzaW5nbGUgdGhyZWFkIOKAnG93bmluZ+KAnSB0aGUgc3RyZWFtPw0KDQpGcm9tOiBSb2JlcnRv IFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIuY29tPj4NClNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDMwLCAyMDE4IDY6MDMgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVm b3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IE1hcnRpbiBUaG9tc29uIDxtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQpD YzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBMdWJhc2hl diwgSWdvciA8aWx1YmFzaGU9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFr YW1haS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFBhcnRpYWxseSBSZWxpYWJs ZSBNZXNzYWdlIFN0cmVhbQ0KDQpJIGZpbmQgaXQgY29uZnVzaW5nIGFzIHdlbGwuICBJIGZhciBw cmVmZXIga2VlcGluZyB0aGUgb2Zmc2V0cyBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgYXMgaXQg YWxsb3dzIGZvciByZWFsLXdvcmxkIHVzZSBvZiBhIHBhcnRpYWxseSByZWxpYWJsZSBzdHJlYW0g KHdoZXJlIHlvdSBtYXkgbm90IHJlY2lldmUgdGhhdCBkYXRhIGJ1dCB5b3UgY2FuIGF0IGxlYXN0 IGZpZ3VyZSBvdXQgd2hhdCB5b3UgZGlkIGdldCBhbmQgaW50ZXJwcmV0IGl0KS4NCkkgZG9udCBr bm93IGhvdyBvbmUgd29odWQgcmVzb2x2ZSB0aGUgcmFjZSBldmVuIHdpdGhpbiB0aGUgc2VuZGlu ZyBhcHBsaWNhdGlvbiAtLSBvbmUgdGhyZWFkIHNlbmRzLCBhbm90aGVyIHRocmVhZCBzZW5kcyB3 aGlsZSB0aGUgZmlyc3Qgc2F5cyB0byBmb3JnZXQgYWJvdXQgc3R1ZmYuIEkgZG9udCBrbm93IHdo YXQgb2Zmc2V0IHN0dWZmIGVuZHMgdXAgYXQgaW4gc3VjaCBjYXNlcywgYW5kIHNvIEkgY2Fubm90 IGZyYW1lIGRhdGEgaW4gYSB3YXkgdGhhdCBpcyBub24tc3luY2hyb25vdXMuIFRoYXQgZGVmZWF0 cyBzb21lIG9mIHRoZSBtYWluIHJlYXNvbnMgdG8gZG8gcGFydGlhbCByZWxpYWJpbGl0eSAoaS5l LiB0byByZWR1Y2Ugaml0dGVyKS4NCkRyYWZ0IDAyIHNlZW1lZCB0byBiZSBnb2luZyBpbiBhIGJl dHRlciBkaXJlY3Rpb24gdy5yLnQgdGhlIHVzZWNhc2VzIGkgY2FuIGNvbmNlaXZlIG9mLiBJIHRo aW5rIHJld2luZGluZyB0byB0aGF0IGFuZCB0aGVuIHBvdGVudGlhbGx5IGZpZ3VyaW5nIG91dCBo b3cgdG8gc2ltcGxpZnkgaXQgd291bGQgYmUgZnVuIQ0KSSdtIGV4Y2l0ZWQgdG8gaGF2ZSB0aGlz IGJlaW5nIGRpc2N1c3NlZCwgc2luY2UgdGhlcmUgaXMgcGVudCB1cCBkZW1hbmQgdG8gdXNlIGl0 IGFscmVhZHkuDQotPVINCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fYWthLm1zX2doZWkzNiZkPUR3TUZB ZyZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09Vk9V al9NbndXZl9QZ2RIdmNHVjFTZTFvM2s1akM4bThub0tEaXhxOEhxQSZzPS14SmJfSldPZExfRHBE TTQzRTA2UzU0TFBFLXhrcFlrU2VuNEVsLXdrUzQmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KU2Vu dDogV2VkbmVzZGF5LCBNYXkgMzAsIDIwMTggNTo1MDo1OSBQTQ0KVG86IE1pa2UgQmlzaG9wDQpD YzogUVVJQyBXRzsgTHViYXNoZXYsIElnb3INClN1YmplY3Q6IFJlOiBQYXJ0aWFsbHkgUmVsaWFi bGUgTWVzc2FnZSBTdHJlYW0NCg0KTGlrZSBNaWtlLCBJIGZpbmQgdGhpcyBnYXAgdGhpbmcgY29u ZnVzaW5nLiAgQW5kIE1pa2UncyBtZXNzYWdlDQpoZWxwZWQsIGJ1dCBub3QgYSBsb3QuDQoNCkl0 IHRvb2sgYSB3aGlsZSB0byByZWFsaXplIHRoYXQgZm9yY2luZyBhIGdhcCBjcmVhdGVzIGEgbmV3 IHN0YXJ0aW5nDQpwb2ludCBmb3IgdGhlIG5leHQgbWVzc2FnZSB0aGF0IGZvcmNlcyB0aGUgcmVj aXBpZW50IHRvIHJlY29nbml6ZSBhbmQNCmRlYWwgd2l0aC4gIEhvd2V2ZXIsIHRoZSBsb2dpYyBm b3IgaWRlbnRpZnlpbmcgdGhhdCBpcyBqdXN0IGhhcmQgYW5kDQppdCdzIGFuIHVubmVjZXNzYXJ5 IGltcG9zaXRpb24gaW4gbXkgdmlldy4NCg0KU2F5IEkgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBhIGxl bmd0aCBvZiAxMCBhbmQgb25seSB0d28gb2N0ZXRzIG1ha2UgaXQNCm9udG8gdGhlIHdpcmUgKGFz IHdpdGggeW91ciBleGFtcGxlKSwgdGhlbiBpdCBpcyBpbW1lZGlhdGVseQ0KYWJhbmRvbmVkLiAg WW91ciBzb2x1dGlvbiB3b3VsZCBoYXZlIHRoZSBFWFBJUkVEX1NUUkVBTV9EQVRBIGZvcmNlIGEN CmdhcCBhZnRlciB0aGUgc2Vjb25kIG9jdGV0LCBzbyB0aGF0IHRoZSBuZXh0IG1lc3NhZ2UgY291 bGQgc3RhcnQgYXQNCm9mZnNldCAzIHJhdGhlciB0aGFuIG9mZnNldCAxMC4gIFRoYXQgc2F2ZXMg dGhlIHJlbWFpbmluZyA3IG9jdGV0cyBvZg0KZmxvdyBjb250cm9sIGNyZWRpdC4gIChVc2UgYmln Z2VyIG51bWJlcnMgYW5kIHBlcmhhcHMgaXQgc2VlbXMgbW9yZQ0KbW90aXZhdGluZykuDQoNCklm IHRoZSBvY3RldHMgdGhhdCBjb3ZlciB0aGUgZ2FwIHdlcmUgc2VudCwgdGhlbiB5b3UgaGF2ZSBh IHByb2JsZW0NCmJlY2F1c2Ugbm93IHlvdSBoYXZlIHNlbnQgdHdvIHZlcnNpb25zIG9mIHRoZSBz YW1lIG9jdGV0cywgc28geW91IGNhbg0Kb25seSBkbyB0aGlzIGlmIHRoZSBvY3RldHMgd2VyZSBu ZXZlciBzZW50LiAgSXQgc3RhcnRzIHRvIGdldCBjbG9zZXINCmFuZCBjbG9zZXIgdG8gdGhlIHBv aW50IHdoZXJlIGEgbmV3IHN0cmVhbSBpcyBqdXN0IGVhc2llci4NCg0KV29yc3QsIEkgdGhpbmsg aXMgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIHRvIGhhdmUgY29tcGxpY2F0ZWQgbG9naWMgZm9yDQpp ZGVudGlmeWluZyB0aGF0IGEgZ2FwIGV4aXN0cyBhbmQgZGVhbGluZyB3aXRoIGl0LiAgSXQgaGFz IHRvIHJlYWQgdXANCnRvIHdoYXQgaXQgaGFzLCBvYnNlcnZlIHRoYXQgdGhlIGRhdGEgaGFzIGV4 cGlyZWQsIHRoZW4gbGVhcm4gd2hlcmUNCnRoZSBnYXAgZW5kcywgdGhlbiByZXN5bmNocm9uaXpl IGJhc2VkIG9uIDErZ2FwX2VuZCBmb3IgdGhlIG5leHQNCm1lc3NhZ2UuDQoNCkJldHRlciB0byBl YXQgdGhlIGZsb3cgY29udHJvbCBjb3N0IGluIG15IHZpZXcuICBPciBzZW5kIFJTVF9TVFJFQU0N CmFuZCBtYWtlIGFub3RoZXIgc3RyZWFtLg0KT24gVGh1LCBNYXkgMzEsIDIwMTggYXQgODo0OCBB TSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVl Zm91LmJlPj4gd3JvdGU6DQo+DQo+IEkgZmluZCB0aGUgb25lIG9jdGV0IGdhcCBhIGJpdCBjb25m dXNpbmcsIGJ1dCBhcyBJIHRoaW5rIGFib3V0IGl0LCBJIHNlZSB3aHkgeW91IG5lZWQgaXQuICBJ ZiBhbGwgdGhlIHN0cmVhbSBkYXRhIGFycml2ZWQgc3VjY2Vzc2Z1bGx5IChidXQgaGFkbuKAmXQg YmVlbiBhY2tub3dsZWRnZWQgeWV0IGR1ZSB0byBsb3NzIG9mIHRoZSBBQ0ssIGRlbGF5LCBldGMu KSBhbmQgdGhlIEVYUElSRURfU1RSRUFNX0RBVEEgZ2V0cyBsb3N0LCB0aGUgcmVjZWl2ZXIgY2Fu IG9ubHkgcmV0cm9hY3RpdmVseSByZWFsaXplIHRoZXJlIHdhcyBhIGp1bXAuICBIYXZpbmcgYW4g b2N0ZXQgdGhhdCBpcyBuZXZlciB0cmFuc21pdHRlZCBlbnN1cmVzIHRoZSByZWNlaXZlciBhY3R1 YWxseSBzZWVzIGEgZ2FwLCB3aGljaCBtZWFucyB0aGF0IGFuIGluLW9yZGVyIEFQSSB3aWxsIG5v dCBwcm9jZWVkIHVudGlsIGl0IGhhcyByZWNlaXZlZCBlaXRoZXIgdGhlIG1pc3Npbmcgb2N0ZXQg b3IgYW4gRVhQSVJFRF9TVFJFQU1fREFUQSBpbmZvcm1pbmcgaXQgdGhlIG9jdGV0IHdpbGwgbmV2 ZXIgYXJyaXZlLg0KPg0KPg0KPg0KPiBUaGlzIHNpbXBsaWZpY2F0aW9uICh2ZXJzdXMgLTAyKSBj b21lcyBhdCBhIHByaWNlOiAgSWYgYW4gQVBJIHdlcmUgZXhwb3Npbmcgc3RyZWFtIGRhdGEgb3V0 LW9mLW9yZGVyLCB0aGVuIGluIHlvdXIgZXhhbXBsZSwgdGhlIHJlY2VpdmVyIGtub3dzIHRoYXQg YSBtZXNzYWdlIGFsd2F5cyBiZWdpbnMgb24gYSB0ZW4tYnl0ZSBib3VuZGFyeS4gIEEgcmVjZWl2 ZXIgY2FuIG5vIGxvbmdlciBmaW5kIHRlbi1ieXRlIGJvdW5kYXJpZXMsIGJlY2F1c2UgdGhlIG9m ZnNldCBvbiB0aGUgcmVhZCBzaWRlIGRvZXNu4oCZdCBtYXRjaCB0aGUgb2Zmc2V0IG9uIHRoZSBz ZW5kIHNpZGUuICBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBzZWVtcyBsaWtlIGEgcmVhc29u YWJsZSB0cmFkZS1vZmYgZm9yIHRoZSBzaW1wbGVyIGZsb3cgY29udHJvbC4NCj4NCj4NCj4NCj4g T25lIGNvbmZsaWN0IEkgc2VlIGluIHRoZSBkb2M6DQo+DQo+IMK3ICAgICAgICAgU2VjdGlvbiAz IHNheXM6ICBSZWNlaXB0IG9mIGFuIEVYUElSRURfU1RSRUFNX0RBVEEgZG9lcyBub3QgYWR2YW5j ZSB0aGUgbGFyZ2VzdCByZWNlaXZlZCBvZmZzZXQgZm9yIHRoZSBzdHJlYW0uDQo+DQo+IFNlY3Rp b24gNSBzYXlzOiAgQSByZWNlaXZlciBTSE9VTEQgZGlzY2FyZCBhbnkgc3RyZWFtIGRhdGEgcmVj ZWl2ZWQgZm9yIGFuIG9mZnNldCBzbWFsbGVyIHRoYW4gdGhlIG5ldyBzbWFsbGVzdCByZWNlaXZl IG9mZnNldCwgcG9zc2libHkgYWR2YW5jaW5nIHRoZSBsYXJnZXN0IHJlY2VpdmVkIG9mZnNldCBm b3IgdGhlIHN0cmVhbS4NCj4NCj4NCj4NCj4gT3RoZXIgbWlub3Igbml0cyBhcmUgYmV0dGVyIGRv bmUgdmlhIFBSLg0KPg0KPiBGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBMdWJhc2hldiwgSWdvcg0KPiBT ZW50OiBXZWRuZXNkYXksIE1heSAzMCwgMjAxOCA5OjQ1IEFNDQo+IFRvOiBRVUlDIFdHIDxxdWlj QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NCj4gU3ViamVjdDogUGFydGlhbGx5IFJl bGlhYmxlIE1lc3NhZ2UgU3RyZWFtDQo+DQo+DQo+DQo+IEnigJl2ZSBqdXN0IHVwbG9hZGVkIGEg bmV3IGRyYWZ0IGZvciBwYXJ0aWFsbHkgcmVsaWFibGUgUVVJQyBzdHJlYW1zLiAgTm90ZTogdGhp cyBmZWF0dXJlIGlzIGxpa2VseSBub3QgaW4gc2NvcGUgZm9yIFYxLCBidXQgaXQgY2FuIGJlIGFu IGV4dGVuc2lvbiBmb3IgVjEgYW5kL29yIGEgcGFydCBvZiBWMi4NCj4NCj4NCj4NCj4gVGhlIG5l dyB2ZXJzaW9uIDAzIChodHRwczovL3VybGRlZmVuc2UuLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEbHViYXNoZXYtMkRxdWljLTJE cGFydGlhbC0yRHJlbGlhYmlsaXR5LTJEMDMmZD1Ed0lGYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIz TVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPXl5UnBiZTE0a1RZZ1k0MTNnalZrT2FsV0Vf VUMzeFllcktwSnFTOEhpUW8mcz1YWjI5NXhpWnNOMTF5UDhHTGNkTXMxamY3ejBiMl9XaGlJeE1M TG9yWlhvJmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGx1YmFzaGV2LTJEcXVpYy0yRHBhcnRp YWwtMkRyZWxpYWJpbGl0eS0yRDAzJmQ9RHdJRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZy PUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmbT15eVJwYmUxNGtUWWdZNDEzZ2pWa09hbFdFX1VDM3hZ ZXJLcEpxUzhIaVFvJnM9WFoyOTV4aVpzTjExeVA4R0xjZE1zMWpmN3owYjJfV2hpSXhNTExvclpY byZlPT4pIG5vIGxvbmdlciBuZWVkcyBjb21wbGV4IGZsb3cgY29udHJvbCBjaGFuZ2VzIGFuZCBy ZW1vdmVzIHRoZSBuZWVkIHRvIHRyYW5zbWl0IG11bHRpcGxlIGZyYW1lcyBpbiB0aGUgc2FtZSBw YWNrZXQuDQo+DQo+DQo+DQo+IElnb3INCj4NCj4NCj4NCj4gUC5TLg0KPg0KPiAgIFRoZXJlIGlz IGFsc28gYSBuZXcgdmVyc2lvbiAwMiwgd2hpY2ggaW5jbHVkZXMgYSBtb3JlIGNvbXBsZXggYWxn b3JpdGhtIHdpdGggbW9yZSBmZWF0dXJlcyBhbmQgZGlmZmVyZW50IHRyYWRlLW9mZnMuICBCdXQg SSB0aGluayB2ZXJzaW9uIDAzIGlzIGEgYmV0dGVyIG1hdGNoIGZvciB0aGUgbmVlZHMgc28gZmFy Lg0KDQo= --_000_FFE07B1FB45A4DA6AFA8059F7DAADBE2fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YW55IG1lc3NhZ2VzIGFyZSBsZXNzIGVmZmljaWVudCBmcm9tIGEgY2FjaGluZyBwZXJzcGVjdGl2 ZSAoY2FjaGVzIHByZWZlciBsYXJnZXIgZmlsZXMgdGhhdCBzdHJlYW0gb3ZlciBsb3RzIG9mIHNt YWxsIHNjYXR0ZXIvZ2F0aGVyKS48YnI+DQpJZiB3ZSBoYWQgYSBub24tSFRUUCBtYXBwaW5nIG9m IHRoZSBuZXR3b3JrIGRhdGEtJmd0O2Rpc2ssIHRoYXQgaXNu4oCZdCBhbiBpc3N1ZSwgYnV0IHRo YXQgd291bGRu4oCZdCBsZXZlcmFnZSBhbnkgb2YgdGhlIGxlYXJuaW5ncyB3ZeKAmXZlIGhhZCBm cm9tIEhUVFAgY2FjaGluZ+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5KYW5hIEl5ZW5n YXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXks IE1heSAzMSwgMjAxOCBhdCAxOjM4IFBNPGJyPg0KPGI+VG86IDwvYj5Sb2JlcnRvIFBlb24gJmx0 O2Zlbml4QGZiLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPk1pa2UgQmlzaG9wICZsdDttYmlzaG9w QGV2ZXF1ZWZvdS5iZSZndDssIE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20mZ3Q7LCBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgJnF1b3Q7THViYXNoZXYs IElnb3ImcXVvdDsgJmx0O2lsdWJhc2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFBhcnRpYWxseSBSZWxpYWJsZSBNZXNzYWdlIFN0cmVh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIG5vdCBrZWVuIHRvIGdldCBpbnRvIHRoZSB3ZWVkcyBvZiB0aGlzIGRpc2N1c3Np b24gYXQgdGhpcyB0aW1lIChhcyB5b3Ugc2F5LCBpdCdzIGZvciB2MiksIGJ1dCBJIHVuZGVyc3Rh bmQgdGhlIG92ZXJhbGwgZGVzaWduLiBBIGZldyBoaWdoZXItb3JkZXIgcG9pbnRzIHdpdGggdGhp cyBkZXNpZ24gZGlyZWN0aW9uOg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xLiBUaGVyZSdzIGNsZWFyIGRlbWFyY2F0aW9uIG9mIGFwcCBtZXNzYWdlcywg YnV0IHRoZXkgYXJlbid0IHJlYWxseSBtYWRlIGZpcnN0IGNsYXNzIGNpdGl6ZW5zLiBJZiB5b3Ug ZGlkIHRoYXQsIEkgaW1hZ2luZSB0aGF0IHlvdSBtaWdodCBoYXZlIGEgc2ltcGxlciBkZXNpZ24u IEZvciBpbnN0YW5jZSwgZGVmaW5lIGEgTVNHX1NUUkVBTSBmcmFtZSwgd2hpY2ggc3VwcG9ydHMg bWVzc2FnZSBzdHJlYW1zIChpbnN0ZWFkDQogb2YgdGhlIGN1cnJlbnQgYnl0ZSBzdHJlYW1zKSwg YW5kIHRoZW4geW91IGNhbiBjYW5jZWwgbWVzc2FnZXMgZWFzaWx5IHdpdGhvdXQgaGF2aW5nIHRv IGRvIHN0cmVhbSBvZmZzZXQgc2hlbmFuaWdhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFlvdXIgZGVzaWduIGhhcyBleGFjdGx5IG9u ZSBvcmRlcmluZyBjYXBhYmlsaXR5LCB3aGljaCBpcyBsaW1pdGluZy4gR2VuZXJhbGx5LCBhcHBz IHRoYXQgY2FuIGRyb3AgbWVzc2FnZXMgYW5kIHJlYWQgc3Vic2VxdWVudCBvbmVzIGFyZSBhbHNv IGNhcGFibGUgb2YgaGFuZGxpbmcgbWVzc2FnZXMgb3V0IG9mIHNlcXVlbmNlLiBZb3UnbGwgd2Fu dCB0byBzdXBwb3J0IHBhcnRpYWwgb3JkZXJpbmcgYXMgd2VsbA0KIGFuZCBub3QgY29uc3RyYWlu IG1lc3NhZ2VzIHRvIGJlIG9ubHkgZGVsaXZlcmVkIGluIHN0cmljdGx5IGxpbmVhciBvcmRlci4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+My4gSSdtIGtlZW4gdG8gc2VlIHdoYXQgd2UgY2FuIGRvIHdpdGggdXNpbmcgc3RyZWFtcyBh cyBtZXNzYWdlcy4gV2UgZG9uJ3QgbmVlZCB0byBwdW50IGV2ZXJ5dGhpbmcgdG8gdGhlIGFwcCAo YXMgeW91ciB0ZXh0IHN1Z2dlc3RzKSwgYnV0IHdlIGNhbiBzdGFydCB3aXRoIGEgZ3JvdXBpbmcg b2Ygc3RyZWFtcyAob3IgbWVzc2FnZXMpIGFuZCBidWlsZGluZyBmbG93IGNvbnRyb2wgbWVjaGFu aXNtcyBmb3IgdGhlc2UNCiBncm91cHMuIEkgc3VzcGVjdCB0aGlzIG1pZ2h0IGJlIGNsZWFuZXIs IGFuZCBpdCBnaXZlcyB5b3UgZmxleGliaWxpdHkgdG8gY29uc2lkZXIgdmFyaW91cyBvcmRlcmlu Z3Mgb2YgbWVzc2FnZXMuIFdoZW4gd2UncmUgY2xvc2VyIHRvIHYyLCBJJ20gaGFwcHkgdG8gc3Bp biB1cCBhIGRyYWZ0IGV4cGxvcmluZyB0aGlzIGRpcmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXkgMzEsIDIwMTgg YXQgODoyMSBBTSwgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMu IFlvdSBtYXkgd2FudCBhIHNpbmdsZSByZXNvdXJjZSBmb3IgYW4gb3V0cHV0IHdoaWNoIHlvdSBt YXkgYmUgZ2VuZXJhdGluZyBpbiBwYXJhbGxlbC4gRXZlbiBpZiBhIHNpbmdsZSB0aHJlYWQgJ293 bnMnIHRoZSBzdHJlYW0sIHlvdSd2ZSBsb3N0IHRoZSBhYmlsaXR5IHRvIGNvb3JkaW5hdGUgdGhl IGRhdGEgaXQgcmVjaWV2ZXMgYnkgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIG9mZnNldC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVudW1i ZXJpbmcgdGhlIG9mZnNldHMgYnJlYWtzIHRoZSBmaWxlLWxpa2UgYWJzdHJhY3Rpb24gd2UndmUg ZWZmZWN0aXZlbHkgdXNlZCBmb3IgaHR0cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV8tNjgxNTM1ODk1NTEwNjgwMTVjb21wb3Nlcl9zaWduYXR1cmUiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29s b3I6IzU3NTc1NyI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFM3LCBhbiBBVCZhbXA7VCA0 RyBMVEUgc21hcnRwaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug LS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZyb206IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVm b3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdGU6IDUv MzAvMTggODozMyBQTSAoR01ULTA4OjAwKSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvOiBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0 bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5mZW5peEBmYi5jb208L2E+Jmd0OywgTWFy dGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ow0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYzogUVVJQyBX RyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWlj QGlldGYub3JnPC9hPiZndDssICZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNo ZT08YSBocmVmPSJtYWlsdG86NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsNCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogUkU6IFBhcnRp YWxseSBSZWxpYWJsZSBNZXNzYWdlIFN0cmVhbSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdCB0byBiZSBjbGVhcuKApi4m bmJzcDsgWW914oCZcmUgc3VnZ2VzdGluZyBtdWx0aXBsZSB0aHJlYWRzIHRoYXQgd291bGQgYmUg d3JpdGluZyB0byBhIHNpbmdsZSBzdHJlYW0gaW4gcGFyYWxsZWwsIHJhdGhlciB0aGFuIGEgc2lu Z2xlIHRocmVhZCDigJxvd25pbmfigJ0gdGhlIHN0cmVhbT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9i ZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZmVuaXhAZmIuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1h eSAzMCwgMjAxOCA2OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBl dmVxdWVmb3UuYmU8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzpt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs7 IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZT08YSBocmVmPSJtYWlsdG86NDBha2FtYWkuY29t QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBha2FtYWkuY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhcnRpYWxseSBSZWxpYWJsZSBN ZXNzYWdlIFN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkkgZmluZCBpdCBjb25mdXNpbmcgYXMgd2VsbC4mbmJzcDsgSSBm YXIgcHJlZmVyIGtlZXBpbmcgdGhlIG9mZnNldHMgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGFz IGl0IGFsbG93cyBmb3IgcmVhbC13b3JsZCB1c2Ugb2YgYSBwYXJ0aWFsbHkNCiByZWxpYWJsZSBz dHJlYW0gKHdoZXJlIHlvdSBtYXkgbm90IHJlY2lldmUgdGhhdCBkYXRhIGJ1dCB5b3UgY2FuIGF0 IGxlYXN0IGZpZ3VyZSBvdXQgd2hhdCB5b3UgZGlkIGdldCBhbmQgaW50ZXJwcmV0IGl0KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkkgZG9udCBrbm93IGhvdyBvbmUgd29odWQgcmVzb2x2ZSB0aGUg cmFjZSBldmVuIHdpdGhpbiB0aGUgc2VuZGluZyBhcHBsaWNhdGlvbiAtLSBvbmUgdGhyZWFkIHNl bmRzLCBhbm90aGVyIHRocmVhZCBzZW5kcyB3aGlsZQ0KIHRoZSBmaXJzdCBzYXlzIHRvIGZvcmdl dCBhYm91dCBzdHVmZi4gSSBkb250IGtub3cgd2hhdCBvZmZzZXQgc3R1ZmYgZW5kcyB1cCBhdCBp biBzdWNoIGNhc2VzLCBhbmQgc28gSSBjYW5ub3QgZnJhbWUgZGF0YSBpbiBhIHdheSB0aGF0IGlz IG5vbi1zeW5jaHJvbm91cy4gVGhhdCBkZWZlYXRzIHNvbWUgb2YgdGhlIG1haW4gcmVhc29ucyB0 byBkbyBwYXJ0aWFsIHJlbGlhYmlsaXR5IChpLmUuIHRvIHJlZHVjZSBqaXR0ZXIpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkRyYWZ0IDAyIHNlZW1lZCB0byBiZSBnb2luZyBpbiBhIGJldHRlciBkaXJlY3Rpb24gdy5yLnQg dGhlIHVzZWNhc2VzIGkgY2FuIGNvbmNlaXZlIG9mLiBJIHRoaW5rIHJld2luZGluZyB0byB0aGF0 IGFuZCB0aGVuIHBvdGVudGlhbGx5DQogZmlndXJpbmcgb3V0IGhvdyB0byBzaW1wbGlmeSBpdCB3 b3VsZCBiZSBmdW4hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSdtIGV4Y2l0ZWQgdG8gaGF2ZSB0aGlzIGJlaW5n IGRpc2N1c3NlZCwgc2luY2UgdGhlcmUgaXMgcGVudCB1cCBkZW1hbmQgdG8gdXNlIGl0IGFscmVh ZHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+LT1SPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkdldA0KPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19ha2EubXNfZ2hl aTM2JmFtcDtkPUR3TUZBZyZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUMwc1Vv LUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209Vk9Val9NbndXZl9QZ2RIdmNHVjFTZTFvM2s1akM4bThu b0tEaXhxOEhxQSZhbXA7cz0teEpiX0pXT2RMX0RwRE00M0UwNlM1NExQRS14a3BZa1NlbjRFbC13 a1M0JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KT3V0bG9vayBmb3IgQW5kcm9pZDwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNp emU9IjAiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t NjgxNTM1ODk1NTEwNjgwMTV4X2RpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiBRVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIE1hcnRpbg0KIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAzMCwgMjAxOCA1OjUwOjU5 IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcDxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRzsg THViYXNoZXYsIElnb3I8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhcnRpYWxseSBSZWxpYWJs ZSBNZXNzYWdlIFN0cmVhbTwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pkxpa2UgTWlrZSwgSSBmaW5kIHRoaXMgZ2FwIHRoaW5nIGNvbmZ1c2luZy4mbmJzcDsgQW5kIE1p a2UncyBtZXNzYWdlPGJyPg0KaGVscGVkLCBidXQgbm90IGEgbG90Ljxicj4NCjxicj4NCkl0IHRv b2sgYSB3aGlsZSB0byByZWFsaXplIHRoYXQgZm9yY2luZyBhIGdhcCBjcmVhdGVzIGEgbmV3IHN0 YXJ0aW5nPGJyPg0KcG9pbnQgZm9yIHRoZSBuZXh0IG1lc3NhZ2UgdGhhdCBmb3JjZXMgdGhlIHJl Y2lwaWVudCB0byByZWNvZ25pemUgYW5kPGJyPg0KZGVhbCB3aXRoLiZuYnNwOyBIb3dldmVyLCB0 aGUgbG9naWMgZm9yIGlkZW50aWZ5aW5nIHRoYXQgaXMganVzdCBoYXJkIGFuZDxicj4NCml0J3Mg YW4gdW5uZWNlc3NhcnkgaW1wb3NpdGlvbiBpbiBteSB2aWV3Ljxicj4NCjxicj4NClNheSBJIHNl bmQgYSBtZXNzYWdlIHdpdGggYSBsZW5ndGggb2YgMTAgYW5kIG9ubHkgdHdvIG9jdGV0cyBtYWtl IGl0PGJyPg0Kb250byB0aGUgd2lyZSAoYXMgd2l0aCB5b3VyIGV4YW1wbGUpLCB0aGVuIGl0IGlz IGltbWVkaWF0ZWx5PGJyPg0KYWJhbmRvbmVkLiZuYnNwOyBZb3VyIHNvbHV0aW9uIHdvdWxkIGhh dmUgdGhlIEVYUElSRURfU1RSRUFNX0RBVEEgZm9yY2UgYTxicj4NCmdhcCBhZnRlciB0aGUgc2Vj b25kIG9jdGV0LCBzbyB0aGF0IHRoZSBuZXh0IG1lc3NhZ2UgY291bGQgc3RhcnQgYXQ8YnI+DQpv ZmZzZXQgMyByYXRoZXIgdGhhbiBvZmZzZXQgMTAuJm5ic3A7IFRoYXQgc2F2ZXMgdGhlIHJlbWFp bmluZyA3IG9jdGV0cyBvZjxicj4NCmZsb3cgY29udHJvbCBjcmVkaXQuJm5ic3A7IChVc2UgYmln Z2VyIG51bWJlcnMgYW5kIHBlcmhhcHMgaXQgc2VlbXMgbW9yZTxicj4NCm1vdGl2YXRpbmcpLjxi cj4NCjxicj4NCklmIHRoZSBvY3RldHMgdGhhdCBjb3ZlciB0aGUgZ2FwIHdlcmUgc2VudCwgdGhl biB5b3UgaGF2ZSBhIHByb2JsZW08YnI+DQpiZWNhdXNlIG5vdyB5b3UgaGF2ZSBzZW50IHR3byB2 ZXJzaW9ucyBvZiB0aGUgc2FtZSBvY3RldHMsIHNvIHlvdSBjYW48YnI+DQpvbmx5IGRvIHRoaXMg aWYgdGhlIG9jdGV0cyB3ZXJlIG5ldmVyIHNlbnQuJm5ic3A7IEl0IHN0YXJ0cyB0byBnZXQgY2xv c2VyPGJyPg0KYW5kIGNsb3NlciB0byB0aGUgcG9pbnQgd2hlcmUgYSBuZXcgc3RyZWFtIGlzIGp1 c3QgZWFzaWVyLjxicj4NCjxicj4NCldvcnN0LCBJIHRoaW5rIGlzIHRoYXQgdGhlIHJlY2VpdmVy IGhhcyB0byBoYXZlIGNvbXBsaWNhdGVkIGxvZ2ljIGZvcjxicj4NCmlkZW50aWZ5aW5nIHRoYXQg YSBnYXAgZXhpc3RzIGFuZCBkZWFsaW5nIHdpdGggaXQuJm5ic3A7IEl0IGhhcyB0byByZWFkIHVw PGJyPg0KdG8gd2hhdCBpdCBoYXMsIG9ic2VydmUgdGhhdCB0aGUgZGF0YSBoYXMgZXhwaXJlZCwg dGhlbiBsZWFybiB3aGVyZTxicj4NCnRoZSBnYXAgZW5kcywgdGhlbiByZXN5bmNocm9uaXplIGJh c2VkIG9uIDEmIzQzO2dhcF9lbmQgZm9yIHRoZSBuZXh0PGJyPg0KbWVzc2FnZS48YnI+DQo8YnI+ DQpCZXR0ZXIgdG8gZWF0IHRoZSBmbG93IGNvbnRyb2wgY29zdCBpbiBteSB2aWV3LiZuYnNwOyBP ciBzZW5kIFJTVF9TVFJFQU08YnI+DQphbmQgbWFrZSBhbm90aGVyIHN0cmVhbS48YnI+DQpPbiBU aHUsIE1heSAzMSwgMjAxOCBhdCA4OjQ4IEFNIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWls dG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZv dS5iZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZmluZCB0aGUgb25lIG9j dGV0IGdhcCBhIGJpdCBjb25mdXNpbmcsIGJ1dCBhcyBJIHRoaW5rIGFib3V0IGl0LCBJIHNlZSB3 aHkgeW91IG5lZWQgaXQuJm5ic3A7IElmIGFsbCB0aGUgc3RyZWFtIGRhdGEgYXJyaXZlZCBzdWNj ZXNzZnVsbHkgKGJ1dCBoYWRu4oCZdCBiZWVuIGFja25vd2xlZGdlZCB5ZXQgZHVlIHRvIGxvc3Mg b2YgdGhlIEFDSywgZGVsYXksIGV0Yy4pIGFuZCB0aGUgRVhQSVJFRF9TVFJFQU1fREFUQSBnZXRz IGxvc3QsIHRoZSByZWNlaXZlcg0KIGNhbiBvbmx5IHJldHJvYWN0aXZlbHkgcmVhbGl6ZSB0aGVy ZSB3YXMgYSBqdW1wLiZuYnNwOyBIYXZpbmcgYW4gb2N0ZXQgdGhhdCBpcyBuZXZlciB0cmFuc21p dHRlZCBlbnN1cmVzIHRoZSByZWNlaXZlciBhY3R1YWxseSBzZWVzIGEgZ2FwLCB3aGljaCBtZWFu cyB0aGF0IGFuIGluLW9yZGVyIEFQSSB3aWxsIG5vdCBwcm9jZWVkIHVudGlsIGl0IGhhcyByZWNl aXZlZCBlaXRoZXIgdGhlIG1pc3Npbmcgb2N0ZXQgb3IgYW4gRVhQSVJFRF9TVFJFQU1fREFUQQ0K IGluZm9ybWluZyBpdCB0aGUgb2N0ZXQgd2lsbCBuZXZlciBhcnJpdmUuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHNpbXBsaWZpY2F0aW9uICh2ZXJzdXMgLTAy KSBjb21lcyBhdCBhIHByaWNlOiZuYnNwOyBJZiBhbiBBUEkgd2VyZSBleHBvc2luZyBzdHJlYW0g ZGF0YSBvdXQtb2Ytb3JkZXIsIHRoZW4gaW4geW91ciBleGFtcGxlLCB0aGUgcmVjZWl2ZXIga25v d3MgdGhhdCBhIG1lc3NhZ2UgYWx3YXlzIGJlZ2lucyBvbiBhIHRlbi1ieXRlIGJvdW5kYXJ5LiZu YnNwOyBBIHJlY2VpdmVyIGNhbiBubyBsb25nZXIgZmluZCB0ZW4tYnl0ZSBib3VuZGFyaWVzLCBi ZWNhdXNlDQogdGhlIG9mZnNldCBvbiB0aGUgcmVhZCBzaWRlIGRvZXNu4oCZdCBtYXRjaCB0aGUg b2Zmc2V0IG9uIHRoZSBzZW5kIHNpZGUuJm5ic3A7IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlz IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHRyYWRlLW9mZiBmb3IgdGhlIHNpbXBsZXIgZmxvdyBj b250cm9sLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIGNvbmZs aWN0IEkgc2VlIGluIHRoZSBkb2M6PGJyPg0KJmd0Ozxicj4NCiZndDsgwrcmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiAzIHNheXM6Jm5ic3A7 IFJlY2VpcHQgb2YgYW4gRVhQSVJFRF9TVFJFQU1fREFUQSBkb2VzIG5vdCBhZHZhbmNlIHRoZSBs YXJnZXN0IHJlY2VpdmVkIG9mZnNldCBmb3IgdGhlIHN0cmVhbS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTZWN0aW9uIDUgc2F5czombmJzcDsgQSByZWNlaXZlciBTSE9VTEQgZGlzY2FyZCBhbnkgc3Ry ZWFtIGRhdGEgcmVjZWl2ZWQgZm9yIGFuIG9mZnNldCBzbWFsbGVyIHRoYW4gdGhlIG5ldyBzbWFs bGVzdCByZWNlaXZlIG9mZnNldCwgcG9zc2libHkgYWR2YW5jaW5nIHRoZSBsYXJnZXN0IHJlY2Vp dmVkIG9mZnNldCBmb3IgdGhlIHN0cmVhbS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IE90aGVyIG1pbm9yIG5pdHMgYXJlIGJldHRlciBkb25lIHZpYSBQUi48YnI+DQom Z3Q7PGJyPg0KJmd0OyBGcm9tOiBRVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg T24gQmVoYWxmIE9mIEx1YmFzaGV2LCBJZ29yPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1h eSAzMCwgMjAxOCA5OjQ1IEFNPGJyPg0KJmd0OyBUbzogUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7IFN1YmplY3Q6IFBhcnRpYWxseSBSZWxpYWJsZSBNZXNzYWdlIFN0cmVhbTxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSeKAmXZlIGp1c3QgdXBsb2FkZWQg YSBuZXcgZHJhZnQgZm9yIHBhcnRpYWxseSByZWxpYWJsZSBRVUlDIHN0cmVhbXMuJm5ic3A7IE5v dGU6IHRoaXMgZmVhdHVyZSBpcyBsaWtlbHkgbm90IGluIHNjb3BlIGZvciBWMSwgYnV0IGl0IGNh biBiZSBhbiBleHRlbnNpb24gZm9yIFYxIGFuZC9vciBhIHBhcnQgb2YgVjIuPGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgbmV3IHZlcnNpb24gMDMgKDxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGx1YmFzaGV2LTJEcXVpYy0yRHBhcnRpYWwtMkRyZWxp YWJpbGl0eS0yRDAzJmFtcDtkPUR3SUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFt cDtyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209eXlScGJlMTRrVFlnWTQxM2dqVmtPYWxX RV9VQzN4WWVyS3BKcVM4SGlRbyZhbXA7cz1YWjI5NXhpWnNOMTF5UDhHTGNkTXMxamY3ejBiMl9X aGlJeE1MTG9yWlhvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS4u cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJh ZnQtMkRsdWJhc2hldi0yRHF1aWMtMkRwYXJ0aWFsLTJEcmVsaWFiaWxpdHktMkQwMyZhbXA7ZD1E d0lGYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9h Q3NmNlRBJmFtcDttPXl5UnBiZTE0a1RZZ1k0MTNnalZrT2FsV0VfVUMzeFllcktwSnFTOEhpUW8m YW1wO3M9WFoyOTV4aVpzTjExeVA4R0xjZE1zMWpmN3owYjJfV2hpSXhNTExvclpYbyZhbXA7ZT08 L2E+KQ0KIG5vIGxvbmdlciBuZWVkcyBjb21wbGV4IGZsb3cgY29udHJvbCBjaGFuZ2VzIGFuZCBy ZW1vdmVzIHRoZSBuZWVkIHRvIHRyYW5zbWl0IG11bHRpcGxlIGZyYW1lcyBpbiB0aGUgc2FtZSBw YWNrZXQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZ29yPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQLlMuPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsgVGhlcmUgaXMgYWxzbyBhIG5ldyB2ZXJzaW9uIDAyLCB3aGljaCBpbmNs dWRlcyBhIG1vcmUgY29tcGxleCBhbGdvcml0aG0gd2l0aCBtb3JlIGZlYXR1cmVzIGFuZCBkaWZm ZXJlbnQgdHJhZGUtb2Zmcy4mbmJzcDsgQnV0IEkgdGhpbmsgdmVyc2lvbiAwMyBpcyBhIGJldHRl ciBtYXRjaCBmb3IgdGhlIG5lZWRzIHNvIGZhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FFE07B1FB45A4DA6AFA8059F7DAADBE2fbcom_-- From nobody Sat Jun 2 17:45:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7072312DA04 for ; Sat, 2 Jun 2018 17:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=bSIUTEtl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mX/9zRpS 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 ITIRoZWpkdj7 for ; Sat, 2 Jun 2018 17:45:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B32120454 for ; Sat, 2 Jun 2018 17:45:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2144F20FE0 for ; Sat, 2 Jun 2018 20:45:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 02 Jun 2018 20:45:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yYiKPuoo/uZFuQ7pi 2JV/oQOqP0Gh5Td9Cro9MC3Fxo=; b=bSIUTEtlXezqatWnKeJaD6de/XMvyXhjT cLnxaFEeiYyv7sQ00Tu6e4AMs4Xm/b5DynNQtweIbP5uvhF9jZtVDKV2+Vu9xBXH uW15Qejqkl+GcbK8cgEDBJxisHGfDzd5aht2oHCSYvBQvSiqPaQhh6ng7KKcHhY6 sbhCmiPHq6rwUgLSXkQqh4MLDlX+AxqK/v6bEQ4K5xrs/I2lLsLjRjUoecsiCOsh K9A6ay99C+Km97QO5iEEe5P+gjJ6XJ3mxD8g5SbzqVujePQRtxIanyAgJFbyUgUl TyA9wRXHvkyPlhk4ipikgjgQ2kKivFAeIFwNQxakcgakPffyXzxDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=yYiKPuoo/uZFuQ7pi2JV/oQOqP0Gh5Td9Cro9MC3Fxo=; b=mX/9zRpS J7G74FGDarwC19z4WYRmedew5kBV4PRemI0DLf8dhZGFof6mCUhdb6x/roj+hw2a bqXBWYNra9etM3EpKS1jk3gf1IPyyXGOxitb1n6k7nS2zm9utemvTyE+ctKvCPF0 JFghPuMNan6kEdVrANiKftDhevXCbInlH+ivW3qGcgas36te/q2eBeJ6Qql52jjO F8SAlSAofut6mRysTHDapVSigmmlCoYnoiMaxiDZK/mZk/kaWm3YEkUp11X8QmJD 4Pst71fJC+CJ2Qj+FDUvgzYQFnYn/vX5AYK6IpJpbMFuIL9wceA302c7Bch4MDni TKyEWshE9bEJqQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id EAD8FE4154 for ; Sat, 2 Jun 2018 20:45:17 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 6877BC03E5 for ; Sun, 3 Jun 2018 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8065969482780776499==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180603004515.6877BC03E5@cloud.mnot.net> Date: Sun, 3 Jun 2018 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 00:45:24 -0000 --===============8065969482780776499== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+5/-4/=F0=9F=92=AC24) 5 issues created: - qpack: "all" header blocks the decoder started reading (by dtikhonov) https://github.com/quicwg/base-drafts/issues/1409 = - Handling of duplicate packets (by gloinul) https://github.com/quicwg/base-drafts/issues/1405 = - Largest Reference too big (by martinthomson) https://github.com/quicwg/base-drafts/issues/1404 [-qpack] [design] = - quic_transport_parameters code point (by seanturner) https://github.com/quicwg/base-drafts/issues/1395 [-tls] = - build broken for draft-ietf-quic-qpack.md (by reschke) https://github.com/quicwg/base-drafts/issues/1394 = 9 issues received 24 new comments: - #1404 Largest Reference too big (7 by martinthomson, afrind, MikeBishop) https://github.com/quicwg/base-drafts/issues/1404 [-qpack] [design] = - #1405 Handling of duplicate packets (7 by kazuho, MikeBishop, martintho= mson, ianswett) https://github.com/quicwg/base-drafts/issues/1405 [-transport] [design] = - #718 Retain use of SETTINGS_ENABLE_PUSH (3 by martinthomson, MikeBishop) https://github.com/quicwg/base-drafts/issues/718 [-http] [design] [park= ed] = - #1370 Implicitly acknowledging table updates by acknowleding header blo= cks (2 by martinthomson, afrind) https://github.com/quicwg/base-drafts/issues/1370 [-qpack] [design] = - #1387 5.6 Packet Number Protection is hard to follow (1 by martinthomso= n) https://github.com/quicwg/base-drafts/issues/1387 [-tls] [design] = - #1394 build broken for draft-ietf-quic-qpack.md (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1394 = - #1296 Packet number transform should be negotiated (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1296 [-transport] [design] = - #1362 Swap largest reference and base indices (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1362 [-qpack] [design] = - #1395 quic_transport_parameters code point (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1395 [-tls] = 4 issues closed: - Swap largest reference and base indices https://github.com/quicwg/base-= drafts/issues/1362 [-qpack] [design] = - No generic error codes https://github.com/quicwg/base-drafts/issues/139= 1 [-http] [design] = - build broken for draft-ietf-quic-qpack.md https://github.com/quicwg/bas= e-drafts/issues/1394 = - 5.6 Packet Number Protection is hard to follow https://github.com/quicw= g/base-drafts/issues/1387 = Pull requests ------------- * quicwg/base-drafts (+10/-6/=F0=9F=92=AC22) 10 pull requests submitted: - qpack: move link to absolute-index to 1st Largest Reference mention (by= dtikhonov) https://github.com/quicwg/base-drafts/pull/1408 = - Add missing words (by ghedo) https://github.com/quicwg/base-drafts/pull/1407 = - Clarify 'packet protection' -> 'packet number protection' (by ghedo) https://github.com/quicwg/base-drafts/pull/1406 = - Set TLS extension codepoint to 0xffa5 (by martinthomson) https://github.com/quicwg/base-drafts/pull/1402 = - Dynamic table resize doesn't get acknowledged (by martinthomson) https://github.com/quicwg/base-drafts/pull/1401 = - Acknowledge stream resets too (by martinthomson) https://github.com/quicwg/base-drafts/pull/1400 = - Remove Flags (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1398 [-http] [design] = - Add general protocol error (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1397 [-http] [design] = - fix incorrect AES key length in the example (should be 16, not 12) (by = kazuho) https://github.com/quicwg/base-drafts/pull/1396 = - Retransmit stream data, not stream frames (by martinthomson) https://github.com/quicwg/base-drafts/pull/1393 = 8 pull requests received 22 new comments: - #1359 Unidirectional Stream Headers in HTTP (7 by martinthomson, LPardu= e, MikeBishop) https://github.com/quicwg/base-drafts/pull/1359 [-http] [-qpack] [desig= n] = - #1406 Clarify 'packet protection' -> 'packet number protection' (5 by m= artinthomson, ghedo, mikkelfj) https://github.com/quicwg/base-drafts/pull/1406 = - #1346 Stateless reset fixes (3 by Pascalh2001, mikkelfj, MikeBishop) https://github.com/quicwg/base-drafts/pull/1346 [-transport] = - #1393 Retransmit stream data, not stream frames (2 by martinthomson, ia= nswett) https://github.com/quicwg/base-drafts/pull/1393 = - #1399 Implicit acknowledgment via header block acknowledgment (2 by mar= tinthomson, MikeBishop) https://github.com/quicwg/base-drafts/pull/1399 [-qpack] = - #1372 Proposal for adding ECN support to QUIC. (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1372 = - #1301 make payload length 0 special (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1301 = - #1400 Acknowledge stream resets too (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1400 = 6 pull requests merged: - qpack: move link to absolute-index to 1st Largest Reference mention https://github.com/quicwg/base-drafts/pull/1408 = - Clarify 'packet protection' -> 'packet number protection' https://github.com/quicwg/base-drafts/pull/1406 = - Add general protocol error https://github.com/quicwg/base-drafts/pull/1397 [-http] [design] = - fix incorrect AES key length in the example (should be 16, not 12) https://github.com/quicwg/base-drafts/pull/1396 = - Retransmit stream data, not stream frames https://github.com/quicwg/base-drafts/pull/1393 = - Make the packet number encryption sampling clearer https://github.com/quicwg/base-drafts/pull/1389 [-tls] [-transport] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============8065969482780776499== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 03, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+5/-4/=F0=9F=92=AC24)

5 issues created:

9 issues received 24 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+10/-6/=F0=9F=92=AC22)

10 pull requests submitted:

8 pull requests received 22 new comments:

6 pull requests merged:

Repositories tracked by this digest:

--===============8065969482780776499==-- From nobody Tue Jun 5 23:40:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0789130EB5 for ; Tue, 5 Jun 2018 23:40:10 -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, 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 Kscy1A93h4Th for ; Tue, 5 Jun 2018 23:40:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D609D130EAC for ; Tue, 5 Jun 2018 23:40:06 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fQS70-00047X-OW for quic@ietf.org; Wed, 06 Jun 2018 08:40:04 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fQS6v-0002UI-W7 for quic@ietf.org; Wed, 06 Jun 2018 02:39:58 -0400 Received: (qmail 23228 invoked from network); 6 Jun 2018 06:39:56 -0000 Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.104]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Jun 2018 06:39:55 -0000 To: IETF QUIC WG From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> Date: Tue, 5 Jun 2018 23:39:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Implicit ACK and Client Finished X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5geVdWmufozmnxJAguvZAT5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViKuEqr/cCH4Nk1RFWptmSfs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYWaemK1ACLD7XuAckzwPC4rxRCZf4woRA Eo2C8wq9PB1z1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqz6Jnv65JqzoprPQQCAlAFYE7tCqypI5WX0qWh4YQLDMPM71MWmKA16n wwGIHZwUbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLUKQCrMv/Srp/VLqDjjh0L1QKHY 6H+wSCoVvwvquzDDiPkKIKnisj+1ZHYjRAh7nr2Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 06:40:12 -0000 During the QUIC interop yesterday, there was a discussion of the proposed implicit ACK of the "client finished" message, during the transition from handshake to 1rtt protection. The sequence that we envisage goes like that: <--- Server sends last message in server flight (server finished), protected with Handshake key, sequence number A <--- Server sends first 1-RTT protected message (really, 0.5RTT), protected with 1 RTT key, sequence number B ---> Client sends last message in client second flight (client finished), protected with Handshake Key, sequence number C ---> Client sends 1-RTT protected message, carrying ACK(C), sequence number D <---Server sends 1-RTT protected message, carrying ACK(D), sequence number E. ---> Client sends ACK(E) in 1RTT protected packet. The implicit ACK proposal would state the following: 1) When the server receives ACK(B), the ack of its first 1RTT message, it knows that the whole server first flight had been received. 2) When the client receives ACK(D), the ack of its first 1RTT message, it knows that the whole client flight has been received, and that the server will not send any more "handshake" packet. 3) When the server receives ACK(E), it knows that the client knows that all handshake packets have been received, and the clientwill not send any more handshake packets. I believe that the 1st assertion is correct, because if the server flight up to server finished was not properly received, the client would not have been able to validate the session, compute the 1RTT key, and receive a packet encrypted.with 1RTT key. But I believe that the 2nd and possibly the 3rd assumptions are not correct. The problem with the second assumption is that the server does not really need to receive the TLS client finished message before acknowledging 1RTT protected packets. Even if we wrote in the spec that the server MUST wait for the final validation of the TLS handshake before acking any 1RTT protected packet, since there is no actual mechanism to enforce that, we know it will be one of those "MUST (BUT WE KNOW YOU WILL NOT)" recommendations. Personally, I would rather see some kind of explicit acknowledgement of the client finished message. But we need an open discussion. -- Christian Huitema From nobody Tue Jun 5 23:51:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F29130EBA for ; Tue, 5 Jun 2018 23:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 CtRP48bSsfmf for ; Tue, 5 Jun 2018 23:50:56 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 BE36C130EB7 for ; Tue, 5 Jun 2018 23:50:56 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id t6-v6so6386452iob.10 for ; Tue, 05 Jun 2018 23:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=epB2tjtc+3008bD/SU038/byZtE5BBdMgWbMmQb+c9Y=; b=J8+yVsBJvJ2IAKm0Hckmm+cRaxUnVYRhni596DA1vfyoUYWuiHZ/eYouijeu3qDBI9 SlRpWjSkOvP38jrPx/FegCYQ0HHDhk+ofeK9gH918x8OtJamJHxDVQTLkFkp0uhRAU6o OZmcN2BPZESfk9CVpVe4PM/G3sIiN2eaOqPRL1lmXRAV67kKhdwM9FCn6g5VD2ShOZYM WCx4BRv8w1ngaSPgQEpxsv01E70FOk2QRaJkxgBc+NBafWLPGP4aMUezfJlLBu+5YiAI pEaMFxDR3LyAr3pcq/X3dh1OK3FyC3umAgvxFeWDjlH4uh27x63FW6nBipYVFn+H/uTq ioLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=epB2tjtc+3008bD/SU038/byZtE5BBdMgWbMmQb+c9Y=; b=rPndLI6rBYLOH0gxr4pARdpeAzEPblfqOTjHiIZnrGoQ3dUxr/PQwImwhL/WTuoj16 DSRoyjDkOeLfei6ps+UyQEZijsYrPlrwPEZG0E9ZD51uLeX1l//jWVfMxiTgjTPFr70O +EXkvOoeKyce17UMC5yJmId04ZdUPa31JjLC2rHfx36/Y4fMqusmMfX5xcGR3ZvlUd4S KAjl/dPk/tZZSoXZZmZ2nBpe0Yy+0Rrw98K37rTjhqWAkZlTVCX5oU5TXo1VKRHxSvYv cklZigT3HCzXAcX0G2z8TjUhvr3uhJbZF++UkVNS7Whh9ck4pFzMA3JqgLKi9fxZw9a9 Jb9g== X-Gm-Message-State: APt69E36R/682RSS8ntKpiafQYWI5/hhCFfuV5A9pWKMSwoVfAxvq4AM mENkA2fpXMICovDakOmBDBmKHgeb6dGHwg8Fair+zQ== X-Google-Smtp-Source: ADUXVKJSSdB6/QUAf1rxmNIwQMM1fwZreoM/54BoGdkNYwRSnKWy+VV/SXwDIdkZxMBkU9IO54J8GCKbxZquY7DaCr0= X-Received: by 2002:a6b:1e4d:: with SMTP id e74-v6mr1789950ioe.36.1528267856088; Tue, 05 Jun 2018 23:50:56 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 02:50:55 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> References: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Jun 2018 02:50:55 -0400 Message-ID: Subject: Re: Implicit ACK and Client Finished To: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000af15c8056df396ae" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 06:51:00 -0000 --000000000000af15c8056df396ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Haven=E2=80=99t read/understood all, but to avoid confusion did you mean AC= K(B) here? ---> Client sends 1-RTT protected message, carrying ACK(C), sequence number D --000000000000af15c8056df396ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Haven=E2=80=99t read= /understood all, but to avoid confusion did you mean ACK(B) here?
---> Client sends 1-RT= T protected message, carrying ACK(C), sequence=C2=A0
number= D=C2=A0

--000000000000af15c8056df396ae-- From nobody Wed Jun 6 00:01:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219C4130EBA for ; Wed, 6 Jun 2018 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fg3StuaTLWSq for ; Wed, 6 Jun 2018 00:01:43 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B74130EB7 for ; Wed, 6 Jun 2018 00:01:42 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id r24-v6so6409543ioh.9 for ; Wed, 06 Jun 2018 00:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=kCC1KSjpwY8f9lXzYBHo9QpXCdhNLZ93pRvhbgGOLdw=; b=DrtOoOWPUZlGLv1WLaAnnyGqlSe9NqkiPr2+WVk+fzYS5XaLqxxP8zGO36z8y/v1m6 ZW+TCBdksfDuS3/6fBlomRdy/mS1n/xPw6OtlYzfPiGVp5HuJvYLM8cRi6lGgD1NFJUx VBDOIewCMK6sSHwvEjO5rM+Nu1/HozyAYdrJ8VYQ0iHLR7qONjTmcZVF/fgRhKvBDkU7 88dEhkH2KEgSYK5wvdqO7AQZPFfI5TJyEzlZC+ZLQ1ELqh+T+u4RDAlOj3Jtqw/i2jDZ +NGi9V4rFF8qUg+r+EfMLBKE3eSvZzMhgkVBu8PTk43i1mQxVwCFfGCDuvcWA63zC/1c EmUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=kCC1KSjpwY8f9lXzYBHo9QpXCdhNLZ93pRvhbgGOLdw=; b=fj/3biSvcbwH2gR5zFMxGrgDcG5gvQwYfkqiFF811PbAX8PH1+2pJuHcTDKtjcFNIh dKCITJruvrR1pdlP9LziSdtn+uUp1fG8NH319tmIFWbGNFZgTheWNfohaXBnVRvC3bAw 8ruJZgAvygEqU87GABTpRIQETgPe62ecU9dwWS+9cDyqEFuwONlgpmyo5OuqmLNCToKC nCq9XnIYUYbITlI37/F7Rg8sfOwluuKoDmELzhkVKgiwuR1ECrSXWAK82BaY820onqZB +31GuEpnYXQJfCKdBmFrPR3+/qDI1zhFbw9fT5yCFQ75x4XFNyrnfbTKx53bfHwHy/au roNA== X-Gm-Message-State: APt69E2T0QXeVwvbhTF7N9u00Rhp1h0gYwqFP4fqiJS2XCPmKLFk6BZz tWjxsIaVur9LVgUYVBXFfeYCZ0m7EclfkfU9p9+8qg== X-Google-Smtp-Source: ADUXVKIxcdkzoa7yQpKw1d9n8WssD75NkyBRvEP326PRvPTwbd/qmg5SkCYpiccrBNz8alWRIBkBHatcshD2OvN4MeA= X-Received: by 2002:a6b:93c6:: with SMTP id v189-v6mr1686486iod.274.1528268500784; Wed, 06 Jun 2018 00:01:40 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 03:01:40 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> References: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Jun 2018 03:01:40 -0400 Message-ID: Subject: Re: Implicit ACK and Client Finished To: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001c5fe1056df3bd7f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 07:01:48 -0000 --0000000000001c5fe1056df3bd7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had the same thought while reading through the assertions, before arriving at your concerns. This question also needs some motivation for the implicit ACK - what is gained by doing so? I guess it could avoid a packet when one part has nothing else to send, but I=E2=80=99d like to see that detailed. I also prefer an explicit client finished signal. Especially because implicit ACK=E2=80=99s ties the handshake close to TLS and especially with = the new stream 0 proposal TLS is fairly decoupled, opening for protocol variants with other handshakes (e.g. IoT devices). Thus, even if it could be assumed that the assertion 2 and 3 holds, they might not hold in other variants, so there should be a good reason to rely on them. On 6 June 2018 at 08.40.29, Christian Huitema (huitema@huitema.net) wrote: During the QUIC interop yesterday, there was a discussion of the proposed implicit ACK of the "client finished" message, during the transition from handshake to 1rtt protection. The sequence that we envisage goes like that: <--- Server sends last message in server flight (server finished), protected with Handshake key, sequence number A <--- Server sends first 1-RTT protected message (really, 0.5RTT), protected with 1 RTT key, sequence number B ---> Client sends last message in client second flight (client finished), protected with Handshake Key, sequence number C ---> Client sends 1-RTT protected message, carrying ACK(C), sequence number D <---Server sends 1-RTT protected message, carrying ACK(D), sequence number E. ---> Client sends ACK(E) in 1RTT protected packet. The implicit ACK proposal would state the following: 1) When the server receives ACK(B), the ack of its first 1RTT message, it knows that the whole server first flight had been received. 2) When the client receives ACK(D), the ack of its first 1RTT message, it knows that the whole client flight has been received, and that the server will not send any more "handshake" packet. 3) When the server receives ACK(E), it knows that the client knows that all handshake packets have been received, and the clientwill not send any more handshake packets. I believe that the 1st assertion is correct, because if the server flight up to server finished was not properly received, the client would not have been able to validate the session, compute the 1RTT key, and receive a packet encrypted.with 1RTT key. But I believe that the 2nd and possibly the 3rd assumptions are not correct. The problem with the second assumption is that the server does not really need to receive the TLS client finished message before acknowledging 1RTT protected packets. Even if we wrote in the spec that the server MUST wait for the final validation of the TLS handshake before acking any 1RTT protected packet, since there is no actual mechanism to enforce that, we know it will be one of those "MUST (BUT WE KNOW YOU WILL NOT)" recommendations. Personally, I would rather see some kind of explicit acknowledgement of the client finished message. But we need an open discussion. -- Christian Huitema --0000000000001c5fe1056df3bd7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I had the same thoug= ht while reading through the assertions, before arriving at your concerns.<= /div>

This question also ne= eds some motivation for the implicit ACK - what is gained by doing so?
I guess it could = avoid a packet when one part has nothing else to send, but I=E2=80=99d like= to see that detailed.


Thus, even if it could be assumed that the assertion= 2 and 3 holds, they might not hold in other variants, so there should be a= good reason to rely on them.

<= br>

On 6 June 2018 at 08.40.29, Chr= istian Huitema (huitema@huitema.net<= /a>) wrote:

During the QUIC interop yesterday, there was a discussion of t= he
proposed implicit ACK of the "client finished" message, durin= g the
transition from handshake to 1rtt protection. The sequence that we
envisage goes like that:

<--- Server sends last message in server flight (server finished),
protected with Handshake key, sequence number A

<--- Server sends first 1-RTT protected message (really, 0.5RTT),
protected with 1 RTT key, sequence number B

---> Client sends last message in client second flight (client
finished), protected with Handshake Key, sequence number C

---> Client sends 1-RTT protected message, carrying ACK(C), sequence
number D

<---Server sends 1-RTT protected message, carrying ACK(D), sequence
number E.

---> Client sends ACK(E) in 1RTT protected packet.

The implicit ACK proposal would state the following:

1) When the server receives ACK(B), the ack of its first 1RTT message,
it knows that the whole server first flight had been received.

2) When the client receives ACK(D), the ack of its first 1RTT message,
it knows that the whole client flight has been received, and that the
server will not send any more "handshake" packet.

3) When the server receives ACK(E), it knows that the client knows that
all handshake packets have been received, and the clientwill not send
any more handshake packets.

I believe that the 1st assertion is correct, because if the server
flight up to server finished was not properly received, the client woul= d
not have been able to validate the session, compute the 1RTT key, and
receive a packet encrypted.with 1RTT key. But I believe that the 2nd an= d
possibly the 3rd assumptions are not correct.

The problem with the second assumption is that the server does not
really need to receive the TLS client finished message before
acknowledging 1RTT protected packets. Even if we wrote in the spec that
the server MUST wait for the final validation of the TLS handshake
before acking any 1RTT protected packet, since there is no actual
mechanism to enforce that, we know it will be one of those "MUST (= BUT WE
KNOW YOU WILL NOT)" recommendations.

Personally, I would rather see some kind of explicit acknowledgement of
the client finished message. But we need an open discussion.

-- Christian Huitema


--0000000000001c5fe1056df3bd7f-- From nobody Wed Jun 6 00:16:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFBA130EC0 for ; Wed, 6 Jun 2018 00:16:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hFYJdFjuMtpt for ; Wed, 6 Jun 2018 00:16:15 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B1E1F12426A for ; Wed, 6 Jun 2018 00:16:15 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fQSg1-0002SG-AE for quic@ietf.org; Wed, 06 Jun 2018 09:16:14 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fQSfy-000495-7V for quic@ietf.org; Wed, 06 Jun 2018 03:16:11 -0400 Received: (qmail 11214 invoked from network); 6 Jun 2018 07:15:56 -0000 Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.104]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Jun 2018 07:15:56 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , IETF QUIC WG References: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <0c5b34b4-6f86-11c2-5cd2-fb6223b877f0@huitema.net> Date: Wed, 6 Jun 2018 00:15:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E9548BAC4991E73367287000" Content-Language: en-US Subject: Re: Implicit ACK and Client Finished X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5g7gZYqSBX9AVtMwTLnJ6/5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViUWGQbBzDWdL1LLI+S4xRfc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX1dGJ7HPnOCWRaxVuHANylF8FcHzzV3acxBudgYcInb2lF+yzFR7I6 esQpgjuwgVmZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZhfURd0e4QPXFipyALWtbLFwBl1z1+w2zS/h3e6UiVRca+nRlijDQMT9Q spfId192/MRlrdRYiHoX9r+Dalnh0GeqA47D/juB1cx4exzYk7zGRNvb2Jhdd2bCgCq95vNY647l NwN4qOsSZg+fYhVZGwX3xdN+1KruynacUoWIYszVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 07:16:20 -0000 This is a multi-part message in MIME format. --------------E9548BAC4991E73367287000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Yes. Sorry. On 6/5/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote: > Haven’t read/understood all, but to avoid confusion did you mean > ACK(B) here? > > ---> Client sends 1-RTT protected message, carrying ACK(C), sequence  > number D  > --------------E9548BAC4991E73367287000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes. Sorry.


On 6/5/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
Haven’t read/understood all, but to avoid confusion did you mean ACK(B) here?

---> Client sends 1-RTT protected message, carrying ACK(C), sequence 
number D 


--------------E9548BAC4991E73367287000-- From nobody Wed Jun 6 00:36:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E03130EC1 for ; Wed, 6 Jun 2018 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 eRmiQB14RiBr for ; Wed, 6 Jun 2018 00:36:35 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 195DE130EC0 for ; Wed, 6 Jun 2018 00:36:35 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id d5-v6so4537843oib.5 for ; Wed, 06 Jun 2018 00:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=pnLUcWTUxK+H/fTmxksaMKyaBbGPfRi1882GENgSIig=; b=rJPphYTgr8Cd8tP73FVMfHu67j3PxRkeKSgmulsk56/Ff5lPLeZCTrorvr3k/XdLN1 CX27sDqYDPdUzlfqylzXSXI26HzT1bTeRz5uhcen+1+gOzRb2+3Xg6/LtNZG0aHJn5/v PMciVph+JrLAyFZ4dChmSf1KHYVYsFalX3a+wgP1BdZNlWna0xU2eJMip5aZ5ybDR4Wt +vE+fyRvA5QVi9yA5GxgbAB1cdQ1LUZSGsEq5bh06wG14ANt6XDd2KcvscUYQizeQdEH QgW6j/Yje2GyLfkE9LY11T/WTjAH3OA1eXpcWqEqmeF8XS62mlhJBKzzhUIrlOzOYoy6 F0JA== 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=pnLUcWTUxK+H/fTmxksaMKyaBbGPfRi1882GENgSIig=; b=LgJXX5gCcL0HkfS0//GgXrLSOXyzUc1B1fk3T1NFl2gTB8yVDZOCNPngoSzbauI9pA hpHcqxx0Chb01jvGvKL5Xn6PdEplY5JTNnsQZTnKdrgabDcvlpz2JOQ5Tw0Jt6vF6bcX C6Z1i1fqPkqgWVmHqnvDMiMqTX8iFzFroGpbLfEPuJE3bOirjNN2EC5bQxcr3PpO/Rda ylabH7FefUZp9mLUVK1F2A3uaWNBfr5M5L123oPzXwG0geueV5TtvEKtCMsd0jvG9q1R XMBwCuT2yFcsKTdnnpqPKFqNyv5Hcc/athM3vMPkj41gLq3GaRaef5LArNZnr0m+ffkf YBIg== X-Gm-Message-State: APt69E2ranfKm2CCk/NeTiY0Ulhb0PJkjcZKDr9bGLZcbuobsbazc7B4 QkX7SJAp9JRCLAUbASnATDXoiC9Fj9Tp3GCiWOPrJT4c2os= X-Google-Smtp-Source: ADUXVKKN7uGydvD6CnV+QyhR+lx7Qsxkl8PN6RJzk8r0gUhXZB+Q7VFFwYXO6RdMsVvo+w5lQyes4yCtnsJ4z384fxM= X-Received: by 2002:aca:1c3:: with SMTP id 186-v6mr1098985oib.174.1528270594094; Wed, 06 Jun 2018 00:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 00:35:53 -0700 (PDT) From: Eric Rescorla Date: Wed, 6 Jun 2018 00:35:53 -0700 Message-ID: Subject: Google doc for today's minutes To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e1cc12056df4398e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 07:36:39 -0000 --000000000000e1cc12056df4398e Content-Type: text/plain; charset="UTF-8" https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0RBe9y4c/edit?usp=sharing --000000000000e1cc12056df4398e Content-Type: text/html; charset="UTF-8" --000000000000e1cc12056df4398e-- From nobody Wed Jun 6 13:50:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40811130FDE for ; Wed, 6 Jun 2018 13:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 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, FROM_EXCESS_BASE64=0.979, 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 FiIgVB-Ktx92 for ; Wed, 6 Jun 2018 13:50:53 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62759130DD0 for ; Wed, 6 Jun 2018 13:50:53 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id n3-v6so8910887ota.5 for ; Wed, 06 Jun 2018 13:50:53 -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; bh=3gnhuMckny+oZ+uBtm6Jy5g7IMaZPcJ+epSkZeYaRGc=; b=GvRfv6prfNU9uHb7ixK/Q57tR741qXhYeL+gDGAwllB6Sq7CwMiuFNliaxvqQ+hC2+ QGEQVUcTa1KVyd++hQe3xGiYIDXil9Ou75ywyDUWLLdizOWbYLlgCZYMBOl26ngwfvah 39tkcrst+M/CkO+oH3vAxERa221D7Fo6OUuajXnW/SqVB85LUn3/4TvG5X5qrihaxMUw e5frdaUeNNxwhzWaqbOQ76cBc62FSm8Ey/5KOYyX5b0ZUgZiQthYSTy8mfI+Ie2efOAc YHGMNrKXra00/789WVqoGV6sVFMFsaJVyPg36vE7EZpJMIjSUCzXQsl20nofQm4wa2uJ GZqg== 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=3gnhuMckny+oZ+uBtm6Jy5g7IMaZPcJ+epSkZeYaRGc=; b=GvmVsJ4/ZczVV5sDYeR60wrrJA71CXCkniySPFFhDx8HI1fCtj6BOv5/BI/N/G2+MC 8Y1f67w2GTz1sNSJ4NYjjqrqywg1mt1SI3+XzrCb48azNn3NR/0DPta4AI8z7qrP0hFb XV4BzbVlMVd2/xM+aP1uL4rFN2/f0uucMJESmhsp0eLYe3oPoctuE3T/MfvQW9au7PE0 WjH6lPoQOt/zWast7vw51My2xOWkA7Z5q7O+17IPb8kxkEckVJbu7DTzRxkZt0QLT82o ENL4v+GQpFlet81eio2bHQERzHY13QjMnROoUGR4K6PjENbooir483om5I7jBZT/S8Ed 4Ofg== X-Gm-Message-State: APt69E2gvbow/F1ME9RoJ0yPh+an7SDbnw5N/eQpdg3kVbpp2tZ+Bb/w BAdD30fkiXlnmuAzhqZSBw0+rKaL3B/ShnopdsY= X-Google-Smtp-Source: ADUXVKIvdd9JIyLKoVpKSAJb4RiR37tNN3r4G4oH7Dnt8irSy3O9zTbHS0WwDbNxehQ+Wn19zuuPxmQKd/6Fx3bOkKM= X-Received: by 2002:a9d:5c7:: with SMTP id 65-v6mr3184062otd.78.1528318252491; Wed, 06 Jun 2018 13:50:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:414:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 13:50:52 -0700 (PDT) From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Wed, 6 Jun 2018 23:50:52 +0300 Message-ID: Subject: quic protection against replayed packets To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 20:50:55 -0000 Hi, I am following QUIC development and there is one aspect I can't find answer to - how does QUIC protect itself if attacker replays/duplicates 1-RTT protected packets? What should happen when repeated packet is received, because it will be decrypted correctly. Should endpoints maintain some sort of received packets window? Or are all the QUIC Frame types resistant against duplicates? -- From nobody Wed Jun 6 14:22:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5A130DDC for ; Wed, 6 Jun 2018 14:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 p4a5K7Lz8faT for ; Wed, 6 Jun 2018 14:22:41 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 16338130DD3 for ; Wed, 6 Jun 2018 14:22:41 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p129-v6so2356555ywg.7 for ; Wed, 06 Jun 2018 14:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1pdLe6mrgWOpYizKmaGjALtbGLmJFyZCT+nA8nny698=; b=U/asEPvGsgsZ428AemmwVk/vURiXdE5aLLNP8gVe761q4O/RUMxaGU4t/uWAj+xAAh godxmhg/9a5vG8ZXXnYv9XrOXB2+O02nAGM/HWdHMHUmrgGSPoHr5Vp5NswYiYDF8Gv/ PktpbEGHe0828rY8OQes91pTspVX+BbUtOE5jp0+Og/e8piUUMrATSYpEoIJifD3nnmg ixkqDTaQY+kxjzoVnAYFGpXGECRSlW2Wt3ZD5S+Pu90alWFOqJpoJItylzEtqOxcS7Lh vx4KI5saBcnXkGQWptH6o7AjtFCN2+jyrrplYOgZkyA54KWjWUbD+vdQjFBwxpsr3E5Y DKAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1pdLe6mrgWOpYizKmaGjALtbGLmJFyZCT+nA8nny698=; b=Il2wUAYFTw0I/XrX864r8uxIM6+rZ+UMcfVKIIqNSKDHA8VbPjFa+svzn0HTu2g/bx hpbvPf2qkABRGqj5/soIxsE5VQ8XsqEUEcZNftuKtGWsuMKoqsPC1T03QUfH6BjcMDmH zz4Kv/Dpta4DAH30iSDX3aff+exnWLGpHGqyu+aQKR7yUyUSM4eV1vXB6rwen6pRQRYC sN9/NJpdcIsPZWMjtIY4OVWH6KtTiIPaogGg+YXL4sgmoglRQFr2MzuVu0NyZlA/AzXT jTJZMoi/WpXul1lChfI9kHX3Qp6G65NL0dPyuPPyY7zAkB3GrHt6DxRihUM69YoWLeuM D7iA== X-Gm-Message-State: APt69E1oVENpP/0ZK1BrsZnL3Gi9PqZhQGJLzhDQUfqKtpVCL4DMuhIF zGpD+RwwmTmHplnN9yqMNE9VdeVDLeVN668eke8JoQ== X-Google-Smtp-Source: ADUXVKLLqs+8STj+055pGFBVjH/iZRDAFs1NM0jwx2iha7RABjCLxDl98b3jueVqMkCOJaPA7znN0mqD4sPSpf9W7vs= X-Received: by 2002:a0d:e849:: with SMTP id r70-v6mr2314907ywe.482.1528320159892; Wed, 06 Jun 2018 14:22:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 6 Jun 2018 17:22:28 -0400 Message-ID: Subject: Re: quic protection against replayed packets To: janis.coders@gmail.com Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000003c634b056dffc411" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:22:46 -0000 --0000000000003c634b056dffc411 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the packet was received recently, the receiver should just drop the packet, because the same packet number was recently processed. If it was a long time in the past, either the receiver will decide the packet number is too low to process or it will process the packet and all the frames it contains will be duplicates. On Wed, Jun 6, 2018 at 4:51 PM J=C4=81nis =C4=8Coders wrote: > Hi, I am following QUIC development and there is one aspect I can't > find answer to - how does QUIC protect itself if attacker > replays/duplicates 1-RTT protected packets? > What should happen when repeated packet is received, because it will > be decrypted correctly. Should endpoints maintain some sort of > received packets window? Or are all the QUIC Frame types resistant > against duplicates? > > > -- > > --0000000000003c634b056dffc411 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the packet was received recently, the receiver should j= ust drop the packet, because the same packet number was recently processed.=

If it was a long time in the past, either the receiver = will decide the packet number is too low to process or it will process the = packet and all the frames it contains will be duplicates.

On Wed, Jun 6, 2018 at 4:51 PM J= =C4=81nis =C4=8Coders <janis.c= oders@gmail.com> wrote:
Hi, = I am following QUIC development and there is one aspect I can't
find answer to - how does QUIC protect itself if attacker
replays/duplicates 1-RTT protected packets?
What should happen when repeated packet is received, because it will
be decrypted correctly. Should endpoints maintain some sort of
received packets window? Or are all the QUIC Frame types resistant
against duplicates?


--

--0000000000003c634b056dffc411-- From nobody Wed Jun 6 14:32:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC105130DE5 for ; Wed, 6 Jun 2018 14:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 NoVtuPxBmFE3 for ; Wed, 6 Jun 2018 14:32:33 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 551AA130DD3 for ; Wed, 6 Jun 2018 14:32:33 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id u4-v6so10168772itg.0 for ; Wed, 06 Jun 2018 14:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=j4VHMoJHYCQWFtoMqKiPlUqU+j1EFADMwsM8AEf19y4=; b=uIBdofcP5tG1l8hcNt/luC/V2FlXgHJI+D54LBVi5pEpOToGEfrK5gz0HYCmy63DjG tUSGycxjvdFO62NJDHLo9f1r1xha7RxRTo71J9+gdDvCrGiwTaVz+eU14siIaXPwQdJo 7QOFPfQS1jW+EORNuYFOxPtZm3hYuvPvI2DhA1UcXg3XNyi0LCWuE3qVLI53qPRCBQCd ALBmskrz5BSc8sEA37P2IC5p9S8Pj7w5M3f4Gaa3ZpVScVLH7hMdHs0fqQT6Hpd/nxrB 1uC0FeE8kb2tuASeCA/PlSwbYYeDtIFTfLSpsE99psEpgOcxkNLaojdmY9/sBnhUq9Sy 9JEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=j4VHMoJHYCQWFtoMqKiPlUqU+j1EFADMwsM8AEf19y4=; b=Gk5ou1P5ek7AS6ViXiKGy/Ol+lZZWMCe2xnNmri3+FqLUD2F9Xhl5adomRcnskP5/A tKnv4+ZadxEW2huD5S5v6yn5nK91aOxcjVfPbQolgRqmdAcGmFcVjEswFlwe/Po56DWI 6S1kVt+gGsg7VOXqR5OjcwrZb/ez6gKHe43wlh3z9/FkBwyyc4npAfqsTqnUqVyL4Xj9 H3XeErwfZa9/+Ffsr1TuvL0yw7/NsuSuIcVhJhnBIe5JYo7TLam0D3nYmQYl2viq1J0J 3Yh0NnOF1OYtrftVVwFZWYdvd6CNGXLMcl7CBK43E9HfzO0Lexueb3phwosW4W9crVFh zffA== X-Gm-Message-State: APt69E0vzrI2rxDqwYNVJ4VjoC38qoqW3wYxCy8hrMLwfqYPG99UkM0P rR39duVmddNwB0WUvqH6niGGYtEMViSrWbX6hIA= X-Google-Smtp-Source: ADUXVKIJzDmk5u3wpoihMM4rqDf40U3C2viEfP7jCKPq6p38SHtSK5xE4yKXmolLoo/xZ3AdNSB5eomykko6LKZ4P8g= X-Received: by 2002:a24:dbd6:: with SMTP id c205-v6mr4661255itg.118.1528320752754; Wed, 06 Jun 2018 14:32:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 14:32:31 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Jun 2018 14:32:31 -0700 Message-ID: Subject: Re: quic protection against replayed packets To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= , QUIC WG Content-Type: multipart/alternative; boundary="0000000000009238dc056dffe7a4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:32:35 -0000 --0000000000009238dc056dffe7a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The first line of defence is that most implementations would filter duplicate packets by tracking recently received packets, and dropping anything with a packet number older than what is tracked. Assuming duplicates are not filtered: It depends on the packet content, or frame type more precisely. Some frames deliver flow control credits or ACK=E2=80=99s and here the problem is not o= nly duplicates but also out of order delivery of same type of content in different packets. Here flow control cannot be reduced, so out of date content is ignored, and ACK=E2=80=99s cannot be unacked. For stream frames, each stream keeps track of already received ranges. An implementation could replace a range in the receive buffer with same content which is harmless, or with different content (for retransmissions done badly), but in either the case the application would (normally) only see a single coherent range. QUIC must offer that view to the application, but an implementation may expose more details and out of order ranges if so desired, but that is outside the protocol. If there is some frame type that does not sanely handle this, it is probably a bug and an issue should be raised. Note that 0-RTT is vulnerable to replays because connections can be repeated. This is not possible in 1-RTT. On 6 June 2018 at 22.51.16, J=C4=81nis =C4=8Coders (janis.coders@gmail.com)= wrote: Hi, I am following QUIC development and there is one aspect I can't find answer to - how does QUIC protect itself if attacker replays/duplicates 1-RTT protected packets? What should happen when repeated packet is received, because it will be decrypted correctly. Should endpoints maintain some sort of received packets window? Or are all the QUIC Frame types resistant against duplicates? -- --0000000000009238dc056dffe7a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = The first line of de= fence is that most implementations would filter duplicate packets by tracki= ng recently received packets, and dropping anything with a packet number ol= der than what is tracked.

Assuming duplicates are not filtered:

It depends on the packet content, or frame type more= precisely. Some frames deliver flow control credits or ACK=E2=80=99s and h= ere the problem is not only duplicates but also out of order delivery of sa= me type of content in different packets. Here flow control cannot be reduce= d, so out of date content is ignored, and ACK=E2=80=99s cannot be unacked.<= /div>

For stream frames, ea= ch stream keeps track of already received ranges. An implementation could r= eplace a range in the receive buffer with same content which is harmless, o= r with different content (for retransmissions done badly), but in either th= e case the application would (normally) only see a single coherent range. Q= UIC must offer that view to the application, but an implementation may expo= se more details and out of order ranges if so desired, but that is outside = the protocol.

If there is some frame type that does no= t sanely handle this, it is probably a bug and an issue should be raised.
Note that 0-RTT is vulnerable to replays because connecti= ons can be repeated. This is not possible in 1-RTT.

On 6 June 2018 at 22.51.16, J=C4=81nis =C4=8Coders (janis.coders@gmail.com) wrote:

Hi, I am followi= ng QUIC development and there is one aspect I can't
find answer to - how does QUIC protect itself if attacker
replays/duplicates 1-RTT protected packets?
What should happen when repeated packet is received, because it will
be decrypted correctly. Should endpoints maintain some sort of
received packets window? Or are all the QUIC Frame types resistant
against duplicates?


--

--0000000000009238dc056dffe7a4-- From nobody Wed Jun 6 15:45:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3C130DE6 for ; Wed, 6 Jun 2018 15:45:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HiV7P6TIuOx2 for ; Wed, 6 Jun 2018 15:45:40 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1EBC8130DE1 for ; Wed, 6 Jun 2018 15:45:40 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fQhBR-0007by-Lg for quic@ietf.org; Thu, 07 Jun 2018 00:45:38 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fQhBM-00036q-UU for quic@ietf.org; Wed, 06 Jun 2018 18:45:33 -0400 Received: (qmail 26090 invoked from network); 6 Jun 2018 22:45:28 -0000 Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.104]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Jun 2018 22:45:28 -0000 To: quic@ietf.org References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net> Date: Wed, 6 Jun 2018 15:45:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------553F0C7898441B33ACE28036" Content-Language: en-US Subject: Re: quic protection against replayed packets X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qdPPB2jC7jTI2z10eNhjMp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViw8DYIND/DzXBuw/UGiR4P87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXXTg8/eGzRNUUVgcQ9smKz+YGaFKm4C5XbPm1ymSRhtX6AB68OLez+ eojwzjYnNgaU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRhK7unSGReaJhoESbMmiSIuggKW28pboyZCmKkHUYXamhm18qCfn8BSDP h8R09528Ws4d1Ezu4znpE/pclEKTkXtB4/4Pbrz2QtFuyl+Sh6eSMv+rdVKXDLDaTBj+LzkUfqb5 R4VemuUI6bcEARsm0KnLtMabt6P+t78klMitoc+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 22:45:46 -0000 This is a multi-part message in MIME format. --------------553F0C7898441B33ACE28036 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/6/2018 2:32 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > The first line of defence is that most implementations would filter > duplicate packets by tracking recently received packets, and dropping > anything with a packet number older than what is tracked. The packet number filed only contains the lower bits of the packet sequence number -- 32, 14 or 6 bits depending on encoding. The higher order bits are filled up based on currently expected value. The completed 64 bit number (62 bit really) is then used as part of the initialization vector when decrypting the packet. If a very old packet is replayed, the receiver fill guess the high order bits wrong, the decryption will fail, and the packet will be rejected. If the packet is relatively recent, then most implementations rely on packet tracking to detect that this packet is not expected. The tracking data is the same data as the "dashboard" that is needed to implement the selective ack process. So in practice, one way or another, the duplicate packet will be ignored. The threat analysis envisages a different attack: intercept a packet, suppress the original transmission, and resend the same packet from a different address. This is one of the reasons why the migration specification includes a challenge/response mechanism. > > Assuming duplicates are not filtered: > > It depends on the packet content, or frame type more precisely. Some > frames deliver flow control credits or ACK=E2=80=99s and here the probl= em is > not only duplicates but also out of order delivery of same type of > content in different packets. Here flow control cannot be reduced, so > out of date content is ignored, and ACK=E2=80=99s cannot be unacked. > > For stream frames, each stream keeps track of already received ranges. > An implementation could replace a range in the receive buffer with > same content which is harmless, or with different content (for > retransmissions done badly), but in either the case the application > would (normally) only see a single coherent range. QUIC must offer > that view to the application, but an implementation may expose more > details and out of order ranges if so desired, but that is outside the > protocol. Frames can be repeated, not because of a replay attack but because of "spurious retransmission", which can happen for a variety of reasons. So yes, applications have to be able to tolerate that and not break. -- Christian Huitema --------------553F0C7898441B33ACE28036 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/6/2018 2:32 PM, Mikkel Fahnøe Jørgensen wrote:

The first line of defence is that most implementations would filter duplicate packets by tracking recently received packets, and dropping anything with a packet number older than what is tracked.

The packet number filed only contains the lower bits of the packet sequence number -- 32, 14 or 6 bits depending on encoding. The higher order bits are filled up based on currently expected value. The completed 64 bit number (62 bit really) is then used as part of the initialization vector when decrypting the packet. If a very old packet is replayed, the receiver fill guess the high order bits wrong, the decryption will fail, and the packet will be rejected.

If the packet is relatively recent, then most implementations rely on packet tracking to detect that this packet is not expected. The tracking data is the same data as the "dashboard" that is needed to implement the selective ack process. So in practice, one way or another, the duplicate packet will be ignored.

The threat analysis envisages a different attack: intercept a packet, suppress the original transmission, and resend the same packet from a different address. This is one of the reasons why the migration specification includes a challenge/response mechanism.



Assuming duplicates are not filtered:

It depends on the packet content, or frame type more precisely. Some frames deliver flow control credits or ACK’s and here the problem is not only duplicates but also out of order delivery of same type of content in different packets. Here flow control cannot be reduced, so out of date content is ignored, and ACK’s cannot be unacked.

For stream frames, each stream keeps track of already received ranges. An implementation could replace a range in the receive buffer with same content which is harmless, or with different content (for retransmissions done badly), but in either the case the application would (normally) only see a single coherent range. QUIC must offer that view to the application, but an implementation may expose more details and out of order ranges if so desired, but that is outside the protocol.

Frames can be repeated, not because of a replay attack but because of "spurious retransmission", which can happen for a variety of reasons. So yes, applications have to be able to tolerate that and not break.

-- Christian Huitema
--------------553F0C7898441B33ACE28036-- From nobody Wed Jun 6 23:33:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69B2130E7C for ; Wed, 6 Jun 2018 23:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 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, FROM_EXCESS_BASE64=0.979, 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 HamMn1o-MAEj for ; Wed, 6 Jun 2018 23:33:50 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1281D12777C for ; Wed, 6 Jun 2018 23:33:50 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id c128-v6so7572912oig.11 for ; Wed, 06 Jun 2018 23:33:50 -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=Z5HyCHelwswn4yONllHgJT3q3irA4eRZStjz4X19c7Y=; b=KYFgnZ5xJOXHwGDt5DghIkG6nOWgvQLjrCcJXUvMU+XmqS3BpmGcKwJDn6mVQVsAL8 9aGx8oN0JG0RxlS4Ne0VA5A/2SD1z14+LhRIGLRXVxgOikFr23gVQPVfA7hSxPhqqrI+ 4Xzg8Ro7T8Joqh8qQZR5QKR6JhkrbbR3gW5tKc0xQ4Ddk2lyOrGDvjQZzsBGBY3CVJ/e V0zNhjXLey8+3I1smOOtr4HIao8fiYn2TOuygiqVJsiQn7KQgcI9KljHJ7iupAjvDP5S mM7obyFKBtTGgtGFNclbElzzKXwHRJhwvF1siY5PzKOqJjAcdRqsmsg6u/RSmxuPiEH6 f0HA== 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=Z5HyCHelwswn4yONllHgJT3q3irA4eRZStjz4X19c7Y=; b=gnEUEYrzZ/RxPgdO70FFbzfXo8Y38SUntwfGRbN4qHnl8YxtGCfrcpXFExrkMNu6Sv ZoIobCwYeYFiADDbRmGDO1iS4xfLKkH8IndVtPazZuDAbgY0WTHiQO3fNGuJiizAsGa9 R63+hI3Vwg1NTaCbIedUEINGimGFYYdk3w6drVkH/QsPqwCwXb/ho4FReKkZ4GnKonBZ 6OP5bxI/ARWvfa8jjjim0TcmES5nfuedeor31udX2GJoMPk9xiZawocq4+l9km7p2+Sy aS88uPStwjIWaMjpDWHGE53iJcHhf7KzC4DjDktsaUDTZiVOGLJsv5SmQouy4qynBh1g 1vkg== X-Gm-Message-State: APt69E25l/dyPW+vInq7kajJVhORYSb4X6tOqk1AZ8pmp5CImePnuHnq u+DMB5Un4esHTJBU4hdFlSuntno/+9fSG3ty/1o= X-Google-Smtp-Source: ADUXVKI4qHXlRXKlFhYRpoA3r0R2B6Hg6K/e0KgQnqhLBubnU56FldOWCqaos7mCNaKNtRq8r23DJF8EXNPQ4RO9NPA= X-Received: by 2002:aca:3e84:: with SMTP id l126-v6mr257202oia.231.1528353229190; Wed, 06 Jun 2018 23:33:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:414:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:33:48 -0700 (PDT) In-Reply-To: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net> References: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net> From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Thu, 7 Jun 2018 09:33:48 +0300 Message-ID: Subject: Re: quic protection against replayed packets To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:33:53 -0000 Ok, so it means endpoints have to keep track of received packet numbers. Just couldn't find that in standard. At first I thought that all packets with lower PN than last valid must be dropped, but then saw implementation where also lower packet numbers are accepted On 7 June 2018 at 01:45, Christian Huitema wrote: > On 6/6/2018 2:32 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > The first line of defence is that most implementations would filter > duplicate packets by tracking recently received packets, and dropping > anything with a packet number older than what is tracked. > > > The packet number filed only contains the lower bits of the packet sequen= ce > number -- 32, 14 or 6 bits depending on encoding. The higher order bits a= re > filled up based on currently expected value. The completed 64 bit number = (62 > bit really) is then used as part of the initialization vector when > decrypting the packet. If a very old packet is replayed, the receiver fil= l > guess the high order bits wrong, the decryption will fail, and the packet > will be rejected. > > If the packet is relatively recent, then most implementations rely on pac= ket > tracking to detect that this packet is not expected. The tracking data is > the same data as the "dashboard" that is needed to implement the selectiv= e > ack process. So in practice, one way or another, the duplicate packet wil= l > be ignored. > > The threat analysis envisages a different attack: intercept a packet, > suppress the original transmission, and resend the same packet from a > different address. This is one of the reasons why the migration > specification includes a challenge/response mechanism. > > > > Assuming duplicates are not filtered: > > It depends on the packet content, or frame type more precisely. Some fram= es > deliver flow control credits or ACK=E2=80=99s and here the problem is not= only > duplicates but also out of order delivery of same type of content in > different packets. Here flow control cannot be reduced, so out of date > content is ignored, and ACK=E2=80=99s cannot be unacked. > > For stream frames, each stream keeps track of already received ranges. An > implementation could replace a range in the receive buffer with same cont= ent > which is harmless, or with different content (for retransmissions done > badly), but in either the case the application would (normally) only see = a > single coherent range. QUIC must offer that view to the application, but = an > implementation may expose more details and out of order ranges if so > desired, but that is outside the protocol. > > > Frames can be repeated, not because of a replay attack but because of > "spurious retransmission", which can happen for a variety of reasons. So > yes, applications have to be able to tolerate that and not break. > > -- Christian Huitema --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Thu Jun 7 00:36:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD68130E7E for ; Thu, 7 Jun 2018 00:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Kd1bAUY3A9Ay for ; Thu, 7 Jun 2018 00:36:01 -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 C4A54130E8F for ; Thu, 7 Jun 2018 00:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528356959; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: 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=PgSaeoFUmP2NYk41EUAXw36y6aUFz4RPah/kbDgEo28=; b=I2eMhKqAd5A0O96DjqxyrTYtLJOGDbXN+LoHMVB88BUaGIwrt/khw/qxZ4NWLdxY B5zvMbgL3bEdmeLO5uCkHv7mXLnOPN9jvL0I4oU07r9CPo6zWvGoy2euLXBUrBVs a8QqHe2lOwJcupE2U11a3hmTDer6T5kTTEXOqU5d7eM=; X-AuditID: c1b4fb30-f7fff700000002c8-80-5b18e05edecd Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.08.00712.E50E81B5; Thu, 7 Jun 2018 09:35:59 +0200 (CEST) Received: from [147.214.250.97] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 7 Jun 2018 09:35:58 +0200 Subject: Re: quic protection against replayed packets To: References: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net> From: Magnus Westerlund Message-ID: <25a2a8c5-a17c-b19f-7970-6b04e43a3baa@ericsson.com> Date: Thu, 7 Jun 2018 09:35:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM2J7uG78A4log44uToueBdwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4MpY8novY8FimYrVO28zNzB+E+ti5OCQEDCR6F8U2MXIxSEkcIRR 4vznqawQziZGifXP/rB0MXJyCAuYSmyatYAZxBYREJbYsPAcE0TRZCaJGTfOM4Ik2AQsJG7+ aGQDsXkF7CU+Xb3OBGKzCKhIrO3vBWsWFYiRWL3xMjtEjaDEyZlPwBZwCgRKrD8wC8xmBpoz cz7ETGYBeYnmrbOZIWxxiaYvK1lBbCEBbYmGpg4wW0JASeL6vOssExgFZyEZOwvJqFlIRs1C MmoBI8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMCQPbjlt8EOxpfPHQ8xCnAwKvHwLrkp ES3EmlhWXJl7iFGCg1lJhDfxkli0EG9KYmVValF+fFFpTmrxIUZpDhYlcV4Lv81RQgLpiSWp 2ampBalFMFkmDk6pBsaeqKNul8rdhRZmO53o7Zp5OtHiWWhGewKv0rsVc49cU0xT+Cpnszrm euzpuDzuzhs7/Bq17v3R8t54z8FE6mfJkd2ht1RMOv+Jb/y6Wen2q2ctSancS78kvt9b3ODu lrpzzc5HW+MfXFg+1UdN/la/7PIVP63XGpv5N21+rZS0qIBryuaoWjclluKMREMt5qLiRABR doi8VQIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 07:36:12 -0000 Hi, Yes, there is no text on this in the drafts.  There is an issue on this: https://github.com/quicwg/base-drafts/issues/1405 /Magnus Den 2018-06-07 kl. 08:33, skrev JÄnis ÄŒoders: > Ok, so it means endpoints have to keep track of received packet > numbers. Just couldn't find that in standard. > At first I thought that all packets with lower PN than last valid must > be dropped, but then saw implementation where also lower packet > numbers are accepted > > On 7 June 2018 at 01:45, Christian Huitema wrote: >> On 6/6/2018 2:32 PM, Mikkel Fahnøe Jørgensen wrote: >> >> The first line of defence is that most implementations would filter >> duplicate packets by tracking recently received packets, and dropping >> anything with a packet number older than what is tracked. >> >> >> The packet number filed only contains the lower bits of the packet sequence >> number -- 32, 14 or 6 bits depending on encoding. The higher order bits are >> filled up based on currently expected value. The completed 64 bit number (62 >> bit really) is then used as part of the initialization vector when >> decrypting the packet. If a very old packet is replayed, the receiver fill >> guess the high order bits wrong, the decryption will fail, and the packet >> will be rejected. >> >> If the packet is relatively recent, then most implementations rely on packet >> tracking to detect that this packet is not expected. The tracking data is >> the same data as the "dashboard" that is needed to implement the selective >> ack process. So in practice, one way or another, the duplicate packet will >> be ignored. >> >> The threat analysis envisages a different attack: intercept a packet, >> suppress the original transmission, and resend the same packet from a >> different address. This is one of the reasons why the migration >> specification includes a challenge/response mechanism. >> >> >> >> Assuming duplicates are not filtered: >> >> It depends on the packet content, or frame type more precisely. Some frames >> deliver flow control credits or ACK’s and here the problem is not only >> duplicates but also out of order delivery of same type of content in >> different packets. Here flow control cannot be reduced, so out of date >> content is ignored, and ACK’s cannot be unacked. >> >> For stream frames, each stream keeps track of already received ranges. An >> implementation could replace a range in the receive buffer with same content >> which is harmless, or with different content (for retransmissions done >> badly), but in either the case the application would (normally) only see a >> single coherent range. QUIC must offer that view to the application, but an >> implementation may expose more details and out of order ranges if so >> desired, but that is outside the protocol. >> >> >> Frames can be repeated, not because of a replay attack but because of >> "spurious retransmission", which can happen for a variety of reasons. So >> yes, applications have to be able to tolerate that and not break. >> >> -- Christian Huitema > > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 7 03:15:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E7130ED8 for ; Thu, 7 Jun 2018 03:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_LINK_PLUS=0.012, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aap1dpsPr_Fg for ; Thu, 7 Jun 2018 03:15:05 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBE0130DFF for ; Thu, 7 Jun 2018 03:15:04 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 411hHV2DhHz2ych for ; Thu, 7 Jun 2018 12:15:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 3132440088 for ; Thu, 7 Jun 2018 12:15:02 +0200 (CEST) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0389.001; Thu, 7 Jun 2018 12:14:57 +0200 From: To: "quic@ietf.org" CC: FERRIEUX Alexandre IMT/OLN , =?iso-8859-1?Q?FIEAU_Fr=E9d=E9ric_IMT/OLN?= Subject: QUIC spinbit tool to show 1/2 RTT from tcpdump Thread-Topic: QUIC spinbit tool to show 1/2 RTT from tcpdump Thread-Index: AdP+RnVNYYRjrnyIR2WujjDIFws7zg== Date: Thu, 7 Jun 2018 10:14:56 +0000 Message-ID: <3304_1528366502_5B1905A6_3304_1_3_7d906cd5-e04f-403b-97cf-d5e668d7c997@OPEXCLILM6C.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_7d906cd5e04f403b97cfd5e668d7c997OPEXCLILM6Ccorporateadr_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 10:15:13 -0000 --_000_7d906cd5e04f403b97cfd5e668d7c997OPEXCLILM6Ccorporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To show the benefit of the spinbit for network troubleshooting we are provi= ding a tool and data at http://193.252.113.227/cgi-bin/quicspin.cgi. The tool extracts and displays the delay of the 2 sides of the path from a = tcpdump file. You can upload you own pcap file and get the 2 half RTT displayed. The current measures displayed are based on picoquic and picoquic+vec. Regards Emile ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_7d906cd5e04f403b97cfd5e668d7c997OPEXCLILM6Ccorporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

To show the benefit of the spin= bit for network troubleshooting we are providing a tool and data at <= span lang=3D"EN-US">http://193.252.113.227/cgi-bin/quicspin.cgi<= /span>.

 

The tool extracts and displays the delay of the 2 sides = of the path from a tcpdump file.

 

You can upload you own pcap fil= e and get the 2 half RTT displayed.

 

The current measures displ= ayed are based on picoquic and picoquic+vec.

 

Regards<= /p>

Emile

 

 

  

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_7d906cd5e04f403b97cfd5e668d7c997OPEXCLILM6Ccorporateadr_-- From nobody Thu Jun 7 08:11:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1445F130F27 for ; Thu, 7 Jun 2018 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 uIwMcIgNJMBX for ; Thu, 7 Jun 2018 08:11:27 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 EDB44130F2D for ; Thu, 7 Jun 2018 08:11:26 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id j80-v6so6751708qke.9 for ; Thu, 07 Jun 2018 08:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=zoKs830pbycydXPJH63EB4wns5a+kusp1u/B8n4pKPY=; b=i7KBwO3a2ZbuwsUaqmDmA6vEo5yq6xsStUh9kM/FlcEAAPdlo1iU+0jLTuA5Wgno1c 6wAeI6OmRJPu/2BYMXA2H7c8TFb/JqY12WKUDsfW4A5vkgKggyk2AewcmFddl4Cm5iHb A8U3IGERDflGF24qu0JIMMJqhqGsz40I1BPxo0A5//cStapJOKI0qsji6wXpNjBTeLD1 72wGp6AAqGYGKUSZflYR03uqudPOz1ZpmXWGsh74pySxlCx4nYKCJlfwIGwkuPiecdJP Zc5619xlfFsIKOZiBWcti98HFG/S3FCjbywOtco3OSxLXXCH8qexWvKJvLhPEIDQCIf8 S8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=zoKs830pbycydXPJH63EB4wns5a+kusp1u/B8n4pKPY=; b=Kln3qy8uTAAW3d+bx4BntVZUWOUq1kd0fyEGh5F8exc4fOEbMACj5SbfFR3WzXy+RL nFuYRfISQEezV198JLEuPvPX1N2+kJsFsAKzP6ntD3d39vh+VxOxf5OWBhcoL/QQxNjC 42Nwb6EYz+MYKIGBOyjYkmGOOA82+mNF2rN/HC37+dWciX1IAmyg5MGgFGY/WCNjhG/O 2l67eDHr48L+Sd+bqjMx6tmdzgeDBgnbRJQk3o6D5WN4Shw8qkQjt/P4ykXLI2zQb9Sq apW3ZprqHk+bLnh7DZQqy/9q00/UANkltSxWk8xJOlDSmDsr8NeKEkMZsFZiv/48Pxrv DyVw== X-Gm-Message-State: APt69E1mht8BMCYS7jRcUVwoHsHnBS7mHdVC/6pv2N3BEz3c6BOEEfLg d47iJ7dhgyOTBYYnFO3d2wNdNWUx X-Google-Smtp-Source: ADUXVKIdbN+M5Nj7txQSbawGFnBO8DMutdPDj4yMRF+1Ah5UVkJS/al7n91e1kih6jI9n+4gxq0tNQ== X-Received: by 2002:a37:1246:: with SMTP id c67-v6mr1891109qkh.411.1528384285649; Thu, 07 Jun 2018 08:11:25 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id j28-v6sm22638760qtk.56.2018.06.07.08.11.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 08:11:24 -0700 (PDT) Date: Thu, 7 Jun 2018 11:11:13 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Proposal: drop QPACK encoder stream framing Message-ID: <20180607151112.GA28823@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 15:11:31 -0000 Abstract -------- The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00 is unnecessary. For reasons of efficiency, I propose that the framing be removed: let the encoder instructions be written and interpreted as a stream instead. Background ---------- I brought this up during the first day (June 6) of the Kista Interim. Alan explained that there are two reasons for framing the instructions in this way on the encoder stream: 1. Historically, some (or most) HPACK decoders have struggled with input that breaks in the middle of an instruction, as they do not maintain state. 2. The blocks can be used as a clue to send Table State Synchronize instructions on the decoder stream (Section 3.4.1). The downside to having length-prefixed blocks is that it makes it difficult to optimize encoding by writing to the outgoing packets directly. One has to buffer the block, write the block length first, and then copy the block. Additionally, there is a potential for a deadlock (issue #1420). Recall that QPACK owes its current form to the fact that the WG decided to prevent deadlocks at the compression protocol level, and not via advisory notes to the implementers. Reasons Behind the Block ------------------------ First, let's look at the historical HPACK chokers. The HPACK decoder only processes HEADER blocks. There is only one stream and thus only one HEADER block can be processed at a time. The QPACK decoder has to process two inputs: a) the encoder stream and b) HEADER blocks. There is only one encoder stream. This stream modifies the decoder state: the dynamic table. The HEADER blocks do not modify the state. The HEADER blocks already come with a prefix length (HQ framing), and so QPACK implementations can choose to wait until the whole HEADER block is available. It is processing of the encoder stream that is under consideration. With regards to the Table Synch signaling, the draft states that " A decoder MAY " coalesce multiple synchronization updates into a single update. This effectively means that the encoder already should not expect to get a one-to-one mapping between its Encoder Blocks and Table Synchs. Working with the Encoder Stream ------------------------------- The dynamic table instruction stream can be thought of as its own state. Already, the QPACK decoder must be able to pause reading from streams when a blocked HEADERS block arrives. Similar techniques can be used to resume reading from the encoder stream. It should not be difficult to resume decoding a single instruction! While breaking with the HPACK precedent (the hold-my-hand-I-need-buffer-size chokers), it keeps in line with the Seattle hum that the new compression mechanism is free from its HPACK shackles. Conclusion ---------- Prefixing arbitrary sets of encoder instructions with a length denies zero-copy optimization opportunities. At the cost of some slight complexity increase at the decoder, this framing mechanism can be dropped. The proposed change is limited to just this -- technically superfluous -- piece. - Dmitri. P.S. An added bonus is some saved framing bytes on the encoder stream. I believe the "compression performance above everything else" is also the Working Group's consensus (Melbourne). From nobody Thu Jun 7 09:55:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB85F130FD7 for ; Thu, 7 Jun 2018 09:55:39 -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 5fTZVpzmliRE for ; Thu, 7 Jun 2018 09:55:36 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 2AEA4131167 for ; Thu, 7 Jun 2018 09:55:36 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id x6-v6so3439224ybl.12 for ; Thu, 07 Jun 2018 09:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4EqpINRHPoIuDxvcubWR4vpKUMxC64RLziVL6DgFaTo=; b=JHDgexr+meL6mL6FrtCirbgEA1Kl/hjldxi0JRCyUg+BjiKmH7Roh6apLB/BX4NKzu 2sdFGbqemxLI1pKDRjgirtjrhDgAhOdHPQBhZnHCNqTeMBcGsYr79OLNGKQQiSOBX7Xp KLlPplYCR8UeFtqPlJRCc/2pMVUGTrtPvOZEpDnWla0wB4m9/PZJGSVi9DEKCHklGJPv adEHE65eG/HjJ5OAXI0h94qWGdgKwWVkTxGCz9FdotMd28nFM7TDR259xVRA7iqpUeZg rRAg/0NCL0naIdTzkZ7W3wFEzPxcyU5HGbN/3AM+u6kbhlz2slqcFvkEM8XIvTH4L53r QRCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4EqpINRHPoIuDxvcubWR4vpKUMxC64RLziVL6DgFaTo=; b=fOMGIGUHmY+oCHWxeaRcfG4ALPTdrElCbtFkmhZ0gkL0EK7TD9vyh/3yb6gTl+rQE7 vZJqS1iC9lDW40cg++iPl2aY+vwLQgKa0je6273oWfkaoAlmMIiYzZscn4bNjQcxYkG4 a12B5SjqiLozp1rEYi2EXDDdjXODW/aTujAicoVubfiLydxJx+OYpO+nb7FH4PoPwuDt Xiyp02/K9EIK/7gAb5vV+BtD2oPjVpozFdPF+EBLck75PgjbEZmpmNvMab+2sirp0VH7 Qy8zSz5/RYxmIOr/5j40M7OMyqnB35Tl+hKaYZSKONy9BJlH+XGemWIHQGytXI+ff/iq 0vXw== X-Gm-Message-State: APt69E1JEjxmcrnHTiYvk4ZD+9nFxtm1/1IbbP1W6fDNIpHxCMuqSuzk 9qLktBIzdOmKMd21gfsNmloxChI4DlDNm7uMqUcZ6Q== X-Google-Smtp-Source: ADUXVKJWBRPOnsYQMQphSDyuICH7PYU7ZJYQpSIyLYQ3cQOOZ3/Rh2soQz5e/c2+jRGDAQrdnmNUGb7/GEjk5uqOzbI= X-Received: by 2002:a25:9083:: with SMTP id t3-v6mr1554377ybl.71.1528390535030; Thu, 07 Jun 2018 09:55:35 -0700 (PDT) MIME-Version: 1.0 References: <20180607151112.GA28823@ubuntu-dmitri> In-Reply-To: <20180607151112.GA28823@ubuntu-dmitri> From: Spencer Dawkins at IETF Date: Thu, 7 Jun 2018 11:55:23 -0500 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000eb2f21056e10260f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:55:51 -0000 --000000000000eb2f21056e10260f Content-Type: text/plain; charset="UTF-8" Hi, Dmitri, This is me as an individual, asking a question, and NOT making an informed observation or suggestion ... but I was curious. On Thu, Jun 7, 2018 at 10:11 AM Dmitri Tikhonov wrote: > Abstract > -------- > > The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00 > is unnecessary. For reasons of efficiency, I propose that the framing > be removed: let the encoder instructions be written and interpreted as > a stream instead. > [snip] I note that TSVWG currently has two FECFRAME docs in WGLC now: (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ The intent for these documents is to add support for sliding window FEC codes to the RFC 6363 FEC Framework, which was limited to block FEC codes. I don't know whether there is any relationship between your proposal (moving from framing to a stream for compression) and the work currently in TSVWG. I have some guesses, but not well-informed guesses, so thought I should ask. Thanks, Spencer --000000000000eb2f21056e10260f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Dmitri,

This is me as an individual= , asking a question, and NOT making an informed observation or suggestion .= .. but I was curious.

O= n Thu, Jun 7, 2018 at 10:11 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com>= ; wrote:
Abstrac= t
--------

The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00
is unnecessary.=C2=A0 For reasons of efficiency, I propose that the framing=
be removed: let the encoder instructions be written and interpreted as
a stream instead.

[snip]

=
I note that TSVWG=C2=A0 currently has two FECFRAME docs in WGLC = now:



The intent for these documents is to add suppor= t for sliding window FEC codes to the RFC 6363 FEC Framework, which was lim= ited to block FEC codes.

I don't know whether = there is any relationship between your proposal (moving from framing to a s= tream for compression) and the work currently in TSVWG. I have some guesses= , but not well-informed guesses, so thought I should ask.

Thanks,

Spencer
--000000000000eb2f21056e10260f-- From nobody Thu Jun 7 12:03:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC1D1310E9 for ; Thu, 7 Jun 2018 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=litespeedtech-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 Gjl-pRWjbswQ for ; Thu, 7 Jun 2018 12:03:07 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B03B41311A5 for ; Thu, 7 Jun 2018 12:02:34 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x34-v6so10982230qtk.5 for ; Thu, 07 Jun 2018 12:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dDdCKLswTqMvSgQIuSEoNcfsCxm7gib5ldudLmMy4kI=; b=UvbuGamgZ1k9bxRY48HpgEY4Mx8cUc43L5ERk85BBFzSY86zLq/hXUNualSTn9fGhp y1tSV47Ft71nqTNPZIP6PaU8CYJwXoY1b/zy+A4E9zVKobP7Tgdx4mSgZAp9/vr5o7J0 /kkSb3/4AYy3MOYzh6QqmfrHwA6VNpl4Gb3dSSNOheTo7XdbCGn45C21+V+zxeYu41t6 ODyXHufrB9cy0B1S8TjfSXRz4RnLDNjJSJoSWsvpb8s/WlZjl9YRfIWJSuw+zaXZcbtY Rain6UAzkOTdwAKl2GTCyZY5XTnVAZsMfq0IEE3TBKT5l76Aw3r5eCwk1/QxF7j0tH47 xxpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=dDdCKLswTqMvSgQIuSEoNcfsCxm7gib5ldudLmMy4kI=; b=lgcBXymbeLgfl0rCUCfXz011btSyDfvGAqAhYeSsg5ojijKRoGytrE1f9N4vmb8e5Z BwGeQaj7s2P1uQTMZsvc7CaF4dbaHDRTxpAwY4sF+87SLUPZszHsiyT2aFx8Ifz/ka0q 6Dst2uykEmQeYJdVtVITpC7P5mhWqQNWiIpu9iZmjCtiObvBl3usWcE6EqOB1xBEoM8v Srf1uziTU00m1+dyqUZpS/ofR9ih1E3dBEGM8inkm8EkhENBcWa4i28aPBMGXC7L49Zg L9m8XxyP5UgtAPT5h4ez3JmUQRr0Ip6EHnX4XLpTwyrWuYl/lXWPQzUXTw5PjdtjTwAG PrNA== X-Gm-Message-State: APt69E3lx3QG3NTl3S3AIDxSKpxpViRj1AMPrFn2ItQuLxqTpopS3fG8 EU+dHbZ/KmnZorrICWXhxblbzQ== X-Google-Smtp-Source: ADUXVKJfaWFPYOFKxmdfZpyJKdVZU6DXAScWMrfVfGMqvnuiUIz74q7uOX0j0uc4y9oiTkuYK+a0kg== X-Received: by 2002:ac8:329:: with SMTP id q41-v6mr3066464qtg.369.1528398153770; Thu, 07 Jun 2018 12:02:33 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id h23-v6sm13065213qtn.79.2018.06.07.12.02.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 12:02:33 -0700 (PDT) Date: Thu, 7 Jun 2018 15:02:27 -0400 From: Dmitri Tikhonov To: Spencer Dawkins at IETF Cc: IETF QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Message-ID: <20180607190226.GA4187@ubuntu-dmitri> Mail-Followup-To: Spencer Dawkins at IETF , IETF QUIC WG References: <20180607151112.GA28823@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 19:03:15 -0000 Hi Spencer, On Thu, Jun 07, 2018 at 11:55:23AM -0500, Spencer Dawkins at IETF wrote: > This is me as an individual, asking a question, and NOT making an informed > observation or suggestion ... but I was curious. [snip] > I note that TSVWG currently has two FECFRAME docs in WGLC now: > > (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ > > (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ > > The intent for these documents is to add support for sliding window FEC > codes to the RFC 6363 FEC Framework, which was limited to block FEC codes. I have to admit, I have never seen RFC 6363 or the FECFRAME drafts until today. With that said, I believe I understand on high level what they are about after reading the abstracts. > I don't know whether there is any relationship between your proposal > (moving from framing to a stream for compression) and the work currently in > TSVWG. I have some guesses, but not well-informed guesses, so thought I > should ask. There is no relationship to the QPACK framing in question. The QPACK framing mechanism used to write encoder instructions to the encoder QUIC stream is there solely as an aid to the decoder -- evidently with the aim of making the QPACK decoder easier to implement (or to port existing HPACK decoders). Google experimented with FEC in gQUIC but the bandwidth overhead proved to outweigh any advantages offered by ability to reconstruct lost packets and the effort was abandoned, IMMSMC, in 2015. Using FEC in IETF QUIC is something that is interesting to think about. For example, one could envision adding FEC to a critical stream, such as the QPACK encoder stream above, to cope with packet loss. The challenges posed by such approach would be non-trivial and likely require changes to the transport layer. - Dmitri. From nobody Thu Jun 7 13:08:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC30127AC2 for ; Thu, 7 Jun 2018 13:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 48C6Z4IgRigH for ; Thu, 7 Jun 2018 13:08:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 DC288127332 for ; Thu, 7 Jun 2018 13:08:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id s201-v6so3411781ywg.8 for ; Thu, 07 Jun 2018 13:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WbdpEj7saB6JmWB7b+2VLRKDZEISOWz+sbRwBEFtvKg=; b=c9HYGRODS7D3IXIsp+qB/I0kwP3KDL+9jz51tyXv1gqMfbrxjWhnTIxPxrviDH5sNc y75fnwGVKULfouDJFh7mOr95cWKQn1vrJCFJwhbE/SJeUTwionNpkY46QMIuXpgjq9Jw J70Sd2ZWpjHsBRKNjcH+pRwbvvDRbuiBB4gnNXwjDZ9slAp8IWdaTGHAIxC+tHxHJM8w wdNXbCV9Zp09U90/e7UW4evI/6LXNo7cGc9P216EJfFGcCGlN9N3jBV5OQ2XjJQTnZIU nilqVqGUimQuKBTsdR/jHWkyT5HOJaQQlWlA4qxiBmcmjTh2ObnlIPoq+9CUTZYIWa3n wSOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WbdpEj7saB6JmWB7b+2VLRKDZEISOWz+sbRwBEFtvKg=; b=pLyUKzNaxbYdSUhEQMhH6g0v1TsCySRCQntY4gutM5QLzCm0Vz6zATe4MD34cum8Ua uUZ8l6GzdAOhSGdyYdEDhvtDFYOLXzebFGWZ/2eSqhqPyz52wP4pQn5XCso+y7rc1E4n 5Imnh/s72xXEQLDGRXA7JCnyVsfy8Lekt1vTzUdeH33DimptFdZwiBD+gRI1KrhaZUdd 4wgOT3dum4bHuB7O+y1Fm7gIYwCYWxLIh6cGUbJJnKfcB3azaGcS7+wzAGUayy5+F2Q8 tegorTl9DxUfTLwfWMsD7b88pAuY/yzPsY81oFB+7OowDzX78/QGGw7f6XukdN63M5vI 5loA== X-Gm-Message-State: APt69E3pChOsDI/EbBXaimjt0P5cdA9Hofu9rcK51Bt5srRZM2NG+dSF oxoEcluW9YipYsrdxy3JjRoyROD0PRnYZ1bwQ7PtAA== X-Google-Smtp-Source: ADUXVKKrkjSnj/BQ6hzIMArKv+rvXLcT96LcEmamknwZjq41vPzcJCkUa+BiA1PV5YXxjxzJReO0TLJyRzoHLwgh964= X-Received: by 2002:a0d:c745:: with SMTP id j66-v6mr1947642ywd.27.1528402100548; Thu, 07 Jun 2018 13:08:20 -0700 (PDT) MIME-Version: 1.0 References: <20180607151112.GA28823@ubuntu-dmitri> <20180607190226.GA4187@ubuntu-dmitri> In-Reply-To: <20180607190226.GA4187@ubuntu-dmitri> From: Spencer Dawkins at IETF Date: Thu, 7 Jun 2018 15:08:08 -0500 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000046fa26056e12d81f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 20:08:27 -0000 --00000000000046fa26056e12d81f Content-Type: text/plain; charset="UTF-8" Hi, Dmitri, On Thu, Jun 7, 2018 at 2:02 PM Dmitri Tikhonov wrote: > Hi Spencer, > > On Thu, Jun 07, 2018 at 11:55:23AM -0500, Spencer Dawkins at IETF wrote: > > This is me as an individual, asking a question, and NOT making an > informed > > observation or suggestion ... but I was curious. > > [snip] > > > I note that TSVWG currently has two FECFRAME docs in WGLC now: > > > > (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ > > > > (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ > > > > The intent for these documents is to add support for sliding window FEC > > codes to the RFC 6363 FEC Framework, which was limited to block FEC > codes. > > I have to admit, I have never seen RFC 6363 or the FECFRAME drafts until > today. With that said, I believe I understand on high level what they > are about after reading the abstracts. > > > I don't know whether there is any relationship between your proposal > > (moving from framing to a stream for compression) and the work currently > in > > TSVWG. I have some guesses, but not well-informed guesses, so thought I > > should ask. > > There is no relationship to the QPACK framing in question. The QPACK > framing mechanism used to write encoder instructions to the encoder > QUIC stream is there solely as an aid to the decoder -- evidently > with the aim of making the QPACK decoder easier to implement (or to > port existing HPACK decoders). > > Google experimented with FEC in gQUIC but the bandwidth overhead > proved to outweigh any advantages offered by ability to reconstruct > lost packets and the effort was abandoned, IMMSMC, in 2015. > > Using FEC in IETF QUIC is something that is interesting to think about. > For example, one could envision adding FEC to a critical stream, such > as the QPACK encoder stream above, to cope with packet loss. The > challenges posed by such approach would be non-trivial and likely > require changes to the transport layer. > Thanks for this. It's helpful. Spencer - Dmitri. > --00000000000046fa26056e12d81f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Dmitri,=C2=A0

On Thu, Jun 7, 2018 at 2:02 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote= :
Hi Spencer,
On Thu, Jun 07, 2018 at 11:55:23AM -0500, Spencer Dawkins at IETF wrote: > This is me as an individual, asking a question, and NOT making an info= rmed
> observation or suggestion ... but I was curious.

[snip]

> I note that TSVWG=C2=A0 currently has two FECFRAME docs in WGLC now: >
> (1) https://datatracker.ietf.org= /doc/draft-ietf-tsvwg-fecframe-ext/
>
> (2) https://datatracker.ietf.o= rg/doc/draft-ietf-tsvwg-rlc-fec-scheme/
>
> The intent for these documents is to add support for sliding window FE= C
> codes to the RFC 6363 FEC Framework, which was limited to block FEC co= des.

I have to admit, I have never seen RFC 6363 or the FECFRAME drafts until today.=C2=A0 With that said, I believe I understand on high level what they=
are about after reading the abstracts.

> I don't know whether there is any relationship between your propos= al
> (moving from framing to a stream for compression) and the work current= ly in
> TSVWG. I have some guesses, but not well-informed guesses, so thought = I
> should ask.

There is no relationship to the QPACK framing in question.=C2=A0 The QPACK<= br> framing mechanism used to write encoder instructions to the encoder
QUIC stream is there solely as an aid to the decoder -- evidently
with the aim of making the QPACK decoder easier to implement (or to
port existing HPACK decoders).

Google experimented with FEC in gQUIC but the bandwidth overhead
proved to outweigh any advantages offered by ability to reconstruct
lost packets and the effort was abandoned, IMMSMC, in 2015.

Using FEC in IETF QUIC is something that is interesting to think about.
For example, one could envision adding FEC to a critical stream, such
as the QPACK encoder stream above, to cope with packet loss.=C2=A0 The
challenges posed by such approach would be non-trivial and likely
require changes to the transport layer.

Thanks for this. It's helpful.=C2=A0

Spencer=C2=A0

=C2=A0 - Dmitri.
--00000000000046fa26056e12d81f-- From nobody Fri Jun 8 03:12:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B71130E58 for ; Fri, 8 Jun 2018 03:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDgZV9N4zMM4 for ; Fri, 8 Jun 2018 03:12:50 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1505512F18C for ; Fri, 8 Jun 2018 03:12:50 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b130-v6so11314112oif.12 for ; Fri, 08 Jun 2018 03:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AiufiNHatJ2IKD9ND26xVJMlmJgLPxTP100FZD9rA4Q=; b=OIhaaNZ2ah1mnfv2Xne+0gn3rOkjow0D0oFjD66LPbxjYM7NnIv8q8dzu0p3+IUNwm CTnXu0KinCWoSvT1gZZdPpB05ss+fow4s9r7DhiAl1VI13u+UCovt5sob6D6FFjrVt6J D8GXYe3SjqoZbofxuAnIcWUXxa7sKBUnReQVMy3P1YMBYaoH1JdNbsx2N2A0jCDU10Qq XjotnQ3MaiohYGgaeXwr1w6Qj+DTtV7NlCdO1jVt6/gBrVDb3RhhoWjJZNSdPz3O5O6E 2iQARxPR5rPWOi6RtxAkNe22sfSmxuQcbZ8xaKJTYiONIzuBF9FHoLcdmG3qTh5ZBsHD UezA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AiufiNHatJ2IKD9ND26xVJMlmJgLPxTP100FZD9rA4Q=; b=j+rTDMTuWJs2jL0dd847itYP4ct4zpcRIavCc3JL6nKiXJa0fHozePml8tEkVskTb4 fXHPdjUomf0hYxLP0VYlqKsuiS5gqlPvNM4G7CTW60XcjvSo1sfNTqBmoKAx7uG3pYjF b2p+EvRAi4XZc9x8an7T9gF41HP4wcLK9MiBP7zCXx1DRdOXs1TeKWQ6a3gjK2KPlp4m OSKS5RBTiDVSIJedwxr+z1AMHY/RubaDGT3xO36/YAZkd9CDmPEd8Ewna/lxf5GqXx6Y YlacEYaVOgonTTi2pDLW+iRkEkwNe5mSWnAQlCs5BAHEDVfbVhcCh5QLeNYH7Ufo81+o bpnQ== X-Gm-Message-State: APt69E3rEXYNKFgqpqZTgdrxVO026m0SbBobVYUjS1w4ig3ldJeLU1hJ VGEKNFSgxMgkfjphsR7m/0mV5+paNGw8wvXNFDfa8g== X-Google-Smtp-Source: ADUXVKIDyNaKzoP0YY7UQ8ui0dAgTk8VgZBQPzU/VhcdjJF/HlXax0/s2INpp3XUKeQT6Gr3/vkxFHYwpV9M2Ckfv8Q= X-Received: by 2002:aca:51cb:: with SMTP id f194-v6mr2996093oib.110.1528452769078; Fri, 08 Jun 2018 03:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20180607151112.GA28823@ubuntu-dmitri> In-Reply-To: <20180607151112.GA28823@ubuntu-dmitri> From: Martin Thomson Date: Fri, 8 Jun 2018 12:12:38 +0200 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:12:52 -0000 I think that this is a reasonable request and I'd support this. It saves an encoder from having to buffer and it even saves a few octets. The complexity increase (the increased need to delay acknowledgments) is manageable and even encourages good practice - the current design encourages a little bit of laziness because you can acknowledge at the end of each block and have a reasonable expectation of it being approximately correct... most of the time. On Thu, Jun 7, 2018 at 5:11 PM Dmitri Tikhonov wrote: > > Abstract > -------- > > The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00 > is unnecessary. For reasons of efficiency, I propose that the framing > be removed: let the encoder instructions be written and interpreted as > a stream instead. > > Background > ---------- > > I brought this up during the first day (June 6) of the Kista Interim. > Alan explained that there are two reasons for framing the instructions > in this way on the encoder stream: > > 1. Historically, some (or most) HPACK decoders have struggled with > input that breaks in the middle of an instruction, as they do > not maintain state. > > 2. The blocks can be used as a clue to send Table State Synchronize > instructions on the decoder stream (Section 3.4.1). > > The downside to having length-prefixed blocks is that it makes it > difficult to optimize encoding by writing to the outgoing packets > directly. One has to buffer the block, write the block length first, > and then copy the block. > > Additionally, there is a potential for a deadlock (issue #1420). Recall > that QPACK owes its current form to the fact that the WG decided to > prevent deadlocks at the compression protocol level, and not via advisory > notes to the implementers. > > Reasons Behind the Block > ------------------------ > > First, let's look at the historical HPACK chokers. > > The HPACK decoder only processes HEADER blocks. There is only one stream > and thus only one HEADER block can be processed at a time. > > The QPACK decoder has to process two inputs: a) the encoder stream > and b) HEADER blocks. There is only one encoder stream. This stream > modifies the decoder state: the dynamic table. The HEADER blocks do not > modify the state. > > The HEADER blocks already come with a prefix length (HQ framing), and so > QPACK implementations can choose to wait until the whole HEADER block is > available. It is processing of the encoder stream that is under > consideration. > > With regards to the Table Synch signaling, the draft states that > > " A decoder MAY > " coalesce multiple synchronization updates into a single update. > > This effectively means that the encoder already should not expect to get > a one-to-one mapping between its Encoder Blocks and Table Synchs. > > Working with the Encoder Stream > ------------------------------- > > The dynamic table instruction stream can be thought of as its own state. > Already, the QPACK decoder must be able to pause reading from streams when > a blocked HEADERS block arrives. Similar techniques can be used to resume > reading from the encoder stream. It should not be difficult to resume > decoding a single instruction! While breaking with the HPACK precedent > (the hold-my-hand-I-need-buffer-size chokers), it keeps in line with the > Seattle hum that the new compression mechanism is free from its HPACK > shackles. > > Conclusion > ---------- > > Prefixing arbitrary sets of encoder instructions with a length denies > zero-copy optimization opportunities. At the cost of some slight > complexity increase at the decoder, this framing mechanism can be > dropped. The proposed change is limited to just this -- technically > superfluous -- piece. > > - Dmitri. > > P.S. An added bonus is some saved framing bytes on the encoder stream. > I believe the "compression performance above everything else" is > also the Working Group's consensus (Melbourne). > From nobody Fri Jun 8 04:19:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB2130E79 for ; Fri, 8 Jun 2018 04:19:39 -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 x80XvfYX7uze for ; Fri, 8 Jun 2018 04:19:36 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 1B3D9130E78 for ; Fri, 8 Jun 2018 04:19:36 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id z9-v6so8135893plk.11 for ; Fri, 08 Jun 2018 04:19:36 -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=owpED+4WVRFfCBNcn7D8TtzEehf1hLtrDEG86f3lXgk=; b=NxPBADMzZeOKzHTmqkZD88JwPq+WFaeBoPxWdTlTPt2bizAsXpETMAkR5bzprJdSSn 6IIsgENk5ijHgHUtACV2IdhLi4tFe/jpJQNpRhT0oVG0B3dBRAyGk44wj7qAuxlKNALZ O/yHv0JUehqAmL5Cv1zLWyc6kapyPH29WNtsrV7eeoRTj5Ue6fze5l7+XuwxjjxIrkqD QFWb0g78rvLRlE5oUcgMmM3xYdGASF/fO67vep564gC0Yd5j0X+m0H54EpiECUVuHZxx h47gRLEktmcHQk4sNepsU9M2Sj5mWcwOh08RGsuOEfMO51POd3xsjNpBYUf4CgHZMB0A MV5g== 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=owpED+4WVRFfCBNcn7D8TtzEehf1hLtrDEG86f3lXgk=; b=PAzzmLc9ztPotlo9Hb6YuN77tmQDst3+soE1fdYFKpGzws7SWiVlDHcamSdjrXXI3g mxwXmMxrRQmfeg0u2hikC8DS9IUBcBOqHO4FQQZtTFV0L63MqmmlgWXhawu/I+/C0zdN VPhBrvJZs1i9L3gyPtf67Q7mNBm1OfIqg6Qae/zPTKyxz0yIz/2KsXF0ARzsBbpzBhVq Y2CdXyiTIMvz58p0QmrbnYc6ZG8TcTvddPYMnXiftE4STommyMD6B1+n0iMDHWccXDeA tUkD/P4z500Y6SaA5o8BOzbDmge09XMyrCQxu9RepxEi85g8wbenzjj3tfusfZ2NcVC6 i/NQ== X-Gm-Message-State: APt69E1bEGWVR4Ev6NaYUZFNoR8ITJi3xFSt3IFdYzuN9Y6TpqJcGPQj 4TDHIU60Bz4JuAQ3jq3EMqqViJ3lXhMCo72VKRY= X-Google-Smtp-Source: ADUXVKKgz2NH0yYZW0XNQAJXBA9GgzbYMgTWhvAUswUADbA38csc7+cQOyXQI6zyLVXjryDG8nXGnU8xcqaBg8t7V7I= X-Received: by 2002:a17:902:d697:: with SMTP id v23-v6mr6157559ply.193.1528456775632; Fri, 08 Jun 2018 04:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 8 Jun 2018 04:19:35 -0700 (PDT) In-Reply-To: References: <20180607151112.GA28823@ubuntu-dmitri> From: Kazuho Oku Date: Fri, 8 Jun 2018 13:19:35 +0200 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 11:19:40 -0000 2018-06-08 13:12 GMT+03:00 Martin Thomson : > I think that this is a reasonable request and I'd support this. It > saves an encoder from having to buffer and it even saves a few octets. > The complexity increase (the increased need to delay acknowledgments) > is manageable and even encourages good practice - the current design > encourages a little bit of laziness because you can acknowledge at the > end of each block and have a reasonable expectation of it being > approximately correct... most of the time. +1 Previously I had thought that having prefix has the possibility of simplifying the encoder. But I think I was wrong. If we have framing, we need to do either of the following: 1a. buffer the entire frame, and then iterate though the instructions, while checking for every instruction that it does not go beyond the end of the frame 1b. iterate though the instructions as they arrive, while checking that the entire instruction is available and that the instruction does not go beyond the end of the frame If we remove framing, the decoder can be implemented as: 2. iterate through the instructions as they arrive, while checking that the entire instruction is available As you can see, removing the framing simplifies the decoder design. Because it reduces one layer of variable-length encoding. > On Thu, Jun 7, 2018 at 5:11 PM Dmitri Tikhonov > wrote: >> >> Abstract >> -------- >> >> The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00 >> is unnecessary. For reasons of efficiency, I propose that the framing >> be removed: let the encoder instructions be written and interpreted as >> a stream instead. >> >> Background >> ---------- >> >> I brought this up during the first day (June 6) of the Kista Interim. >> Alan explained that there are two reasons for framing the instructions >> in this way on the encoder stream: >> >> 1. Historically, some (or most) HPACK decoders have struggled with >> input that breaks in the middle of an instruction, as they do >> not maintain state. >> >> 2. The blocks can be used as a clue to send Table State Synchronize >> instructions on the decoder stream (Section 3.4.1). >> >> The downside to having length-prefixed blocks is that it makes it >> difficult to optimize encoding by writing to the outgoing packets >> directly. One has to buffer the block, write the block length first, >> and then copy the block. >> >> Additionally, there is a potential for a deadlock (issue #1420). Recall >> that QPACK owes its current form to the fact that the WG decided to >> prevent deadlocks at the compression protocol level, and not via advisory >> notes to the implementers. >> >> Reasons Behind the Block >> ------------------------ >> >> First, let's look at the historical HPACK chokers. >> >> The HPACK decoder only processes HEADER blocks. There is only one stream >> and thus only one HEADER block can be processed at a time. >> >> The QPACK decoder has to process two inputs: a) the encoder stream >> and b) HEADER blocks. There is only one encoder stream. This stream >> modifies the decoder state: the dynamic table. The HEADER blocks do not >> modify the state. >> >> The HEADER blocks already come with a prefix length (HQ framing), and so >> QPACK implementations can choose to wait until the whole HEADER block is >> available. It is processing of the encoder stream that is under >> consideration. >> >> With regards to the Table Synch signaling, the draft states that >> >> " A decoder MAY >> " coalesce multiple synchronization updates into a single update. >> >> This effectively means that the encoder already should not expect to get >> a one-to-one mapping between its Encoder Blocks and Table Synchs. >> >> Working with the Encoder Stream >> ------------------------------- >> >> The dynamic table instruction stream can be thought of as its own state. >> Already, the QPACK decoder must be able to pause reading from streams when >> a blocked HEADERS block arrives. Similar techniques can be used to resume >> reading from the encoder stream. It should not be difficult to resume >> decoding a single instruction! While breaking with the HPACK precedent >> (the hold-my-hand-I-need-buffer-size chokers), it keeps in line with the >> Seattle hum that the new compression mechanism is free from its HPACK >> shackles. >> >> Conclusion >> ---------- >> >> Prefixing arbitrary sets of encoder instructions with a length denies >> zero-copy optimization opportunities. At the cost of some slight >> complexity increase at the decoder, this framing mechanism can be >> dropped. The proposed change is limited to just this -- technically >> superfluous -- piece. >> >> - Dmitri. >> >> P.S. An added bonus is some saved framing bytes on the encoder stream. >> I believe the "compression performance above everything else" is >> also the Working Group's consensus (Melbourne). >> > -- Kazuho Oku From nobody Fri Jun 8 07:51:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAA4130EDA for ; Fri, 8 Jun 2018 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NSLTzJNP1slZ for ; Fri, 8 Jun 2018 07:51:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864D3130E8D for ; Fri, 8 Jun 2018 07:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528469499; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: 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=i1c3GZGBCijJZ5Qgu53sj4aVCwaX5x5aVn70HYAAM/Y=; b=A1VhyXVQIP/PkBcyAsjzxzcDbAMpEJ97GEI9CaPyLuDsMU9oTqNWUpGSS9IxrjQG ldA6kfgvOA6f0GDctx6sMQXbDHviXLtCs7PECswNMlZxaLrR8QGWW8RefIloC2zF VVZXxFIgqt9+cYZX5I6xXyUnhXtI0xRan/+wgo30QWg=; X-AuditID: c1b4fb2d-03f859c0000028db-64-5b1a97fbdc16 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 56.B5.10459.BF79A1B5; Fri, 8 Jun 2018 16:51:39 +0200 (CEST) Received: from [100.94.35.95] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 8 Jun 2018 16:51:39 +0200 Subject: Re: Adding ECN to Transport and Recovery To: References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> From: Magnus Westerlund Message-ID: <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> Date: Fri, 8 Jun 2018 16:51:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7ou7v6VLRBsfeGlj0LOB2YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG/6332AtahSsavm9gbGA8z9/FyMEhIWAicaE5rouRi0NI4Aij xILFD9khnA2MEjs+zmUBKRIWMJTYcdGhi5GTQ0RAWGLDwnNMILaQgL3Exz372EFsNgELiZs/ GtlAbF6g+O81J5hBbBYBFYmdXfNYQWxRgRiJ1Rsvs0PUCEqcnPmEBcTmFHCQuPjxFzPIKmag 3gdby0DCzALyEs1bZzND2OISTV9WskKs1ZZoaOoAsyUElCSuz7vOMoFRcBaSqbMQJs1CMmkW kkkLGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgSG6sEtv3V3MK5+7XiIUYCDUYmH93yr VLQQa2JZcWXuIUYJDmYlEd5nSkAh3pTEyqrUovz4otKc1OJDjNIcLErivHqr9kQJCaQnlqRm p6YWpBbBZJk4OKUaGJPutnw+s1n2ZcjFh9N89fW2Myrlmik+v5KwvS7jcbrwn+biMwtaVtr+ vlKxcnegpdaGrKCUB9du5d1xXmD46nhNTUb9jki+p7JuunfmitwKfWnz3LEi/KGgaGOZ3JY/ E4yi+Vs3tNlt3cn8+/VOy/MOIcZRS1f/6eD547S0x3znH5aHLrtjfymxFGckGmoxFxUnAgDw cPD1UQIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 14:51:44 -0000 WG, The pull request has been updated so that each received CE mark will result in an immediate ACK. This will prevent the uncertainty of CE marks in related to the recovery period assuming no ACK loss, and having a fair chance to avoid the issue also at some ACK loss. Secondly, I have added a security consideration section for ECN related issues. My understanding of the views at the interim was that eliminating the additional ACK_ECN frame was desired. I will next update the pull request to use an updated ACK frame with a signaling bit for the present or absence of the ECN counters. The plan is to steal a bit in the ACK Block count and make that into a fixed 7-bit field rather than a variable length encoding. Limiting an ACK Frame to 128 ACK blocks. Cheers Magnus Den 2018-05-28 kl. 22:29, skrev Magnus Westerlund: > WG, > > I have been working on a Pull Request > (https://github.com/quicwg/base-drafts/pull/1372) that implements the > ECN proposal from the design team > (https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC) into > something reasonably well integrated into the current drafts. Thus, I > think it is time that people review and consider this proposal so that > any issues can be addressed. > > I would very much like to present at the interim this proposal, some > of the choices made, and determine if there are additional changes to > be made before merging this. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB                 | Phone  +46 10 7148287 > Torshamnsgatan 23           | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 8 08:08:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B953A130EE9 for ; Fri, 8 Jun 2018 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 PkZqYg1BOsSH for ; Fri, 8 Jun 2018 08:08:38 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9017D130EDF for ; Fri, 8 Jun 2018 08:08:38 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id k86-v6so8923386qkh.13 for ; Fri, 08 Jun 2018 08:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KXT8gogesKP9x0EIPllSJ2+p3zESi5kCHid3YPUEZkE=; b=KwFzY0q1JCTWKMyKZCLqFM34LBCoZDhvMpBlB2WMNJYE5pZ0uw1YJPJ18Yyb+bmuRg DD6Xk/bd5H0O58m7HZcz98NAqbSI2AtIfIsdBAtVEuFrOk5k412su9fp33ZmiuxoxceF X8+X83jPtbspDZB7LEAy8W4mvfd4iO1c0XeC8dufxlOvK420h0lYoTmtt9LuW42w5jy3 5hYGBjXdJw15nItrqE89Ov+//+Lp7JZXSYFAJjV/oPtU3mmcJPTTR96Jy48kwOGerbqx wtxhhxjN0rjmJ7ifYEOKcWWJxZn6NajIL3Hk1qCESkOuquNqkAFjZDrCs1ZveJqeykIN 8wdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=KXT8gogesKP9x0EIPllSJ2+p3zESi5kCHid3YPUEZkE=; b=UJrezlmNog/2XEFwMaiSWfaTSDPtuzboE+b/KcGMhd8CNQDIwNfJizDLkHws67V70E fZuUhDhWa/2cg02776ODU+aaBX3Vwir81B464JA/L1f0scZGTTDC69Pffr2zEIZ/Cb2Q 5Xpq6LWwRlvK8X57l8E4yi+5Gcm9gDC3MMyPoU+R8kOmRdq30UcCAGeCyHBPw/oSZsoE LQ9L4AxVGTy+VzJdcu2CcZOW3OilvxF9MJQTYenDdZJgpfD/91e05aivDBcsexvfgx0A kDdDIX/OD9KRLCkp1eunjPp/W/Ak5G2pK0pdFwDxOAuSUHN/TgC+WsncZIFYH2QPPOCd kMBw== X-Gm-Message-State: APt69E0PSN+Dl0QIq7juahZgvQvjDv6zIQJOzRIKoYEtwqwIUka46Qxd B6qK6EUnNPa0keZbtDtb2paqvB24 X-Google-Smtp-Source: ADUXVKJaYtbkXnwsxiJt8qeC7HaoNFF7PSnaDfK+4rrS5p5szXetsWOslJi7geGLtd/mHvef6RJNNQ== X-Received: by 2002:a37:951:: with SMTP id 78-v6mr5492855qkj.445.1528470517694; Fri, 08 Jun 2018 08:08:37 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id u22-v6sm29637878qtk.18.2018.06.08.08.08.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 08:08:37 -0700 (PDT) Date: Fri, 8 Jun 2018 11:08:35 -0400 From: Dmitri Tikhonov To: Magnus Westerlund Cc: quic@ietf.org Subject: Re: Adding ECN to Transport and Recovery Message-ID: <20180608150833.GB13418@ubuntu-dmitri> Mail-Followup-To: Magnus Westerlund , quic@ietf.org References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 15:08:42 -0000 On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote: > My understanding of the views at the interim was that eliminating the > additional ACK_ECN frame was desired. That is my understanding as well. > I will next update the pull request to use an updated ACK frame with a > signaling bit for the present or absence of the ECN counters. The plan > is to steal a bit in the ACK Block count and make that into a fixed > 7-bit field rather than a variable length encoding. Limiting an ACK > Frame to 128 ACK blocks. Even though I don't have strong feelings about this, I wonder if there is another way. The ACK frame (Section 7.15 of [draft-ietf-quic-transport-12]) is all varints. Changing a field to a fixed encoding would go against the "flavor of the frame," if one may say so. Perhaps we could keep the varint encoding and interpret the decoded value as an ORed block count with the ECN bit (the low bit)? Introducing an artifial limit to where there was none is a separate discussion. Perhaps 128 blocks is really enough for all practical purposes. And yet: at some point the block limit was removed as we went from gQUIC to IETF QUIC... - Dmitri. From nobody Fri Jun 8 08:39:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9163130EFD for ; Fri, 8 Jun 2018 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 lSOLvq3OORwy for ; Fri, 8 Jun 2018 08:39:22 -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 C1BAE130EF8 for ; Fri, 8 Jun 2018 08:39:21 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id p23-v6so13846972qtn.6 for ; Fri, 08 Jun 2018 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=0huvE4sNNvtzSQ4RYv+c/DCipYOmiATMkGGcyGzmkFI=; b=xFPdjJRxSritu0Tn9Qgs0m3ta5AlM/oWfcBPwyNo/tXHUmUTEnj3QUwadslOjn01x7 QWn7PN1pb2hV3YVbNAUT/jhgNxrCqSR9WH73AVO8xwEZS/GW752LaaemV0HaCZEM03bm ECyPFFswSa7q8pXeRjZPDoXBEXzxOKO6GJ6dDEtYw8E1RXGvVNSj6XxPKZijWyhDD/8E nyYrXiXEa5FUI8ziOPw00x5KZUz89gbRRbUwivdBLiQOYXRWcRXIc1t4gpqUuwMFgbYB W4M6cXwiu4VF6eNJ3CcAYu9fQIBCr+ZS2cll8lZuFsVttBHGVd366YvVuN9UsCHdRpj4 qYTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=0huvE4sNNvtzSQ4RYv+c/DCipYOmiATMkGGcyGzmkFI=; b=LUHrLH9buXMhjiG61WK6+ZVImEAaagLqcokubTsvFjOpOtJAadIapPkRMY+wemF1Kn TvYawjxhgYIUdOogg/O/imd9y+9oWddvNmzsMaMwQWIHEaHXsNRuSHz/0/v73wSRItK/ VBNeZh0MxIk04Qgkzdv8aMH0dLHgsdeYuhE1uqf3/KZbB8bq7YqhEkoQTqPk7WSSssIb Kb5ONeVoKZjwxnpn7NlYQ6q1iRsgI8q1He3fku/SpSgzoeDUL4BrA+cJvtYPcyRIFR/6 kpsIUevm05DM+SWRgKC5kxRTaKVH/higxqT1itchoT8bxVoNh9ztOoBLvRvdVSDiB9tZ 5TIQ== X-Gm-Message-State: APt69E19XUFfx7t83eZI7y4wGvScgqVN78SCJQZnbCmt3Q5rFPoGuTgO G4/tkpMVokmx/zOQ6tU9b+84RM0V X-Google-Smtp-Source: ADUXVKJWRg56JkQA9kRunSBq7FfcCgYpTNVcF5zaFOXf77QXLldH3/0aoLJ/2zt3Y272XMTZKKTS+A== X-Received: by 2002:ac8:2f2c:: with SMTP id j41-v6mr6372043qta.366.1528472360488; Fri, 08 Jun 2018 08:39:20 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id j7-v6sm37377214qth.35.2018.06.08.08.39.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 08:39:19 -0700 (PDT) Date: Fri, 8 Jun 2018 11:39:18 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: What was the QUIC Load Balancers resolution? Message-ID: <20180608153916.GC13418@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 15:39:25 -0000 All, What was the WG resolution with regard to the QUIC Load Balancers proposal? I failed to grasp the outcome of the discussion and the minutes [1] do not have it. Thanks, - Dmitri. 1. https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0RBe9y4c/edit#heading=h.jlkx7yo7rr9h From nobody Fri Jun 8 08:43:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8D130EFE for ; Fri, 8 Jun 2018 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 MyZPT2NY0eko for ; Fri, 8 Jun 2018 08:43:45 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09A5130EFD for ; Fri, 8 Jun 2018 08:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HoknuPoiRrYVC68UruxjluGVQ+OnYInU1/V5ZfKOdHM=; b=nX38fEuTUjWXMBkNwgKJf72iJ/Tos2BuUMY2AnCg3CktAJlPNSG6ilQdDe+qtnlwu3Sm55ZU93fKi85YP8oaX77MpRDrIOgRaIcXSXVSqEYfnC0Dokw5XK0gmuj09jqRE1auHkUwqdWHQUr5XR1ccnwJkWOeIE95gehE3HdMLN4= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4102.namprd08.prod.outlook.com (52.135.195.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Fri, 8 Jun 2018 15:43:43 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0841.015; Fri, 8 Jun 2018 15:43:43 +0000 From: Mike Bishop To: Dmitri Tikhonov , IETF QUIC WG Subject: RE: What was the QUIC Load Balancers resolution? Thread-Topic: What was the QUIC Load Balancers resolution? Thread-Index: AQHT/z7wL6rXHN82VkCiLfPXhYFmKKRWgBMQ Date: Fri, 8 Jun 2018 15:43:42 +0000 Message-ID: References: <20180608153916.GC13418@ubuntu-dmitri> In-Reply-To: <20180608153916.GC13418@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [12.130.119.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4102; 7:AgkxHmea1Pu6fdzsRBdJ4CK6UG/AzoDJMqznUk/wn3WHtXZJQq3evRkjbDRQdE4eacOA8KwjekuqYZE0R/zJZ7ERfMfRqpDUCpd2zjnq3v1qstSyxGgGBlK/UWbKKxiqktlszO5rL4V1Cl7kl2FM45cMB4sgBYqZQeNG9qpCPYFOrFJB0+2BFwTjFIchw8UU5TpkQVmsK9cRu3SE+oiKZ00QJQlzfg2ACz+RbS1R9SNfgAhKJ/Q5GfWZaAM0M7ll x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4102; x-ms-traffictypediagnostic: BYAPR08MB4102: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(119230021023882); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(2016111802025)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4102; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4102; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39380400002)(376002)(366004)(39830400003)(13464003)(189003)(199004)(6436002)(5250100002)(33656002)(106356001)(55016002)(105586002)(66066001)(97736004)(5660300001)(229853002)(2900100001)(68736007)(3846002)(6116002)(102836004)(8936002)(2906002)(11346002)(110136005)(81156014)(81166006)(6246003)(186003)(14454004)(26005)(7736002)(305945005)(76176011)(7696005)(74316002)(410100003)(25786009)(53546011)(486006)(316002)(6506007)(476003)(561944003)(8676002)(446003)(575784001)(478600001)(86362001)(3660700001)(3280700002)(966005)(99286004)(53936002)(6306002)(9686003)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4102; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8vxqOn6XHCWjeOgBqr/x32YZ5+YrvMyT2hHiuUsbeWlo5nRqoh3UDcVFuB6D/IaaB3NK+OSC3PpO7+ssi8LmC3l89M5q8vqpeYQHRVfh9uxjD0iZTAGHRvQhLMlJ9B991twwm5+lE+h9I8sktzClfZcYOvYc4ngEOAHPylOC4osEcbsymhNJ8LqPkKrC5+Uv spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1c6dd57a-a592-4ad1-554b-08d5cd569d3a X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 1c6dd57a-a592-4ad1-554b-08d5cd569d3a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 15:43:42.9459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4102 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 15:43:48 -0000 It wasn't a resolution, just a discussion -- Martin presented the work he's= been doing and asked for people interested in working with him to get in t= ouch. -----Original Message----- From: QUIC On Behalf Of Dmitri Tikhonov Sent: Friday, June 8, 2018 9:39 AM To: IETF QUIC WG Subject: What was the QUIC Load Balancers resolution? All, What was the WG resolution with regard to the QUIC Load Balancers proposal?= I failed to grasp the outcome of the discussion and the minutes [1] do no= t have it. Thanks, - Dmitri. 1. https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0= RBe9y4c/edit#heading=3Dh.jlkx7yo7rr9h From nobody Fri Jun 8 09:40:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C4B130F2C for ; Fri, 8 Jun 2018 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 KfEpTIfgv28F for ; Fri, 8 Jun 2018 09:40:48 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 BC0B0130F29 for ; Fri, 8 Jun 2018 09:40:48 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u124-v6so4318997ywg.0 for ; Fri, 08 Jun 2018 09:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=v8HkgXLCuJag5xa8wNLM7L/OS5GkQt5iaBw1HdVCI7E=; b=NSryLvSlhDerRouzyB59q9R8F9v5HSx+ZG0QQ2DrW+LDvFX4xwiTrxclyppIWJ9Few Q9NBBydreovxhVH+GvaAqQ9fhXrJCwSN1c/dcTeCocDTe7xVPFb5w0h0lcyhG1dKvFiy 0nzcwbfweAdu97lMMn+ERH1T0t2QcX4Qm8uuE4VaG8fdJR91TCZlQW7WVxJ5JR+xyUnZ dyH9k1tevKtLcIbqwOvnOTZAqzlCGTpqOwKIbRqfL0dJWf2hdlr2UG9ZveNuUCImm2Qg 9CBhXMj6/TvXBWsln7v/wz+bFpcWG+rQSjAw/ruXxcZC8VMtLUwDBa9BHlUrCdriQzgG V6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=v8HkgXLCuJag5xa8wNLM7L/OS5GkQt5iaBw1HdVCI7E=; b=VJmmisNy+N47ELxvI5cQmK/w+OuAqKy8RcUWSweRnV4jZoeAPjyWfLsGGXZTryjv1A YfqZ5wBx5EiJZY3uEIG3tiJS2yOuZQdQnGf6pMaERA1nR5yob5o7gNCpn89nLcDlTQwz v6v1eTQ7E1HhacAq7Y2UbZ8nDxzJ8NtkiI4VcBTx8kMUJTwypl9Mxo3FfqeHp5vdUdsh 9Ujdk3QDAEnfsMwPVULsJ1gloBbaWCCX5voHau1PK9TUXCXzi8eHq64W11gv5hnxN2nR hhQOinrl8SXokJhDnK91cT/zJr9VILkSHK2gYGNj3e39BSwPMWcMpbYR0ZFI0YH7ixtV rWQw== X-Gm-Message-State: APt69E23SP45dJDGBQPMErVhU9qpJ1uidIjWy8YlPmJHByWdDw8nWmph A+WO41DJcRyeznO8w0E81kmVs5Q5a7JvajAfVwTXSw== X-Google-Smtp-Source: ADUXVKKMxNoHcMer712wqPyancIu347FYcsQBz+h+IpD/KrCaOUXyISycAauW/xQdvteifbFPyp/w22zHLo7MLdSmBs= X-Received: by 2002:a81:2406:: with SMTP id k6-v6mr1000946ywk.151.1528476047650; Fri, 08 Jun 2018 09:40:47 -0700 (PDT) MIME-Version: 1.0 References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> In-Reply-To: <20180608150833.GB13418@ubuntu-dmitri> From: Ian Swett Date: Fri, 8 Jun 2018 12:40:35 -0400 Message-ID: Subject: Re: Adding ECN to Transport and Recovery To: Magnus Westerlund , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000deed52056e240ff7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 16:40:50 -0000 --000000000000deed52056e240ff7 Content-Type: text/plain; charset="UTF-8" As Dmitri said, the num blocks is currently a varint, it's not a single byte like it was in GQUIC, so stealing a bit from it is a bit awkward and would not change the limit on the number of ack blocks from 256 to 128, and instead it would decrease it from 2^62 to 2^61. Can you make the least significant bit of the ACK frame type indicate whether the ECN section is present, such as by using the 0x0d and 0x0e code points? This is basically equivalent to defining two types, admittedly, but by making the least significant bit the indicator, one could write up the text as a single frame if people prefer that. On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov wrote: > On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote: > > My understanding of the views at the interim was that eliminating the > > additional ACK_ECN frame was desired. > > That is my understanding as well. > > > I will next update the pull request to use an updated ACK frame with a > > signaling bit for the present or absence of the ECN counters. The plan > > is to steal a bit in the ACK Block count and make that into a fixed > > 7-bit field rather than a variable length encoding. Limiting an ACK > > Frame to 128 ACK blocks. > > Even though I don't have strong feelings about this, I wonder if there > is another way. The ACK frame (Section 7.15 of > [draft-ietf-quic-transport-12]) is all varints. Changing a field to a > fixed encoding would go against the "flavor of the frame," if one may > say so. Perhaps we could keep the varint encoding and interpret the > decoded value as an ORed block count with the ECN bit (the low bit)? > > Introducing an artifial limit to where there was none is a separate > discussion. Perhaps 128 blocks is really enough for all practical > purposes. And yet: at some point the block limit was removed as we > went from gQUIC to IETF QUIC... > > - Dmitri. > > --000000000000deed52056e240ff7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Dmitri said, the num blocks is currently a varint, it&#= 39;s not a single byte like it was in GQUIC, so stealing a bit from it is a= bit awkward and would not change the limit on the number of ack blocks fro= m 256 to 128, and instead it would decrease it from 2^62 to 2^61.

<= /div>
Can you make the least significant bit of the ACK frame type indi= cate whether the ECN section is present, such as by using the=C2=A00x0d and= =C2=A00x0e code points?=C2=A0 This is basically equivalent to defining two = types, admittedly, but by making the least significant bit the indicator, o= ne could write up the text as a single frame if people prefer that.

On Fri, Jun 8, 2018 at = 11:08 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote:=
> My understanding of the views at the interim was that eliminating the<= br> > additional ACK_ECN frame was desired.

That is my understanding as well.

> I will next update the pull request to use an updated ACK frame with a=
> signaling bit for the present or absence of the ECN counters. The plan=
> is to steal a bit in the ACK Block count and make that into a fixed > 7-bit field rather than a variable length encoding.=C2=A0 Limiting an = ACK
> Frame to 128 ACK blocks.

Even though I don't have strong feelings about this, I wonder if there<= br> is another way.=C2=A0 The ACK frame (Section 7.15 of
[draft-ietf-quic-transport-12]) is all varints.=C2=A0 Changing a field to a=
fixed encoding would go against the "flavor of the frame," if one= may
say so.=C2=A0 Perhaps we could keep the varint encoding and interpret the decoded value as an ORed block count with the ECN bit (the low bit)?

Introducing an artifial limit to where there was none is a separate
discussion.=C2=A0 Perhaps 128 blocks is really enough for all practical
purposes.=C2=A0 And yet: at some point the block limit was removed as we went from gQUIC to IETF QUIC...

=C2=A0 - Dmitri.

--000000000000deed52056e240ff7-- From nobody Fri Jun 8 11:41:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A35B131002 for ; Fri, 8 Jun 2018 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Kw750e-kVUjO for ; Fri, 8 Jun 2018 11:41:51 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 9F079130F75 for ; Fri, 8 Jun 2018 11:41:51 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id f79-v6so4716781ybg.2 for ; Fri, 08 Jun 2018 11:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l385/Dri+0TniRXMS1z9oBo8cXSCoemVTy6zgj0qfto=; b=QH0tHpzPzWQqpbHICGJcctVAn3h5dGw3Rkt8Ck4jI7P4awfLfZbbJnDx70hat4p/c5 rDNpHmMLrJ+m5PZVJ5KNO2Nki0YgYkcP+om4Txl35zQowAQQzeeDwPRreYwKLASgfIF+ U3RuPvUyqhiWO1YEiLwUVgHbWNZxUKEXTcbfbgHD7TjKg80fcoFNw1ib2VywmKiTqJ28 jwt7rqJ11obXqf8tDp3citLzRVbKZ/8DY4lNa67cEnHGyKxj61u+rC/ku9lxuDC+MB1l 7p9Dg9AU0su98KWfXV1/L4ON+G14gBtqpD1uZGTDKGmnF9ozvJ9GFE3bLGKAoqa+XM3a q5Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l385/Dri+0TniRXMS1z9oBo8cXSCoemVTy6zgj0qfto=; b=nr9Xva87j0lGgc7ayCNwWDdbDfBg6dtTGesg9lJCsunekWQRgjDYSjlyCZiRjNX2K6 WCWunezXyxhyeTNBdkZpjxDeiGUwpM/nNLFRLEwvd1RkoMGLr1QLntosI3VwY44yD14K ZMCTPAYGkqykgkwm36v1mvfY03tcQZDBB2irhLrnwMTfxZKp43altdbrNFr90Do+Wt0h U9HVYSWp/YogOmvFs2rlfSRikwBmKIpDeSSLfRyZF44vQ1qv3/C/Fkr4bpVKfakqgtLu USnQH+xMAIo94FEjk6GoaHGGorfe07GbTj+SXpy5WkHTzf4jTeOQyQR9KYebVhKJsqZV tlIQ== X-Gm-Message-State: APt69E2jncpmkxhOwgFfM4Srq/kSHAG108wT29Jyca53O00vVj6hC5cA jbWr4MTqa6kPMdR12+iBhDet4KJrjCFUalEUqkrbK1ws X-Google-Smtp-Source: ADUXVKJgEVlyexSXjEHsczzfyyUOjaUYF7Ay7VTIfI2R4AmLxjmGqBHB0ZQ7vWjHdAoCjRgn01fe2Rgw/TloHUgQJUU= X-Received: by 2002:a25:cb96:: with SMTP id b144-v6mr4332524ybg.376.1528483310468; Fri, 08 Jun 2018 11:41:50 -0700 (PDT) MIME-Version: 1.0 References: <20180607151112.GA28823@ubuntu-dmitri> In-Reply-To: From: Ian Swett Date: Fri, 8 Jun 2018 14:40:59 -0400 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c4b435056e25c046" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 18:41:55 -0000 --000000000000c4b435056e25c046 Content-Type: text/plain; charset="UTF-8" I'm not as much a QPACK expert as others on this thread, but I do agree that it would be simpler without the length in this case, as well as saving a few bytes. On Fri, Jun 8, 2018 at 7:19 AM Kazuho Oku wrote: > 2018-06-08 13:12 GMT+03:00 Martin Thomson : > > I think that this is a reasonable request and I'd support this. It > > saves an encoder from having to buffer and it even saves a few octets. > > The complexity increase (the increased need to delay acknowledgments) > > is manageable and even encourages good practice - the current design > > encourages a little bit of laziness because you can acknowledge at the > > end of each block and have a reasonable expectation of it being > > approximately correct... most of the time. > > +1 > > Previously I had thought that having prefix has the possibility of > simplifying the encoder. But I think I was wrong. > > If we have framing, we need to do either of the following: > > 1a. buffer the entire frame, and then iterate though the instructions, > while checking for every instruction that it does not go beyond the > end of the frame > 1b. iterate though the instructions as they arrive, while checking > that the entire instruction is available and that the instruction does > not go beyond the end of the frame > > If we remove framing, the decoder can be implemented as: > > 2. iterate through the instructions as they arrive, while checking > that the entire instruction is available > > As you can see, removing the framing simplifies the decoder design. > Because it reduces one layer of variable-length encoding. > > > On Thu, Jun 7, 2018 at 5:11 PM Dmitri Tikhonov > > wrote: > >> > >> Abstract > >> -------- > >> > >> The encoder block specified in Section 3.3 of draft-ietf-quic-qpack-00 > >> is unnecessary. For reasons of efficiency, I propose that the framing > >> be removed: let the encoder instructions be written and interpreted as > >> a stream instead. > >> > >> Background > >> ---------- > >> > >> I brought this up during the first day (June 6) of the Kista Interim. > >> Alan explained that there are two reasons for framing the instructions > >> in this way on the encoder stream: > >> > >> 1. Historically, some (or most) HPACK decoders have struggled with > >> input that breaks in the middle of an instruction, as they do > >> not maintain state. > >> > >> 2. The blocks can be used as a clue to send Table State Synchronize > >> instructions on the decoder stream (Section 3.4.1). > >> > >> The downside to having length-prefixed blocks is that it makes it > >> difficult to optimize encoding by writing to the outgoing packets > >> directly. One has to buffer the block, write the block length first, > >> and then copy the block. > >> > >> Additionally, there is a potential for a deadlock (issue #1420). Recall > >> that QPACK owes its current form to the fact that the WG decided to > >> prevent deadlocks at the compression protocol level, and not via > advisory > >> notes to the implementers. > >> > >> Reasons Behind the Block > >> ------------------------ > >> > >> First, let's look at the historical HPACK chokers. > >> > >> The HPACK decoder only processes HEADER blocks. There is only one > stream > >> and thus only one HEADER block can be processed at a time. > >> > >> The QPACK decoder has to process two inputs: a) the encoder stream > >> and b) HEADER blocks. There is only one encoder stream. This stream > >> modifies the decoder state: the dynamic table. The HEADER blocks do not > >> modify the state. > >> > >> The HEADER blocks already come with a prefix length (HQ framing), and so > >> QPACK implementations can choose to wait until the whole HEADER block is > >> available. It is processing of the encoder stream that is under > >> consideration. > >> > >> With regards to the Table Synch signaling, the draft states that > >> > >> " A decoder MAY > >> " coalesce multiple synchronization updates into a single update. > >> > >> This effectively means that the encoder already should not expect to get > >> a one-to-one mapping between its Encoder Blocks and Table Synchs. > >> > >> Working with the Encoder Stream > >> ------------------------------- > >> > >> The dynamic table instruction stream can be thought of as its own state. > >> Already, the QPACK decoder must be able to pause reading from streams > when > >> a blocked HEADERS block arrives. Similar techniques can be used to > resume > >> reading from the encoder stream. It should not be difficult to resume > >> decoding a single instruction! While breaking with the HPACK precedent > >> (the hold-my-hand-I-need-buffer-size chokers), it keeps in line with the > >> Seattle hum that the new compression mechanism is free from its HPACK > >> shackles. > >> > >> Conclusion > >> ---------- > >> > >> Prefixing arbitrary sets of encoder instructions with a length denies > >> zero-copy optimization opportunities. At the cost of some slight > >> complexity increase at the decoder, this framing mechanism can be > >> dropped. The proposed change is limited to just this -- technically > >> superfluous -- piece. > >> > >> - Dmitri. > >> > >> P.S. An added bonus is some saved framing bytes on the encoder stream. > >> I believe the "compression performance above everything else" is > >> also the Working Group's consensus (Melbourne). > >> > > > > > > -- > Kazuho Oku > > --000000000000c4b435056e25c046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not as much a QPACK expert as others on this threa= d, but I do agree that it would be simpler without the length in this case,= as well as saving a few bytes.

On Fri, Jun 8, 2018 at 7:19 AM Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-08 13:12 GMT+03:00 Martin Thomson <martin.thomson@gmail= .com>:
> I think that this is a reasonable request and I'd support this.=C2= =A0 It
> saves an encoder from having to buffer and it even saves a few octets.=
> The complexity increase (the increased need to delay acknowledgments)<= br> > is manageable and even encourages good practice - the current design > encourages a little bit of laziness because you can acknowledge at the=
> end of each block and have a reasonable expectation of it being
> approximately correct... most of the time.

+1

Previously I had thought that having prefix has the possibility of
simplifying the encoder. But I think I was wrong.

If we have framing, we need to do either of the following:

1a. buffer the entire frame, and then iterate though the instructions,
while checking for every instruction that it does not go beyond the
end of the frame
1b. iterate though the instructions as they arrive, while checking
that the entire instruction is available and that the instruction does
not go beyond the end of the frame

If we remove framing, the decoder can be implemented as:

2. iterate through the instructions as they arrive, while checking
that the entire instruction is available

As you can see, removing the framing simplifies the decoder design.
Because it reduces one layer of variable-length encoding.

> On Thu, Jun 7, 2018 at 5:11 PM Dmitri Tikhonov
> <d= tikhonov@litespeedtech.com> wrote:
>>
>> Abstract
>> --------
>>
>> The encoder block specified in Section 3.3 of draft-ietf-quic-qpac= k-00
>> is unnecessary.=C2=A0 For reasons of efficiency, I propose that th= e framing
>> be removed: let the encoder instructions be written and interprete= d as
>> a stream instead.
>>
>> Background
>> ----------
>>
>> I brought this up during the first day (June 6) of the Kista Inter= im.
>> Alan explained that there are two reasons for framing the instruct= ions
>> in this way on the encoder stream:
>>
>>=C2=A0 =C2=A0 =C2=A01. Historically, some (or most) HPACK decoders = have struggled with
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 input that breaks in the middle of an i= nstruction, as they do
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 not maintain state.
>>
>>=C2=A0 =C2=A0 =C2=A02. The blocks can be used as a clue to send Tab= le State Synchronize
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 instructions on the decoder stream (Sec= tion 3.4.1).
>>
>> The downside to having length-prefixed blocks is that it makes it<= br> >> difficult to optimize encoding by writing to the outgoing packets<= br> >> directly.=C2=A0 One has to buffer the block, write the block lengt= h first,
>> and then copy the block.
>>
>> Additionally, there is a potential for a deadlock (issue #1420).= =C2=A0 Recall
>> that QPACK owes its current form to the fact that the WG decided t= o
>> prevent deadlocks at the compression protocol level, and not via a= dvisory
>> notes to the implementers.
>>
>> Reasons Behind the Block
>> ------------------------
>>
>> First, let's look at the historical HPACK chokers.
>>
>> The HPACK decoder only processes HEADER blocks.=C2=A0 There is onl= y one stream
>> and thus only one HEADER block can be processed at a time.
>>
>> The QPACK decoder has to process two inputs: a) the encoder stream=
>> and b) HEADER blocks.=C2=A0 There is only one encoder stream.=C2= =A0 This stream
>> modifies the decoder state: the dynamic table.=C2=A0 The HEADER bl= ocks do not
>> modify the state.
>>
>> The HEADER blocks already come with a prefix length (HQ framing), = and so
>> QPACK implementations can choose to wait until the whole HEADER bl= ock is
>> available.=C2=A0 It is processing of the encoder stream that is un= der
>> consideration.
>>
>> With regards to the Table Synch signaling, the draft states that >>
>>=C2=A0 "=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0A decoder MAY
>>=C2=A0 " coalesce multiple synchronization updates into a sing= le update.
>>
>> This effectively means that the encoder already should not expect = to get
>> a one-to-one mapping between its Encoder Blocks and Table Synchs.<= br> >>
>> Working with the Encoder Stream
>> -------------------------------
>>
>> The dynamic table instruction stream can be thought of as its own = state.
>> Already, the QPACK decoder must be able to pause reading from stre= ams when
>> a blocked HEADERS block arrives.=C2=A0 Similar techniques can be u= sed to resume
>> reading from the encoder stream.=C2=A0 It should not be difficult = to resume
>> decoding a single instruction!=C2=A0 While breaking with the HPACK= precedent
>> (the hold-my-hand-I-need-buffer-size chokers), it keeps in line wi= th the
>> Seattle hum that the new compression mechanism is free from its HP= ACK
>> shackles.
>>
>> Conclusion
>> ----------
>>
>> Prefixing arbitrary sets of encoder instructions with a length den= ies
>> zero-copy optimization opportunities.=C2=A0 At the cost of some sl= ight
>> complexity increase at the decoder, this framing mechanism can be<= br> >> dropped.=C2=A0 The proposed change is limited to just this -- tech= nically
>> superfluous -- piece.
>>
>>=C2=A0 =C2=A0- Dmitri.
>>
>> P.S.=C2=A0 An added bonus is some saved framing bytes on the encod= er stream.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe the "compression performa= nce above everything else" is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0also the Working Group's consensus (= Melbourne).
>>
>



--
Kazuho Oku

--000000000000c4b435056e25c046-- From nobody Fri Jun 8 13:49:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A3130DC4 for ; Fri, 8 Jun 2018 13:49:44 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=dyqT5hV0; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=KVUQMyrI 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 AEY59_duXJL6 for ; Fri, 8 Jun 2018 13:49:42 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 C6FDC12F1A5 for ; Fri, 8 Jun 2018 13:49:42 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w58KmGET015669; Fri, 8 Jun 2018 13:49:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=8774ZncPc7bQGAAqSw73RaFaTJAKMmER43yGj8Hwbjw=; b=dyqT5hV0GXJlWlow1ks+u/VXd14IyUpIWYgfiL8f8pzd14bPfXz5ox3krhknmy/LHA3T ax1TLSRKxHH4HSN8slKpPumzC2AKtcs/lUlX3CFKkrs+FC1sgJEkhj4axfeNiA1X0Nq6 CTwCvwsSCbB9d9ffpF4Ds0U0XnYQoqaO6uY= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jg007r6ay-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 08 Jun 2018 13:49:40 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 8 Jun 2018 16:49:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8774ZncPc7bQGAAqSw73RaFaTJAKMmER43yGj8Hwbjw=; b=KVUQMyrILd7ITmnhbngjSjFGHMP6mgRmZjz5fGNQHLkIQ1QFEg1uSlS5twArfbIvf7A4bXz01dIz3vxF5dHPlCtBDdhDTvnymAttMtxXej3OMdC2n0Ei/4tapwpoNguzP2GxNm85+/mgIjtc5GzP2UVgBO0/YGy/0IscOn9xyZ8= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) by MWHPR15MB1167.namprd15.prod.outlook.com (10.175.2.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Fri, 8 Jun 2018 20:49:37 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860%4]) with mapi id 15.20.0841.015; Fri, 8 Jun 2018 20:49:37 +0000 From: Alan Frindell To: Kazuho Oku , Martin Thomson CC: QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHqXJJQhdl+r0afCsPvVPdYN6RWJZAAgAAStYCAACnpgA== Date: Fri, 8 Jun 2018 20:49:37 +0000 Message-ID: References: <20180607151112.GA28823@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-originating-ip: [2620:10d:c090:200::6:31fc] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1167; 7:5Tg5u0iXipKWx7rKNLcvGzD+8TllbipJwbFrQDcsGJt8AsvZ/RFOUYiGIQArUhUssJiBxo/jqQHQtTOcF/OFzhKK4nYBqqJI9ThdXil2E5qfK6MWHrjpnNBUFeho4oQ8dmq7FrXkLtatmCaOUkiKbPBhuZH3VLX4QTw1d5z4M+B5nexFyfgPnorG1n/pFD6cOEhiPOS+iG2JCGmavJWE04cbQL0VjRWB62KTX6LQ1hD/m28aSWV+A7KJnifBhOw7; 20:yX9/aFonUC1pDAGIQ1Kbsfq7DiS02IPfRO5RqSWwjPRfcMVqYeGcbRAb8OYB6JoW4F52M87euRgPxjoCSeThKnxrSeKBqY2FUqgWAWum7y0sSRfgbozdWc8I5Wr4BONAD1fe4aKYMuxqbAPy3p1/HfmZfbhWgx9IhFBsmx5iaks= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1167; x-ms-traffictypediagnostic: MWHPR15MB1167: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1167; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1167; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(366004)(376002)(39860400002)(346002)(189003)(199004)(446003)(11346002)(2616005)(486006)(14454004)(105586002)(106356001)(2906002)(46003)(86362001)(58126008)(39060400002)(305945005)(53936002)(6512007)(5660300001)(7736002)(6246003)(83716003)(5250100002)(4326008)(82746002)(110136005)(6486002)(316002)(81156014)(478600001)(8676002)(186003)(102836004)(229853002)(8936002)(3280700002)(97736004)(36756003)(3660700001)(6436002)(81166006)(6506007)(6116002)(476003)(68736007)(33656002)(2900100001)(76176011)(99286004)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1167; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QudqTcagfPNnI/15qwfeq/nCeHQn4jA4s/f7uOn9+tnfSdYoczvWX5eGw+dzez5IIvXUgQLP7hqQ8rJenxTM4PJdluc2HSQT8REUZMshVUxHmUz5t40fS38SDELDjg0GANMIwW3zd7fZKPaig7XwOR1FjSW/tac/adOoHORHcgFReaIJ3vFoMsMNoMDuhIO1 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <46A9CDAC1283D440BBBD3A7576329825@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4f541b21-adeb-4fa6-4fe5-08d5cd815926 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f541b21-adeb-4fa6-4fe5-08d5cd815926 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 20:49:37.1220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1167 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-08_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 20:49:45 -0000 ICAgIDFhLiBidWZmZXIgdGhlIGVudGlyZSBmcmFtZSwgYW5kIHRoZW4gaXRlcmF0ZSB0aG91Z2gg dGhlIGluc3RydWN0aW9ucywNCiAgICB3aGlsZSBjaGVja2luZyBmb3IgZXZlcnkgaW5zdHJ1Y3Rp b24gdGhhdCBpdCBkb2VzIG5vdCBnbyBiZXlvbmQgdGhlDQogICAgZW5kIG9mIHRoZSBmcmFtZQ0K ICAgIDFiLiBpdGVyYXRlIHRob3VnaCB0aGUgaW5zdHJ1Y3Rpb25zIGFzIHRoZXkgYXJyaXZlLCB3 aGlsZSBjaGVja2luZw0KICAgIHRoYXQgdGhlIGVudGlyZSBpbnN0cnVjdGlvbiBpcyBhdmFpbGFi bGUgYW5kIHRoYXQgdGhlIGluc3RydWN0aW9uIGRvZXMNCiAgICBub3QgZ28gYmV5b25kIHRoZSBl bmQgb2YgdGhlIGZyYW1lDQogICAgDQogICAgSWYgd2UgcmVtb3ZlIGZyYW1pbmcsIHRoZSBkZWNv ZGVyIGNhbiBiZSBpbXBsZW1lbnRlZCBhczoNCiAgICANCiAgICAyLiBpdGVyYXRlIHRocm91Z2gg dGhlIGluc3RydWN0aW9ucyBhcyB0aGV5IGFycml2ZSwgd2hpbGUgY2hlY2tpbmcNCiAgICB0aGF0 IHRoZSBlbnRpcmUgaW5zdHJ1Y3Rpb24gaXMgYXZhaWxhYmxlDQoNCkNvbnNpZGVyIHRoZSBtb3N0 IGNvbXBsaWNhdGVkIGluc3RydWN0aW9uLCB3aGljaCBpcyBJbnNlcnRpbmcgYSBwdXJlIGxpdGVy YWwgKGFsbCBmaWVsZHMgaGF2ZSB2YXJpYWJsZSBsZW5ndGgpDQoNCnwgTmFtZSBMZW5ndGggfCBO YW1lIHwgVmFsdWUgTGVuZ3RoIHwgVmFsdWUgfA0KDQpXaGVuIHlvdSBrbm93IHRoZSBsZW5ndGgg b2YgdGhlIGluc3RydWN0aW9uIGJsb2NrIGluIGFkdmFuY2UsIHlvdSBrbm93IHRoYXQgYW4gaW5j b21wbGV0ZSBpbnN0cnVjdGlvbiBpcyBhIGRlY29kaW5nIGVycm9yIHdoaWNoIHlvdSBjYW4gY2hl Y2sgYXMgeW91IGRlY29kZSwgYW5kIGZhaWwgaW1tZWRpYXRlbHkgb24gdW5kZXJmbG93LiAgSGVy ZSwgeW91IGVpdGhlciBuZWVkIHRvIGRvIGEgdHJpYWwgZGVjb2RlIG9mIHRoZSB2YXJpYWJsZSBs ZW5ndGhzIHRvIHNlZSBpZiB5b3UgaGF2ZSBlbm91Z2ggYnl0ZXMsIG9yIGNoZWNrIHdoaWxlIGRl Y29kaW5nLCBhbmQgZGVjaWRlIHdoZXRoZXIgeW91IHdhbnQgdG8gc2F2ZSB0aGUgc3RhdGUgZm9y IGxhdGVyIG9yIGRpc2NhcmQgaXQgYW5kIHJlcGFyc2UgZnJvbSB0aGUgYmVnaW5uaW5nIG9mIHRo ZSBpbnN0cnVjdGlvbi4gIEknbSBub3QgZXZlbiBzdXJlIHJlcGFyc2luZyBpcyB3b3JrYWJsZSBz aW5jZSBpdCBtaWdodCBvcGVuIHlvdSB1cCB0byBkb2luZyBOXjIgd29yayAtLSBhdCBsZWFzdCB5 b3UgbmVlZCB0byBiZSBjYXJlZnVsIGhvdyB5b3UgaW1wbGVtZW50IGl0LiAgSXQncyB3b3J0aCBj YWxsaW5nIG91dCB0aGF0IGRpc2NvdmVyaW5nIHRoZSBsZW5ndGggb2YgYSBRUEFDSyB2YXJpbnQg aXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIGEgUVVJQyB2YXJpbnQuDQogICAgDQpJdOKAmXMgbm90 IGltcG9zc2libGUgdG8gc29sdmUgb2YgY291cnNlLiAg4oCcSXTigJlzIGp1c3Qgc29mdHdhcmXi gJ0gYXMgRG1pdHJpIGxpa2VzIHRvIHNheS4gIEl04oCZcyBqdXN0IG9uZSBwaWVjZSBvZiBjb21w bGV4aXR5IEkgd2FzIGhvcGluZyB0byBhdm9pZC4NCg0KLUFsYW4NCg0K From nobody Fri Jun 8 14:44:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0721130934 for ; Fri, 8 Jun 2018 14:44:26 -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 P2N-qSuqtBGM for ; Fri, 8 Jun 2018 14:44:25 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 5E02C129385 for ; Fri, 8 Jun 2018 14:44:25 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id b17-v6so7263602pfi.0 for ; Fri, 08 Jun 2018 14:44:25 -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=cP/jjiUuMp4KUlwn68ExiWpY0bf/PHADBposgxkOrXY=; b=r4uSz/8w0dtrUaL7FFw7xUJTGhH06hWa9cF4kNx+BrXeIS/X1Q25gRsw/sIJQb/mRT l2lhugoWMdMhM+6QyTLYqOa6koJgd1uyooXhV2WjUlJQof2WF+bLwfzSFMJ8tUH/OXZy 9N2nmGbAlKDCYWq1K8saaY1g+7RiHyiMARpL+bZu1fn5w+EezSA8mEMfF6Cv5eiUkZaG ZwJvQPrA5QB+nQhTj5VPFnzni38MQ5WH4KY/auQnJiNoYinCHnGY3cs7BOcVQUVhrbVZ DtUqxqTFBwGXm2sHRW0RiZXPYKuvva0dgSxFr37+/R+Q6b9eigy7tXsbTgZ0KGMji1Q9 wqtg== 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=cP/jjiUuMp4KUlwn68ExiWpY0bf/PHADBposgxkOrXY=; b=cYqFzhfsfTUUM2oMYehrVdfgUbXcFvGAot+PUtnm9htLsaoPiHlP01KxpNAQv8haGX +kboCnZBZYO691Jud5LpD5B0Q3mJ5rEghnYOSCVICirUYeqiv+3MjBy8KtFKjItpAfGI 9t195HD8wcIByHTvJLzXmMJtXmp5j1fTaRTbKAwqh0rgVTLouCWDiCyNEalrdnygy0ZR TsmUQTmkA31nrYfgNfbyyjrtyz2zGs6+6VTx3fIf5RUqRB3U0KCmH+hczYM+RvZ+x14g +K58mjinXnY/Lm+RvctiObBnZd0TLxzaiCA0I4/CRGwp39LgDiDFlZs05fdY0WULPFE0 TbXA== X-Gm-Message-State: APt69E13LZQHuwQJQ6Smwbdb5NBzcuB+BXp1ixuFeJfqOotEvN71UMPl ve7WAmzqEqSzQQhxk/R26uPMpGCdKA4dByIWvEI= X-Google-Smtp-Source: ADUXVKLMlB8IABDWHny3aOTXGJfzE3te9QV9zFk+HSvcs4jIYDx5pMBW2b05Lm+8GEHLqwfL9/E/TcIfGbmOsv8Rq2k= X-Received: by 2002:a63:a902:: with SMTP id u2-v6mr1656368pge.67.1528494264914; Fri, 08 Jun 2018 14:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 8 Jun 2018 14:44:24 -0700 (PDT) In-Reply-To: References: <20180607151112.GA28823@ubuntu-dmitri> From: Kazuho Oku Date: Sat, 9 Jun 2018 00:44:24 +0300 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: Alan Frindell Cc: Martin Thomson , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 21:44:28 -0000 2018-06-08 23:49 GMT+03:00 Alan Frindell : > 1a. buffer the entire frame, and then iterate though the instructions= , > while checking for every instruction that it does not go beyond the > end of the frame > 1b. iterate though the instructions as they arrive, while checking > that the entire instruction is available and that the instruction doe= s > not go beyond the end of the frame > > If we remove framing, the decoder can be implemented as: > > 2. iterate through the instructions as they arrive, while checking > that the entire instruction is available > > Consider the most complicated instruction, which is Inserting a pure lite= ral (all fields have variable length) > > | Name Length | Name | Value Length | Value | Thank you for bringing up the example. I think this is a very good example, that would help us determine the complexity. > When you know the length of the instruction block in advance, you know th= at an incomplete instruction is a decoding error which you can check as you= decode, and fail immediately on underflow. Here, you either need to do a = trial decode of the variable lengths to see if you have enough bytes, or ch= eck while decoding, and decide whether you want to save the state for later= or discard it and reparse from the beginning of the instruction. I'm not = even sure reparsing is workable since it might open you up to doing N^2 wor= k -- at least you need to be careful how you implement it. It's worth call= ing out that discovering the length of a QPACK varint is more complicated t= han a QUIC varint. Because I think reparsing is the best strategy here, let me argue that the worst case is not O(N^2). Of course, in theory it is O(N^2), because there is no upper bound for the integer representation. But the reality is that implementations are required to have an upper bound. I'd assume that they would typically only permit values that fit in a 32-bit (u)int (16-bit is another option for some). Note that such safe-guard is required even if we have framing. RFC7541; section 5.1 specifically requires HPACK stacks to implement such safe-guard: This integer representation allows for values of indefinite size. It is also possible for an encoder to send a large number of zero values, which can waste octets and could be used to overflow integer values. Integer encodings that exceed implementation limits -- in value or octet length -- MUST be treated as decoding errors. Different limits can be set for each of the different uses of integers, based on implementation constraints. Considering these facts, I would argue that the worst case cost of parsing a Literal header field will remain O(N), and that complexity of the code will remain at least comparable to when having framing (considering the fact that framing is a complexity by itself). > It=E2=80=99s not impossible to solve of course. =E2=80=9CIt=E2=80=99s ju= st software=E2=80=9D as Dmitri likes to say. It=E2=80=99s just one piece o= f complexity I was hoping to avoid. Yeah. It's a trade-off between having more layers to split the issues vs. reducing the numbers of layers to minimize overall complexity. > > -Alan > --=20 Kazuho Oku From nobody Fri Jun 8 15:17:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7D130EC7 for ; Fri, 8 Jun 2018 15:17:20 -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=unavailable 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 DyjzUMW2k2pf for ; Fri, 8 Jun 2018 15:17:15 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBF1131064 for ; Fri, 8 Jun 2018 15:17:15 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id w7-v6so7279283pfn.9 for ; Fri, 08 Jun 2018 15:17:15 -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=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=ic3wIFBRuLXtDNhkKRim+3Cp52Fn/e42ZVEDfVQZsky7+mbAqEICUW9sVLFPRoz77G esXARDN9UHoDQqtQKMAR5W4d65gn7Mo4cOfAbiJoLJDh8vEqNCoTYqiNm1SxuDZzYHcn usfmFQerZc2uNPiJ0ZAF02qSJ85DkkNqd4Tz7st8DO0pl5k4hP9+CCvcWb3LXfqdNejf aNV69amItb5olFzrlZWniNNBQ1TCwfoYAne0j9rJIspbubStgDiUqNwWAXjbzY14d9AO 7K1nt7RveUMLZD+Oc23irHk3Jd+e7IGeRK2gAqXRcIFlfeXrVBC6d8+GQAhVgdMUDFrf iwTw== 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=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=KSU4AWL1X52IXt55CJa7f42+8lzeOT9zg5nHHjc1gG555NDMkRJW5Vhkk/zi97NZ4/ a1WOmeNFHv5wBjNTSgjRoRBIWTkLDLqSoZzpBw6avIYStoH9X6LrK/w3Ev2Cm2V2/5Ic atexHRMyzAkdvAdr8f4fCheIa+nghYBfhB2/riBM9aPPWK9ZvAB7G9UhMk/cRNg/H3pV U3SxMDGQuxh3okzBBCS9jikVs1Lj7mZSJvX4hyGAXGLHanMh37q0fz2A0l3VmZulnjOh tL6jr3NB0Haj1F49SQ/o+6MMjCXklAGhFRT3UymBfNoPDhLbJfFdt0Ou+1jE6bVp2h72 4V3A== X-Gm-Message-State: APt69E343fl+y91dGc+2rmQB15MVL7/fnc+0AIbTrF9SMtxS+ddIPA5H 1jqhp8k6ktkSVFYOLvsEICA9nLm1Kgz6KI8gomI= X-Google-Smtp-Source: ADUXVKI/vZ+3/tBDyb5ilZH3etPD9IvWKq1Q1yDC7xGDfVI+VNwK/dVAJ4NwLHM8tLhxcHg8Fkz3ifaEgfj81+cP/vg= X-Received: by 2002:a63:6e08:: with SMTP id j8-v6mr6684428pgc.428.1528496235075; Fri, 08 Jun 2018 15:17:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 8 Jun 2018 15:17:14 -0700 (PDT) In-Reply-To: References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> From: Kazuho Oku Date: Sat, 9 Jun 2018 01:17:14 +0300 Message-ID: Subject: Re: Adding ECN to Transport and Recovery To: Ian Swett Cc: Magnus Westerlund , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 22:17:21 -0000 2018-06-08 19:40 GMT+03:00 Ian Swett : > As Dmitri said, the num blocks is currently a varint, it's not a single byte > like it was in GQUIC, so stealing a bit from it is a bit awkward and would > not change the limit on the number of ack blocks from 256 to 128, and > instead it would decrease it from 2^62 to 2^61. > > Can you make the least significant bit of the ACK frame type indicate > whether the ECN section is present, such as by using the 0x0d and 0x0e code > points? This is basically equivalent to defining two types, admittedly, but > by making the least significant bit the indicator, one could write up the > text as a single frame if people prefer that. +1 to using different frame types. We do not want to introduce complexity for conserving the frame types. That was the conclusion of the extension discussion, wasn't it? I would prefer having different frame types, unless we find a very clean way of encoding ACK and ACK_ECN using a single frame type. Stealing bits from a varint encoding is a haphazard approach that comes with a complexity. Personally, I doubt if we will ever run out of frames types, considering how we have done so far with TLS ContentType and HTTP/2 frame type. And if we do run out, we have the luxury of renumbering unlike TCP or TLS, because QUIC encrypts the frame types. > > On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov > wrote: >> >> On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote: >> > My understanding of the views at the interim was that eliminating the >> > additional ACK_ECN frame was desired. >> >> That is my understanding as well. >> >> > I will next update the pull request to use an updated ACK frame with a >> > signaling bit for the present or absence of the ECN counters. The plan >> > is to steal a bit in the ACK Block count and make that into a fixed >> > 7-bit field rather than a variable length encoding. Limiting an ACK >> > Frame to 128 ACK blocks. >> >> Even though I don't have strong feelings about this, I wonder if there >> is another way. The ACK frame (Section 7.15 of >> [draft-ietf-quic-transport-12]) is all varints. Changing a field to a >> fixed encoding would go against the "flavor of the frame," if one may >> say so. Perhaps we could keep the varint encoding and interpret the >> decoded value as an ORed block count with the ECN bit (the low bit)? >> >> Introducing an artifial limit to where there was none is a separate >> discussion. Perhaps 128 blocks is really enough for all practical >> purposes. And yet: at some point the block limit was removed as we >> went from gQUIC to IETF QUIC... >> >> - Dmitri. >> > -- Kazuho Oku From nobody Fri Jun 8 16:27:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90235130DC1 for ; Fri, 8 Jun 2018 16:27:13 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=js/qQni5; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CV5lh+Pk 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 W0OR6yy6xkpV for ; Fri, 8 Jun 2018 16:27:12 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 246B0126F72 for ; Fri, 8 Jun 2018 16:27:12 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w58NNFoO010921; Fri, 8 Jun 2018 16:27:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=9srrctTrs2kKHWeOzE9Z+i9BxaezpXUpK/vtdi8YYaw=; b=js/qQni5xufmZ82Maa6pzqJPaRIjSrFONL6dEmWnC4YFsGtP7xTgqcyLOQVAKOsPCZIc aY2srzl9dcQbHi55qtj6pzangTeCAFqTeb/EjgJRoUNIhE+EbM6uz8+43FHbF8wzzLSC NlM+C71IpUMawHon+9PiQ97Bgb5S0izYp1U= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jg007rjbc-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 08 Jun 2018 16:27:09 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 8 Jun 2018 16:26:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9srrctTrs2kKHWeOzE9Z+i9BxaezpXUpK/vtdi8YYaw=; b=CV5lh+PkQvLo2nCMnBko1rXKdfpkhT4YcJat3a2wxnR/sRVd9i+1R2TeyA6t1IcZXZJiEUy06CO7d70Z72UOQhNMFvhiay8qZd8T8kI3dCfCe78YyhCqmUtpSweoGNqIiAqo/6DfsQWT3hkA3NXTdz0YRtg26wZHjPsZb4OS/38= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) by MWHPR15MB1552.namprd15.prod.outlook.com (10.173.235.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Fri, 8 Jun 2018 23:26:55 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860%4]) with mapi id 15.20.0841.015; Fri, 8 Jun 2018 23:26:55 +0000 From: Alan Frindell To: Kazuho Oku CC: Martin Thomson , QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHqXJJQhdl+r0afCsPvVPdYN6RWJZAAgAAStYCAACnpgIAAhKkA//+nSwA= Date: Fri, 8 Jun 2018 23:26:55 +0000 Message-ID: <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> References: <20180607151112.GA28823@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-originating-ip: [2620:10d:c090:200::7:1e0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1552; 7:BxfNXryQURaV1bDaP/g3uy86Lgyq+CttHXowv7T6SDMWOZ6I7bJ7sv2DiT5QJGWlaxHQCAgN+2FivqyxtZ+5kU42ZKI8hQl8JEAvhNqhlWeqTrHIKG7OaC8uHL9ayhhX/y5fL6a8ysafZHGFzZJChtM4Q9ZpvJ4NArtlbF6lECRRPQFNFgrYYOIm5vEuAF5CEioMYbC24761MbAU8eDEB51V6e8jY8oGdkm7oCJmrbhmCQWb6uotEJdvlm+ece33; 20:d7QxjwsyWeg/uXgkOxjKjQr5lutMfyS6p97csdiSV3o/cX2ZkBKKMf07fN26qm7q/I0DAJ4stKgC2TrgG9wrhGEOmEVZniTELd3opX1cfBZ3+Cb2XqYh8PHvUHLGy5ze52LwNbAG9tGhIop1Af3yFcH09p7bV8Unt/sK4dQDLEs= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1552; x-ms-traffictypediagnostic: MWHPR15MB1552: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1552; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1552; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(396003)(366004)(376002)(189003)(199004)(46003)(4326008)(6916009)(1411001)(83716003)(446003)(6436002)(54906003)(33656002)(11346002)(6486002)(8936002)(53936002)(93886005)(86362001)(99286004)(478600001)(6246003)(14454004)(76176011)(6512007)(8676002)(39060400002)(2616005)(2900100001)(186003)(5660300001)(59450400001)(486006)(3660700001)(305945005)(82746002)(6116002)(3280700002)(229853002)(2906002)(7736002)(476003)(81166006)(81156014)(25786009)(5250100002)(68736007)(105586002)(102836004)(36756003)(6506007)(316002)(97736004)(58126008)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1552; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mxz1ajwGYDCo2s7/AbRrODXxMvb3Y8QDQc5rS/kxjDddR+A0V1BTi9+9tpbapo6K/TUevK0nxfItuFKo8nAxaumK8XVN1wFKcUczyJJBpSFGlrsySKItpTiRwSE+Omb9oDcBvKNASGlDsvts5VpRECPe7JrKkDt6are9/F8UZy1imeyrTLevhLqmQNdu3Q9n spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <59D4E207024B39459D6C434F770CDD4C@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 205ae0b1-a95d-41c5-8fb9-08d5cd9752c6 X-MS-Exchange-CrossTenant-Network-Message-Id: 205ae0b1-a95d-41c5-8fb9-08d5cd9752c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 23:26:55.3622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1552 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-08_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 23:27:14 -0000 ICAgIEJlY2F1c2UgSSB0aGluayByZXBhcnNpbmcgaXMgdGhlIGJlc3Qgc3RyYXRlZ3kgaGVyZSwg bGV0IG1lIGFyZ3VlIHRoYXQNCiAgICB0aGUgd29yc3QgY2FzZSBpcyBub3QgTyhOXjIpLg0KICAg IA0KICAgIE9mIGNvdXJzZSwgaW4gdGhlb3J5IGl0IGlzIE8oTl4yKSwgYmVjYXVzZSB0aGVyZSBp cyBubyB1cHBlciBib3VuZCBmb3INCiAgICB0aGUgaW50ZWdlciByZXByZXNlbnRhdGlvbi4gQnV0 IHRoZSByZWFsaXR5IGlzIHRoYXQgaW1wbGVtZW50YXRpb25zDQogICAgYXJlIHJlcXVpcmVkIHRv IGhhdmUgYW4gdXBwZXIgYm91bmQuIEknZCBhc3N1bWUgdGhhdCB0aGV5IHdvdWxkDQogICAgdHlw aWNhbGx5IG9ubHkgcGVybWl0IHZhbHVlcyB0aGF0IGZpdCBpbiBhIDMyLWJpdCAodSlpbnQgKDE2 LWJpdCBpcw0KICAgIGFub3RoZXIgb3B0aW9uIGZvciBzb21lKS4NCg0KVGhlIE8oTl4yKSB3b3Jr IEkgd2FzIHRoaW5raW5nIG9mIHdhcyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpUaGUgZW5jb2Rl ciBzZW5kcyBhIHZlcnkgbG9uZyBIdWZmbWFuIGVuY29kZWQgaGVhZGVyIG5hbWUgZm9sbG93ZWQg YnkgYSBsb25nIHZhbHVlLCBidXQgdGhleSBzZW5kIHRoZSB2YWx1ZSBvbmUgYnl0ZSBhdCBhIHRp bWUuICBJZiB0aGUgZGVjb2RlciBuYWl2ZWx5IHJlcGFyc2VzIHRoZSBlbnRpcmUgSW5zZXJ0IGlu c3RydWN0aW9uIGV2ZXJ5IHRpbWUgYSBieXRlIGFycml2ZXMsIGl0IHdpbGwgZW5kIHVwIEh1ZmZt YW4gZGVjb2RpbmcgdGhlIGhlYWRlciBuYW1lIG9uIGV2ZXJ5IG5ldyBieXRlIG9mIHRoZSB2YWx1 ZS4gIFRoZSBuYW1lIGNhbiBiZSBza2lwcGVkIG92ZXIgdG8gcmUtcGFyc2UgdGhlIHZhbHVlIGxl bmd0aCwgYW5kIHZlcmlmeSBpZiB0aGUgZnVsbCB2YWx1ZSBpcyBwcmVzZW50LiAgSG93ZXZlciwg ZXZlbiBza2lwcGluZyBvdmVyIGl0IG1heSBiZSBhIGxpbmVhciBvcGVyYXRpb24gaW4gYSB6ZXJv LWNvcHkgaW1wbGVtZW50YXRpb24gdGhhdCBtYWludGFpbnMgYSBsaW5rZWQgbGlzdCBvZiBkYXRh IGJ1ZmZlcnMuDQoNCi1BbGFuDQoNCg0K From nobody Fri Jun 8 17:36:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0DE130DFA for ; Fri, 8 Jun 2018 17:36:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 u7pYnd8CRk5Q for ; Fri, 8 Jun 2018 17:36:43 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 490BE130DE4 for ; Fri, 8 Jun 2018 17:36:43 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fRRrz-0006V6-Jj for quic@ietf.org; Sat, 09 Jun 2018 02:36:40 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fRRrt-0006pn-VB for quic@ietf.org; Fri, 08 Jun 2018 20:36:38 -0400 Received: (qmail 15159 invoked from network); 9 Jun 2018 00:36:32 -0000 Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.97]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2018 00:36:32 -0000 To: quic@ietf.org References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> Date: Fri, 8 Jun 2018 17:36:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------57303DE16CC9EE879A1B9469" Content-Language: en-US Subject: Re: Adding ECN to Transport and Recovery X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.38) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5opjpzIzbmRh96R8q3B8Ik9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVifAQXhO2+HSibRNEjbiq3Ks7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYOLJMkQ9To4JqzagQVo4NfUcW/npAtc21 1XqrIPm5MJVz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqutd2F/yaZGqnwJYwSpQ91YE7tCqypI5WX0qWh4YQLCQTFu6teL8aiVr EyEjJND2br8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXekflWG4A3HDBzBq/sLmCzQKHY 6H+wSCoVvwvquzDDiP1kW3XKN6SjV/ce7POAEs6Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 00:36:46 -0000 This is a multi-part message in MIME format. --------------57303DE16CC9EE879A1B9469 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 6/8/2018 3:17 PM, Kazuho Oku wrote: > 2018-06-08 19:40 GMT+03:00 Ian Swett : >> As Dmitri said, the num blocks is currently a varint, it's not a single byte >> like it was in GQUIC, so stealing a bit from it is a bit awkward and would >> not change the limit on the number of ack blocks from 256 to 128, and >> instead it would decrease it from 2^62 to 2^61. >> >> Can you make the least significant bit of the ACK frame type indicate >> whether the ECN section is present, such as by using the 0x0d and 0x0e code >> points? This is basically equivalent to defining two types, admittedly, but >> by making the least significant bit the indicator, one could write up the >> text as a single frame if people prefer that. > +1 to using different frame types. We do not want to introduce > complexity for conserving the frame types. That was the conclusion of > the extension discussion, wasn't it? > > I would prefer having different frame types, unless we find a very > clean way of encoding ACK and ACK_ECN using a single frame type. > Stealing bits from a varint encoding is a haphazard approach that > comes with a complexity. > > Personally, I doubt if we will ever run out of frames types, > considering how we have done so far with TLS ContentType and HTTP/2 > frame type. And if we do run out, we have the luxury of renumbering > unlike TCP or TLS, because QUIC encrypts the frame types. +1. It is much simpler to have two frame types. And in fact is would be better to not try to be too smart, Ian's suggestion of allocating two consecutive types differing by one bit is cute, but it will create incompatibility with the previous versions for which 0xE means "path challenge". Not a very big deal but still annoying, especially if one attempts to support multiple versions while testing the new one. -- Christian Huitema --------------57303DE16CC9EE879A1B9469 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 6/8/2018 3:17 PM, Kazuho Oku wrote:

2018-06-08 19:40 GMT+03:00 Ian Swett <ianswett=40google.com@dmarc.ietf.org>:

As Dmitri said, the num blocks is currently a varint, it's not a single byte
like it was in GQUIC, so stealing a bit from it is a bit awkward and would
not change the limit on the number of ack blocks from 256 to 128, and
instead it would decrease it from 2^62 to 2^61.

Can you make the least significant bit of the ACK frame type indicate
whether the ECN section is present, such as by using the 0x0d and 0x0e code
points?  This is basically equivalent to defining two types, admittedly, but
by making the least significant bit the indicator, one could write up the
text as a single frame if people prefer that.

+1 to using different frame types. We do not want to introduce
complexity for conserving the frame types. That was the conclusion of
the extension discussion, wasn't it?

I would prefer having different frame types, unless we find a very
clean way of encoding ACK and ACK_ECN using a single frame type.
Stealing bits from a varint encoding is a haphazard approach that
comes with a complexity.

Personally, I doubt if we will ever run out of frames types,
considering how we have done so far with TLS ContentType and HTTP/2
frame type. And if we do run out, we have the luxury of renumbering
unlike TCP or TLS, because QUIC encrypts the frame types.

+1. It is much simpler to have two frame types. And in fact is would be better to not try to be too smart, Ian's suggestion of allocating two consecutive types differing by one bit is cute, but it will create incompatibility with the previous versions for which 0xE means "path challenge". Not a very big deal but still annoying, especially if one attempts to support multiple versions while testing the new one.

-- Christian Huitema
--------------57303DE16CC9EE879A1B9469-- From nobody Sat Jun 9 04:25:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C39D1294D0 for ; Sat, 9 Jun 2018 04:25:33 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 gsJuSPHPn7Pm for ; Sat, 9 Jun 2018 04:25:30 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E66B130E4D for ; Sat, 9 Jun 2018 04:25:28 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A8D18340D93; Sat, 9 Jun 2018 13:25:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.2023); Sat, 9 Jun 2018 13:25:24 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Sat, 9 Jun 2018 13:25:23 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 57684075; Sat, 09 Jun 2018 13:25:23 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Adding ECN to Transport and Recovery From: "Brian Trammell (IETF)" In-Reply-To: <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> Date: Sat, 9 Jun 2018 13:25:23 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 11:25:34 -0000 +1 to two frame types; IIRC the suggestion was to add ECN data to the = "normal" ACK frame, then have a diminished ACK frame for situations = where there is no ECN information to report. The concern here is that = having an ACK and an ACK-ECN frame reinforces the incorrect idea that = ECN is somehow optional to implement for QUIC, which it should not be. Half-serious suggestions for the smaller ACK frame included SMACK (small = ACK), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification). Cheers, Brian > On 9 Jun 2018, at 02:36, Christian Huitema = wrote: >=20 > On 6/8/2018 3:17 PM, Kazuho Oku wrote: >> 2018-06-08 19:40 GMT+03:00 Ian Swett = >> : >>=20 >>> As Dmitri said, the num blocks is currently a varint, it's not a = single byte >>> like it was in GQUIC, so stealing a bit from it is a bit awkward and = would >>> not change the limit on the number of ack blocks from 256 to 128, = and >>> instead it would decrease it from 2 >>> 62 to 261 >>> . >>>=20 >>> Can you make the least significant bit of the ACK frame type = indicate >>> whether the ECN section is present, such as by using the 0x0d and = 0x0e code >>> points? This is basically equivalent to defining two types, = admittedly, but >>> by making the least significant bit the indicator, one could write = up the >>> text as a single frame if people prefer that. >>>=20 >> +1 to using different frame types. We do not want to introduce >> complexity for conserving the frame types. That was the conclusion of >> the extension discussion, wasn't it? >>=20 >> I would prefer having different frame types, unless we find a very >> clean way of encoding ACK and ACK_ECN using a single frame type. >> Stealing bits from a varint encoding is a haphazard approach that >> comes with a complexity. >>=20 >> Personally, I doubt if we will ever run out of frames types, >> considering how we have done so far with TLS ContentType and HTTP/2 >> frame type. And if we do run out, we have the luxury of renumbering >> unlike TCP or TLS, because QUIC encrypts the frame types. >>=20 >=20 > +1. It is much simpler to have two frame types. And in fact is would = be better to not try to be too smart, Ian's suggestion of allocating two = consecutive types differing by one bit is cute, but it will create = incompatibility with the previous versions for which 0xE means "path = challenge". Not a very big deal but still annoying, especially if one = attempts to support multiple versions while testing the new one. >=20 > -- Christian Huitema From nobody Sat Jun 9 07:43:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD45D130E8A for ; Sat, 9 Jun 2018 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJu3fNHj3FoD for ; Sat, 9 Jun 2018 07:43:50 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F67130E89 for ; Sat, 9 Jun 2018 07:43:50 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w59Ehmvj021673 for ; Sat, 9 Jun 2018 15:43:48 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0361.001; Sat, 9 Jun 2018 15:43:45 +0100 From: Lucas Pardue To: IETF QUIC WG Subject: Unidirectional stream reservation Thread-Topic: Unidirectional stream reservation Thread-Index: AQHUAABE0LSUozrYCESnhxU00MplGQ== Date: Sat, 9 Jun 2018 14:43:44 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99@bgb01xud1012> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23896.006 x-tm-as-result: No--0.478600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 14:43:53 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99bgb01xud1012_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The discussion in Kista about unidirectional streams focused on not "grabbi= ng" streams that are reserved for control or QPACK. This relates to PR #135= 9. I have an HTTP/QUIC extension proposal [1] that would like to use server-in= itiated unidirectional streams in a dynamic, ad-hoc manner. With the curren= t design, I hoped that I would be ok if I avoided the reserved streams. Wel= l, while working through an implementation, I've realised that HTTP/QUIC se= rver push effectively "grabs" all non-reserved streams. This means that cli= ents would attempt to parse the first byte of my extension stream data as a= Push ID, probably succeed, and subsequently rapidly fail. Patrick made the point in Kista that this is a nice extension point. My vie= w now is that it is necessary, since we can't realistically reserve other s= tream IDs at a later point and will lose this extension capability. Lucas [1] - https://tools.ietf.org/html/draft-pardue-quic-http-unbound-server-pu= sh-00 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99bgb01xud1012_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

The discussion in Kista about unidirectional streams focused on not &q= uot;grabbing" streams that are reserved for control or QPACK. This rel= ates to PR #1359.

I have an HTTP/QUIC extension proposal [1] that would like to use serv= er-initiated unidirectional streams in a dynamic, ad-hoc manner. With the c= urrent design, I hoped that I would be ok if I avoided the reserved streams= . Well, while working through an implementation, I've realised that HTTP/QUIC server push effectively "= ;grabs" all non-reserved streams. This means that clients would attemp= t to parse the first byte of my extension stream data as a Push ID, probabl= y succeed, and subsequently rapidly fail.

Patrick made the point in Kista that this is a nice extension point. M= y view now is that it is necessary, since we can't realistically reserve ot= her stream IDs at a later point and will lose this extension capability.

Lucas

[1]  - https://tools.ietf.org/html/draft-pardue-quic-http-unbound= -server-push-00
--_000_7CF7F94CB496BF4FAB1676F375F9666A3BB4FA99bgb01xud1012_-- From nobody Sat Jun 9 08:28:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17731130EA0 for ; Sat, 9 Jun 2018 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.309 X-Spam-Level: X-Spam-Status: No, score=-16.309 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 TZGEaLEBhUuT for ; Sat, 9 Jun 2018 08:27:59 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BA9130E9E for ; Sat, 9 Jun 2018 08:27:59 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id u124-v6so5058364ywg.0 for ; Sat, 09 Jun 2018 08:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zppV3DHx7ouu95jAElVdyG1z+URLzIMWrGpksUCRUNk=; b=PwS17KHkfHcsnkUXUPZmf/QPHCIQAw8nngmbn8t+hkC3rwXudLtGcW7cqQh9C11U/0 YlOUOyboghHRe614FJhpWSeohVDAEWe2hiZ2uMCkwicDvLcMD7tFu3Xu/AE3O+1fG2zm C5vfP8xR16l2DoZRks3BFVN722PXrpZJmblhJT6veb9SSf9bYQcQcx47cRc7yEdNeNQN AicYWh2uNFHOqk32rOh49EOf1E9YjJwDtLfxhQRaGgJvaxfNqyAqSP16klrrGOscknQ7 RezYAIIFFWTGXK0ZznD6JUUUKZmJ/pt3MXIBgYaHjs6o1vkRIlULiwVXKzZIO2Ud2g+e IFzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zppV3DHx7ouu95jAElVdyG1z+URLzIMWrGpksUCRUNk=; b=XzOYRXMfasbSwqNIlhqpjjPxvu/FaP2H4VvZwJk/5ByGmLmKdNiyKHymRANXdc29/y gxQYckw02+k/7AoOENo+aOSMsX45yhXqpHRyJ+LVL7BZfvC8t1PQkzKxWhPKDodDAebi H50+kicms2xhtOxI4Xl/FIR6RsbNAY/FPHWKOw0TeiavELXZbSGlQoibR5+OojOcqSRC GAnFP2QuUlNkGjT3wQK0aBJSfTt04aHgUDdK9F7uUGAocLtup7LBBIlAmxvMfCXsKA76 fJr0u4j8B82TW8flpXQZF6VMf3q67KAEQ3ux1rmzSzZLCG4QpBAHGD40sHkIx5/12G/H cQnA== X-Gm-Message-State: APt69E0yhTAav1TiqzJ3mSeYR9Lp09Jp6SK/sWAmBWxyVgAcDQFDChRj 7uDlRPXEgQxjUZqcIZnmz1QxRogolgJD6PXNqaikRA== X-Google-Smtp-Source: ADUXVKJ9hjGc7wSvzZxZQgWbpxGMfJNtNnZKphSYB16Fd3Uh1kk8X9topxy9ZpBTfVaJy+OZB8hG9hfdfJYun0XsUPc= X-Received: by 2002:a81:2406:: with SMTP id k6-v6mr3183939ywk.151.1528558077727; Sat, 09 Jun 2018 08:27:57 -0700 (PDT) MIME-Version: 1.0 References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> In-Reply-To: <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> From: Ian Swett Date: Sat, 9 Jun 2018 11:27:45 -0400 Message-ID: Subject: Re: Adding ECN to Transport and Recovery To: Brian Trammell Cc: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000003ea0f4056e37290b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 15:28:01 -0000 --0000000000003ea0f4056e37290b Content-Type: text/plain; charset="UTF-8" QUIC is complex enough, I think we should just call them ACK and ACK_ECN. A few implementations sending at least one ACK_ECN frame per connection will dispel any belief that ACK_ECN is optional. A small amount of use will be a lot more valuable than clever naming. On Sat, Jun 9, 2018 at 7:25 AM Brian Trammell (IETF) wrote: > +1 to two frame types; IIRC the suggestion was to add ECN data to the > "normal" ACK frame, then have a diminished ACK frame for situations where > there is no ECN information to report. The concern here is that having an > ACK and an ACK-ECN frame reinforces the incorrect idea that ECN is somehow > optional to implement for QUIC, which it should not be. > > Half-serious suggestions for the smaller ACK frame included SMACK (small > ACK), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification). > > Cheers, > > Brian > > > On 9 Jun 2018, at 02:36, Christian Huitema wrote: > > > > On 6/8/2018 3:17 PM, Kazuho Oku wrote: > >> 2018-06-08 19:40 GMT+03:00 Ian Swett 40google.com@dmarc.ietf.org> > >> : > >> > >>> As Dmitri said, the num blocks is currently a varint, it's not a > single byte > >>> like it was in GQUIC, so stealing a bit from it is a bit awkward and > would > >>> not change the limit on the number of ack blocks from 256 to 128, and > >>> instead it would decrease it from 2 > >>> 62 to 261 > >>> . > >>> > >>> Can you make the least significant bit of the ACK frame type indicate > >>> whether the ECN section is present, such as by using the 0x0d and 0x0e > code > >>> points? This is basically equivalent to defining two types, > admittedly, but > >>> by making the least significant bit the indicator, one could write up > the > >>> text as a single frame if people prefer that. > >>> > >> +1 to using different frame types. We do not want to introduce > >> complexity for conserving the frame types. That was the conclusion of > >> the extension discussion, wasn't it? > >> > >> I would prefer having different frame types, unless we find a very > >> clean way of encoding ACK and ACK_ECN using a single frame type. > >> Stealing bits from a varint encoding is a haphazard approach that > >> comes with a complexity. > >> > >> Personally, I doubt if we will ever run out of frames types, > >> considering how we have done so far with TLS ContentType and HTTP/2 > >> frame type. And if we do run out, we have the luxury of renumbering > >> unlike TCP or TLS, because QUIC encrypts the frame types. > >> > > > > +1. It is much simpler to have two frame types. And in fact is would be > better to not try to be too smart, Ian's suggestion of allocating two > consecutive types differing by one bit is cute, but it will create > incompatibility with the previous versions for which 0xE means "path > challenge". Not a very big deal but still annoying, especially if one > attempts to support multiple versions while testing the new one. > > > > -- Christian Huitema > > --0000000000003ea0f4056e37290b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
QUIC is complex enough, I think we should just call them A= CK and ACK_ECN.=C2=A0 A few implementations sending at least one ACK_ECN fr= ame per connection will dispel any belief that ACK_ECN is optional.=C2=A0 A= small amount of use will be a lot more valuable than clever naming.
On Sat, Jun 9, 2018 at 7:25 AM= Brian Trammell (IETF) <ietf@trammel= l.ch> wrote:
+1 to two frame= types; IIRC the suggestion was to add ECN data to the "normal" A= CK frame, then have a diminished ACK frame for situations where there is no= ECN information to report. The concern here is that having an ACK and an A= CK-ECN frame reinforces the incorrect idea that ECN is somehow optional to = implement for QUIC, which it should not be.

Half-serious suggestions for the smaller ACK frame included SMACK (small AC= K), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification).

Cheers,

Brian

> On 9 Jun 2018, at 02:36, Christian Huitema <huitema@huitema.net> wrote:
>
> On 6/8/2018 3:17 PM, Kazuho Oku wrote:
>> 2018-06-08 19:40 GMT+03:00 Ian Swett <ianswett=3D40google.com@dmarc.ietf.= org>
>> :
>>
>>> As Dmitri said, the num blocks is currently a varint, it's= not a single byte
>>> like it was in GQUIC, so stealing a bit from it is a bit awkwa= rd and would
>>> not change the limit on the number of ack blocks from 256 to 1= 28, and
>>> instead it would decrease it from 2
>>> 62 to 261
>>> .
>>>
>>> Can you make the least significant bit of the ACK frame type i= ndicate
>>> whether the ECN section is present, such as by using the 0x0d = and 0x0e code
>>> points?=C2=A0 This is basically equivalent to defining two typ= es, admittedly, but
>>> by making the least significant bit the indicator, one could w= rite up the
>>> text as a single frame if people prefer that.
>>>
>> +1 to using different frame types. We do not want to introduce
>> complexity for conserving the frame types. That was the conclusion= of
>> the extension discussion, wasn't it?
>>
>> I would prefer having different frame types, unless we find a very=
>> clean way of encoding ACK and ACK_ECN using a single frame type. >> Stealing bits from a varint encoding is a haphazard approach that<= br> >> comes with a complexity.
>>
>> Personally, I doubt if we will ever run out of frames types,
>> considering how we have done so far with TLS ContentType and HTTP/= 2
>> frame type. And if we do run out, we have the luxury of renumberin= g
>> unlike TCP or TLS, because QUIC encrypts the frame types.
>>
>
> +1. It is much simpler to have two frame types. And in fact is would b= e better to not try to be too smart, Ian's suggestion of allocating two= consecutive types differing by one bit is cute, but it will create incompa= tibility with the previous versions for which 0xE means "path challeng= e". Not a very big deal but still annoying, especially if one attempts= to support multiple versions while testing the new one.
>
> -- Christian Huitema

--0000000000003ea0f4056e37290b-- From nobody Sat Jun 9 08:39:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649E7130EAA for ; Sat, 9 Jun 2018 08:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, 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 oGCiZqx7aC0U for ; Sat, 9 Jun 2018 08:39:05 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D718C130E8D for ; Sat, 9 Jun 2018 08:39:04 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fRfxE-0005A0-Nw for quic@ietf.org; Sat, 09 Jun 2018 17:39:02 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fRfx9-0003Mb-79 for quic@ietf.org; Sat, 09 Jun 2018 11:38:56 -0400 Received: (qmail 26944 invoked from network); 9 Jun 2018 15:38:50 -0000 Received: from unknown (HELO [192.168.0.107]) (Authenticated-user:_huitema@huitema.net@[172.56.42.97]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2018 15:38:50 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Sat, 9 Jun 2018 08:38:48 -0700 Cc: Brian Trammell , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> To: Ian Swett Subject: Re: Adding ECN to Transport and Recovery X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nJ+JO4UM63HucZHpxcj7Fh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViqU2Wy9J7ll15H9pI1pFEBM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBcfHbpla9upwqbpLVZbiC0R/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpV4YM2GxQgsSyTO9ao59sey+YGaFKm4C5XbPm1ymSRhtT90eRDIy2CI MgFAGU8EIfaU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRbLz+Z/8OylBaLzk09eGtkuggKW28pboyZCmKkHUYXanaIbqAgfg7+GDC sLQyQ8LmTTKchEWbWngab8QfMTQnf3tB4/4Pbrz2QtFuyl+Sh6ctJJaoNQlm9OuZnd22I17dfqb5 R4VemuUI6bcEARsm0L3ImxSUHqpGB7nC++w7dpmNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 15:39:07 -0000 =20 > On Jun 9, 2018, at 8:27 AM, Ian Swett wrote: >=20 > QUIC is complex enough, I think we should just call them ACK and ACK_ECN. = A few implementations sending at least one ACK_ECN frame per connection wil= l dispel any belief that ACK_ECN is optional. A small amount of use will be= a lot more valuable than clever naming. Also, ECN is just one of the extensions that could be planned for ACK. Times= tamps would be nice too, for those who want one-way-delay based congestion c= ontrol.=20 -- Christian Huitema=20= From nobody Sat Jun 9 08:55:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BBD130EB2 for ; Sat, 9 Jun 2018 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 m2OB8y92eQjJ for ; Sat, 9 Jun 2018 08:55:38 -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 403E2126DBF for ; Sat, 9 Jun 2018 08:55:38 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id q6-v6so16453910qtn.7 for ; Sat, 09 Jun 2018 08:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=kMhKUCKQF9tcQGwR9NfViYrAQesuQ/p8McxjVB9k9bI=; b=CRpsZH2FbXcFdX4nGg197ABDn0ZUOkLczMVrsTp+oftUKhrE5fY+mTtlApJOGOnv14 jXycKyKoAGYAb3azUx7KEYeWOcjbjk+3rF/Vh8RgqAy0JOp/vDGUNkW1eXglHAFgKXGH 7EDoNFtba8Oy3UeF0hAU6fjFLoJq01ZsU8TQOf9AfOz9UEUde+s5NtbB3kRRzKbK/Mfg LmtgfUQ/RP2KyX68TXyp7cUYkquNz4vr0wykY2eBunzNrHUuuGjxBdvtporCVBTrkZHH yYuHD1OXPbUIHXOD8CUA9AVOFnv8yQhLru11rlh95p7KQoHwTnGw3WXoa6pt1tWSKcW4 eHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=kMhKUCKQF9tcQGwR9NfViYrAQesuQ/p8McxjVB9k9bI=; b=THGJxtr1lfSKveFbchguUJvQRT5+xI+37vfNqAJXqVnYQmoUxnCkG90DquspaFVJdJ fs5ssKo+1WcYr0Rrj2scv4qGfCxfRfVPvCSrY2I5Ey8FJFedbSA52gXZ2p6if6GLe/J+ eDdbcEG3PnuVeWcuHJysjzPoOvOIhJCCD4kysu2BT7AbHfMiBz+6xXKw5cnxq1eGvyA3 wVk+LjdFzXhgZfJ8Vp6Uze3bMonShPrA0T8OEx8nkN8IwWk/Ts66cjwJgAUKMC2XFS1U aiRgjnron2En2MjdQko++/AK8VOa7EVsNNIE1JU/mJSnEU6aZPWetTVru3oKgTPzsInv G78w== X-Gm-Message-State: APt69E38Olub7qCmxLFTrGxZEBGTNsUoV/m3bQn2VsseZHm4cjA4X1M4 FnN0XX2nskenNKkNIJgptmb7vA== X-Google-Smtp-Source: ADUXVKJ0yrWhbF3oCHwx7d04Wy69ECOizABS9Zy/uNqJEiZituubttLhAPNNRMkwr7UT24JPuWA7jw== X-Received: by 2002:ac8:2a39:: with SMTP id k54-v6mr5427530qtk.360.1528559737392; Sat, 09 Jun 2018 08:55:37 -0700 (PDT) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id a24-v6sm21574738qth.70.2018.06.09.08.55.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 08:55:36 -0700 (PDT) Date: Sat, 9 Jun 2018 11:55:31 -0400 From: Dmitri Tikhonov To: Alan Frindell Cc: Kazuho Oku , Martin Thomson , QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Message-ID: <20180609155530.GA6795@ubuntu-dmitri> Mail-Followup-To: Alan Frindell , Kazuho Oku , Martin Thomson , QUIC WG References: <20180607151112.GA28823@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 15:55:40 -0000 On Fri, Jun 08, 2018 at 08:49:37PM +0000, Alan Frindell wrote: > Consider the most complicated instruction, which is Inserting a pure > literal (all fields have variable length) > > | Name Length | Name | Value Length | Value | > > When you know the length of the instruction block in advance, you know > that an incomplete instruction is a decoding error which you can check > as you decode, and fail immediately on underflow. The example above contradicts the argument that follows. It is evident that we have a length followed by an instruction block (the Huffman-encoded string). A QPACK implementation is still free to buffer the instruction blocks, in which case all the perceived advantages of framing you present below are applicable. Parsing of the length is, of course, more complicated than requiring a known number of bytes to be available to read in a fixed-length integer. Nevertheless, as Kazuho points out, there are practical limits whereby most implementations will abide. > Here, you either need to do a trial decode of the variable lengths > to see if you have enough bytes, or check while decoding, and decide > whether you want to save the state for later or discard it and reparse > from the beginning of the instruction. I'm not even sure reparsing > is workable since it might open you up to doing N^2 work -- at least > you need to be careful how you implement it. It's worth calling out > that discovering the length of a QPACK varint is more complicated than > a QUIC varint. An efficient implementation will not just blindly reparse over and over as each byte of the stream data becomes available. With a buffering implementation, the need to reparse disappears if one is willing to allocate the buffer large enough. This is exactly the approach you advocate to use with the current instruction block framing. The proposal to drop framing is to allow an optimization (eliminate a copy) at the encoder, not the decoder. The decoder is still free to use the same programming techniques as before. > It’s not impossible to solve of course. “It’s just software†> as Dmitri likes to say. It’s just one piece of complexity I was > hoping to avoid And I hope I have demonstrated that the complexity increase is minimal. Soon, I will demonstrate the same using C code. - Dmitri. From nobody Sat Jun 9 15:56:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0114A130FB8 for ; Sat, 9 Jun 2018 15:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 nXYMO50CBAWH for ; Sat, 9 Jun 2018 15:56:55 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 C835C130F24 for ; Sat, 9 Jun 2018 15:56:55 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id b74-v6so8348840pfl.5 for ; Sat, 09 Jun 2018 15:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i0LIx8BaWs2rBLtjD1kp71rwdo/EcoIO+ACW4TPsYqQ=; b=P0HNC8SHn2Y5uyYi0/6JcwJ1NbOdR6DSE0trgrNcDumwFuowXCxZ/nrp6ZWGSndpWQ KMQyzAd3oVTVLYR06PHUv4adLMlApL73wV0iee6/jOSwJE/05/RAaAxUzjD/1mEgKrEN tRB2h1HhovWLIHR1+aUapmhCfZq6i7+9RkZj7hajdqPxn9Fr9RIudl5i7T4HFPBF7hQH VMgIwxHgSPLxJLT8t+R7O4eWSvZhv1OZV43rZSbz3CXzOiVq7TdZT1nrYf+ZNACweqig j7KkE0F72jfixqlZIOCsQDANN+R9Ad0mY7vrMddRPydThPbsGBwvB2ieDlRg0rZhW1Lm wirQ== 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=i0LIx8BaWs2rBLtjD1kp71rwdo/EcoIO+ACW4TPsYqQ=; b=WCi8mEbytgBFiKdF+GdGRlq9nVse9C1PnFH1P2R1tw/QgtKzfNa2wkXWaJ2HOMF7wI GDr9yllj+ew7us9bDT63kJvIb6znm6EiAM2C+Sj9iEWXeoYOGuJ4Ie0c/lyUOdsA+7sQ L3l45iqpcWTJZW2iXYrrcTTS/YAYG2kpZzD9VjDgjbI40LLyrbB5GHuN8MKsC0+qRmzo acnhvu3yIh9jjv6QytSPadDJo8AkKSIwit0RmjCo4pl4YKBeI8dXuvzZWXZ4FZ7p+l/O +NENp2IHUUCTM5y1yWluSOQmaZz8DgJW8iQqwPK2jX+x6ZZ34XR2DOfU7KsUlLff2D7V gKcw== X-Gm-Message-State: APt69E1C/VGs3S4Onm/k7m+zKdmWNYlsrT0QKSAFbtxsdjNoCwD8nlCx eftUi05+2hSlx8ziVK0ey7MFQtPDjqOkq9wHUu8= X-Google-Smtp-Source: ADUXVKLtH29y4tkfcXv8t0H7XQccEPhcWKTq7E94C5E5lkh1nsJ3hXppYXP2BT+pAA3ATXqTK9LiR0+xDKGVuUz2NRY= X-Received: by 2002:a63:ba02:: with SMTP id k2-v6mr9936630pgf.179.1528585015247; Sat, 09 Jun 2018 15:56:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sat, 9 Jun 2018 15:56:54 -0700 (PDT) In-Reply-To: <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> References: <20180607151112.GA28823@ubuntu-dmitri> <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> From: Kazuho Oku Date: Sun, 10 Jun 2018 01:56:54 +0300 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: Alan Frindell Cc: Martin Thomson , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 22:56:57 -0000 2018-06-09 8:26 GMT+09:00 Alan Frindell : > Because I think reparsing is the best strategy here, let me argue tha= t > the worst case is not O(N^2). > > Of course, in theory it is O(N^2), because there is no upper bound fo= r > the integer representation. But the reality is that implementations > are required to have an upper bound. I'd assume that they would > typically only permit values that fit in a 32-bit (u)int (16-bit is > another option for some). > > The O(N^2) work I was thinking of was something like this: > > The encoder sends a very long Huffman encoded header name followed by a l= ong value, but they send the value one byte at a time. If the decoder naiv= ely reparses the entire Insert instruction every time a byte arrives, it wi= ll end up Huffman decoding the header name on every new byte of the value. = The name can be skipped over to re-parse the value length, and verify if t= he full value is present. However, even skipping over it may be a linear o= peration in a zero-copy implementation that maintains a linked list of data= buffers. Thank you for the clarification. That sounds like an interesting attack vector that we need to be aware of. OTOH, I am not sure if we need to consider the possibility of streaming Huffman decoding in this discussion, considering the fact that the compressed strings remain length-prefixed. Even if we remove the framing of the QCACK instructions, implementations will continue to have the freedom to buffer a complete Huffman-encoded string (the length of the string being identified by the length octets. > -Alan > > --=20 Kazuho Oku From nobody Sat Jun 9 17:45:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951E0130EB4 for ; Sat, 9 Jun 2018 17:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nWgzGC/U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PxDj0+oz 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 a8mEBEusZbNV for ; Sat, 9 Jun 2018 17:45:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519A513105F for ; Sat, 9 Jun 2018 17:45:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B5FCF218F2 for ; Sat, 9 Jun 2018 20:45:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 09 Jun 2018 20:45:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CyWP2KN4VAHw+NyrD MlIOllE1HzzSMgB37vNZD0N4Xk=; b=nWgzGC/UdUQo3HXEsJRqKyPGog2Hex9ky Jj30y2vt4+1k/gO6KL+B6U0kl3i2VHwIlvdwOJJFAt7fbzxUyu59C3KMqGBkLpQN 4cxIlIl9/TtAm/j2FjboFviYtyMLwrL8ZD4k1ssmxya0rz/IFmQzbLNjYt0Qordk yWnSQF9qowwNZlcOh9jvSzUtkq2FgvdvFhlDKijXBtc8TzyKDBbwoqIti2cYVqFH GobWZ9SLYvAtN42RAycJXBqm8IFaWlTY9F7YuRdiH5pWXcIL+b0yMhlZnlag1iQE oxSiD6B2L83mkAS4RN87zlk49/6gJt3miQn6iEoeF9AYKe5lfd7Jg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=CyWP2KN4VAHw+NyrDMlIOllE1HzzSMgB37vNZD0N4Xk=; b=PxDj0+oz R3NgvX8jZcc7imUrEsPs2NhJsvKbFlq222UXh0O9YClgurqfZSVplF3uZN0UEgIH YahCmcUXPPBzEtoPwZ2mjmgmwmzQLf1FyZMvp7Ez/2bBE+nXIYy41kxuug9LNImx 9yc3fGB50bqqFD7JRolk6ggCTngPdRUK/QOxELk3p0CV1n2W5NB1gKDLV3gVNQdJ 1aNOonAxNWu7Vpsvp15oU1u6SO7UwsGO7mbZxL7OEZTYZ2rxXFS1Jxtl9C3ncwQ8 Pn+Mnl0WSj0pU1bP33VWCqaH0ZPJIBiO+I4SyqA32EhbJcGnxu+si+nXbT5Ttw88 byybGkbiYJCXEQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id BCFC81025D for ; Sat, 9 Jun 2018 20:45:17 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 22155C03FC for ; Sun, 10 Jun 2018 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5045981169035948725==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180610004515.22155C03FC@cloud.mnot.net> Date: Sun, 10 Jun 2018 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 00:45:30 -0000 --===============5045981169035948725== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+11/-17/=F0=9F=92=AC65) 11 issues created: - Interleaved Stream IDs are awkward (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1430 [-transport] [design] = - Idle timeout interaction with RTO (by siyengar) https://github.com/quicwg/base-drafts/issues/1429 = - When the sender is using standard Reno congestion control, ack every ~2= packets (by ianswett) https://github.com/quicwg/base-drafts/issues/1428 [-recovery] = - Detect adversarial ECN reporting (by huitema) https://github.com/quicwg/base-drafts/issues/1426 = - Duplicate detection (by martinthomson) https://github.com/quicwg/base-drafts/issues/1425 = - Stream 0 DT proposal conflicts with PRIORITY (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1421 [-http] [design] = - HTTP/QUIC: "Streams SHOULD be used sequentially, with no gaps." ambigui= ty. (by LPardue) https://github.com/quicwg/base-drafts/issues/1417 = - HTTP/QUIC: are SETTINGS HTTP/QUIC specific? (by LPardue) https://github.com/quicwg/base-drafts/issues/1416 = - HTTP/QUIC: Enhance guidance of using "hq" (by LPardue) https://github.com/quicwg/base-drafts/issues/1415 = - Speed handshake recovery when only undecryptable packets arrive (by ian= swett) https://github.com/quicwg/base-drafts/issues/1414 = - Recovery incorrectly declares packets lost at higher encryption levels = (by ianswett) https://github.com/quicwg/base-drafts/issues/1413 [-recovery] [stream0] = 32 issues received 65 new comments: - #1287 Order of Coalesced Packets (8 by martinthomson, nibanks, mikkelfj= , MikeBishop) https://github.com/quicwg/base-drafts/issues/1287 [-transport] [design]= [needs-discussion] = - #1243 ICMP and ICMPv6 PMTUD with asymmetric connection-ids (6 by kazuho= , martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/1243 [-transport] [design]= [parked] = - #1413 Recovery incorrectly declares packets lost at higher encryption l= evels (5 by mikkelfj, huitema, ianswett) https://github.com/quicwg/base-drafts/issues/1413 [-recovery] [design] = [stream0] = - #1420 encoder stream can deadlock (3 by krasic, afrind, MikeBishop) https://github.com/quicwg/base-drafts/issues/1420 [-qpack] [design] = - #1421 Stream 0 DT proposal conflicts with PRIORITY (3 by martinthomson,= ianswett, mikkelfj) https://github.com/quicwg/base-drafts/issues/1421 [-http] [design] = - #1371 Tracking of header blocks for reset streams (3 by MikeBishop, afr= ind, ianswett) https://github.com/quicwg/base-drafts/issues/1371 [-qpack] [design] = - #1405 Handling of duplicate packets (3 by gloinul, kazuho, huitema) https://github.com/quicwg/base-drafts/issues/1405 [-transport] [design] = - #904 HTTP header compression: static table fit for QUIC (2 by afrind, L= Pardue) https://github.com/quicwg/base-drafts/issues/904 [-qpack] [design] = - #1296 Packet number transform should be negotiated (2 by bobdug, pravb) https://github.com/quicwg/base-drafts/issues/1296 [-transport] [design] = - #1429 Idle timeout interaction with RTO (2 by nibanks, MikeBishop) https://github.com/quicwg/base-drafts/issues/1429 = - #1430 Interleaved Stream IDs are awkward (2 by mikkelfj) https://github.com/quicwg/base-drafts/issues/1430 [-transport] [design] = - #1317 per-CID PN space to avoid PN leak becoming a privacy issue? (2 by= kazuho, janaiyengar) https://github.com/quicwg/base-drafts/issues/1317 = - #1342 Implicit stream open (2 by martinthomson, dtikhonov) https://github.com/quicwg/base-drafts/issues/1342 [-transport] [design] = - #838 Clarify PADDING vs PING frames (2 by igorlord, martinthomson) https://github.com/quicwg/base-drafts/issues/838 [-recovery] [-transpor= t] [design] = - #1230 Stateless Reset needs "on-path" proof (2 by martinthomson, mikkel= fj) https://github.com/quicwg/base-drafts/issues/1230 [-transport] [design] = - #1260 Invariants extensbility (2 by martinthomson, pravb) https://github.com/quicwg/base-drafts/issues/1260 [-invariants] = - #1280 HoLB from NCID frames (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/1280 [-transport] [design] = - #1414 Speed handshake recovery when only undecryptable packets arrive (= 1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1414 [-recovery] [-transpo= rt] [design] [quicv2] = - #1426 Detect adversarial ECN reporting (1 by gorryfair) https://github.com/quicwg/base-drafts/issues/1426 [-transport] [design] = - #269 Public Packet Number Echo (1 by ianswett) https://github.com/quicwg/base-drafts/issues/269 [-transport] [design] = [parked] = - #1209 Use Conservative Initial Packet Size (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1209 [-transport] [design] = - #1343 Static table negotiation (1 by afrind) https://github.com/quicwg/base-drafts/issues/1343 [-qpack] [design] = - #1232 ACKs for receiver-only (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1232 [-transport] [design] = - #1234 Allow repeat ACK's (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1234 [-transport] [design] = - #1148 Replace HPACK integer encoding (1 by afrind) https://github.com/quicwg/base-drafts/issues/1148 [-qpack] [design] = - #1258 Stateless Reset during Path Migration (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1258 [-transport] [design] = - #1264 Stateless Reset processing must be path-bound (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1264 [-transport] [design] = - #1265 error handling for path_response (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/1265 [-transport] [design] = - #1267 Packet protection keys not CID-based (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/1267 [-tls] [design] = - #761 Rejection of 0-RTT: start over? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/761 [-tls] [-transport] [d= esign] = - #1276 Exhausting a supply of connection IDs (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/1276 [-transport] [design] = - #1278 Connection migration failure mode (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/1278 [-transport] [design] = 17 issues closed: - HoLB from NCID frames https://github.com/quicwg/base-drafts/issues/1280= [-transport] [editor-ready] = - Duplicate detection https://github.com/quicwg/base-drafts/issues/1425 = - Flags in HTTP/QUIC frames are wasted space https://github.com/quicwg/ba= se-drafts/issues/1388 [-http] [design] [has-proposal] = - per-CID PN space to avoid PN leak becoming a privacy issue? https://git= hub.com/quicwg/base-drafts/issues/1317 = - Consistent presenting Connection ID in packet or frame https://github.c= om/quicwg/base-drafts/issues/1336 [-transport] [design] = - Packet protection keys not CID-based https://github.com/quicwg/base-dra= fts/issues/1267 [-tls] [design] = - Public Packet Number Echo https://github.com/quicwg/base-drafts/issues/= 269 [-transport] [design] [parked] = - quic_transport_parameters code point https://github.com/quicwg/base-dra= fts/issues/1395 [-tls] = - Stateless Reset processing must be path-bound https://github.com/quicwg= /base-drafts/issues/1264 [-transport] [design] = - Invariants extensbility https://github.com/quicwg/base-drafts/issues/12= 60 [-invariants] = - Stateless Reset during Path Migration https://github.com/quicwg/base-dr= afts/issues/1258 [-transport] [design] = - Allow repeat ACK's https://github.com/quicwg/base-drafts/issues/1234 [-= transport] [design] = - ACKs for receiver-only https://github.com/quicwg/base-drafts/issues/123= 2 [-transport] [design] = - Use Conservative Initial Packet Size https://github.com/quicwg/base-dra= fts/issues/1209 [-transport] [design] = - Replace HPACK integer encoding https://github.com/quicwg/base-drafts/is= sues/1148 [-qpack] [design] = - Writing after closed frame enqueued https://github.com/quicwg/base-draf= ts/issues/777 [-transport] [design] = - Rejection of 0-RTT: start over? https://github.com/quicwg/base-drafts/i= ssues/761 [-tls] [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+7/-4/=F0=9F=92=AC10) 7 pull requests submitted: - fix typo (by ami-GS) https://github.com/quicwg/base-drafts/pull/1433 = - Move stream type into frame type (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1431 [-transport] [design] = - Coalescing guidance (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1423 [-transport] [design] = - Remove sequence number from NEW_CONNECTION_ID (by martinthomson) https://github.com/quicwg/base-drafts/pull/1419 [-transport] = - Add PUSH_PROMISE xref (by LPardue) https://github.com/quicwg/base-drafts/pull/1418 = - Updated ICMP PMTU section (by igorlord) https://github.com/quicwg/base-drafts/pull/1412 = - Describe QPACK Feedback mechanisms (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1410 [-qpack] [design] = 4 pull requests received 10 new comments: - #1431 Move stream type into frame type (6 by martinthomson, MikeBishop,= mikkelfj, LPardue, ianswett) https://github.com/quicwg/base-drafts/pull/1431 [-transport] [design] = - #1423 Coalescing guidance (2 by MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/pull/1423 [-transport] [design] = - #1419 Remove sequence number from NEW_CONNECTION_ID (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1419 [-transport] = - #1359 Unidirectional Stream Headers in HTTP (1 by LPardue) https://github.com/quicwg/base-drafts/pull/1359 [-http] [-qpack] [desig= n] = 4 pull requests merged: - Remove sequence number from NEW_CONNECTION_ID https://github.com/quicwg/base-drafts/pull/1419 [-transport] = - fix typo https://github.com/quicwg/base-drafts/pull/1433 = - Remove Flags https://github.com/quicwg/base-drafts/pull/1398 [-http] [design] = - Set TLS extension codepoint to 0xffa5 https://github.com/quicwg/base-drafts/pull/1402 [-tls] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============5045981169035948725== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 10, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+11/-17/=F0=9F=92=AC65)

11 issues created:

32 issues received 65 new comments:

17 issues closed:

Pull requests

quicwg/base-drafts (+7/-4/=F0=9F=92=AC10)

7 pull requests submitted:

4 pull requests received 10 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============5045981169035948725==-- From nobody Sun Jun 10 10:14:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A32130E94 for ; Sun, 10 Jun 2018 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhK7ZV7HwfZ3 for ; Sun, 10 Jun 2018 10:14:41 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 982E3130E7C for ; Sun, 10 Jun 2018 10:14:41 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g7-v6so21276690ioh.11 for ; Sun, 10 Jun 2018 10:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wq3feLZWLz22iPckhhgVTPmkQ0uLDkwAyVuPpiMFX7M=; b=SlQYr+1f8IhP/m6zs6zg7ZRX0yTmIFCBz1ntN1SxNIzZlTTz1hgSQMQUaeOrjdMDUW 2zK9vA9Z3iUVNsHgdccZyEB7D4Iqgr+yb9Bvt8yjsCYmdBK3LYfsp3x0arOQcx0oSBQo tTaJXZwqFLqF8+SQxh4MyNWIeDfPmq6MKp30o+zgh34SP71z9EfMWW9zTOu3kownVVIX TQhsZikF0Q/Y1bIuA8tBw32bKsCTWOTLZjIFoYR94Ckmbyx1pRIrMjxQyRIQX9TFWb/i fAbaHcwANPtIVi6shfxTZrbYaG2EQJ0fsOtB7g6VCy22H7dYsEcrr/wfF5YM6PTh9BUf Smbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wq3feLZWLz22iPckhhgVTPmkQ0uLDkwAyVuPpiMFX7M=; b=dVPrqU8DqHREkgZHM1p6RNP5oBMcH5Lu2MbaZ/P82HvepD3mEAN/0SZDHb7uXcdbQO Ebq1dVkYDOMlD0omYg3Vk4Bcy6mE01u5X1u2TNIJaxLJNuqLrNw2h2iv4kK3Cvb6DbG7 wMl5IC2lpBmVsvRYdfR/TWtP1KqCR+oL0YA+KqjfpI2tvOOG/sy5nFMaGsNpnK86E0dr uUAb1Ryx2L6MZ05B4wkV/K7npdmpzCnWHzarrsPr9yNDHxku23RM9Pb7PFiR+rHjB8PN T0faZSihUJueoU4B0qpc4WkLb1yrhUP5pd/dgFd/dwS6xcJhEbpZefY8jsP2jsRm979E r5Ew== X-Gm-Message-State: APt69E2Stz0FaC4obOpyGYE5KEzNpYrxNMUajWZvEp5SRzc0kGTt+PRA R34wv5E5PAapQoBJe3qyiKKCjCLs0X3jZq1Izzg= X-Google-Smtp-Source: ADUXVKJO0f3VzponGSbASvrG25Zr16/VYVQRr7uNFvVA5ewE4a8/3NP9ikZKpVIz6GwKDMDXapoDe0Rn85wcvxp1+BY= X-Received: by 2002:a6b:8d05:: with SMTP id p5-v6mr4913929iod.59.1528650880947; Sun, 10 Jun 2018 10:14:40 -0700 (PDT) MIME-Version: 1.0 References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> In-Reply-To: <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> From: Jana Iyengar Date: Sun, 10 Jun 2018 10:14:30 -0700 Message-ID: Subject: Re: Adding ECN to Transport and Recovery To: Christian Huitema Cc: Ian Swett , "Brian Trammell (IETF)" , QUIC WG Content-Type: multipart/alternative; boundary="000000000000be98f6056e4cc4fb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 17:14:43 -0000 --000000000000be98f6056e4cc4fb Content-Type: text/plain; charset="UTF-8" Sounds like there's general agreement that modifying the varint to contain a flag bit will add unnecessary complexity. Let's try to get the PR in as it is now, and if anyone really wants to go merge this and the ACK frame or rename things, let's paint that bikeshed separately. On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema wrote: > > > > On Jun 9, 2018, at 8:27 AM, Ian Swett wrote: > > > > QUIC is complex enough, I think we should just call them ACK and > ACK_ECN. A few implementations sending at least one ACK_ECN frame per > connection will dispel any belief that ACK_ECN is optional. A small amount > of use will be a lot more valuable than clever naming. > > Also, ECN is just one of the extensions that could be planned for ACK. > Timestamps would be nice too, for those who want one-way-delay based > congestion control. > > -- Christian Huitema > --000000000000be98f6056e4cc4fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds like there's general agreement that modify= ing the varint to contain a flag bit will add unnecessary complexity.=C2=A0=
Let's try to get the PR in as it is now, and if anyone really wants= to go merge this and the ACK frame or rename things, let's paint that = bikeshed separately.



On Sat, Jun 9, 201= 8 at 8:39 AM Christian Huitema <h= uitema@huitema.net> wrote:
= =C2=A0

> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_E= CN.=C2=A0 A few implementations sending at least one ACK_ECN frame per conn= ection will dispel any belief that ACK_ECN is optional.=C2=A0 A small amoun= t of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Time= stamps would be nice too, for those who want one-way-delay based congestion= control.

-- Christian Huitema
--000000000000be98f6056e4cc4fb-- From nobody Sun Jun 10 16:16:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5005C130F25 for ; Sun, 10 Jun 2018 16:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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=evequefou.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 NWkXwAypYIwZ for ; Sun, 10 Jun 2018 16:16:05 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700111.outbound.protection.outlook.com [40.107.70.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC49130EDE for ; Sun, 10 Jun 2018 16:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y6DQbI7O55Bx2BE8ouMkh5kbj9apuYeSba1jGzI18nA=; b=IJPTpcvgi4tyRXrFPYMSHz15tTKZV1RNShOaseyj8rV+OCLPqdtSvv3pcT9eWm75ux43VcAwSYAepDUuCLZaGCigjwD5xxv8HRXjNDF1ZsojiP7KbUVJpq5SC2Cw+DJavb14f6nLJkM3orAIYoKSoBygRjDDRf+LC3e1eMQs5HQ= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4150.namprd08.prod.outlook.com (52.135.196.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Sun, 10 Jun 2018 23:15:59 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0841.019; Sun, 10 Jun 2018 23:15:59 +0000 From: Mike Bishop To: Kazuho Oku , Alan Frindell CC: QUIC WG , Martin Thomson Subject: RE: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHe+1l0+zihD0qpT4Ov4UtYwaRWJZAAgAAStYCAAJ9EgIAAD04AgAAcpYCAAYnyAIABlE8Q Date: Sun, 10 Jun 2018 23:15:59 +0000 Message-ID: References: <20180607151112.GA28823@ubuntu-dmitri> <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:600:8080:5a28:8d18:eaf1:e372:5b55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4150; 7:bfg91XZch+8oeuwhjrdEM4WPAfeG2kMOj8Qwwaq67SH8crEDciIQZhdIX5du5tbyI8U1ttkJAM96Ajn9mF3yKL4soVgLmi6rKxfiyifrOdBRbgg1EAxY7VlJrEwLVFp8/VGhFiHLfsUA3XXCkOAT29m4IsRPme614m7xmAoxBE5T/w8UVbWaJggeNk46Cz11aP+oxYX3rlLlioZS7qsOgCPWfu/hshrqMqacu9LJn0QsZ8hIX+Ju1i1SFxU8zDxi x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4150; x-ms-traffictypediagnostic: BYAPR08MB4150: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(2016111802025)(20161123560045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4150; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4150; x-forefront-prvs: 0699FCD394 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39830400003)(346002)(39380400002)(13464003)(199004)(189003)(97736004)(6246003)(6306002)(54896002)(46003)(68736007)(5660300001)(478600001)(5250100002)(105586002)(790700001)(74316002)(86362001)(25786009)(6116002)(236005)(93886005)(106356001)(55016002)(2900100001)(9686003)(7696005)(4326008)(59450400001)(39060400002)(7736002)(110136005)(53546011)(3660700001)(33656002)(99286004)(81156014)(81166006)(486006)(476003)(3280700002)(8936002)(102836004)(561944003)(2906002)(6506007)(8676002)(54906003)(316002)(345774005)(74482002)(14454004)(186003)(53936002)(229853002)(446003)(11346002)(6436002)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4150; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: iacVP6TZsV06Eyku6/gKmoxtoS6CDKni2NxaoH1vCzKY2kIs+Q4tAhgiL56BOcBMQdGB+IyWGaLRuplcerg/HQRFBkmSKCGfjv4Hvk0SqEqLy7Dg1BMt3Lh59BLoXpZ4M/QMdEt9B5FqPH/tZt09yB4WrbvrM5a/XykT0zZqBNzBEE+ex8qEGrb6Xo+f4xRS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944795B91F2EEF1E0A08543DA790BYAPR08MB3944namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6750487f-6062-4778-e425-08d5cf2820d9 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 6750487f-6062-4778-e425-08d5cf2820d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2018 23:15:59.8674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4150 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:16:09 -0000 --_000_BYAPR08MB3944795B91F2EEF1E0A08543DA790BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIHRoZXkgcHJvYmFibHkgc2hvdWxkLCBzaW5jZSB0aGV5IGNhbid0IHNlbnNpYmx5IGRvIGFu eXRoaW5nIHdpdGhvdXQgYSBmdWxsIGluc3RydWN0aW9uLiAgU28gYW4gaW1wbGVtZW50YXRpb24g d291bGQgbmVlZCB0byBkbyB0aGUgZm9sbG93aW5nIHN0ZXBzOg0KDQogICogICBDaGVjayB0aGUg Zmlyc3QgYnl0ZTsgYXQgdGhpcyBwb2ludCwgeW91IGVpdGhlciBrbm93IHRoZSBzdHJpbmfigJlz IGV4YWN0IGxlbmd0aCwgb3IgeW91IGtub3cgaXTigJlzIGxvbmdlciB0aGFuIDMyIGJ5dGVzDQog ICAgICogICBJZiBsb25nZXIsIHdhaXQgdW50aWwgeW914oCZdmUgZ290dGVuIGF0IGxlYXN0IDMy IG1vcmUgYnl0ZXMsIGFuZCB5b3XigJlyZSBndWFyYW50ZWVkIHRvIGhhdmUgdGhlIHJlbWFpbmRl ciBvZiB0aGUgbnVtYmVyOyBmaW5kIHRoZSBhY3R1YWwgbGVuZ3RoDQogICAgICogICBXYWl0IHVu dGlsIHlvdSBoYXZlIHRoZSBhY3R1YWwgbGVuZ3RoIHBsdXMgb25lIGJ5dGUNCiAgKiAgIFVzZSB0 aGUgbGVuZ3RoIG9mIHRoZSBlbmNvZGVkIHN0cmluZyB0byBsb2NhdGUgdGhlIGZpcnN0IGJ5dGUg b2YgdGhlIHZhbHVlIGxlbmd0aDsgeW91IGVpdGhlciBmaW5kIHRoZSBmdWxsIGxlbmd0aCwgb3Ig eW91IGtub3cgaXTigJlzIGF0IGxlYXN0IDEyOCBieXRlcyBsb25nDQogICAgICogICBJZiBsb25n ZXIsIHdhaXQgdW50aWwgeW914oCZdmUgZ290dGVuIGF0IGxlYXN0IDEyOCBtb3JlIGJ5dGVzOyB5 b3XigJlyZSBndWFyYW50ZWVkIHRvIGhhdmUgdGhlIGFjdHVhbCBudW1iZXIgaW4gdGhlcmUNCiAg ICAgKiAgIFdhaXQgdW50aWwgeW91IGhhdmUgdGhlIGFjdHVhbCBsZW5ndGggKHJlbWFpbmRlciBv ZiB0aGUgaW5zdHJ1Y3Rpb24pDQogICogICBEZWNvZGUgdGhlIGluc3RydWN0aW9uDQoNCg0KDQpT byB5b3XigJlyZSBwb3RlbnRpYWxseSB3YWl0aW5nIGZvciBtb3JlIGJ5dGVzIHVwIHRvIGZvdXIg dGltZXMgcGVyIGluc3RydWN0aW9uICh0aG91Z2ggdGhlIG9kZHMgdGhhdCBhIG5vbi1tYWxpY2lv dXMgc2VuZGVyIHdvdWxkIGhpdCBhbGwgZm91ciBhcmUgbG93KSwgYW5kIGEgbmHDr3ZlIGltcGxl bWVudGF0aW9uIG1pZ2h0IHdlbGwgcmUtcGFyc2UgdGhlIGluc3RydWN0aW9uIGZyb20gdGhlIGJl Z2lubmluZyBhZnRlciBlYWNoIHdhaXQgY29tcGxldGVzLiAgSW1wbGljaXQgaW4gdGhpcyBpcyB0 aGUgYXNzdW1wdGlvbiB0aGF0IGEgMzIgYnl0ZSBsb25nIGludGVnZXIgd2lsbCBhbHdheXMgYmUg dW5hY2NlcHRhYmx5IGxvbmcsIGFuZCBpZiBhZnRlciB0aGUgd2FpdCB5b3UgY2Fu4oCZdCBtb3Zl IHRvIHRoZSBuZXh0IGZpZWxkIHN1Y2Nlc3NmdWxseSwgeW914oCZbGwgZmFpbCB0aGUgaW5zdHJ1 Y3Rpb24uDQoNCg0KDQpBbiBpbXBsZW1lbnRhdGlvbiBjYW4gYWx3YXlzIGRldGVybWluZSBob3cg bWFueSBieXRlcyBpdCBuZWVkcyB0byB3YWl0IGZvciB0byBtYWtlIHByb2dyZXNzLCB3aXRob3V0 IGFjY2lkZW50YWxseSB3YWl0aW5nIHBhc3QgdGhlIGVuZCBvZiB0aGUgaW5zdHJ1Y3Rpb24gYW5k IGNyZWF0aW5nIGEgZGVhZGxvY2sgaWYgdGhhdOKAmXMgYSB0YWlsLiAgSSB0aGluayB0aGlzIGV4 YW1wbGUgaGFzIGNvbnZpbmNlZCBtZSB0aGF0IHRoZSBsZW5ndGggcHJlZml4IGlzIHVubmVjZXNz YXJ5LiAgKEl0IGRvZXMgbWFrZSBtZSB3b25kZXIgd2hldGhlciBpdCB3b3VsZCBoYXZlIG1hZGUg bW9yZSBzZW5zZSB0byBwdXQgYm90aCBsZW5ndGhzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGlu c3RydWN0aW9uLCBmb2xsb3dlZCBieSB0aGUgdmFsdWVzLikNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBLYXp1aG8gT2t1DQpTZW50OiBTYXR1cmRheSwgSnVuZSA5LCAyMDE4IDM6NTcgUE0NClRv OiBBbGFuIEZyaW5kZWxsIDxhZnJpbmRAZmIuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDog UmU6IFByb3Bvc2FsOiBkcm9wIFFQQUNLIGVuY29kZXIgc3RyZWFtIGZyYW1pbmcNCg0KDQoNCjIw MTgtMDYtMDkgODoyNiBHTVQrMDk6MDAgQWxhbiBGcmluZGVsbCA8YWZyaW5kQGZiLmNvbTxtYWls dG86YWZyaW5kQGZiLmNvbT4+Og0KDQo+ICAgICBCZWNhdXNlIEkgdGhpbmsgcmVwYXJzaW5nIGlz IHRoZSBiZXN0IHN0cmF0ZWd5IGhlcmUsIGxldCBtZSBhcmd1ZSB0aGF0DQoNCj4gICAgIHRoZSB3 b3JzdCBjYXNlIGlzIG5vdCBPKE5eMikuDQoNCj4NCg0KPiAgICAgT2YgY291cnNlLCBpbiB0aGVv cnkgaXQgaXMgTyhOXjIpLCBiZWNhdXNlIHRoZXJlIGlzIG5vIHVwcGVyIGJvdW5kIGZvcg0KDQo+ ICAgICB0aGUgaW50ZWdlciByZXByZXNlbnRhdGlvbi4gQnV0IHRoZSByZWFsaXR5IGlzIHRoYXQg aW1wbGVtZW50YXRpb25zDQoNCj4gICAgIGFyZSByZXF1aXJlZCB0byBoYXZlIGFuIHVwcGVyIGJv dW5kLiBJJ2QgYXNzdW1lIHRoYXQgdGhleSB3b3VsZA0KDQo+ICAgICB0eXBpY2FsbHkgb25seSBw ZXJtaXQgdmFsdWVzIHRoYXQgZml0IGluIGEgMzItYml0ICh1KWludCAoMTYtYml0IGlzDQoNCj4g ICAgIGFub3RoZXIgb3B0aW9uIGZvciBzb21lKS4NCg0KPg0KDQo+IFRoZSBPKE5eMikgd29yayBJ IHdhcyB0aGlua2luZyBvZiB3YXMgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KPg0KDQo+IFRoZSBl bmNvZGVyIHNlbmRzIGEgdmVyeSBsb25nIEh1ZmZtYW4gZW5jb2RlZCBoZWFkZXIgbmFtZSBmb2xs b3dlZCBieSBhIGxvbmcgdmFsdWUsIGJ1dCB0aGV5IHNlbmQgdGhlIHZhbHVlIG9uZSBieXRlIGF0 IGEgdGltZS4gIElmIHRoZSBkZWNvZGVyIG5haXZlbHkgcmVwYXJzZXMgdGhlIGVudGlyZSBJbnNl cnQgaW5zdHJ1Y3Rpb24gZXZlcnkgdGltZSBhIGJ5dGUgYXJyaXZlcywgaXQgd2lsbCBlbmQgdXAg SHVmZm1hbiBkZWNvZGluZyB0aGUgaGVhZGVyIG5hbWUgb24gZXZlcnkgbmV3IGJ5dGUgb2YgdGhl IHZhbHVlLiAgVGhlIG5hbWUgY2FuIGJlIHNraXBwZWQgb3ZlciB0byByZS1wYXJzZSB0aGUgdmFs dWUgbGVuZ3RoLCBhbmQgdmVyaWZ5IGlmIHRoZSBmdWxsIHZhbHVlIGlzIHByZXNlbnQuICBIb3dl dmVyLCBldmVuIHNraXBwaW5nIG92ZXIgaXQgbWF5IGJlIGEgbGluZWFyIG9wZXJhdGlvbiBpbiBh IHplcm8tY29weSBpbXBsZW1lbnRhdGlvbiB0aGF0IG1haW50YWlucyBhIGxpbmtlZCBsaXN0IG9m IGRhdGEgYnVmZmVycy4NCg0KDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFRo YXQgc291bmRzIGxpa2UgYW4gaW50ZXJlc3RpbmcgYXR0YWNrIHZlY3RvciB0aGF0IHdlIG5lZWQg dG8gYmUgYXdhcmUgb2YuDQoNCg0KDQpPVE9ILCBJIGFtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8g Y29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIHN0cmVhbWluZyBIdWZmbWFuIGRlY29kaW5nIGlu IHRoaXMgZGlzY3Vzc2lvbiwgY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCB0aGUgY29tcHJlc3Nl ZCBzdHJpbmdzIHJlbWFpbiBsZW5ndGgtcHJlZml4ZWQuDQoNCg0KDQpFdmVuIGlmIHdlIHJlbW92 ZSB0aGUgZnJhbWluZyBvZiB0aGUgUUNBQ0sgaW5zdHJ1Y3Rpb25zLCBpbXBsZW1lbnRhdGlvbnMg d2lsbCBjb250aW51ZSB0byBoYXZlIHRoZSBmcmVlZG9tIHRvIGJ1ZmZlciBhIGNvbXBsZXRlIEh1 ZmZtYW4tZW5jb2RlZCBzdHJpbmcgKHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZyBiZWluZyBpZGVu dGlmaWVkIGJ5IHRoZSBsZW5ndGggb2N0ZXRzLg0KDQoNCg0KPiAtQWxhbg0KDQo+DQoNCj4NCg0K DQoNCg0KDQoNCg0KLS0NCg0KS2F6dWhvIE9rdQ0KDQoNCg== --_000_BYAPR08MB3944795B91F2EEF1E0A08543DA790BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDEzNjQ3ODgyOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTQ1NjY1MDAwIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QW5kIHRoZXkgcHJvYmFibHkgc2hvdWxkLCBzaW5jZSB0aGV5IGNhbid0IHNlbnNp Ymx5IGRvIGFueXRoaW5nIHdpdGhvdXQgYSBmdWxsIGluc3RydWN0aW9uLiZuYnNwOyBTbyBhbiBp bXBsZW1lbnRhdGlvbiB3b3VsZCBuZWVkIHRvIGRvIHRoZSBmb2xsb3dpbmcgc3RlcHM6PG86cD48 L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkNoZWNr IHRoZSBmaXJzdCBieXRlOyBhdCB0aGlzIHBvaW50LCB5b3UgZWl0aGVyIGtub3cgdGhlIHN0cmlu Z+KAmXMgZXhhY3QgbGVuZ3RoLCBvciB5b3Uga25vdyBpdOKAmXMgbG9uZ2VyIHRoYW4gMzIgYnl0 ZXM8bzpwPjwvbzpwPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4N CjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi PklmIGxvbmdlciwgPGI+d2FpdDwvYj4gdW50aWwgeW914oCZdmUgZ290dGVuIGF0IGxlYXN0IDMy IG1vcmUgYnl0ZXMsIGFuZCB5b3XigJlyZSBndWFyYW50ZWVkIHRvIGhhdmUgdGhlIHJlbWFpbmRl ciBvZiB0aGUgbnVtYmVyOyBmaW5kIHRoZSBhY3R1YWwgbGVuZ3RoPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPjxi PldhaXQ8L2I+IHVudGlsIHlvdSBoYXZlIHRoZSBhY3R1YWwgbGVuZ3RoIHBsdXMgb25lIGJ5dGU8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VXNlIHRoZSBsZW5ndGggb2YgdGhlIGVuY29kZWQg c3RyaW5nIHRvIGxvY2F0ZSB0aGUgZmlyc3QgYnl0ZSBvZiB0aGUgdmFsdWUgbGVuZ3RoOyB5b3Ug ZWl0aGVyIGZpbmQgdGhlIGZ1bGwgbGVuZ3RoLCBvciB5b3Uga25vdyBpdOKAmXMgYXQgbGVhc3Qg MTI4IGJ5dGVzIGxvbmc8bzpwPjwvbzpwPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEiPklmIGxvbmdlciwgPGI+d2FpdDwvYj4gdW50aWwgeW914oCZdmUgZ290dGVu IGF0IGxlYXN0IDEyOCBtb3JlIGJ5dGVzOyB5b3XigJlyZSBndWFyYW50ZWVkIHRvIGhhdmUgdGhl IGFjdHVhbCBudW1iZXIgaW4gdGhlcmU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+PGI+V2FpdDwvYj4gdW50aWwg eW91IGhhdmUgdGhlIGFjdHVhbCBsZW5ndGggKHJlbWFpbmRlciBvZiB0aGUgaW5zdHJ1Y3Rpb24p PG86cD48L286cD48L2xpPjwvdWw+DQo8L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkRlY29kZSB0aGUgaW5zdHJ1Y3Rpb248bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U28geW914oCZcmUgcG90ZW50aWFsbHkgd2Fp dGluZyBmb3IgbW9yZSBieXRlcyB1cCB0byBmb3VyIHRpbWVzIHBlciBpbnN0cnVjdGlvbiAodGhv dWdoIHRoZSBvZGRzIHRoYXQgYSBub24tbWFsaWNpb3VzIHNlbmRlciB3b3VsZCBoaXQgYWxsIGZv dXIgYXJlIGxvdyksIGFuZCBhIG5hw692ZSBpbXBsZW1lbnRhdGlvbiBtaWdodCB3ZWxsIHJlLXBh cnNlIHRoZSBpbnN0cnVjdGlvbiBmcm9tIHRoZSBiZWdpbm5pbmcNCiBhZnRlciBlYWNoIHdhaXQg Y29tcGxldGVzLiZuYnNwOyBJbXBsaWNpdCBpbiB0aGlzIGlzIHRoZSBhc3N1bXB0aW9uIHRoYXQg YSAzMiBieXRlIGxvbmcgaW50ZWdlciB3aWxsIGFsd2F5cyBiZSB1bmFjY2VwdGFibHkgbG9uZywg YW5kIGlmIGFmdGVyIHRoZSB3YWl0IHlvdSBjYW7igJl0IG1vdmUgdG8gdGhlIG5leHQgZmllbGQg c3VjY2Vzc2Z1bGx5LCB5b3XigJlsbCBmYWlsIHRoZSBpbnN0cnVjdGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+QW4gaW1wbGVtZW50YXRpb24gY2FuIGFsd2F5cyBkZXRlcm1pbmUg aG93IG1hbnkgYnl0ZXMgaXQgbmVlZHMgdG8gd2FpdCBmb3IgdG8gbWFrZSBwcm9ncmVzcywgd2l0 aG91dCBhY2NpZGVudGFsbHkgd2FpdGluZyBwYXN0IHRoZSBlbmQgb2YgdGhlIGluc3RydWN0aW9u IGFuZCBjcmVhdGluZyBhIGRlYWRsb2NrIGlmIHRoYXTigJlzIGEgdGFpbC4mbmJzcDsgSSB0aGlu ayB0aGlzIGV4YW1wbGUgaGFzIGNvbnZpbmNlZCBtZQ0KIHRoYXQgdGhlIGxlbmd0aCBwcmVmaXgg aXMgdW5uZWNlc3NhcnkuJm5ic3A7IChJdCBkb2VzIG1ha2UgbWUgd29uZGVyIHdoZXRoZXIgaXQg d291bGQgaGF2ZSBtYWRlIG1vcmUgc2Vuc2UgdG8gcHV0DQo8aT5ib3RoPC9pPiBsZW5ndGhzIGF0 IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGluc3RydWN0aW9uLCBmb2xsb3dlZCBieSB0aGUgdmFsdWVz Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQpGcm9tOiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IE9uIEJlaGFs ZiBPZiBLYXp1aG8gT2t1PGJyPg0KU2VudDogU2F0dXJkYXksIEp1bmUgOSwgMjAxOCAzOjU3IFBN PGJyPg0KVG86IEFsYW4gRnJpbmRlbGwgJmx0O2FmcmluZEBmYi5jb20mZ3Q7PGJyPg0KQ2M6IFFV SUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0Ozxicj4NClN1YmplY3Q6IFJlOiBQcm9wb3NhbDogZHJvcCBRUEFD SyBlbmNvZGVyIHN0cmVhbSBmcmFtaW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yMDE4LTA2LTA5IDg6 MjYgR01UJiM0MzswOTowMCBBbGFuIEZyaW5kZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YWZyaW5k QGZiLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmFmcmluZEBmYi5jb208L3NwYW4+PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlY2F1c2UgSSB0 aGluayByZXBhcnNpbmcgaXMgdGhlIGJlc3Qgc3RyYXRlZ3kgaGVyZSwgbGV0IG1lIGFyZ3VlIHRo YXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIHdvcnN0IGNhc2UgaXMgbm90IE8oTl4yKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2YgY291 cnNlLCBpbiB0aGVvcnkgaXQgaXMgTyhOXjIpLCBiZWNhdXNlIHRoZXJlIGlzIG5vIHVwcGVyIGJv dW5kIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaW50ZWdlciByZXByZXNlbnRhdGlvbi4gQnV0IHRoZSBy ZWFsaXR5IGlzIHRoYXQgaW1wbGVtZW50YXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSByZXF1aXJlZCB0 byBoYXZlIGFuIHVwcGVyIGJvdW5kLiBJJ2QgYXNzdW1lIHRoYXQgdGhleSB3b3VsZDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0eXBpY2FsbHkgb25seSBwZXJtaXQgdmFsdWVzIHRoYXQgZml0IGluIGEgMzItYml0ICh1 KWludCAoMTYtYml0IGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFub3RoZXIgb3B0aW9uIGZvciBzb21lKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIE8oTl4yKSB3b3JrIEkgd2Fz IHRoaW5raW5nIG9mIHdhcyBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgZW5jb2RlciBzZW5kcyBhIHZlcnkgbG9uZyBIdWZmbWFu IGVuY29kZWQgaGVhZGVyIG5hbWUgZm9sbG93ZWQgYnkgYSBsb25nIHZhbHVlLCBidXQgdGhleSBz ZW5kIHRoZSB2YWx1ZSBvbmUgYnl0ZSBhdCBhIHRpbWUuJm5ic3A7IElmIHRoZSBkZWNvZGVyIG5h aXZlbHkgcmVwYXJzZXMgdGhlIGVudGlyZSBJbnNlcnQgaW5zdHJ1Y3Rpb24gZXZlcnkgdGltZSBh IGJ5dGUgYXJyaXZlcywgaXQgd2lsbCBlbmQgdXANCiBIdWZmbWFuIGRlY29kaW5nIHRoZSBoZWFk ZXIgbmFtZSBvbiBldmVyeSBuZXcgYnl0ZSBvZiB0aGUgdmFsdWUuJm5ic3A7IFRoZSBuYW1lIGNh biBiZSBza2lwcGVkIG92ZXIgdG8gcmUtcGFyc2UgdGhlIHZhbHVlIGxlbmd0aCwgYW5kIHZlcmlm eSBpZiB0aGUgZnVsbCB2YWx1ZSBpcyBwcmVzZW50LiZuYnNwOyBIb3dldmVyLCBldmVuIHNraXBw aW5nIG92ZXIgaXQgbWF5IGJlIGEgbGluZWFyIG9wZXJhdGlvbiBpbiBhIHplcm8tY29weSBpbXBs ZW1lbnRhdGlvbiB0aGF0DQogbWFpbnRhaW5zIGEgbGlua2VkIGxpc3Qgb2YgZGF0YSBidWZmZXJz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3UgZm9yIHRoZSBjbGFyaWZp Y2F0aW9uLiBUaGF0IHNvdW5kcyBsaWtlIGFuIGludGVyZXN0aW5nIGF0dGFjayB2ZWN0b3IgdGhh dCB3ZSBuZWVkIHRvIGJlIGF3YXJlIG9mLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5P VE9ILCBJIGFtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5 IG9mIHN0cmVhbWluZyBIdWZmbWFuIGRlY29kaW5nIGluIHRoaXMgZGlzY3Vzc2lvbiwgY29uc2lk ZXJpbmcgdGhlIGZhY3QgdGhhdCB0aGUgY29tcHJlc3NlZCBzdHJpbmdzIHJlbWFpbiBsZW5ndGgt cHJlZml4ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkV2ZW4gaWYgd2UgcmVtb3Zl IHRoZSBmcmFtaW5nIG9mIHRoZSBRQ0FDSyBpbnN0cnVjdGlvbnMsIGltcGxlbWVudGF0aW9ucyB3 aWxsIGNvbnRpbnVlIHRvIGhhdmUgdGhlIGZyZWVkb20gdG8gYnVmZmVyIGEgY29tcGxldGUgSHVm Zm1hbi1lbmNvZGVkIHN0cmluZyAodGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5nIGJlaW5nIGlkZW50 aWZpZWQgYnkgdGhlIGxlbmd0aCBvY3RldHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgLUFsYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LYXp1 aG8gT2t1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR08MB3944795B91F2EEF1E0A08543DA790BYAPR08MB3944namp_-- From nobody Mon Jun 11 04:15:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DFF130E2D for ; Mon, 11 Jun 2018 04:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 w2Nlc8MtbMZe for ; Mon, 11 Jun 2018 04:15:40 -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 07A5512777C for ; Mon, 11 Jun 2018 04:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528715738; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: 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=WIVKZz91Q77AevtdPNylHH17VLwG3ANcuJP10YPagCo=; b=ayhN4A2MrOLgcn357uunGBhHMYD+7pXOIdD9i0axhCkng/V4tu+RlA+9ywth2qdB BjrUCL7xTo3i8xvg91Ue0aS3w5hovZNHtvu7wofXK6fToig6zm5KObIUwzyNP7az kP0fLWc1lwLvOKaMXoLZt3WF8DqIASV6pu3Hh3jCrwI=; X-AuditID: c1b4fb3a-f47ff70000005fee-d0-5b1e59d972ad Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.3A.24558.9D95E1B5; Mon, 11 Jun 2018 13:15:38 +0200 (CEST) Received: from [100.94.32.30] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 11 Jun 2018 13:15:37 +0200 Subject: Re: Adding ECN to Transport and Recovery To: Jana Iyengar , Christian Huitema CC: "Brian Trammell (IETF)" , Ian Swett , QUIC WG References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> From: Magnus Westerlund Message-ID: <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> Date: Mon, 11 Jun 2018 13:15:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C99B96D7C2697FFA6A5DF7FD" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbE9RPdWpFy0wZF/TBaTG2ezW/y8t5PV YmPLOzaL9kvzmC16FnA7sHrsnHWX3WPBplKPWzNOsXgsWfKTyePJ/pksAaxRXDYpqTmZZalF +nYJXBnXey+zFRzXrfh+pYu1gXGhUhcjJ4eEgIlEU08TSxcjF4eQwBFGiRUXprBCOBsZJW6s /czexcjBISxgKLHjogNIg4iAn8Sk02uYQGxmgSyJnX9usEPU32SRePzvIQtIgk3AQuLmj0Y2 EJtXwF5i1bV57CA2i4CqxI7e+WC2qECMxOqNl9khagQlTs58AtbLKRAosfL5ZnaIBWESk+f8 YIWwxSWavqwEs4UEtCUamjpYIT5Qkrg+7zrLBEbBWUhGzULSPgtJO4RtITFz/nlGCFteonnr bGYIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+nglt9WOxgPPnc8 xCjAwajEw8vgIhctxJpYVlyZe4hRgoNZSYTXSwEoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNcp zSJKSCA9sSQ1OzW1ILUIJsvEwSnVwCjzPOVNSPyplZr8P/Ldlm2Y8IHhcnFa8j777zNZ/T78 SNp5SV9bRFou8fYOjuqw+6cZP7ldzBfrMnltZ8En4rBs/4Hmlfk/bmV/iXv1Xeje7XU6563M PX8nnO73n+KhcTr7mlFN8Acr2zU51le07aZKyrzf8G+rnvgeZ59FJYZ58/X1Zt33nqjEUpyR aKjFXFScCACDyPzXoAIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 11:15:43 -0000 --------------C99B96D7C2697FFA6A5DF7FD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, I agree with Jana, as there are not a clear consensus lets take any further modifications of the ACK frames as a separate issue. The PR have from my perspective no open technical content issues. I will await to see if the editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon. I will now start working on a new section for a separate PR regarding the ECN black hole mitigation. Cheers Magnus Den 2018-06-10 kl. 19:14, skrev Jana Iyengar: > Sounds like there's general agreement that modifying the varint to > contain a flag bit will add unnecessary complexity. > Let's try to get the PR in as it is now, and if anyone really wants to > go merge this and the ACK frame or rename things, let's paint that > bikeshed separately. > > > > On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema > wrote: > > > > > On Jun 9, 2018, at 8:27 AM, Ian Swett > wrote: > > > > QUIC is complex enough, I think we should just call them ACK and > ACK_ECN.  A few implementations sending at least one ACK_ECN frame > per connection will dispel any belief that ACK_ECN is optional.  A > small amount of use will be a lot more valuable than clever naming. > > Also, ECN is just one of the extensions that could be planned for > ACK. Timestamps would be nice too, for those who want > one-way-delay based congestion control. > > -- Christian Huitema > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------C99B96D7C2697FFA6A5DF7FD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi,

I agree with Jana, as there are not a clear consensus lets take any further modifications of the ACK frames as a separate issue. The PR have from my perspective no open technical content issues. I will await to see if the editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding the ECN black hole mitigation.

Cheers

Magnus


Den 2018-06-10 kl. 19:14, skrev Jana Iyengar:
Sounds like there's general agreement that modifying the varint to contain a flag bit will add unnecessary complexity. 
Let's try to get the PR in as it is now, and if anyone really wants to go merge this and the ACK frame or rename things, let's paint that bikeshed separately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <huitema@huitema.net> wrote:
 

> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_ECN.  A few implementations sending at least one ACK_ECN frame per connection will dispel any belief that ACK_ECN is optional.  A small amount of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Timestamps would be nice too, for those who want one-way-delay based congestion control.

-- Christian Huitema 

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------------C99B96D7C2697FFA6A5DF7FD-- From nobody Mon Jun 11 05:23:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABB130E37 for ; Mon, 11 Jun 2018 05:23:49 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 XrN98kd9TKT9 for ; Mon, 11 Jun 2018 05:23:47 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1F9F0130E30 for ; Mon, 11 Jun 2018 05:23:47 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5BCIE7j032078; Mon, 11 Jun 2018 13:23:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=QRM1yxbhd5m4TREOkmo4eVSmOIFm8ci+4OLi0/HbFmo=; b=DfrPp/4DPqsyt5Vic3vqNSDaJcCtv3tzOVwrwGQRGy6qRm4hmsjuF4kxE7qw5yNC/qjY lHxoNV0KW1EzKfDes/oZudiZ7aOvVEpyU/3htCl3JVw5gpbJWPWZni3zfxrUz8WRlUZZ SShjcjr1VzILiY8vjRvvudh1fTDwJks3y67kgXSboSketsbMpiIkKTPEAz5ZpYPr5B4Y NkT7e0XTKUjKNrjBV03eRmA8Dk3tCjXcr4lMRpfH2p+BCa9x4K9do7FHdBHhmZNah/9b i5toj4Nr6i8OOacwliEXyrdKTBJ0eWi4W7fIpxhuvTQFnltTPy0gTvaJ90sx/DIe2NSx xA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jg6xfwa04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 13:23:32 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5BCLdGx020155; Mon, 11 Jun 2018 08:23:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jga7vdg06-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 08:23:30 -0400 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 11 Jun 2018 07:18:11 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Mon, 11 Jun 2018 05:18:11 -0700 From: "Lubashev, Igor" To: "huitema@huitema.net" , "magnus.westerlund@ericsson.com" , "jri.ietf@gmail.com" CC: "ietf@trammell.ch" , "quic@ietf.org" , "ianswett@google.com" Subject: RE: Adding ECN to Transport and Recovery Thread-Topic: Adding ECN to Transport and Recovery Thread-Index: AQHT9sK0H8sBCsQDiUuMTPA/hgyVTqRW+DkAgAAEvoCAABm1gIAAXg8AgAAm5gCAALVPgIAAQ7eAgAADFgCAAa0SAIABLgUA//+cLbA= Date: Mon, 11 Jun 2018 12:18:11 +0000 Message-ID: References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> , <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> In-Reply-To: <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_c89e100409774521b24cbe0c1167d978ustx2exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806110145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806110145 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 12:23:49 -0000 --_000_c89e100409774521b24cbe0c1167d978ustx2exdag1mb6msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not think I have seen this in the PR, so I am wondering what your reco= mmendation is for defending against an on-a-side attacker, who sets CE bits= on every EC(*) packet and races that packet to the destination? Should tha= t be a part of this PR? - Igor -----Original Message----- From: Magnus Westerlund [magnus.westerlund@ericsson.com] Received: Monday, 11 Jun 2018, 1:15PM To: Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema [huitema@huitema.n= et] CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett [ianswett@google.co= m]; QUIC WG [quic@ietf.org] Subject: Re: Adding ECN to Transport and Recovery Hi, I agree with Jana, as there are not a clear consensus lets take any further= modifications of the ACK frames as a separate issue. The PR have from my p= erspective no open technical content issues. I will await to see if the edi= tors or any of you have any editorial issues. But, otherwise I expect this = PR to be merged quite soon. I will now start working on a new section for a separate PR regarding the E= CN black hole mitigation. Cheers Magnus Den 2018-06-10 kl. 19:14, skrev Jana Iyengar: Sounds like there's general agreement that modifying the varint to contain = a flag bit will add unnecessary complexity. Let's try to get the PR in as it is now, and if anyone really wants to go m= erge this and the ACK frame or rename things, let's paint that bikeshed sep= arately. On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema > wrote: > On Jun 9, 2018, at 8:27 AM, Ian Swett > wrote: > > QUIC is complex enough, I think we should just call them ACK and ACK_ECN.= A few implementations sending at least one ACK_ECN frame per connection w= ill dispel any belief that ACK_ECN is optional. A small amount of use will= be a lot more valuable than clever naming. Also, ECN is just one of the extensions that could be planned for ACK. Time= stamps would be nice too, for those who want one-way-delay based congestion= control. -- Christian Huitema -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_c89e100409774521b24cbe0c1167d978ustx2exdag1mb6msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not think I have seen this in the PR, so I am wonderi= ng what your recommendation is for defending against an on-a-side attacker,= who sets CE bits on every EC(*) packet and races that packet to the destination? Should that be a part of this PR= ?

- Igor

-----Original Message-----
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Received: Monday, 11 Jun 2018, 1:15PM
To: Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema [huitema@hu= itema.net]
CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett [ianswett@go= ogle.com]; QUIC WG [quic@ietf.org]
Subject: Re: Adding ECN to Transport and Recovery

Hi,

I agree with Jana, as there are not a clear consensus lets take any furt= her modifications of the ACK frames as a separate issue. The PR have from m= y perspective no open technical content issues. I will await to see if the = editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding th= e ECN black hole mitigation.

Cheers

Magnus


Den 2018-06-10 kl. 19:14, skrev Jana Iyengar= :
Sounds like there's general agreement that modifying the varint to con= tain a flag bit will add unnecessary complexity. 
Let's try to get the PR in as it is now, and if anyone really wants to go m= erge this and the ACK frame or rename things, let's paint that bikeshed sep= arately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <huitema@huitema.net> wrote:
 

> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_E= CN.  A few implementations sending at least one ACK_ECN frame per conn= ection will dispel any belief that ACK_ECN is optional.  A small amoun= t of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Time= stamps would be nice too, for those who want one-way-delay based congestion= control.

-- Christian Huitema 

--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com
----------------------------------------------------------------------
--_000_c89e100409774521b24cbe0c1167d978ustx2exdag1mb6msgcorpak_-- From nobody Mon Jun 11 08:22:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9F131016 for ; Mon, 11 Jun 2018 08:22:29 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, 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=fb.com header.b=rm/zO51D; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HRzY40Xi 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 LVULEQE1MFMI for ; Mon, 11 Jun 2018 08:22:26 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 F1B72130F3A for ; Mon, 11 Jun 2018 08:22:25 -0700 (PDT) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5BFHp6n002985; Mon, 11 Jun 2018 08:22:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=/qM+XMdlSUPJKF/32uE9ILHJF2hyCQgM1XmTBgUzbmI=; b=rm/zO51DYQA9slIK8ed7htofVtE81+RGYBuhJU0VU1Md6/WquLsgYTiEuK1cBmekWM5p ZYNc9MZBsGljZPG6nl2bU9PpV1OcsrUJUVlIHtTorHPgNNAbI/nL+1WqFqtH8YRP5KEW X0xH+KRMng0w5wxAbW1SJ9tP4dWC6h36gCs= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jhs12gdp1-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jun 2018 08:22:21 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.20) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 11 Jun 2018 08:22:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/qM+XMdlSUPJKF/32uE9ILHJF2hyCQgM1XmTBgUzbmI=; b=HRzY40XiFRDJKfv+Ro1FvLMWhO4g3nqUZMrXyn/Oqtnnn5kruZg8b7ykjCcLbVr7lfglWyXJzcNibMl4sZpzEBiyoEJU4IaeJdXbNKt9HkojQBr2z9AGFWlEykzwgXPMGw5k21eGWQb+mZTz0DArCTsaky9an2WFGF3BNuqr7kA= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) by MWHPR15MB1678.namprd15.prod.outlook.com (10.175.141.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Mon, 11 Jun 2018 15:22:18 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::399c:db50:dfc0:3860%4]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 15:22:18 +0000 From: Alan Frindell To: Mike Bishop , Kazuho Oku CC: QUIC WG , Martin Thomson Subject: Re: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHqXJJQhdl+r0afCsPvVPdYN6RWJZAAgAAStYCAACnpgIAAhKkA//+nSwCAAf9MAIABl6mAgACYpAA= Date: Mon, 11 Jun 2018 15:22:18 +0000 Message-ID: <0A25977E-C62A-4035-90C7-63D2D6B874E3@fb.com> References: <20180607151112.GA28823@ubuntu-dmitri> <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-originating-ip: [2620:10d:c090:200::7:3ed] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1678; 7:1Nmsyem2Et7OO5gkRydjtZr7YftVUGhTfi/tLdFDvI+8AnKSlnMw95x6rlnI1CKkXhcL8HKXH7bflM6MW54LGTdAFfGTn07Ry4u025hXTol38EeHSngDTF0JXcFElhBF3FuEstsodhIZL6zooJHtje8IMB5Pw+Cg2yrMiPCSLuPqT0Fj8iTY3xK5nHSLIx0RxsKRzFxhGwIj2WqIlNRUiSEtkm/WJVPRK85ue42/ym5QiKUPV7Zeyn+xZQFPibRV; 20:muOoBrxZcQaunbw7HpH1H5uGT7OXnjPc3tYwTwLhxoP/FQXKKQQdn5N8pwYUpjfP9tLpQF4tnibu0bJT/JOe9H1R+SMKYCiMXgxIZBK15bUAawwnI2vwn1diqUbG1CZdPs1HGC+dRiPz6rGe1tEj2kSljlau0lFsz6NY7cR8P8o= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1678; x-ms-traffictypediagnostic: MWHPR15MB1678: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(67672495146484)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1678; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1678; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(376002)(396003)(346002)(189003)(199004)(13464003)(486006)(6116002)(97736004)(8676002)(561944003)(6436002)(81166006)(2900100001)(81156014)(14454004)(7736002)(476003)(4326008)(33656002)(11346002)(229853002)(2616005)(446003)(6486002)(25786009)(6246003)(106356001)(39060400002)(105586002)(36756003)(68736007)(345774005)(53546011)(8936002)(53936002)(236005)(82746002)(83716003)(46003)(478600001)(6506007)(2906002)(5660300001)(102836004)(186003)(86362001)(5250100002)(54906003)(58126008)(3660700001)(76176011)(110136005)(99286004)(3280700002)(59450400001)(316002)(93886005)(6512007)(54896002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1678; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: m8RLcMcP+cHd3J4oq2xJ5Zd6Y1GXQpQnz2hiWzW0rbXo6O0K7F85p1bSeXvK4HhMxrVwACF9PWBRG4lHSz4XuymKJxWfjNxMgFWlNTr4FSegyhlYf/Y+hp0PjStkRx+2qH6eq6+XEn5w26YHluusgn9zpxaM7fy7n44WYqnhRYflH3K4aXlCnBgWKFe+hCza spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0A25977EC62A403590C763D2D6B874E3fbcom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8c316efb-8963-4f2d-8dad-08d5cfaf1ef3 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c316efb-8963-4f2d-8dad-08d5cfaf1ef3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 15:22:18.6606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1678 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:22:34 -0000 --_000_0A25977EC62A403590C763D2D6B874E3fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGZhY3QgdGhhdCB5b3Ugbm93IG5lZWQgYW4gYWxnb3JpdGhtIHRoYXQgdGVsbHMgeW91IGhv dyB0byBjb3JyZWN0bHkvc2FmZWx5IGRlc2VyaWFsaXplIGEgc2luZ2xlIGluc3RydWN0aW9uIGlz IHByZXR0eSBtdWNoIHRoZSBwb2ludCBJIHdhcyBtYWtpbmcuICBUaGlzIGlzIG1vcmUgY29tcGxl eCB0aGFuIGp1c3QgaGF2aW5nIGEgYnl0ZSBvbiB0aGUgd2lyZSB0ZWxsIHlvdSBob3cgbWFueSBi eXRlcyBhcmUgcmVxdWlyZWQuICBCdXQgSSBmZWVsIHRoZXJl4oCZcyBjbGVhciBjb25zZW5zdXMg aGVyZSB0byBkaXNjYXJkIHRoZSBsZW5ndGggcHJlZml4Lg0KDQotQWxhbg0KDQpGcm9tOiBNaWtl IEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+DQpEYXRlOiBTdW5kYXksIEp1bmUgMTAsIDIw MTggYXQgNDoxNiBQTQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+LCBBbGFu IEZyaW5kZWxsIDxhZnJpbmRAZmIuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+LCBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDogUkU6IFBy b3Bvc2FsOiBkcm9wIFFQQUNLIGVuY29kZXIgc3RyZWFtIGZyYW1pbmcNCg0KDQpBbmQgdGhleSBw cm9iYWJseSBzaG91bGQsIHNpbmNlIHRoZXkgY2FuJ3Qgc2Vuc2libHkgZG8gYW55dGhpbmcgd2l0 aG91dCBhIGZ1bGwgaW5zdHJ1Y3Rpb24uICBTbyBhbiBpbXBsZW1lbnRhdGlvbiB3b3VsZCBuZWVk IHRvIGRvIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQoNCiAgKiAgIENoZWNrIHRoZSBmaXJzdCBieXRl OyBhdCB0aGlzIHBvaW50LCB5b3UgZWl0aGVyIGtub3cgdGhlIHN0cmluZ+KAmXMgZXhhY3QgbGVu Z3RoLCBvciB5b3Uga25vdyBpdOKAmXMgbG9uZ2VyIHRoYW4gMzIgYnl0ZXMNCiAgICAgKiAgIElm IGxvbmdlciwgd2FpdCB1bnRpbCB5b3XigJl2ZSBnb3R0ZW4gYXQgbGVhc3QgMzIgbW9yZSBieXRl cywgYW5kIHlvdeKAmXJlIGd1YXJhbnRlZWQgdG8gaGF2ZSB0aGUgcmVtYWluZGVyIG9mIHRoZSBu dW1iZXI7IGZpbmQgdGhlIGFjdHVhbCBsZW5ndGgNCiAgICAgKiAgIFdhaXQgdW50aWwgeW91IGhh dmUgdGhlIGFjdHVhbCBsZW5ndGggcGx1cyBvbmUgYnl0ZQ0KICAqICAgVXNlIHRoZSBsZW5ndGgg b2YgdGhlIGVuY29kZWQgc3RyaW5nIHRvIGxvY2F0ZSB0aGUgZmlyc3QgYnl0ZSBvZiB0aGUgdmFs dWUgbGVuZ3RoOyB5b3UgZWl0aGVyIGZpbmQgdGhlIGZ1bGwgbGVuZ3RoLCBvciB5b3Uga25vdyBp dOKAmXMgYXQgbGVhc3QgMTI4IGJ5dGVzIGxvbmcNCiAgICAgKiAgIElmIGxvbmdlciwgd2FpdCB1 bnRpbCB5b3XigJl2ZSBnb3R0ZW4gYXQgbGVhc3QgMTI4IG1vcmUgYnl0ZXM7IHlvdeKAmXJlIGd1 YXJhbnRlZWQgdG8gaGF2ZSB0aGUgYWN0dWFsIG51bWJlciBpbiB0aGVyZQ0KICAgICAqICAgV2Fp dCB1bnRpbCB5b3UgaGF2ZSB0aGUgYWN0dWFsIGxlbmd0aCAocmVtYWluZGVyIG9mIHRoZSBpbnN0 cnVjdGlvbikNCiAgKiAgIERlY29kZSB0aGUgaW5zdHJ1Y3Rpb24NCg0KDQoNClNvIHlvdeKAmXJl IHBvdGVudGlhbGx5IHdhaXRpbmcgZm9yIG1vcmUgYnl0ZXMgdXAgdG8gZm91ciB0aW1lcyBwZXIg aW5zdHJ1Y3Rpb24gKHRob3VnaCB0aGUgb2RkcyB0aGF0IGEgbm9uLW1hbGljaW91cyBzZW5kZXIg d291bGQgaGl0IGFsbCBmb3VyIGFyZSBsb3cpLCBhbmQgYSBuYcOvdmUgaW1wbGVtZW50YXRpb24g bWlnaHQgd2VsbCByZS1wYXJzZSB0aGUgaW5zdHJ1Y3Rpb24gZnJvbSB0aGUgYmVnaW5uaW5nIGFm dGVyIGVhY2ggd2FpdCBjb21wbGV0ZXMuICBJbXBsaWNpdCBpbiB0aGlzIGlzIHRoZSBhc3N1bXB0 aW9uIHRoYXQgYSAzMiBieXRlIGxvbmcgaW50ZWdlciB3aWxsIGFsd2F5cyBiZSB1bmFjY2VwdGFi bHkgbG9uZywgYW5kIGlmIGFmdGVyIHRoZSB3YWl0IHlvdSBjYW7igJl0IG1vdmUgdG8gdGhlIG5l eHQgZmllbGQgc3VjY2Vzc2Z1bGx5LCB5b3XigJlsbCBmYWlsIHRoZSBpbnN0cnVjdGlvbi4NCg0K DQoNCkFuIGltcGxlbWVudGF0aW9uIGNhbiBhbHdheXMgZGV0ZXJtaW5lIGhvdyBtYW55IGJ5dGVz IGl0IG5lZWRzIHRvIHdhaXQgZm9yIHRvIG1ha2UgcHJvZ3Jlc3MsIHdpdGhvdXQgYWNjaWRlbnRh bGx5IHdhaXRpbmcgcGFzdCB0aGUgZW5kIG9mIHRoZSBpbnN0cnVjdGlvbiBhbmQgY3JlYXRpbmcg YSBkZWFkbG9jayBpZiB0aGF04oCZcyBhIHRhaWwuICBJIHRoaW5rIHRoaXMgZXhhbXBsZSBoYXMg Y29udmluY2VkIG1lIHRoYXQgdGhlIGxlbmd0aCBwcmVmaXggaXMgdW5uZWNlc3NhcnkuICAoSXQg ZG9lcyBtYWtlIG1lIHdvbmRlciB3aGV0aGVyIGl0IHdvdWxkIGhhdmUgbWFkZSBtb3JlIHNlbnNl IHRvIHB1dCBib3RoIGxlbmd0aHMgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgaW5zdHJ1Y3Rpb24s IGZvbGxvd2VkIGJ5IHRoZSB2YWx1ZXMuKQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEthenVo byBPa3UNClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDksIDIwMTggMzo1NyBQTQ0KVG86IEFsYW4gRnJp bmRlbGwgPGFmcmluZEBmYi5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRp biBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogUHJvcG9z YWw6IGRyb3AgUVBBQ0sgZW5jb2RlciBzdHJlYW0gZnJhbWluZw0KDQoNCg0KMjAxOC0wNi0wOSA4 OjI2IEdNVCswOTowMCBBbGFuIEZyaW5kZWxsIDxhZnJpbmRAZmIuY29tPG1haWx0bzphZnJpbmRA ZmIuY29tPj46DQoNCj4gICAgIEJlY2F1c2UgSSB0aGluayByZXBhcnNpbmcgaXMgdGhlIGJlc3Qg c3RyYXRlZ3kgaGVyZSwgbGV0IG1lIGFyZ3VlIHRoYXQNCg0KPiAgICAgdGhlIHdvcnN0IGNhc2Ug aXMgbm90IE8oTl4yKS4NCg0KPg0KDQo+ICAgICBPZiBjb3Vyc2UsIGluIHRoZW9yeSBpdCBpcyBP KE5eMiksIGJlY2F1c2UgdGhlcmUgaXMgbm8gdXBwZXIgYm91bmQgZm9yDQoNCj4gICAgIHRoZSBp bnRlZ2VyIHJlcHJlc2VudGF0aW9uLiBCdXQgdGhlIHJlYWxpdHkgaXMgdGhhdCBpbXBsZW1lbnRh dGlvbnMNCg0KPiAgICAgYXJlIHJlcXVpcmVkIHRvIGhhdmUgYW4gdXBwZXIgYm91bmQuIEknZCBh c3N1bWUgdGhhdCB0aGV5IHdvdWxkDQoNCj4gICAgIHR5cGljYWxseSBvbmx5IHBlcm1pdCB2YWx1 ZXMgdGhhdCBmaXQgaW4gYSAzMi1iaXQgKHUpaW50ICgxNi1iaXQgaXMNCg0KPiAgICAgYW5vdGhl ciBvcHRpb24gZm9yIHNvbWUpLg0KDQo+DQoNCj4gVGhlIE8oTl4yKSB3b3JrIEkgd2FzIHRoaW5r aW5nIG9mIHdhcyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQo+DQoNCj4gVGhlIGVuY29kZXIgc2Vu ZHMgYSB2ZXJ5IGxvbmcgSHVmZm1hbiBlbmNvZGVkIGhlYWRlciBuYW1lIGZvbGxvd2VkIGJ5IGEg bG9uZyB2YWx1ZSwgYnV0IHRoZXkgc2VuZCB0aGUgdmFsdWUgb25lIGJ5dGUgYXQgYSB0aW1lLiAg SWYgdGhlIGRlY29kZXIgbmFpdmVseSByZXBhcnNlcyB0aGUgZW50aXJlIEluc2VydCBpbnN0cnVj dGlvbiBldmVyeSB0aW1lIGEgYnl0ZSBhcnJpdmVzLCBpdCB3aWxsIGVuZCB1cCBIdWZmbWFuIGRl Y29kaW5nIHRoZSBoZWFkZXIgbmFtZSBvbiBldmVyeSBuZXcgYnl0ZSBvZiB0aGUgdmFsdWUuICBU aGUgbmFtZSBjYW4gYmUgc2tpcHBlZCBvdmVyIHRvIHJlLXBhcnNlIHRoZSB2YWx1ZSBsZW5ndGgs IGFuZCB2ZXJpZnkgaWYgdGhlIGZ1bGwgdmFsdWUgaXMgcHJlc2VudC4gIEhvd2V2ZXIsIGV2ZW4g c2tpcHBpbmcgb3ZlciBpdCBtYXkgYmUgYSBsaW5lYXIgb3BlcmF0aW9uIGluIGEgemVyby1jb3B5 IGltcGxlbWVudGF0aW9uIHRoYXQgbWFpbnRhaW5zIGEgbGlua2VkIGxpc3Qgb2YgZGF0YSBidWZm ZXJzLg0KDQoNCg0KVGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhhdCBzb3VuZHMg bGlrZSBhbiBpbnRlcmVzdGluZyBhdHRhY2sgdmVjdG9yIHRoYXQgd2UgbmVlZCB0byBiZSBhd2Fy ZSBvZi4NCg0KDQoNCk9UT0gsIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCB0byBjb25zaWRlciB0 aGUgcG9zc2liaWxpdHkgb2Ygc3RyZWFtaW5nIEh1ZmZtYW4gZGVjb2RpbmcgaW4gdGhpcyBkaXNj dXNzaW9uLCBjb25zaWRlcmluZyB0aGUgZmFjdCB0aGF0IHRoZSBjb21wcmVzc2VkIHN0cmluZ3Mg cmVtYWluIGxlbmd0aC1wcmVmaXhlZC4NCg0KDQoNCkV2ZW4gaWYgd2UgcmVtb3ZlIHRoZSBmcmFt aW5nIG9mIHRoZSBRQ0FDSyBpbnN0cnVjdGlvbnMsIGltcGxlbWVudGF0aW9ucyB3aWxsIGNvbnRp bnVlIHRvIGhhdmUgdGhlIGZyZWVkb20gdG8gYnVmZmVyIGEgY29tcGxldGUgSHVmZm1hbi1lbmNv ZGVkIHN0cmluZyAodGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5nIGJlaW5nIGlkZW50aWZpZWQgYnkg dGhlIGxlbmd0aCBvY3RldHMuDQoNCg0KDQo+IC1BbGFuDQoNCj4NCg0KPg0KDQoNCg0KDQoNCg0K DQotLQ0KDQpLYXp1aG8gT2t1DQoNCg0K --_000_0A25977EC62A403590C763D2D6B874E3fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <699F69BB08F45241BD2E4A4AB3A142B3@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFp blRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBs YWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcxNTE5ODExODsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6NzM4MzY5Mjc2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMDEzNjQ3ODgyOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTQ1NjY1MDAw IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmYWN0IHRoYXQgeW91IG5vdyBuZWVkIGFuIGFs Z29yaXRobSB0aGF0IHRlbGxzIHlvdSBob3cgdG8gY29ycmVjdGx5L3NhZmVseSBkZXNlcmlhbGl6 ZSBhIHNpbmdsZSBpbnN0cnVjdGlvbiBpcyBwcmV0dHkgbXVjaCB0aGUgcG9pbnQgSSB3YXMgbWFr aW5nLiZuYnNwOyBUaGlzIGlzIG1vcmUgY29tcGxleCB0aGFuIGp1c3QgaGF2aW5nIGEgYnl0ZSBv biB0aGUgd2lyZSB0ZWxsIHlvdSBob3cgbWFueSBieXRlcyBhcmUNCiByZXF1aXJlZC4mbmJzcDsg QnV0IEkgZmVlbCB0aGVyZeKAmXMgY2xlYXIgY29uc2Vuc3VzIGhlcmUgdG8gZGlzY2FyZCB0aGUg bGVuZ3RoIHByZWZpeC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUFsYW48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2 ZXF1ZWZvdS5iZSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBKdW5lIDEwLCAyMDE4IGF0 IDQ6MTYgUE08YnI+DQo8Yj5UbzogPC9iPkthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5j b20mZ3Q7LCBBbGFuIEZyaW5kZWxsICZsdDthZnJpbmRAZmIuY29tJmd0Ozxicj4NCjxiPkNjOiA8 L2I+UVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDssIE1hcnRpbiBUaG9tc29uICZsdDttYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBQcm9wb3Nh bDogZHJvcCBRUEFDSyBlbmNvZGVyIHN0cmVhbSBmcmFtaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIG5hbWU9Il9NYWlsT3JpZ2lu YWxCb2R5Ij5BbmQgdGhleSBwcm9iYWJseSBzaG91bGQsIHNpbmNlIHRoZXkgY2FuJ3Qgc2Vuc2li bHkgZG8gYW55dGhpbmcgd2l0aG91dCBhIGZ1bGwgaW5zdHJ1Y3Rpb24uJm5ic3A7IFNvIGFuIGlt cGxlbWVudGF0aW9uIHdvdWxkIG5lZWQgdG8gZG8gdGhlIGZvbGxvd2luZyBzdGVwczo8bzpwPjwv bzpwPjwvYT48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkNoZWNrIHRoZSBmaXJzdCBi eXRlOyBhdCB0aGlzIHBvaW50LCB5b3UgZWl0aGVyIGtub3cgdGhlIHN0cmluZ+KAmXMgZXhhY3Qg bGVuZ3RoLCBvciB5b3Uga25vdyBpdOKAmXMgbG9uZ2VyIHRoYW4gMzIgYnl0ZXMNCjxvOnA+PC9v OnA+PC9zcGFuPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPklmIGxvbmdlciwNCjxiPndh aXQ8L2I+IHVudGlsIHlvdeKAmXZlIGdvdHRlbiBhdCBsZWFzdCAzMiBtb3JlIGJ5dGVzLCBhbmQg eW914oCZcmUgZ3VhcmFudGVlZCB0byBoYXZlIHRoZSByZW1haW5kZXIgb2YgdGhlIG51bWJlcjsg ZmluZCB0aGUgYWN0dWFsIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+V2FpdDwvYj48L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+IHVudGlsIHlvdSBoYXZlIHRoZSBh Y3R1YWwgbGVuZ3RoIHBsdXMgb25lIGJ5dGU8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlVzZSB0aGUgbGVu Z3RoIG9mIHRoZSBlbmNvZGVkIHN0cmluZyB0byBsb2NhdGUgdGhlIGZpcnN0IGJ5dGUgb2YgdGhl IHZhbHVlIGxlbmd0aDsgeW91IGVpdGhlciBmaW5kIHRoZSBmdWxsIGxlbmd0aCwgb3IgeW91IGtu b3cgaXTigJlzIGF0IGxlYXN0IDEyOCBieXRlcyBsb25nDQo8bzpwPjwvbzpwPjwvc3Bhbj4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8zIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JZiBsb25nZXIsDQo8Yj53YWl0PC9iPiB1bnRpbCB5 b3XigJl2ZSBnb3R0ZW4gYXQgbGVhc3QgMTI4IG1vcmUgYnl0ZXM7IHlvdeKAmXJlIGd1YXJhbnRl ZWQgdG8gaGF2ZSB0aGUgYWN0dWFsIG51bWJlciBpbiB0aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+V2FpdDwvYj48 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+IHVudGls IHlvdSBoYXZlIHRoZSBhY3R1YWwgbGVuZ3RoIChyZW1haW5kZXIgb2YgdGhlIGluc3RydWN0aW9u KTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+RGVjb2RlIHRoZSBpbnN0cnVjdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPlNvIHlvdeKAmXJlIHBvdGVudGlhbGx5IHdhaXRpbmcgZm9yIG1vcmUgYnl0 ZXMgdXAgdG8gZm91ciB0aW1lcyBwZXIgaW5zdHJ1Y3Rpb24gKHRob3VnaCB0aGUgb2RkcyB0aGF0 IGEgbm9uLW1hbGljaW91cyBzZW5kZXIgd291bGQgaGl0IGFsbCBmb3VyIGFyZSBsb3cpLCBhbmQg YSBuYcOvdmUgaW1wbGVtZW50YXRpb24gbWlnaHQgd2VsbA0KIHJlLXBhcnNlIHRoZSBpbnN0cnVj dGlvbiBmcm9tIHRoZSBiZWdpbm5pbmcgYWZ0ZXIgZWFjaCB3YWl0IGNvbXBsZXRlcy4mbmJzcDsg SW1wbGljaXQgaW4gdGhpcyBpcyB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgMzIgYnl0ZSBsb25nIGlu dGVnZXIgd2lsbCBhbHdheXMgYmUgdW5hY2NlcHRhYmx5IGxvbmcsIGFuZCBpZiBhZnRlciB0aGUg d2FpdCB5b3UgY2Fu4oCZdCBtb3ZlIHRvIHRoZSBuZXh0IGZpZWxkIHN1Y2Nlc3NmdWxseSwgeW91 4oCZbGwgZmFpbCB0aGUgaW5zdHJ1Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QW4gaW1wbGVt ZW50YXRpb24gY2FuIGFsd2F5cyBkZXRlcm1pbmUgaG93IG1hbnkgYnl0ZXMgaXQgbmVlZHMgdG8g d2FpdCBmb3IgdG8gbWFrZSBwcm9ncmVzcywgd2l0aG91dCBhY2NpZGVudGFsbHkgd2FpdGluZyBw YXN0IHRoZSBlbmQgb2YgdGhlIGluc3RydWN0aW9uIGFuZCBjcmVhdGluZyBhIGRlYWRsb2NrIGlm IHRoYXTigJlzDQogYSB0YWlsLiZuYnNwOyBJIHRoaW5rIHRoaXMgZXhhbXBsZSBoYXMgY29udmlu Y2VkIG1lIHRoYXQgdGhlIGxlbmd0aCBwcmVmaXggaXMgdW5uZWNlc3NhcnkuJm5ic3A7IChJdCBk b2VzIG1ha2UgbWUgd29uZGVyIHdoZXRoZXIgaXQgd291bGQgaGF2ZSBtYWRlIG1vcmUgc2Vuc2Ug dG8gcHV0DQo8aT5ib3RoPC9pPiBsZW5ndGhzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGluc3Ry dWN0aW9uLCBmb2xsb3dlZCBieSB0aGUgdmFsdWVzLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFFVSUMgJmx0O3F1aWMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgT24gQmVoYWxmIE9mIEthenVobyBPa3U8YnI+DQpTZW50OiBTYXR1cmRheSwg SnVuZSA5LCAyMDE4IDM6NTcgUE08YnI+DQpUbzogQWxhbiBGcmluZGVsbCAmbHQ7YWZyaW5kQGZi LmNvbSZndDs8YnI+DQpDYzogUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBU aG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KU3ViamVjdDogUmU6 IFByb3Bvc2FsOiBkcm9wIFFQQUNLIGVuY29kZXIgc3RyZWFtIGZyYW1pbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij4yMDE4LTA2LTA5IDg6MjYgR01UJiM0MzswOTowMCBBbGFuIEZyaW5kZWxsICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFmcmluZEBmYi5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5hZnJpbmRAZmIuY29tPC9zcGFuPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ozo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlY2F1 c2UgSSB0aGluayByZXBhcnNpbmcgaXMgdGhlIGJlc3Qgc3RyYXRlZ3kgaGVyZSwgbGV0IG1lIGFy Z3VlIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSB3b3JzdCBjYXNlIGlzIG5vdCBPKE5eMikuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2YgY291cnNlLCBpbiB0 aGVvcnkgaXQgaXMgTyhOXjIpLCBiZWNhdXNlIHRoZXJlIGlzIG5vIHVwcGVyIGJvdW5kIGZvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhlIGludGVnZXIgcmVwcmVzZW50YXRpb24uIEJ1dCB0aGUgcmVhbGl0eSBpcyB0aGF0 IGltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIHJlcXVpcmVkIHRvIGhhdmUgYW4gdXBwZXIgYm91 bmQuIEknZCBhc3N1bWUgdGhhdCB0aGV5IHdvdWxkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBpY2FsbHkgb25seSBwZXJt aXQgdmFsdWVzIHRoYXQgZml0IGluIGEgMzItYml0ICh1KWludCAoMTYtYml0IGlzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh bm90aGVyIG9wdGlvbiBmb3Igc29tZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsgVGhl IE8oTl4yKSB3b3JrIEkgd2FzIHRoaW5raW5nIG9mIHdhcyBzb21ldGhpbmcgbGlrZSB0aGlzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7IFRoZSBlbmNvZGVyIHNlbmRzIGEgdmVyeSBsb25n IEh1ZmZtYW4gZW5jb2RlZCBoZWFkZXIgbmFtZSBmb2xsb3dlZCBieSBhIGxvbmcgdmFsdWUsIGJ1 dCB0aGV5IHNlbmQgdGhlIHZhbHVlIG9uZSBieXRlIGF0IGEgdGltZS4mbmJzcDsgSWYgdGhlIGRl Y29kZXIgbmFpdmVseSByZXBhcnNlcyB0aGUgZW50aXJlIEluc2VydCBpbnN0cnVjdGlvbg0KIGV2 ZXJ5IHRpbWUgYSBieXRlIGFycml2ZXMsIGl0IHdpbGwgZW5kIHVwIEh1ZmZtYW4gZGVjb2Rpbmcg dGhlIGhlYWRlciBuYW1lIG9uIGV2ZXJ5IG5ldyBieXRlIG9mIHRoZSB2YWx1ZS4mbmJzcDsgVGhl IG5hbWUgY2FuIGJlIHNraXBwZWQgb3ZlciB0byByZS1wYXJzZSB0aGUgdmFsdWUgbGVuZ3RoLCBh bmQgdmVyaWZ5IGlmIHRoZSBmdWxsIHZhbHVlIGlzIHByZXNlbnQuJm5ic3A7IEhvd2V2ZXIsIGV2 ZW4gc2tpcHBpbmcgb3ZlciBpdCBtYXkgYmUgYSBsaW5lYXINCiBvcGVyYXRpb24gaW4gYSB6ZXJv LWNvcHkgaW1wbGVtZW50YXRpb24gdGhhdCBtYWludGFpbnMgYSBsaW5rZWQgbGlzdCBvZiBkYXRh IGJ1ZmZlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNh dGlvbi4gVGhhdCBzb3VuZHMgbGlrZSBhbiBpbnRlcmVzdGluZyBhdHRhY2sgdmVjdG9yIHRoYXQg d2UgbmVlZCB0byBiZSBhd2FyZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PVE9ILCBJIGFtIG5v dCBzdXJlIGlmIHdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIHN0cmVhbWlu ZyBIdWZmbWFuIGRlY29kaW5nIGluIHRoaXMgZGlzY3Vzc2lvbiwgY29uc2lkZXJpbmcgdGhlIGZh Y3QgdGhhdCB0aGUgY29tcHJlc3NlZCBzdHJpbmdzIHJlbWFpbiBsZW5ndGgtcHJlZml4ZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+RXZlbiBpZiB3ZSByZW1vdmUgdGhlIGZyYW1pbmcgb2YgdGhlIFFD QUNLIGluc3RydWN0aW9ucywgaW1wbGVtZW50YXRpb25zIHdpbGwgY29udGludWUgdG8gaGF2ZSB0 aGUgZnJlZWRvbSB0byBidWZmZXIgYSBjb21wbGV0ZSBIdWZmbWFuLWVuY29kZWQgc3RyaW5nICh0 aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmcgYmVpbmcgaWRlbnRpZmllZA0KIGJ5IHRoZSBsZW5ndGgg b2N0ZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsgLUFsYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+S2F6dWhvIE9rdTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0A25977EC62A403590C763D2D6B874E3fbcom_-- From nobody Mon Jun 11 08:33:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D751277BB for ; Mon, 11 Jun 2018 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6QwfMNNIf6Q for ; Mon, 11 Jun 2018 08:33:45 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 D96EC12D949 for ; Mon, 11 Jun 2018 08:33:44 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2018 08:33:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.49,502,1520924400"; d="scan'208,217"; a="62198523" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga004.fm.intel.com with ESMTP; 11 Jun 2018 08:33:42 -0700 Received: from orsmsx163.amr.corp.intel.com (10.22.240.88) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Jun 2018 08:33:42 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX163.amr.corp.intel.com ([169.254.9.20]) with mapi id 14.03.0319.002; Mon, 11 Jun 2018 08:33:41 -0700 From: "Deval, Manasi" To: IETF QUIC WG Subject: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xA== Date: Mon, 11 Jun 2018 15:33:35 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWNjMzYzNmQtYzE5NS00Y2IzLWE2YmUtNGVkYjQyNzIyNmVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZmk1aXVVNTIrbnNBWHJSeTlPWVJ5YnZKXC9NVXN4aFd2eHZTRUMwQUsyTjlMR2Qxdklwb0RDOXE2QVFRSDNNRFAifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B832414ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:33:48 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B832414ORSMSX111amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I was wondering why QUIC ACK header does not have a length field. For example, while parsing the QUIC ACK, I find that an offload for segment= ation or coalescing needs to identify an ACK interleaved between streams. A= s the ACK cannot be broken up and the chunk of ACK bytes needs to be moved = as a block, reading the entire ACK to identify its length is a heavy lift. Therefore, I'm proposing an ACK format with an ACK length instead of ACK bl= ock count. What is the change? * ACK length is the first field, fixed length of 2 bytes. * ACK length is defined as the length of the entire ACK block, inclu= ding the 2 byte ACK length. * ACK length replaces the ACK block count. There is no change to Largest Acknowledged or ACK delay. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Acknowledged (i) max 64 bit ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Delay (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Blocks (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The advantages of the length field are: - Moving the ACK length to the front of the ACK allows the flexibili= ty of either reading the entire ACK or reading the first 16 bits and skippi= ng over the length. This is a useful feature for the case where ACK process= ing is split into multiple layers. Depending on the processor this is run o= n, there are different advantages - o If this is run on high end CPUs, the length helps identify the length = for some SIMD modifications. o If this is a low end CPU, the multi-threading becomes more important fo= r performance. - For the case where a receiver coalesce layer is augmenting the QUI= C stack, I expect that it would separate the coalescing into stream frames,= ACK frames and control frames. Availability of ACK length, simplifies this= logic. - For a case where a transmit segmentation layer would like to make = an intelligent decision on whether the ACK can be placed in a segment or no= t - it needs to know the size of ACK. Having to do a series of reads to ide= ntify the ACK size is inefficient. Thanks, Manasi --_000_1F436ED13A22A246A59CA374CBC543998B832414ORSMSX111amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I was wondering why QUIC ACK header does not have a = length field.

 

For example, while parsing the QUIC ACK, I find that= an offload for segmentation or coalescing needs to identify an ACK interle= aved between streams. As the ACK cannot be broken up and the chunk of ACK b= ytes needs to be moved as a block, reading the entire ACK to identify its length is a heavy lift. =

 

Therefore, I’m proposing an ACK format with an= ACK length instead of ACK block count.

 

What is the change?

·        ACK length is the first field, fixed length = of 2 bytes.

·        ACK length is defined as the length of the e= ntire ACK block, including the 2 byte ACK length.

·        ACK length replaces the ACK block count.

 

There is no change to Largest Acknowledged or ACK de= lay.

 

 

    0   &nbs=
p;            &=
nbsp;  1          &n=
bsp;        2    &nb=
sp;            =
  3
    0 1 2 3 4 5 6 7 8 9 0 1=
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+
   |    &nbs=
p;   ACK Length        &n=
bsp;    |    
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   |    &nbs=
p;            &=
nbsp;   Largest Acknowledged (i) max 64 bit   &nbs=
p; ...
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   |    &nbs=
p;            &=
nbsp;         ACK Delay (i) &n=
bsp;            =
;       ...
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   |    &nbs=
p;            &=
nbsp;        ACK Blocks (*)  &=
nbsp;           &nbs=
p;      ...
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+

 

 

The advantages of the length field are:

-       = ; Moving the ACK length to the front of the ACK allow= s the flexibility of either reading the entire ACK or reading the first 16 = bits and skipping over the length. This is a useful feature for the case wh= ere ACK processing is split into multiple layers. Depending on the processor this is run on, there are diff= erent advantages –

o    If this is run on high end CPUs, the l= ength helps identify the length for some SIMD modifications.

o   If this is a low end CPU, the multi-threadin= g becomes more important for performance.

-       = ; For the case where a receiver coalesce layer is aug= menting the QUIC stack, I expect that it would separate the coalescing into= stream frames, ACK frames and control frames. Availability of ACK length, = simplifies this logic.

-       = ; For a case where a transmit segmentation layer woul= d like to make an intelligent decision on whether the ACK can be placed in = a segment or not – it needs to know the size of ACK. Having to do a s= eries of reads to identify the ACK size is inefficient.

 

Thanks,

Manasi

 

 

 

--_000_1F436ED13A22A246A59CA374CBC543998B832414ORSMSX111amrcor_-- From nobody Mon Jun 11 08:43:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51D130E39 for ; Mon, 11 Jun 2018 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 RZ_19icsZpAF for ; Mon, 11 Jun 2018 08:43:22 -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 78793130E31 for ; Mon, 11 Jun 2018 08:43:22 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id o9-v6so20672057qtp.3 for ; Mon, 11 Jun 2018 08:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D/5UzF84eL+kJZTXKWOywLsCa/qxokA1jLW8wf+cnHM=; b=mUIn+ndhLd6xDB8H5MZx49vaGhnt9VdQdwUh7my0C+nEhjtJ1mO31COM5JxTYSoZtZ oU1Aic1jDcogRPTImGCn6qyy48ar15QIPT2jfWxpvY2hJCSsSdjJ3uRsJbTEa5c78ALY OXo0FtzRadafDDa8mBNo02qxs0hj0HF9g1ddA6TFHoCNKh9bYx2Vid6j5W9DIM2TC8Xt BPB5dBEegjpsG/PJYuPTWr3+QTxD7DVjjuSN8LXilgqbXL4C+LCFOWyF1+jQGke+3sFh s+riDwuIiQVt2ylZT37i5JvUJqZ3KHHDmvrMLN/Sbu9VkLbnOBbVuTE/5pladuYuh1WM NKfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=D/5UzF84eL+kJZTXKWOywLsCa/qxokA1jLW8wf+cnHM=; b=Id2J3/+zh63ClHKo6qh13zqF3SGcN3c5vkcdC5B7wogLllClQuMM2nn9gF6fsxEOwg QOoK4aeaubKvp5+ohgdVrHrWsnHqaKGIcULeRt77bIIVNnxVsH+9f/3nrTlJQznt2z5D hAa/0gUK1sVwgc9a8CE3BfpdbBqYg556n/u446g7H+1ptGgVSfkkzuziW72yc36NSBqR 7yrammnbADvCBRh7oMhPg5M8lhzC+80LnyNGTS1BdSHS3NcqTo/Qy8g3G0qxC0js0cu2 0bMh6Gkcjg8R1nQD6LrWohFc3XenkViuELNnbupSCfPiBH3KBQ8mOg67wrS7uMXMtAP/ opEQ== X-Gm-Message-State: APt69E2w/c/xW/gdI7EtzGnni3n1bHIy3eR2C0XGp+NfUv607m//NwA5 MyQbAWKlgfZM9zh+8JJKtpYaVg== X-Google-Smtp-Source: ADUXVKJHcbOvEOTm2lNHXN1S30/tnydiKiKPbkaMli+t3iGf5cfCWgwSHV6wumu6FuY76yacDuHYgQ== X-Received: by 2002:aed:3d09:: with SMTP id g9-v6mr16746275qtf.272.1528731801593; Mon, 11 Jun 2018 08:43:21 -0700 (PDT) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id k67-v6sm4811392qte.95.2018.06.11.08.43.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 08:43:21 -0700 (PDT) Date: Mon, 11 Jun 2018 11:43:15 -0400 From: Dmitri Tikhonov To: "Deval, Manasi" Cc: IETF QUIC WG Subject: Re: Proposal to replace ACK block count with ACK length Message-ID: <20180611154244.GA27622@ubuntu-dmitri> Mail-Followup-To: "Deval, Manasi" , IETF QUIC WG References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:43:25 -0000 On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > - Moving the ACK length to the front of the ACK allows the > flexibility of either reading the entire ACK or reading the > first 16 bits and skipping over the length. This is a useful > feature for the case where ACK processing is split into > multiple layers. Depending on the processor this is run on, > there are different advantages - Just a note. In my experience, the cost of parsing an ACK frame is negligible compared to the cost of processing an ACK frame: that is, poking at various memory locations to discard newly ACKed packets. - Dmitri. From nobody Mon Jun 11 15:11:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE69130ED8 for ; Mon, 11 Jun 2018 15:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM0L0FTMukVB for ; Mon, 11 Jun 2018 15:11:37 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 7E154130EB4 for ; Mon, 11 Jun 2018 15:11:37 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id g7-v6so25718457ioh.11 for ; Mon, 11 Jun 2018 15:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2aSmJc9vtbjz5+9AjzZJx58CPsDuyf0iNk0MXQKp5GQ=; b=UpPJW8okq1A96thDINkH5Q1BmHEvtPKn5KYOAFegbQYyqTQK9t3r17LHl0iaAHkq/Q FHnUaQfp05ztK5P320iHtMyZYxqkEA4ClF7zQSKs+jPvnmqMjrOJpIK3YVMYmmUMaIdD 4Do3R4HcaMZKbmxyZPGBolqcyQ1JGP2fLpBcd2ao+T47TBFaS/5G6Bxm3NxphKYp8UNm KpPesOnl7ZN1RovXwwBzCMrTlTvg06BEvlFT9+Bnso/Aoi8EFGGl0VO60CpUlljFvPu6 6ULs/tZ2l5VJAA3RXQqtJOmRqXFyW/zfTPP9JdjIRFXoQ0SMnl4Yc0IVftELZXnt7EqM wucQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2aSmJc9vtbjz5+9AjzZJx58CPsDuyf0iNk0MXQKp5GQ=; b=s3gAj7T+fvLEKgmoukIxObT5PbTZKGuDY0OEfNEA10i1xG1BtB4D9aDTi/pzznASyZ d3faMHOJdI75kl9WLv0DCC9szn/GBlB4745iJyS9KFSJJWf38OJvBDs5nsZb2pv3yP/N xJMiL7Fueg/VhHt014/mlU4oxvO9TLZOl90FvSBPgK/f7jGwPQ1hOXddqrHGvzFtC38F dXoQUqiJWEzZ5SwPaa5TiuIFF4JWDWryaUyKcEpcIsvVCZOi4Ddai/2P8ujUd5pKoUnw cTm0w2W3FDvmLzp9JHVR1WLN9PPF52m05n2RK2DU3xnYfxxGwG9MsxFOV0+yDVHhTRb4 VJLQ== X-Gm-Message-State: APt69E11jKQxno+/uHaTFQComvV92fK5QZ74uxqAqjF17JYA6yBwH3A5 VSbsCJQD0NyTtjdE4tfSY3ICOjAcbld8zyYjMMY= X-Google-Smtp-Source: ADUXVKJfYlpMS9Pt1m4+WkvJaqoKIJ/iFQ/p9LBCUj4dkiABi/4O5AU417lnIjW0Ep1v02sCjtuCtW4oG7SVkTFPv5M= X-Received: by 2002:a6b:d106:: with SMTP id l6-v6mr948034iob.8.1528755096837; Mon, 11 Jun 2018 15:11:36 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> In-Reply-To: <20180611154244.GA27622@ubuntu-dmitri> From: Jana Iyengar Date: Mon, 11 Jun 2018 15:11:25 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" , QUIC WG Content-Type: multipart/alternative; boundary="0000000000007ee4bc056e6508e4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 22:11:40 -0000 --0000000000007ee4bc056e6508e4 Content-Type: text/plain; charset="UTF-8" You're right that we no longer have the ability to skip an ACK frame, and this crept in when we moved to varints. I believe your problem though is generally true of most frames not just ACKs, since ids, packet numbers, and numbers in all frames are now all varints. To skip any frame, you'll need to parse the varint fields in those frames. If you have logic to process and skip varints, then skipping the ack block section is merely repeating this operation (2*num_block+1) times. Do you see specific value in skipping ACK frames over the other control frames? On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov wrote: > On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > > - Moving the ACK length to the front of the ACK allows the > > flexibility of either reading the entire ACK or reading the > > first 16 bits and skipping over the length. This is a useful > > feature for the case where ACK processing is split into > > multiple layers. Depending on the processor this is run on, > > there are different advantages - > > Just a note. In my experience, the cost of parsing an ACK frame is > negligible compared to the cost of processing an ACK frame: that is, > poking at various memory locations to discard newly ACKed packets. > > - Dmitri. > > --0000000000007ee4bc056e6508e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You're right that we no longer have the ability to ski= p an ACK frame, and this crept in when we moved to varints.

I = believe your problem though is generally true of most frames not just ACKs,= since ids, packet numbers, and numbers in all frames are now all varints. = To skip any frame, you'll need to parse the varint fields in those fram= es. If you have logic to process and skip varints, then skipping the ack bl= ock section is merely repeating this operation (2*num_block+1) times. Do yo= u see specific value in skipping ACK frames over the other control frames?<= /div>


O= n Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
=
On Mon, Jun 11, 2018 at 03:33:35PM +0000, De= val, Manasi wrote:
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the front of the= ACK allows the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either reading the en= tire ACK or reading the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping over the = length. This is a useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where ACK proce= ssing is split into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending on the pr= ocessor this is run on,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advantages -

Just a note.=C2=A0 In my experience, the cost of parsing an ACK frame is negligible compared to the cost of processing an ACK frame: that is,
poking at various memory locations to discard newly ACKed packets.

=C2=A0 - Dmitri.

--0000000000007ee4bc056e6508e4-- From nobody Mon Jun 11 15:51:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5E12F1A5 for ; Mon, 11 Jun 2018 15:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fpeKglrhxQh for ; Mon, 11 Jun 2018 15:51:35 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 EBE141274D0 for ; Mon, 11 Jun 2018 15:51:34 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id a3-v6so13086009itd.0 for ; Mon, 11 Jun 2018 15:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sAe97rCdnkzZf/fJIFrUWuRh5hzUsp27b0bFG4WALtY=; b=QDDVBcqgfi+fBK3YokMb11bgXTrF1eOZsfU1GJnq0r5xCcCcrGB5LHAVSgTSahIWrW 5i22Mn5vipb6t5BLQ43wiirBn5SzK6qhipgNqBWVu9HHzrJIAG7JHrekvnsg+FrYWAma qyY6Qew8wPBq5IfjmibOZiflx0SaXBiy/YymjL0ct/fr0Gvz7ujHQLb5VOr1N+lO7Zho 28cuGhhtyf7RAoj/JYMG1aW+dCblpm+i2n1u+eMkheC/IJX/XoxkzE+HxAkUVhg/qz/O YwUvqlveRPSJkTe6SP6677J/+4r4aK2JOjWUZWzCqGkvKuGgHReZr4Zgadi9gQrzblAa zl3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sAe97rCdnkzZf/fJIFrUWuRh5hzUsp27b0bFG4WALtY=; b=a5ZPLgBNg5fcHKKc3shNTus4aam12gUrcvQSaRH5/R3rD2Sg4p93Q6vO0LlX6fN3Gi NTPAgzI8iRoDHdROW4rt/yjILzPS/gJKoZWOQeX4XmUUysAOYz66koKkWT0HkslF5Ugc WfCBrFFMLn04L9fom7n4Y4TEY3wmsizE7spH7dXllt+e2wPXKJQt1vzxlK/HbcWiHLUj x4/HSRjhWs9kSCmkfuqZpi5NbSseaAFtqNBeqFkogfmG2CD5sWiviQ8yjG6o43/D9nxA HEO7hrL5v5/uL1X/EZJoSH0LEkBuM+zF5wR5+QKxbDRBQbqtaC/qF9XF1BeyCHPqH41j Cb+w== X-Gm-Message-State: APt69E0upV+mHmDBdxVdY+SQckFt/aZAO7AhgoImhVGyQlqQNjTNZW2s hHp4vJ4aiN8bc47ar3/9VYQiFZByCAaJFtE5Tk8= X-Google-Smtp-Source: ADUXVKIwp69J96GmMXbndg4cEYFcoLEKjWFL8k1kUrrZhRM21jp71Yi3eHRnzHaWsddanjc6dzfDwWvrBLfqWfhYfNs= X-Received: by 2002:a24:5594:: with SMTP id e142-v6mr907271itb.46.1528757494235; Mon, 11 Jun 2018 15:51:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Mon, 11 Jun 2018 15:51:23 -0700 Message-ID: Subject: Re: ack delay in rx packets To: Subodh Iyengar Cc: Ian Swett , Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="00000000000064479b056e6597b4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 22:51:38 -0000 --00000000000064479b056e6597b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subodh, I think you're right. We should fix this issue, though I'm not exactly sure how. We dropped this earlier; I've filed #1438 so that we can continue this discussion there. - jana On Wed, Apr 25, 2018 at 9:48 AM Subodh Iyengar wrote: > It's possible that both sides will TLP at the same time assuming their RT= T > estimates are the same and both sides are tails. To see whether this > happens I'll have to actually look at data in practice to see whether we > see whether there is a delay between the server's TLP/RTO and the client'= s > TLP/RTO. > > There is also another class case which in which it might be useful to > retransmit the ack without a new packet where one side does not have a ta= il > but the other does. For example, in the case of a revproxy where there is > an upstream server. The client has sent a tail request to the revproxy, > which it forwards to a webserver. > > > There are 2 cases here: > > 1. The webserver has some processing delay which is < 2 * RTT, so the > response comes back and we have new data to send. The server could als= o > bundle a duplicate ack with this packet. > 2. The response is larger than the request, so we could have bundled > some dup ACKs with the response. > > > It is possible that the client would set an ACK timer < RTO timer and the= n > send an ACK for this new packet, however if a server strictly does not AC= K > acks, the client would still have to wait for the RTO timer. > > > Subodh > ------------------------------ > *From:* Ian Swett > *Sent:* Wednesday, April 25, 2018 9:32:40 AM > *To:* Subodh Iyengar > *Cc:* ianswett=3D40google.com@dmarc.ietf.org; Jana Iyengar; IETF QUIC WG > *Subject:* Re: ack delay in rx packets > > I'm not sure it would be much better, but it's worth thinking through the > case you're describing. > > It must be that no 'retransmittable'(I hate that term) packets are being > received, but you're sending packets. If it's a one-way transfer, then > you're receiving ACKs for the data you're sending at a regular rate. If > you bundled an ack with outgoing data every sometimes, the ack would have= a > new largest acked of the received ACK packets, so all is well. > > If it's a long pause, such as a TLP or RTO, then you've waited more than > an RTT and received no packets to acknowledge, but then you decide to > bundle an ACK? At that point, it's likely the peer has already TLP'd > around the same time, so you're probably not saving them a retransmission= . > > It had never occurred to me to bundle an ACK in this case, but doing so > does have the side effect of creating useless RTT estimates. We could ha= ve > a special value(already disliking this) for max_ack_delay which indicates > the ACK should not be used for RTT estimates, but I'm not sure it's > valuable to bundle an ACK with TLPs and RTOs. > > On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar wrote: > > @Ian Swett sending ACKs in response to packets or > delay seems fine, and an implementation might choose to do that. If we ha= ve > more opportunities to send an ACK and avoid an RTO on the peer, wouldn't > that be better? Is the objective of sending packets only during timer or > recv data to simplify the ack delay calculation logic? > > > Subodh > ------------------------------ > *From:* Subodh Iyengar > *Sent:* Wednesday, April 25, 2018 9:11:15 AM > *To:* Ian Swett; Jana Iyengar > *Cc:* IETF QUIC WG > *Subject:* Re: ack delay in rx packets > > > My concern is this situation: a "receiver" had not seen the original ACK > (the packet was lost), then the sender rtos and sends a large ack delay t= o > compensate for the rto, the max filter for max ack delay would inflate th= e > delay for future packet. > > > if latest_rtt - min_rtt > ack_delay: > > max_ack_delay =3D max(max_ack_delay, ack_delay) > > > latest_rtt in this case would be rto_timer + rtt because the sender sends > an ack after an rto. > > > The rtt cal So max ack delay would become the rto timer. Is this a correc= t > characterization? > > > Subodh > > ------------------------------ > *From:* QUIC on behalf of Ian Swett 40google.com@dmarc.ietf.org> > *Sent:* Wednesday, April 25, 2018 9:09:39 AM > *To:* Jana Iyengar > *Cc:* Subodh Iyengar; IETF QUIC WG > *Subject:* Re: ack delay in rx packets > > Jana's right about ignoring the ack for RTT calculation if it doesn't > acknowledge a new packet, see section 3.1: > https://tools.ietf.org/html/draft-ietf-quic-recovery-11#section-3.1 > > > If it did acknowledge a new packet because the previous ACK was lost, the= n > you end up with either a useless RTT, a useless max ack delay, or both. > Because of issues like this, I prefer sending acks in response to packets= , > or within an alarm of packet receipt, rather than at other times. > > On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar wrote: > > If the sender has seen a previous ack for the same largest received, then > it should basically ignore this new ack. If not, the ack delay will be > accurate... What concern do you see with having a large ack delay? > > On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar wrote: > > We ran into very common cases where we might have all our data to send > already outstanding, so when a TLP and RTO alarm fires, we have no new da= ta > to send, so we resend data that was in previous packets. > > > In the time that the RTO fires, we might not have received any new > packets, however want to send ACKs in this new packet as well. Since no n= ew > packets were received, this ACK will have the same largest acked as the > previous packet. > > > One question came up as to what the ack delay of an ACK in such a rx > packet should be. We could technically set it to the time since receipt o= f > the packet, however with the new max_ack_delay computations, adding this > might screw up our estimate of the normal ack delay, so I don't really wa= nt > to do that. Is there a better option here, or does max_ack_delay not cove= r > this case? > > > Subodh > > --00000000000064479b056e6597b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Subodh,

I think you're right. We should fix thi= s issue, though I'm not exactly sure how.=C2=A0 We dropped this earlier= ; I've filed #1438 so that we can continue this discussion there.

- = jana

On Wed, Apr= 25, 2018 at 9:48 AM Subodh Iyengar <su= bodh@fb.com> wrote:

It's possible that both sides= will TLP at the same time assuming their RTT estimates are the same and bo= th sides are tails. To see whether this happens I'll have to actually l= ook at data in practice to see whether we see whether there is a delay between the server's TLP/RTO and the clie= nt's TLP/RTO.

There is also another class case=C2=A0which in which it might be useful to = retransmit the ack without a new packet where one side does not have a tail= but the other does. For example, in the case of a revproxy where there is = an upstream server. The client has sent a tail request to the revproxy, which it forwards to a webserver.


There are 2 cases here:

  1. The webserver has some processing delay which is < 2 * RTT, so the r= esponse comes back and we have new data to send. The server could also bund= le a duplicate ack with this packet.
  2. The response is larger than the request, so we could have bundled = some dup ACKs with the response.


It is possible that the client wo= uld set an ACK timer < RTO timer and then send an ACK for this new packe= t, however if a server strictly does not ACK acks,=C2=A0 the client would s= till have to wait for the RTO timer.


Subodh

From: = Ian Swett <ians= wett@google.com>
Sent: Wednesday, April 25, 2018 9:32:40 AM
To: Subodh Iyengar
Cc: ianswett=3D40google.com@dmarc.ietf.org; Jana Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets
=C2=A0
I'm not sure it would be much better, but it's wor= th thinking through the case you're describing.

It must be that no 'retransmittable'(I hate that term) packets= are being received, but you're sending packets.=C2=A0 If it's a on= e-way transfer, then you're receiving ACKs for the data you're send= ing at a regular rate.=C2=A0 If you bundled an ack with outgoing data every sometimes, the ack would have a new largest acked of the received AC= K packets, so all is well.

If it's a long pause, such as a TLP or RTO, then you've waited= more than an RTT and received no packets to acknowledge, but then you deci= de to bundle an ACK?=C2=A0 At that point, it's likely the peer has alre= ady TLP'd around the same time, so you're probably not saving them a retransmission.

It had never occurred to me to bundle an ACK in this case, but doing s= o does have the side effect of creating useless RTT estimates.=C2=A0 We cou= ld have a special value(already disliking this) for max_ack_delay which ind= icates the ACK should not be used for RTT estimates, but I'm not sure it's valuable to bundle an ACK wit= h TLPs and RTOs.

On Wed, Apr 25, 2018 at 12:20 PM Subodh Iyengar <subodh@fb.com> wrote:

@Ian Swett sending ACKs in response to packets or delay seems fine, and an implementation mig= ht choose to do that. If we have more opportunities to send an ACK and avoi= d an RTO on the peer, wouldn't that be better? Is the objective of send= ing packets only during timer or recv data to simplify the ack delay calculation logic?


Subodh

From: Subodh Iyengar
Sent: Wednesday, April 25, 2018 9:11:15 AM
To: Ian Swett; Jana Iyengar
Cc: IETF QUIC WG
Subject: Re: ack delay in rx packets
=C2=A0

My concern is this situation: a &= quot;receiver" had not seen the original ACK (the packet was lost), th= en the sender rtos and sends=C2=A0a large ack delay to compensate for the r= to, the max filter for max ack delay would inflate the delay for future packet.


if latest_rtt=C2=A0- min_rtt=C2= =A0 > ack_delay:

=C2=A0 =C2=A0max_ack_delay =3D ma= x(max_ack_delay, ack_delay)


latest_rtt in this case would be = rto_timer + rtt because the sender sends an ack after an rto.


The rtt cal So max ack delay woul= d become the rto timer. Is this a correct characterization?


Subodh


From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <= ianswett=3D40google.com@dmarc.ietf.org>
Sent: Wednesday, April 25, 2018 9:09:39 AM
To: Jana Iyengar
Cc: Subodh Iyengar; IETF QUIC WG
Subject: Re: ack delay in rx packets
=C2=A0
Jana's right about ignoring the ack for RTT calculatio= n if it doesn't acknowledge a new packet, see section 3.1:=C2=A0https://tools.ietf.org/html/draft-i= etf-quic-recovery-11#section-3.1

If it did acknowledge a new packet because the previous ACK was lost, = then you end up with either a useless RTT, a useless max ack delay, or both= .=C2=A0 Because of issues like this, I prefer sending acks in response to p= ackets, or within an alarm of packet receipt, rather than at other times.

On Wed, Apr 25, 2018 at 11:53 AM Jana Iyengar <jri.ietf@gmail.com>= wrote:
If the sender has seen a previous ack for the same larges= t received, then it should basically ignore this new ack. If not, the ack d= elay will be accurate... What concern do you see with having a large ack de= lay?

On Wed, Apr 25, 2018, 8:08 AM Subodh Iyengar <subodh@fb.com> wrote:

We ran into very common cases whe= re we might have all our data to send already outstanding, so when a TLP an= d RTO alarm fires, we have no new data to send, so we resend data that was = in previous packets.


In the time that the RTO fires, w= e might not have received any new packets, however want to send ACKs in thi= s new packet as well. Since no new packets were received, this ACK will hav= e the same largest acked as the previous packet.


One question came up as to what t= he ack delay of an ACK in such a rx packet should be. We could technically = set it to the time since receipt of the packet, however with the new max_ac= k_delay computations, adding this might screw up our estimate of the normal ack delay, so I don't really= want to do that. Is there a better option here, or does max_ack_delay not = cover this case?


Subodh

--00000000000064479b056e6597b4-- From nobody Mon Jun 11 17:22:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CEC130E7D for ; Mon, 11 Jun 2018 17:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0kJdchc5Rv6 for ; Mon, 11 Jun 2018 17:22:06 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 C7783130DC3 for ; Mon, 11 Jun 2018 17:22:06 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2018 17:22:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,212,1526367600"; d="scan'208,217";a="207242152" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga004.jf.intel.com with ESMTP; 11 Jun 2018 17:22:05 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Jun 2018 17:22:05 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX157.amr.corp.intel.com ([169.254.9.202]) with mapi id 14.03.0319.002; Mon, 11 Jun 2018 17:22:05 -0700 From: "Deval, Manasi" To: Jana Iyengar , QUIC WG Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUA== Date: Tue, 12 Jun 2018 00:22:04 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGQxNTBhNWYtNGQ1NC00NzY1LTg3YjMtM2RlN2Q1NWMwY2Y2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWTZ5K2d6TWJjWWpFZzF1cHNMcXBTSEdmQ1BcLzh0VFRpXC9xNXc5TWxSbTdpbStIYXBHZVdXNTZ5eHJUT2ZrdGZnIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B833B91ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:22:11 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B833B91ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gZ2VuZXJhbCwgdmFyaW50cyByZXF1aXJlIHNvbWUgc3BlY2lmaWMgbG9naWMgZm9yIHBhcnNp bmcuIFRvIHNraXAgb3ZlciBhbnkgaGVhZGVyLCBJIGhhdmUgdG8gcmVhZCBldmVyeSBzaW5nbGUg dmFyaW50LiBBcyB0aGUgY29kZSBzZWVzIFN0cmVhbSBhbmQgQUNLIGhlYWRlcnMgbW9zdCBmcmVx dWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiAgVGhlIFN0cmVhbSBmcmFtZSBoYXMgYSBsZW5ndGgg aW4gaXRzIHRoaXJkIGZpZWxkLg0KDQpBQ0sgcGFyc2luZywgaG93ZXZlciwgbmVlZHMgNiArIDIq bnVtX2Jsb2NrcyByZWFkcyB0byBpZGVudGlmeSBsZW5ndGguIFRoZXJlIGFyZSB0d28gcmVhZHMg ZWFjaCBmb3Ig4oCYbGFyZ2VzdCBhY2tub3dsZWRnZWTigJksIOKAmEFDSyBkZWxheeKAmSBhbmQg 4oCYQUNLIGJsb2NrIGNvdW504oCZLiBUaGUgcGFpbiBwb2ludCBpcyB0aGUgdG90YWwgbnVtYmVy IG9mIGN5Y2xlcyBwYXJzZSBhbiBBQ0suIElmIEkgYW0gcHJvY2Vzc2luZyAxME0gcHBzLCB3aGVy ZSAxMCUgLSAzMCUgb2YgdGhlIHBhY2tldHMgaGF2ZSBhIHBpZ2d5YmFja2VkIEFDSywgdGhlc2Ug Y3ljbGVzIGJlY29tZXMgYSBzaWduaWZpY2FudCBib3R0bGVuZWNrLg0KDQpUaGFua3MsDQpNYW5h c2kNCg0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IE1vbmRheSwgSnVuZSAxMSwgMjAxOCAzOjExIFBN DQpUbzogRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT47IFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sg Y291bnQgd2l0aCBBQ0sgbGVuZ3RoDQoNCllvdSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBo YXZlIHRoZSBhYmlsaXR5IHRvIHNraXAgYW4gQUNLIGZyYW1lLCBhbmQgdGhpcyBjcmVwdCBpbiB3 aGVuIHdlIG1vdmVkIHRvIHZhcmludHMuDQpJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBp cyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1lcyBub3QganVzdCBBQ0tzLCBzaW5jZSBpZHMs IHBhY2tldCBudW1iZXJzLCBhbmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzIGFyZSBub3cgYWxsIHZh cmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50 IGZpZWxkcyBpbiB0aG9zZSBmcmFtZXMuIElmIHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5k IHNraXAgdmFyaW50cywgdGhlbiBza2lwcGluZyB0aGUgYWNrIGJsb2NrIHNlY3Rpb24gaXMgbWVy ZWx5IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2srMSkgdGltZXMuIERvIHlv dSBzZWUgc3BlY2lmaWMgdmFsdWUgaW4gc2tpcHBpbmcgQUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhl ciBjb250cm9sIGZyYW1lcz8NCg0KDQpPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERt aXRyaSBUaWtob25vdiA8ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPG1haWx0bzpkdGlraG9u b3ZAbGl0ZXNwZWVkdGVjaC5jb20+PiB3cm90ZToNCk9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDAz OjMzOjM1UE0gKzAwMDAsIERldmFsLCBNYW5hc2kgd3JvdGU6DQo+IC0gICAgICAgIE1vdmluZyB0 aGUgQUNLIGxlbmd0aCB0byB0aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3MgdGhlDQo+ICAgICAg ICAgIGZsZXhpYmlsaXR5IG9mIGVpdGhlciByZWFkaW5nIHRoZSBlbnRpcmUgQUNLIG9yIHJlYWRp bmcgdGhlDQo+ICAgICAgICAgIGZpcnN0IDE2IGJpdHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxl bmd0aC4gVGhpcyBpcyBhIHVzZWZ1bA0KPiAgICAgICAgICBmZWF0dXJlIGZvciB0aGUgY2FzZSB3 aGVyZSBBQ0sgcHJvY2Vzc2luZyBpcyBzcGxpdCBpbnRvDQo+ICAgICAgICAgIG11bHRpcGxlIGxh eWVycy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3IgdGhpcyBpcyBydW4gb24sDQo+ICAgICAg ICAgIHRoZXJlIGFyZSBkaWZmZXJlbnQgYWR2YW50YWdlcyAtDQoNCkp1c3QgYSBub3RlLiAgSW4g bXkgZXhwZXJpZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWUgaXMNCm5lZ2xp Z2libGUgY29tcGFyZWQgdG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRo YXQgaXMsDQpwb2tpbmcgYXQgdmFyaW91cyBtZW1vcnkgbG9jYXRpb25zIHRvIGRpc2NhcmQgbmV3 bHkgQUNLZWQgcGFja2V0cy4NCg0KICAtIERtaXRyaS4NCg== --_000_1F436ED13A22A246A59CA374CBC543998B833B91ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ3MTI4NTkxMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Njk5Mjk2NTg2IDY3Njk4NzEzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4 dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPkluIGdlbmVyYWwsIHZhcmludHMgcmVxdWlyZSBzb21l IHNwZWNpZmljIGxvZ2ljIGZvciBwYXJzaW5nLiBUbyBza2lwIG92ZXIgYW55IGhlYWRlciwgSSBo YXZlIHRvIHJlYWQNCiBldmVyeSBzaW5nbGUgdmFyaW50LiBBcyB0aGUgY29kZSBzZWVzIFN0cmVh bSBhbmQgQUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiAmbmJz cDtUaGUgU3RyZWFtIGZyYW1lIGhhcyBhIGxlbmd0aCBpbiBpdHMgdGhpcmQgZmllbGQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNv LXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmls bC1hbHBoYToxMDAuMCUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMUY0 RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+QUNLIHBhcnNpbmcsIGhv d2V2ZXIsIG5lZWRzIDYgJiM0MzsgMipudW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5IGxlbmd0 aC4gVGhlcmUgYXJlIHR3byByZWFkcyBlYWNoIGZvcg0KIOKAmGxhcmdlc3QgYWNrbm93bGVkZ2Vk 4oCZLCDigJhBQ0sgZGVsYXnigJkgYW5kIOKAmEFDSyBibG9jayBjb3VudOKAmS4gVGhlIHBhaW4g cG9pbnQgaXMgdGhlIHRvdGFsIG51bWJlciBvZiBjeWNsZXMgcGFyc2UgYW4gQUNLLiBJZiBJIGFt IHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBwYWNrZXRzIGhhdmUg YSBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQgYm90 dGxlbmVjay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMUY0RTc5O21zby1zdHls ZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1m aWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRl eHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5NYW5hc2k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwt Y29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbmEgSXllbmdhcjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTTxicj4NCjxiPlRv OjwvYj4gRGV2YWwsIE1hbmFzaSAmbHQ7bWFuYXNpLmRldmFsQGludGVsLmNvbSZndDs7IFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQcm9wb3Nh bCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPllv dSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBoYXZlIHRoZSBhYmlsaXR5IHRvIHNraXAgYW4g QUNLIGZyYW1lLCBhbmQgdGhpcyBjcmVwdCBpbiB3aGVuIHdlIG1vdmVkIHRvIHZhcmludHMuDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgeW91 ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1lcyBub3QganVz dCBBQ0tzLCBzaW5jZSBpZHMsIHBhY2tldCBudW1iZXJzLCBhbmQgbnVtYmVycyBpbiBhbGwgZnJh bWVzIGFyZSBub3cgYWxsIHZhcmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0 byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkcyBpbiB0aG9zZSBmcmFtZXMuIElmIHlvdSBoYXZlDQog bG9naWMgdG8gcHJvY2VzcyBhbmQgc2tpcCB2YXJpbnRzLCB0aGVuIHNraXBwaW5nIHRoZSBhY2sg YmxvY2sgc2VjdGlvbiBpcyBtZXJlbHkgcmVwZWF0aW5nIHRoaXMgb3BlcmF0aW9uICgyKm51bV9i bG9jayYjNDM7MSkgdGltZXMuIERvIHlvdSBzZWUgc3BlY2lmaWMgdmFsdWUgaW4gc2tpcHBpbmcg QUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhlciBjb250cm9sIGZyYW1lcz88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1biAxMSwg MjAxOCBhdCA4OjQzIEFNIERtaXRyaSBUaWtob25vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR0aWto b25vdkBsaXRlc3BlZWR0ZWNoLmNvbSI+ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIE1vbiwgSnVuIDExLCAy MDE4IGF0IDAzOjMzOjM1UE0gJiM0MzswMDAwLCBEZXZhbCwgTWFuYXNpIHdyb3RlOjxicj4NCiZn dDsgLSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNb3ZpbmcgdGhlIEFDSyBsZW5ndGggdG8g dGhlIGZyb250IG9mIHRoZSBBQ0sgYWxsb3dzIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGZsZXhpYmlsaXR5IG9mIGVpdGhlciByZWFkaW5nIHRoZSBlbnRp cmUgQUNLIG9yIHJlYWRpbmcgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZmlyc3QgMTYgYml0cyBhbmQgc2tpcHBpbmcgb3ZlciB0aGUgbGVuZ3RoLiBUaGlz IGlzIGEgdXNlZnVsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg ZmVhdHVyZSBmb3IgdGhlIGNhc2Ugd2hlcmUgQUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQgaW50bzxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG11bHRpcGxlIGxheWVy cy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3IgdGhpcyBpcyBydW4gb24sPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgYXJlIGRpZmZlcmVudCBhZHZh bnRhZ2VzIC08YnI+DQo8YnI+DQpKdXN0IGEgbm90ZS4mbmJzcDsgSW4gbXkgZXhwZXJpZW5jZSwg dGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWUgaXM8YnI+DQpuZWdsaWdpYmxlIGNvbXBh cmVkIHRvIHRoZSBjb3N0IG9mIHByb2Nlc3NpbmcgYW4gQUNLIGZyYW1lOiB0aGF0IGlzLDxicj4N CnBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBuZXdseSBBQ0tl ZCBwYWNrZXRzLjxicj4NCjxicj4NCiZuYnNwOyAtIERtaXRyaS48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1F436ED13A22A246A59CA374CBC543998B833B91ORSMSX111amrcor_-- From nobody Tue Jun 12 01:23:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99BA1310FC for ; Tue, 12 Jun 2018 01:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Ql0XKyWGO_X1 for ; Tue, 12 Jun 2018 01:23:17 -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 DB2F4130F93 for ; Tue, 12 Jun 2018 01:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528791795; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: 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=mOFGjXvqQ9wybQuSY8ofkK780F9PWGm+xgBQ3ciN5vY=; b=VXjVtlT4rdTmp228nIFTliTAqQZn1s2L3UkyLEKTEBmQJZrnLHUSNz7sSNzMKEAs eQjkUKHb946TR2bwCdgojFOTgUzEzxac29Edjp61AUu67gHUphP+NkuFW9TLmciA q94Sw9e+vtdwH4Cm1MWGXqL4gAS/Bgtp3G8sz/hnkyU=; X-AuditID: c1b4fb3a-323229c000005fee-f3-5b1f82f216bf Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.D4.24558.2F28F1B5; Tue, 12 Jun 2018 10:23:15 +0200 (CEST) Received: from [147.214.160.173] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 12 Jun 2018 10:22:33 +0200 Subject: Re: Adding ECN to Transport and Recovery To: "Lubashev, Igor" , "huitema@huitema.net" , "jri.ietf@gmail.com" CC: "ietf@trammell.ch" , "quic@ietf.org" , "ianswett@google.com" References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> From: Magnus Westerlund Message-ID: <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> Date: Tue, 12 Jun 2018 10:22:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4944FC734587CA0F6A8716C7" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7tO7nJvlog939zBaTG2ezW/y8t5PV YmPLOzaLpoYVzBbtl+YxW/Qs4HZg85h8ZAGzx85Zd9k9Fmwq9bg14xSLx5IlP5k8nuyfyRLA FsVlk5Kak1mWWqRvl8CVMfXXHvaCvQ2MFW2LfjA2MC5L6mLk5JAQMJE4+GgRexcjF4eQwBFG iQfHJkM5Wxglbq7pZOxi5OAQFjCU2HHRAaRBRKCFUWLtNBYQm1mgUuLUnVlsEPU3WCWufn3B CpJgE7CQuPmjkQ3E5hWwl5g24RyYzSKgKnG4Yw4TiC0qECOxeuNldogaQYmTM5+ADeUUCJa4 3bSCEWJBmMTJ7ffZIWxxiaYvK8HmCwloSzQ0dbBCfKAkcX3edZYJjIKzkIyahaR9FpL2WUDv MAOd9GBrGURYXqJ562xmCFtf4vqd+6zI4gsY2VcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxi BEbXwS2/rXYwHnzueIhRgINRiYc3q0A+Wog1say4MvcQowQHs5IIb64OUIg3JbGyKrUoP76o NCe1+BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyWiYNTqoGR5/2Kc6w7LVt5zvsvvm78/Tbj 67b4XsmSLZXN/+ebtPSl16UePr7yZcYSZilFwUtPFZ2Xvdi+jnW+6xLbOXWXLq3h3BVx+vPm nuqT8T07FmkvWx90s0LB9lrutRD2JO2qNa2n73+/uXzOu1SGib/SDwf9sO7TXJgfe8lOq2GW 62e2YN9t1hGCSizFGYmGWsxFxYkAizhtpaoCAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 08:23:22 -0000 --------------4944FC734587CA0F6A8716C7 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi, So, if the on-a-side attack manages to race its attack packet with CE set so that it arrives prior to the original packet with an ECT code-point it will affect the congestion window. The same way that if an attack can cause periodic network drop of packets for a QUIC connection the connection can't really distinguish this attack from a legit congestion indication signal. So the PR's current security consideration addition says: 12.7. Explicit Congestion Notification Attacks The ECN bits [RFC3168] are an unauthenticated signal from the network. An on-path attacker may manipulate the value of the field. Thus, affecting the congestion avoidance behavior of the sender. By clearing any CE marks the connection can help drive a bottle neck queue into a loss regime. By setting the ECN field to CE marking it can drive down the senders congestion window thus resulting in reduced throughput. The later could equally be accomplished by dropping packets for the connection. Section 18 and 19 of [RFC3168] discusses the effects of undesired manipulation of the ECN field in more details. If a receiver would not have packet duplication detection and not discard any duplicates an off-path attacker that can receive copies of the connection's packets can manipulate the senders congestion avoidance state. If packet duplicates are dropped, the off-path attacker will need to race the original packet to be successful in this attack. If there is a proper on-path attack, then it can accomplish this already to day by dropping packets, so ECN does not create a new vulnerability. The requirement for an on-the-side attacker to successfully race its modified packets make the attack harder to perform, the right situation must exist where the normal route is longer than the route for the attacker, i.e. tap -> attacker -> receiver. And the attacker must be able to tap the flow. From my perspective, that makes this an attack with limited applicability. Mitigating the attack in either of the QUIC endpoints are also extremely hard. How does a receiver or sender determine that the congestion signals are manipulated? For an attacker that changes an ECT to ECN-CE I don't see there being any reasonable detection mechanism. One would need to generate parallel flow and statistically compare the behaviour of the flows to determine that one flow was manipulated. But, such a flow is likely to be picked up by an attacker as if I am attacking one I would tap the flows using a single source or destination IP as flow template for the traffic that I as an attacker are interested in. For the case where an attacker removes the CE marks, that would be possible to detect by sender side probes injecting CE marked packets, as discussed in this issue: https://github.com/quicwg/base-drafts/issues/1426 My view is that the PR has the necessary text noting the issue and referencing the far more extensive discussion in RFC 3168. We have an issue to continue to discuss additional mitigation. Such mitigation should be written up in a separate PR in my view. Cheers Magnus Den 2018-06-11 kl. 14:18, skrev Lubashev, Igor: > I do not think I have seen this in the PR, so I am wondering what your > recommendation is for defending against an on-a-side attacker, who > sets CE bits on every EC(*) packet and races that packet to the > destination? Should that be a part of this PR? > > - Igor > > -----Original Message----- > *From:* Magnus Westerlund [magnus.westerlund@ericsson.com] > *Received:* Monday, 11 Jun 2018, 1:15PM > *To:* Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema > [huitema@huitema.net] > *CC:* Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett > [ianswett@google.com]; QUIC WG [quic@ietf.org] > *Subject:* Re: Adding ECN to Transport and Recovery > > Hi, > > I agree with Jana, as there are not a clear consensus lets take any > further modifications of the ACK frames as a separate issue. The PR > have from my perspective no open technical content issues. I will > await to see if the editors or any of you have any editorial issues. > But, otherwise I expect this PR to be merged quite soon. > > I will now start working on a new section for a separate PR regarding > the ECN black hole mitigation. > > Cheers > > Magnus > > > Den 2018-06-10 kl. 19:14, skrev Jana Iyengar: >> Sounds like there's general agreement that modifying the varint to >> contain a flag bit will add unnecessary complexity. >> Let's try to get the PR in as it is now, and if anyone really wants >> to go merge this and the ACK frame or rename things, let's paint that >> bikeshed separately. >> >> >> >> On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema > > wrote: >> >> >> >> > On Jun 9, 2018, at 8:27 AM, Ian Swett > > wrote: >> > >> > QUIC is complex enough, I think we should just call them ACK >> and ACK_ECN.  A few implementations sending at least one ACK_ECN >> frame per connection will dispel any belief that ACK_ECN is >> optional.  A small amount of use will be a lot more valuable than >> clever naming. >> >> Also, ECN is just one of the extensions that could be planned for >> ACK. Timestamps would be nice too, for those who want >> one-way-delay based congestion control. >> >> -- Christian Huitema >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------4944FC734587CA0F6A8716C7 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi,

So, if the on-a-side attack manages to race its attack packet with CE set so that it arrives prior to the original packet with an ECT code-point it will affect the congestion window. The same way that if an attack can cause periodic network drop of packets for a QUIC connection the connection can't really distinguish this attack from a legit congestion indication signal. 

So the PR's current security consideration addition says: 

12.7.  Explicit Congestion Notification Attacks

   The ECN bits [RFC3168] are an unauthenticated signal from the
   network.  An on-path attacker may manipulate the value of the field.
   Thus, affecting the congestion avoidance behavior of the sender.  By
   clearing any CE marks the connection can help drive a bottle neck
   queue into a loss regime.  By setting the ECN field to CE marking it
   can drive down the senders congestion window thus resulting in
   reduced throughput.  The later could equally be accomplished by
   dropping packets for the connection.  Section 18 and 19 of [RFC3168]
   discusses the effects of undesired manipulation of the ECN field in
   more details.

   If a receiver would not have packet duplication detection and not
   discard any duplicates an off-path attacker that can receive copies
   of the connection's packets can manipulate the senders congestion
   avoidance state.  If packet duplicates are dropped, the off-path
   attacker will need to race the original packet to be successful in
   this attack.


If there is a proper on-path attack, then it can accomplish this already 
to day by dropping packets, so ECN does not create a new vulnerability.
The requirement for an on-the-side attacker to successfully race its modified 
packets make the attack harder to perform, the right situation must exist 
where the normal route is longer than the route for the attacker, i.e. 
tap -> attacker -> receiver. And the attacker must be able to tap the flow.
>From my perspective, that makes this an attack with limited applicability. 

Mitigating the attack in either of the QUIC endpoints are also extremely 
hard. How does a receiver or sender determine that the congestion signals 
are manipulated? For an attacker that changes an ECT to ECN-CE I don't see 
there being any reasonable detection mechanism. One would need to generate 
parallel flow and statistically compare the behaviour of the flows to determine 
that one flow was manipulated. But, such a flow is likely to be picked up by 
an attacker as if I am attacking one I would tap the flows using a single 
source or destination IP as flow template for the traffic that I as an 
attacker are interested in. 

For the case where an attacker removes the CE marks, that would be possible 
to detect by sender side probes injecting CE marked packets, as discussed 
in this issue: https://github.com/quicwg/base-drafts/issues/1426

My view is that the PR has the necessary text noting the issue and 
referencing the far more extensive discussion in RFC 3168. We have an 
issue to continue to discuss additional mitigation. Such mitigation should
be written up in a separate PR in my view. 

Cheers

Magnus
Den 2018-06-11 kl. 14:18, skrev Lubashev, Igor:
I do not think I have seen this in the PR, so I am wondering what your recommendation is for defending against an on-a-side attacker, who sets CE bits on every EC(*) packet and races that packet to the destination? Should that be a part of this PR?

- Igor

-----Original Message-----
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Received: Monday, 11 Jun 2018, 1:15PM
To: Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema [huitema@huitema.net]
CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett [ianswett@google.com]; QUIC WG [quic@ietf.org]
Subject: Re: Adding ECN to Transport and Recovery

Hi,

I agree with Jana, as there are not a clear consensus lets take any further modifications of the ACK frames as a separate issue. The PR have from my perspective no open technical content issues. I will await to see if the editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding the ECN black hole mitigation.

Cheers

Magnus


Den 2018-06-10 kl. 19:14, skrev Jana Iyengar:
Sounds like there's general agreement that modifying the varint to contain a flag bit will add unnecessary complexity. 
Let's try to get the PR in as it is now, and if anyone really wants to go merge this and the ACK frame or rename things, let's paint that bikeshed separately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <huitema@huitema.net> wrote:
 

> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_ECN.  A few implementations sending at least one ACK_ECN frame per connection will dispel any belief that ACK_ECN is optional.  A small amount of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Timestamps would be nice too, for those who want one-way-delay based congestion control.

-- Christian Huitema 

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------------4944FC734587CA0F6A8716C7-- From nobody Tue Jun 12 05:17:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790C0130E2C for ; Tue, 12 Jun 2018 05:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 0o20Njfle5cx for ; Tue, 12 Jun 2018 05:17:43 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A37EE130DCA for ; Tue, 12 Jun 2018 05:17:43 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5CCGp0o012473; Tue, 12 Jun 2018 13:17:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=9vBdm4ljcZR4CEMISwdBauIPjttyINL+4zEzMd222FU=; b=VjP2D64NDxwpL/UZ6qxZIoJhPb+Z0dgr6rhySfUQP4eXoOggVoCTfsGkRTbcBTX+Dw4O yesvUiDksiNRzrgVlWB5jOaIvSyokSf7wILxRdcJMJWLxY28zBaW2QS6z/R15nA5uZmn Hl7ooPEIqvLkFfbr/O4Mvt6Lmqs7iCV5RZDT+hKZp70YpApZDdjdDNRe1aYEb5wLohlC tzIBjEdFm1XIS/NwhDVJ+Y+ewj1jWPBdQObxT7R3tzMRIQHjXH851fDOMQElmEmjqBLJ 9sc+11yrW2RCPss4Y2ddvROc1gSTVEOkR/iFh1Yj6OewhDPpqFKuFaurU60napivqGZo 4g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2jg7abh7ye-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jun 2018 13:17:30 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5CCGGWo028720; Tue, 12 Jun 2018 08:17:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jga7uxkek-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Jun 2018 08:17:29 -0400 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 12 Jun 2018 07:17:28 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Tue, 12 Jun 2018 05:17:28 -0700 From: "Lubashev, Igor" To: "huitema@huitema.net" , "magnus.westerlund@ericsson.com" , "jri.ietf@gmail.com" CC: "ietf@trammell.ch" , "quic@ietf.org" , "ianswett@google.com" Subject: RE: Adding ECN to Transport and Recovery Thread-Topic: Adding ECN to Transport and Recovery Thread-Index: AQHT9sK0H8sBCsQDiUuMTPA/hgyVTqRW+DkAgAAEvoCAABm1gIAAXg8AgAAm5gCAALVPgIAAQ7eAgAADFgCAAa0SAIABLgUA//+cLbCAAcXYgP//zEk/ Date: Tue, 12 Jun 2018 12:17:27 +0000 Message-ID: References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> , <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> In-Reply-To: <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_af85bf371c9f423d88acc4a674e9e3b0ustx2exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120144 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:17:48 -0000 --_000_af85bf371c9f423d88acc4a674e9e3b0ustx2exdag1mb6msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks. So what you are saying is that a requirement for a on-a-side attack= er to race cooked packets is what make this attack hard? I can buy this, es= pecially since such an attacker could interfere with the initial version ne= gotiation, too. The only thing that makes an attack on the congestion windo= w nefarious vs an attack on version negotiation is that it leaves the user = with an impression that the service is poor vs that the network is interfer= ing with him connecting to the service. -----Original Message----- From: Magnus Westerlund [magnus.westerlund@ericsson.com] Received: Tuesday, 12 Jun 2018, 4:23AM To: Lubashev, Igor [ilubashe@akamai.com]; huitema@huitema.net [huitema@huit= ema.net]; jri.ietf@gmail.com [jri.ietf@gmail.com] CC: ietf@trammell.ch [ietf@trammell.ch]; quic@ietf.org [quic@ietf.org]; ian= swett@google.com [ianswett@google.com] Subject: Re: Adding ECN to Transport and Recovery Hi, So, if the on-a-side attack manages to race its attack packet with CE set s= o that it arrives prior to the original packet with an ECT code-point it wi= ll affect the congestion window. The same way that if an attack can cause p= eriodic network drop of packets for a QUIC connection the connection can't = really distinguish this attack from a legit congestion indication signal. So the PR's current security consideration addition says: 12.7. Explicit Congestion Notification Attacks The ECN bits [RFC3168] are an unauthenticated signal from the network. An on-path attacker may manipulate the value of the field. Thus, affecting the congestion avoidance behavior of the sender. By clearing any CE marks the connection can help drive a bottle neck queue into a loss regime. By setting the ECN field to CE marking it can drive down the senders congestion window thus resulting in reduced throughput. The later could equally be accomplished by dropping packets for the connection. Section 18 and 19 of [RFC3168] discusses the effects of undesired manipulation of the ECN field in more details. If a receiver would not have packet duplication detection and not discard any duplicates an off-path attacker that can receive copies of the connection's packets can manipulate the senders congestion avoidance state. If packet duplicates are dropped, the off-path attacker will need to race the original packet to be successful in this attack. If there is a proper on-path attack, then it can accomplish this already to day by dropping packets, so ECN does not create a new vulnerability. The requirement for an on-the-side attacker to successfully race its modifi= ed packets make the attack harder to perform, the right situation must exist where the normal route is longer than the route for the attacker, i.e. tap -> attacker -> receiver. And the attacker must be able to tap the flow. >From my perspective, that makes this an attack with limited applicability. Mitigating the attack in either of the QUIC endpoints are also extremely hard. How does a receiver or sender determine that the congestion signals are manipulated? For an attacker that changes an ECT to ECN-CE I don't see there being any reasonable detection mechanism. One would need to generate parallel flow and statistically compare the behaviour of the flows to deter= mine that one flow was manipulated. But, such a flow is likely to be picked up b= y an attacker as if I am attacking one I would tap the flows using a single source or destination IP as flow template for the traffic that I as an attacker are interested in. For the case where an attacker removes the CE marks, that would be possible to detect by sender side probes injecting CE marked packets, as discussed in this issue: https://github.com/quicwg/base-drafts/issues/1426 My view is that the PR has the necessary text noting the issue and referencing the far more extensive discussion in RFC 3168. We have an issue to continue to discuss additional mitigation. Such mitigation should be written up in a separate PR in my view. Cheers Magnus Den 2018-06-11 kl. 14:18, skrev Lubashev, Igor: I do not think I have seen this in the PR, so I am wondering what your reco= mmendation is for defending against an on-a-side attacker, who sets CE bits= on every EC(*) packet and races that packet to the destination? Should tha= t be a part of this PR? - Igor -----Original Message----- From: Magnus Westerlund [magnus.westerlund@ericsson.com] Received: Monday, 11 Jun 2018, 1:15PM To: Jana Iyengar [jri.ietf@gmail.com]; Christian= Huitema [huitema@huitema.net] CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian = Swett [ianswett@google.com]; QUIC WG [quic@ietf= .org] Subject: Re: Adding ECN to Transport and Recovery Hi, I agree with Jana, as there are not a clear consensus lets take any further= modifications of the ACK frames as a separate issue. The PR have from my p= erspective no open technical content issues. I will await to see if the edi= tors or any of you have any editorial issues. But, otherwise I expect this = PR to be merged quite soon. I will now start working on a new section for a separate PR regarding the E= CN black hole mitigation. Cheers Magnus Den 2018-06-10 kl. 19:14, skrev Jana Iyengar: Sounds like there's general agreement that modifying the varint to contain = a flag bit will add unnecessary complexity. Let's try to get the PR in as it is now, and if anyone really wants to go m= erge this and the ACK frame or rename things, let's paint that bikeshed sep= arately. On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema > wrote: > On Jun 9, 2018, at 8:27 AM, Ian Swett > wrote: > > QUIC is complex enough, I think we should just call them ACK and ACK_ECN.= A few implementations sending at least one ACK_ECN frame per connection w= ill dispel any belief that ACK_ECN is optional. A small amount of use will= be a lot more valuable than clever naming. Also, ECN is just one of the extensions that could be planned for ACK. Time= stamps would be nice too, for those who want one-way-delay based congestion= control. -- Christian Huitema -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_af85bf371c9f423d88acc4a674e9e3b0ustx2exdag1mb6msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks. So what you are saying is that a requirement for a= on-a-side attacker to race cooked packets is what make this attack hard? I= can buy this, especially since such an attacker could interfere with the initial version negotiation, too. The= only thing that makes an attack on the congestion window nefarious vs an a= ttack on version negotiation is that it leaves the user with an impression = that the service is poor vs that the network is interfering with him connecting to the service.

-----Original Message-----
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Received: Tuesday, 12 Jun 2018, 4:23AM
To: Lubashev, Igor [ilubashe@akamai.com]; huitema@huitema.net [huite= ma@huitema.net]; jri.ietf@gmail.com [jri.ietf@gmail.com]
CC: ietf@trammell.ch [ietf@trammell.ch]; quic@ietf.org [quic@ietf.or= g]; ianswett@google.com [ianswett@google.com]
Subject: Re: Adding ECN to Transport and Recovery

Hi,

So, if the on-a-side attack manages to race its attack packet with CE se= t so that it arrives prior to the original packet with an ECT code-point it= will affect the congestion window. The same way that if an attack can caus= e periodic network drop of packets for a QUIC connection the connection can't really distinguish this attack = from a legit congestion indication signal. 

So the PR's current security consideration addition says: 

12.7.  Explicit Congestion Notification Attacks=0A=
=0A=
   The ECN bits [RFC3168] are an unauthenticated signal from the=0A=
   network.  An on-path attacker may manipulate the value of the field.=0A=
   Thus, affecting the congestion avoidance behavior of the sender.  By=0A=
   clearing any CE marks the connection can help drive a bottle neck=0A=
   queue into a loss regime.  By setting the ECN field to CE marking it=0A=
   can drive down the senders congestion window thus resulting in=0A=
   reduced throughput.  The later could equally be accomplished by=0A=
   dropping packets for the connection.  Section 18 and 19 of [RFC3168]=0A=
   discusses the effects of undesired manipulation of the ECN field in=0A=
   more details.=0A=
=0A=
   If a receiver would not have packet duplication detection and not=0A=
   discard any duplicates an off-path attacker that can receive copies=0A=
   of the connection's packets can manipulate the senders congestion=0A=
   avoidance state.  If packet duplicates are dropped, the off-path=0A=
   attacker will need to race the original packet to be successful in=0A=
   this attack.=0A=
=0A=
=0A=
If there is a proper on-path attack, then it can accomplish this already =
=0A=
to day by dropping packets, so ECN does not create a new vulnerability.=0A=
The requirement for an on-the-side attacker to successfully race its modifi=
ed =0A=
packets make the attack harder to perform, the right situation must exist =
=0A=
where the normal route is longer than the route for the attacker, i.e. =0A=
tap -> attacker -> receiver. And the attacker must be able to tap the=
 flow.=0A=
>From my perspective, that makes this an attack with limited applicability. =
=0A=
=0A=
Mitigating the attack in either of the QUIC endpoints are also extremely =
=0A=
hard. How does a receiver or sender determine that the congestion signals =
=0A=
are manipulated? For an attacker that changes an ECT to ECN-CE I don't see =
=0A=
there being any reasonable detection mechanism. One would need to generate =
=0A=
parallel flow and statistically compare the behaviour of the flows to deter=
mine =0A=
that one flow was manipulated. But, such a flow is likely to be picked up b=
y =0A=
an attacker as if I am attacking one I would tap the flows using a single =
=0A=
source or destination IP as flow template for the traffic that I as an =0A=
attacker are interested in. =0A=
=0A=
For the case where an attacker removes the CE marks, that would be possible=
 =0A=
to detect by sender side probes injecting CE marked packets, as discussed =
=0A=
in this issue: https:=
//github.com/quicwg/base-drafts/issues/1426=0A=
=0A=
My view is that the PR has the necessary text noting the issue and =0A=
referencing the far more extensive discussion in RFC 3168. We have an =0A=
issue to continue to discuss additional mitigation. Such mitigation should=
=0A=
be written up in a separate PR in my view. =0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
Den 2018-06-11 kl. 14:18, skrev Lubashev, Ig= or:
I do not think I have seen this in the PR, so I am wonderi= ng what your recommendation is for defending against an on-a-side attacker,= who sets CE bits on every EC(*) packet and races that packet to the destination? Should that be a part of this PR= ?

- Igor

-----Original Message-----
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Received: Monday, 11 Jun 2018, 1:15PM
To: Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema [huitema@h= uitema.net]
CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett [ianswett@goo= gle.com]; QUIC WG [quic@ietf.org]
Subject: Re: Adding ECN to Transport and Recovery

Hi,

I agree with Jana, as there are not a clear consensus lets take any furt= her modifications of the ACK frames as a separate issue. The PR have from m= y perspective no open technical content issues. I will await to see if the = editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding th= e ECN black hole mitigation.

Cheers

Magnus


Den 2018-06-10 kl. 19:14, skrev Jana Iyengar= :
Sounds like there's general agreement that modifying the varint to con= tain a flag bit will add unnecessary complexity. 
Let's try to get the PR in as it is now, and if anyone really wants to go m= erge this and the ACK frame or rename things, let's paint that bikeshed sep= arately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <huitema@huitema.net> wrote:
 

> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_E= CN.  A few implementations sending at least one ACK_ECN frame per conn= ection will dispel any belief that ACK_ECN is optional.  A small amoun= t of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Time= stamps would be nice too, for those who want one-way-delay based congestion= control.

-- Christian Huitema 

-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------


-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------
--_000_af85bf371c9f423d88acc4a674e9e3b0ustx2exdag1mb6msgcorpak_-- From nobody Tue Jun 12 05:27:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2B130EB7 for ; Tue, 12 Jun 2018 05:27:07 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 u-wgExv5NO3E for ; Tue, 12 Jun 2018 05:27:04 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9BB130EA1 for ; Tue, 12 Jun 2018 05:27:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,214,1526367600"; d="asc'?scan'208";a="279622411" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx141-out.netapp.com with ESMTP; 12 Jun 2018 05:27:03 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Jun 2018 05:27:03 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 12 Jun 2018 05:27:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kic0ljThSFw3CS37SLeuS/I5MvyI1fpNhkdAXWNQ5hg=; b=o7vQwjDmn4Bib5ikJopqrWWBxITo/zl4WEE3ttP1IOFNs3SYtdTYFo3cN48oDB+rNs/O3K2bI2r+l9p9tZSott1cr8OevJOK+GDQbXbMXPNyxCcHmtn+7HVm6PXZkJpIcJsrAP1l6btxWK/QQuz1lObHeJX9iVGTeClFv0YmoXE= Received: from BY2PR06MB1765.namprd06.prod.outlook.com (10.163.33.19) by BY2PR06MB2213.namprd06.prod.outlook.com (10.166.113.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.20; Tue, 12 Jun 2018 12:27:01 +0000 Received: from BY2PR06MB1765.namprd06.prod.outlook.com ([fe80::6d3a:7b15:4033:467d]) by BY2PR06MB1765.namprd06.prod.outlook.com ([fe80::6d3a:7b15:4033:467d%7]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 12:27:01 +0000 From: "Eggert, Lars" To: "Lubashev, Igor" CC: "huitema@huitema.net" , Magnus Westerlund , Janardhan Iyengar , Brian Trammell , Ian Swett , "quic@ietf.org" Subject: Re: Adding ECN to Transport and Recovery Thread-Topic: Adding ECN to Transport and Recovery Thread-Index: AQHT9sK74JS6a9xjIU6vjmjlxWg5s6RWguAAgAAEvoCAABm1gIAAXg8AgAAm5wCAALVOgIAAQ7eAgAADFwCAAa0RAIABLgUAgAARhoCAAVB/gIAAQaGAgAACqoA= Date: Tue, 12 Jun 2018 12:27:01 +0000 Message-ID: <7FBCB032-0B09-42CA-B3F3-4F2EBE664D7A@netapp.com> References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [195.50.186.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR06MB2213; 7:yGsLEQit/djoZ/VkRXfzRf0glAUFGvOUcLrRnaY5i/7gndqH7qMdIgDEpRi6xZNxh/USf/QMqD528277NIJHLtpTR2cOlsmYvhii/0SScO7bB7artpYRoWSeouBvRkACwnxH+1ITWZhnuJcP4ANEaxikZGbT8JiV5aB1J5D7gkAn61gtWItbaby7YeaGk5Tsr73H3coUc1kuKFdsb95cG7Q/WhuynH92M+WcH18P4pUqDv02AEdkfyj4+R8sCT1+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(49563074)(7193020); SRVR:BY2PR06MB2213; x-ms-traffictypediagnostic: BY2PR06MB2213: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BY2PR06MB2213; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB2213; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(39380400002)(396003)(39860400002)(346002)(376002)(189003)(199004)(8936002)(3280700002)(4001150100001)(97736004)(68736007)(39060400002)(6246003)(105586002)(4326008)(106356001)(50226002)(14454004)(25786009)(99936001)(229853002)(6436002)(6512007)(6486002)(478600001)(2906002)(6116002)(3846002)(81166006)(81156014)(86362001)(8676002)(57306001)(3660700001)(53936002)(99286004)(83716003)(7736002)(82746002)(2900100001)(93886005)(33656002)(11346002)(54906003)(66066001)(316002)(102836004)(36756003)(26005)(2616005)(446003)(186003)(476003)(486006)(76176011)(5250100002)(53546011)(305945005)(5660300001)(6506007)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB2213; H:BY2PR06MB1765.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: C0xdz81rCJlZdUBKg7bJZX/mltgOPDVo++PTHcEkB2c5Y8b6lqlDL/1N72g1pHkszf3DXIK2jv8Z5r4V28Z9kw2ELx6fc9LVAAFfT5VO0zCEKOtUxkcN4l4hGjQdMcndC9HZcBagOyGbOBF5CGVJFjoVsrIA8zucW0IA7vp2vuVzvWEnl2Lh1FHSA0IyR/5C spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_76E6A8C5-30DC-4609-A713-5C7E48784F3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0c9c68c5-21eb-4f8c-40e1-08d5d05fcc66 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c9c68c5-21eb-4f8c-40e1-08d5d05fcc66 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 12:27:01.1736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB2213 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:27:07 -0000 --Apple-Mail=_76E6A8C5-30DC-4609-A713-5C7E48784F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2018-6-12, at 14:17, Lubashev, Igor = wrote: > The only thing that makes an attack on the congestion window nefarious = vs an attack on version negotiation is that it leaves the user with an = impression that the service is poor vs that the network is interfering = with him connecting to the service. Right, but that is not specific to QUIC. There are possibilities to add mitigations at a later stage (QUIC v2 or = v1.1), but I personally don't think these need to be part of v1. Lars --Apple-Mail=_76E6A8C5-30DC-4609-A713-5C7E48784F3A 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlsfvBMACgkQVLXDCb9w wVdqGBAAhCo4XfCdYX/rvmchCghXeOXo3HHWrndRxuzB6bFBo4gg2tACWScy6n/6 RP16GioqRTJHx2TWNJvVFMMOBaBlFMVH+0mcaDJ613B0Qar0UEYO7JItS//Y4W48 5tJb8vQ5eK0ocxxeJxwhoHn0l0S+NyB7OkNXxJQ1wtb9ESUfH1jN/8cLRectdBhT SfAUfRLN1bSsZaDPtDrDDIK+QE+lp+Hg56in5y7LaPzMY+sRkwCI886CWU1F+LW4 0pHwwpAS0B8nPxWTQY++cN7vJ0FIvDYvGWPNkT8Eo6z/w8etQWST/3MxdsTSZvW4 FH5SregCOES+kBNKrHk8TE2O2jJPFY04YMNVOKYkYHOjVFrSubeQ0SBzI7vYmObm ecJaQwpRDhkVU62p60jCKKErfhPJvoTuRGHJGeXYB4wz6MbSIMdakodODORgOPno FCI/cJFwIR2ODuwOONbvQMqS9JsHw1pHzr7oifZjs9+X2x2ytpul/ip6UB04NMgc zlrFas7uJta9VX0WtvTGsEaryn5hGgl+9wxd5CC+kw0APukhKYVSrHPLLmmuwXgw YuZ1zOIBNLq1dOkthmiW5mtNxa1Y6G6U7ezEqJF7AMDZKif/TT/01fKie2Ws7fWp 7nMiEHMbq7YbX7cksPYYvbEUq83k0on3U8kfvgu1ApYDWggciWQ= =DOby -----END PGP SIGNATURE----- --Apple-Mail=_76E6A8C5-30DC-4609-A713-5C7E48784F3A-- From nobody Tue Jun 12 05:33:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485F5130EE4 for ; Tue, 12 Jun 2018 05:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 KWA1t-H5TjRZ for ; Tue, 12 Jun 2018 05:33:30 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 33565130E8D for ; Tue, 12 Jun 2018 05:33:30 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id h141-v6so7858865ybg.4 for ; Tue, 12 Jun 2018 05:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzatb1BWZsadFjI8Y4rykEZ7YC3WnLVJDjP7d6cX7qI=; b=hMid9tzKGT2ua0P4bUSb8PUbj3QwLGkjwCyuXtw8ua/Yw5rc2Fkn8T6OHqHKp0ipqt voQqa9SGZhPHCIONwjNN8/SY2VbG4cI6Znv6mStHUE25GWkdGxvJg5wTjzoNVyEwr9ge IdgaNj8fgRDXDevm/SUpS1b9kcsqK8agmkKXByvKjZO/x08kImdZ0vbOl29LRQKho89Z DkGVliNvbVraV6Di5PS1grjdYkhXDJFoORaPft6xXQX47I8uWxr99hMwqCdaDt8Ddtr3 FDWtvGGSlVk6M3+43nkD1tfxN3Qr7va+7uG6+yljIhS/mNjl8wmCYQs0TLFXZInPCRFm ea7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jzatb1BWZsadFjI8Y4rykEZ7YC3WnLVJDjP7d6cX7qI=; b=NnOdg5Yfm3rpmDHlAKFKoXuD+O9Herw4I1bCIiV3b27kpR6ePlqKA9p++jMiUTePCU w+bP0oT4lQ1ONSunG+To76tM4T8utNkrYCwWTrnRPJEyTGNbDXoMU43K/Dsig+QI/vQG 9tF1j+4Ir7SI3q6utAKvrhwCFvfgtHlBNBD6FZzaqOb+0eADQpMTLnQb6bXnGHYgcD15 4DzfA1+5/KD0kFUuWvlNUzLan84HmuTiPwk5Yaowfmq5qfnjYtzS7Omy6ObKpBBBIBI0 lBBiaVdWMUuBFUVCHzu3VbJLiTqVs6/ClEAjx5a+/5HgOhVwC8c3a1Qd8X1y4dtc1rte riMw== X-Gm-Message-State: APt69E3BiIHxpMKfIimTfmIjI4e/AZiTFi6f5i6pWdDaErgU4ZorZ9Y+ DPS9oJS1TNJM1MlpX5K051t3QVOeN7hV1LnRq6WZPA== X-Google-Smtp-Source: ADUXVKIkKueUtPedF6ynUIrwdoNFf9ThnNS8zV9yn4SHmKutFbrQWSO7Jp1eZwtVFZGU0d1PaA6RpZuurAGdz17jvBU= X-Received: by 2002:a25:814a:: with SMTP id j10-v6mr91692ybm.178.1528806809100; Tue, 12 Jun 2018 05:33:29 -0700 (PDT) MIME-Version: 1.0 References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> <7FBCB032-0B09-42CA-B3F3-4F2EBE664D7A@netapp.com> In-Reply-To: <7FBCB032-0B09-42CA-B3F3-4F2EBE664D7A@netapp.com> From: Ian Swett Date: Tue, 12 Jun 2018 08:33:17 -0400 Message-ID: Subject: Re: Adding ECN to Transport and Recovery To: "Eggert, Lars" Cc: ilubashe=40akamai.com@dmarc.ietf.org, Magnus Westerlund , Jana Iyengar , Christian Huitema , Brian Trammell , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c9fa69056e71126f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:33:34 -0000 --000000000000c9fa69056e71126f Content-Type: text/plain; charset="UTF-8" I'd be shocked if anyone tried to use this attack in practice, and as Lars said, this is in no way specific to QUIC. The one case I can imagine someone wanting to inject ECN is an on path middlebox, in which case that's what ECN is for. I don't think this needs to be part of v1. On Tue, Jun 12, 2018 at 8:27 AM Eggert, Lars wrote: > On 2018-6-12, at 14:17, Lubashev, Igor 40akamai.com@dmarc.ietf.org> wrote: > > The only thing that makes an attack on the congestion window nefarious > vs an attack on version negotiation is that it leaves the user with an > impression that the service is poor vs that the network is interfering with > him connecting to the service. > > Right, but that is not specific to QUIC. > > There are possibilities to add mitigations at a later stage (QUIC v2 or > v1.1), but I personally don't think these need to be part of v1. > > Lars > --000000000000c9fa69056e71126f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd be shocked if anyone tried to use this attack in p= ractice, and as Lars said, this is in no way specific to QUIC.=C2=A0 The on= e case I can imagine someone wanting to inject ECN is an on path middlebox,= in which case that's what ECN is for.

I don'= ;t think this needs to be part of v1.

On Tue, Jun 12, 2018 at 8:27 AM Eggert, Lars <lars@netapp.com> wrote:
On 2018-6-12, at 14:17, Lubashev, Igor <iluba= she=3D40ak= amai.com@dmarc.ietf.org> wrote:
> The only thing that makes an attack on the congestion window nefarious= vs an attack on version negotiation is that it leaves the user with an imp= ression that the service is poor vs that the network is interfering with hi= m connecting to the service.

Right, but that is not specific to QUIC.

There are possibilities to add mitigations at a later stage (QUIC v2 or v1.= 1), but I personally don't think these need to be part of v1.

Lars
--000000000000c9fa69056e71126f-- From nobody Tue Jun 12 07:41:09 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA38E130E3D; Tue, 12 Jun 2018 07:41:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152881446669.9189.14111737411901419243.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2018 07:41:06 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 14:41:07 -0000 A new interim meeting request has just been submitted by Lars Eggert. This request requires approval by the Transport Area Area Director The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2018-quic-03 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert City: New York City, NY Country: US Session 1: Date: 2018-09-19 Start Time: 09:30 US/Eastern Duration: 17:00 Remote Participation Information: Webex information will be emailed to registered remote participants Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangements.md Session 2: Date: 2018-09-20 Start Time: 09:30 US/Eastern Duration: 17:00 Remote Participation Information: Webex information will be emailed to registered remote participants Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangements.md --------------------------------------------------------- From nobody Tue Jun 12 07:41:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF701130F3F for ; Tue, 12 Jun 2018 07:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 kdl1sspVBlwR for ; Tue, 12 Jun 2018 07:41:47 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E0115130F55 for ; Tue, 12 Jun 2018 07:41:42 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5CEfUDu009963; Tue, 12 Jun 2018 15:41:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=4Mqv6J4c0IJ6+AWiS0ayfnUnZMzosyMAEZuKy2YVaSM=; b=d2okNn4XE5Mhr+Ew4oCMnSwHmMM9R92sMbGion61xubbHRp8S7uJ+WjfZVlAoSjkK34Y 9+WtTOh0EyOyX0qxpXjwzGopT8Pd+KY4z6vlQiQwJnrkWgzfEIJ1B+6+6V0vgEvsmxrI ebXDnO4cY7VE+rEjVk7WbSfYVZGTXpva4ihfDxchV7n//ccnNLSR1koBzDj/HwvyAjqP Qx8shwtinP2d6J02Lz6FHkuH9kQqJwsNvGO3OceslX43PK8x5BoIG7bRxQUkbrLredH7 oh8QnMG7Rnun3Mixnz1WJIY+87OVWOrv/vOVmmuA4NrDX1IiSqzpI3LfcRH+pdsz9J+0 CA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2jg65ns7pk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jun 2018 15:41:31 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5CEewHb017596; Tue, 12 Jun 2018 10:41:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jga7vhgrp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Jun 2018 10:41:30 -0400 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 12 Jun 2018 09:41:29 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Tue, 12 Jun 2018 07:41:29 -0700 From: "Lubashev, Igor" To: Ian Swett , "Eggert, Lars" CC: Magnus Westerlund , Jana Iyengar , Christian Huitema , Brian Trammell , IETF QUIC WG Subject: RE: Adding ECN to Transport and Recovery Thread-Topic: Adding ECN to Transport and Recovery Thread-Index: AQHT9sK0H8sBCsQDiUuMTPA/hgyVTqRW+DkAgAAEvoCAABm1gIAAXg8AgAAm5gCAALVPgIAAQ7eAgAADFgCAAa0SAIABLgUA//+cLbCAAcXYgP//zEk/gAB4BICAAAHBgP//rYfQ Date: Tue, 12 Jun 2018 14:41:29 +0000 Message-ID: <67a111e1eb754e118255ef67afeac60f@ustx2ex-dag1mb6.msg.corp.akamai.com> References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com> <8cbb589e-860b-9007-4f07-adf7c43f037b@ericsson.com> <7FBCB032-0B09-42CA-B3F3-4F2EBE664D7A@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.206] Content-Type: multipart/alternative; boundary="_000_67a111e1eb754e118255ef67afeac60fustx2exdag1mb6msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120167 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120167 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 14:41:50 -0000 --_000_67a111e1eb754e118255ef67afeac60fustx2exdag1mb6msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZSBhcmUgaW4gYW4gYWdyZWVtZW50IGhlcmUuDQoNCkEgbW9yZSBnZW5lcmljIGNv bmNsdXNpb24gZnJvbSB0aGlzIGRpc2N1c3Npb24gaXMgdGhhdCBkZWZlbnNlIGFnYWluc3QgbWFu LW9uLWEtc2lkZSBEb1MgYXR0YWNrcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgV0cgKGF0IGxl YXN0IGZvciB2MSkuDQoNCg0KICAqICAgSQ0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5z d2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmddDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEy LCAyMDE4IDg6MzMgQU0NClRvOiBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbT4NCkNjOiBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IE1hZ251cyBXZXN0ZXJsdW5kIDxt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdt YWlsLmNvbT47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgQnJpYW4g VHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogQWRkaW5nIEVDTiB0byBUcmFuc3BvcnQgYW5kIFJlY292ZXJ5DQoNCkkn ZCBiZSBzaG9ja2VkIGlmIGFueW9uZSB0cmllZCB0byB1c2UgdGhpcyBhdHRhY2sgaW4gcHJhY3Rp Y2UsIGFuZCBhcyBMYXJzIHNhaWQsIHRoaXMgaXMgaW4gbm8gd2F5IHNwZWNpZmljIHRvIFFVSUMu ICBUaGUgb25lIGNhc2UgSSBjYW4gaW1hZ2luZSBzb21lb25lIHdhbnRpbmcgdG8gaW5qZWN0IEVD TiBpcyBhbiBvbiBwYXRoIG1pZGRsZWJveCwgaW4gd2hpY2ggY2FzZSB0aGF0J3Mgd2hhdCBFQ04g aXMgZm9yLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgcGFydCBvZiB2MS4NCg0K T24gVHVlLCBKdW4gMTIsIDIwMTggYXQgODoyNyBBTSBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBw LmNvbTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPj4gd3JvdGU6DQpPbiAyMDE4LTYtMTIsIGF0IDE0 OjE3LCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGU9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4gVGhlIG9ubHkg dGhpbmcgdGhhdCBtYWtlcyBhbiBhdHRhY2sgb24gdGhlIGNvbmdlc3Rpb24gd2luZG93IG5lZmFy aW91cyB2cyBhbiBhdHRhY2sgb24gdmVyc2lvbiBuZWdvdGlhdGlvbiBpcyB0aGF0IGl0IGxlYXZl cyB0aGUgdXNlciB3aXRoIGFuIGltcHJlc3Npb24gdGhhdCB0aGUgc2VydmljZSBpcyBwb29yIHZz IHRoYXQgdGhlIG5ldHdvcmsgaXMgaW50ZXJmZXJpbmcgd2l0aCBoaW0gY29ubmVjdGluZyB0byB0 aGUgc2VydmljZS4NCg0KUmlnaHQsIGJ1dCB0aGF0IGlzIG5vdCBzcGVjaWZpYyB0byBRVUlDLg0K DQpUaGVyZSBhcmUgcG9zc2liaWxpdGllcyB0byBhZGQgbWl0aWdhdGlvbnMgYXQgYSBsYXRlciBz dGFnZSAoUVVJQyB2MiBvciB2MS4xKSwgYnV0IEkgcGVyc29uYWxseSBkb24ndCB0aGluayB0aGVz ZSBuZWVkIHRvIGJlIHBhcnQgb2YgdjEuDQoNCkxhcnMNCg== --_000_67a111e1eb754e118255ef67afeac60fustx2exdag1mb6msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MzkyNjIwNTc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NzEyMTU1MDQgNDU1MDA1MzcwIDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgd2UgYXJlIGluIGFuIGFncmVlbWVudCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BIG1vcmUgZ2VuZXJpYyBjb25jbHVzaW9uIGZyb20gdGhpcyBkaXNjdXNzaW9uIGlzIHRoYXQg ZGVmZW5zZSBhZ2FpbnN0IG1hbi1vbi1hLXNpZGUgRG9TIGF0dGFja3MgaXMgb3V0IG9mIHNjb3Bl IGZvciB0aGlzIFdHIChhdCBsZWFzdCBmb3IgdjEpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+STxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHQ9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1 bmUgMTIsIDIwMTggODozMyBBTTxicj4NCjxiPlRvOjwvYj4gRWdnZXJ0LCBMYXJzICZsdDtsYXJz QG5ldGFwcC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFz aGVAYWthbWFpLmNvbSZndDs7IE1hZ251cyBXZXN0ZXJsdW5kICZsdDttYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZn dDs7IENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgQnJpYW4g VHJhbW1lbGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBZGRpbmcgRUNOIHRvIFRyYW5z cG9ydCBhbmQgUmVjb3Zlcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBz aG9ja2VkIGlmIGFueW9uZSB0cmllZCB0byB1c2UgdGhpcyBhdHRhY2sgaW4gcHJhY3RpY2UsIGFu ZCBhcyBMYXJzIHNhaWQsIHRoaXMgaXMgaW4gbm8gd2F5IHNwZWNpZmljIHRvIFFVSUMuJm5ic3A7 IFRoZSBvbmUgY2FzZSBJIGNhbiBpbWFnaW5lIHNvbWVvbmUgd2FudGluZyB0byBpbmplY3QgRUNO IGlzIGFuIG9uIHBhdGggbWlkZGxlYm94LCBpbiB3aGljaCBjYXNlIHRoYXQncyB3aGF0IEVDTiBp cyBmb3IuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv bid0IHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgcGFydCBvZiB2MS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdW4gMTIsIDIwMTgg YXQgODoyNyBBTSBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5j b20iPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxOC02LTEyLCBhdCAxNDox NywgTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlPTxhIGhyZWY9Im1haWx0bzo0MGFrYW1haS5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFrYW1haS5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRoZSBvbmx5IHRoaW5nIHRoYXQgbWFrZXMg YW4gYXR0YWNrIG9uIHRoZSBjb25nZXN0aW9uIHdpbmRvdyBuZWZhcmlvdXMgdnMgYW4gYXR0YWNr IG9uIHZlcnNpb24gbmVnb3RpYXRpb24gaXMgdGhhdCBpdCBsZWF2ZXMgdGhlIHVzZXIgd2l0aCBh biBpbXByZXNzaW9uIHRoYXQgdGhlIHNlcnZpY2UgaXMgcG9vciB2cyB0aGF0IHRoZSBuZXR3b3Jr IGlzIGludGVyZmVyaW5nIHdpdGggaGltIGNvbm5lY3RpbmcgdG8gdGhlIHNlcnZpY2UuPGJyPg0K PGJyPg0KUmlnaHQsIGJ1dCB0aGF0IGlzIG5vdCBzcGVjaWZpYyB0byBRVUlDLjxicj4NCjxicj4N ClRoZXJlIGFyZSBwb3NzaWJpbGl0aWVzIHRvIGFkZCBtaXRpZ2F0aW9ucyBhdCBhIGxhdGVyIHN0 YWdlIChRVUlDIHYyIG9yIHYxLjEpLCBidXQgSSBwZXJzb25hbGx5IGRvbid0IHRoaW5rIHRoZXNl IG5lZWQgdG8gYmUgcGFydCBvZiB2MS48YnI+DQo8YnI+DQpMYXJzPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_67a111e1eb754e118255ef67afeac60fustx2exdag1mb6msgcorpak_-- From nobody Tue Jun 12 16:34:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1191129619 for ; Tue, 12 Jun 2018 16:34:02 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=azMENvy1; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=d86Evl7+ 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 uyH6nvycuD7I for ; Tue, 12 Jun 2018 16:33:58 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 CF8A0130FDA for ; Tue, 12 Jun 2018 16:33:58 -0700 (PDT) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5CNWLwD007930; Tue, 12 Jun 2018 16:33:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=dVeTxSh6PWfD0aBh/Gj0lHWmDfBP+XC5VLLnexMtvIE=; b=azMENvy1cVoMsopVAllgyWAqctJWl+tJsqKo0BGYaJ6SmjMh/2kRGTCKHoMvrNE+f87Z zqWZ8mJd98EOKIdUk0i+0eHZ4N7O/fvx4pktvCp7ys6YzuckzdzAVKCBEDlobxcOc4fA flme5EBlGW8wDdqCmh2ObSYLUErm2spbhos= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jjp7a890y-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2018 16:33:56 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.16) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 12 Jun 2018 16:33:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dVeTxSh6PWfD0aBh/Gj0lHWmDfBP+XC5VLLnexMtvIE=; b=d86Evl7+mQ3oz/ysv+XPnpuruCpCGOw9Tvno8yhGLSBtNMb+An/jYJei4Wjq2++qAmb+pZA4u+qdjTYoNzwx9O4qo3fuIhPQzzKDnO7zmu0gXF5/C8+ypMYCqZMoPRc/kNLmkkmzeDUHdIJKAJi25yBOQ7yM4WNFvwV8xi1imc4= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2344.namprd15.prod.outlook.com (52.135.197.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.15; Tue, 12 Jun 2018 23:33:46 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0%4]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 23:33:46 +0000 From: Roberto Peon To: Dmitri Tikhonov , Spencer Dawkins at IETF CC: IETF QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHnJassB3eSU02Rr8SQ8wAp5KRVA8KAgAAjgYCAB7IcgA== Date: Tue, 12 Jun 2018 23:33:46 +0000 Message-ID: <54C69A73-24CB-426D-BDE4-03A59C78505C@fb.com> References: <20180607151112.GA28823@ubuntu-dmitri> <20180607190226.GA4187@ubuntu-dmitri> In-Reply-To: <20180607190226.GA4187@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [2620:10d:c090:200::7:88c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2344; 7:oP1WqlhA+khctWsVP/aEmpel+5Y0Ci6KMwpGXG80xXwKFe/0RCunpYPOym+qqK1Ll5OJTqi1H6pmaVD36kPuBPrTyi7i0PE/hH7LD6KJgOWFaGUrOb59UsRqggTTHeOYq9Pxh+u82TOjD86smXhpG1DYfmhwYFndG32Zob3Rx0lLdAd11MxNZwT33a1XpCYXQc5PkFKXQEiKbBG1lFnaxEB24mmuimmznaSfeJrO1/1stnmF2+HXQm/rxrres6Xs; 20:aw9UyYvx9xvHx8eJC/a5J4Mour5lLAo8N1FmDdrMEWnr/D0g8cPKykxardYnvfaf6mHfXQ9/LFbaSRZL0CSipMyN9YI0CezT1FpDZT6cfZn1NcbeYyKjE8ljPZqU9R9VOMEMOk0Txl0fBXvJo0I664uxjogoeTr27c/GKhG2w5Q= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2344; x-ms-traffictypediagnostic: BYAPR15MB2344: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2344; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2344; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(366004)(376002)(346002)(199004)(189003)(83716003)(59450400001)(82746002)(8936002)(81166006)(53936002)(39060400002)(68736007)(25786009)(102836004)(6506007)(106356001)(561944003)(105586002)(6246003)(58126008)(316002)(33656002)(99286004)(110136005)(76176011)(81156014)(6116002)(966005)(6436002)(6486002)(8676002)(186003)(5660300001)(575784001)(3660700001)(86362001)(229853002)(14454004)(305945005)(5250100002)(3280700002)(478600001)(2906002)(446003)(11346002)(2616005)(476003)(36756003)(6512007)(97736004)(46003)(486006)(6306002)(4326008)(2900100001)(7736002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2344; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YnBinLlzvHiuPZn2QvGXdcKPa7yI0eKi/l0yaHBpoMH7L6/U6NwHbVgJOtUsx1a57qX5JRhTXzYzV7pfRbUhqYmi1O1TKQv93CTsjI2vkDBxGzBMs6gDDY9wWFg2dwAoFWmxgYILnWP+HRxfx+w/eJZNUaEMwnY8uLNVlkeRvNX2fSehBJfKhu1JQCr6NTc2 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1a9fad69-ac86-456d-ccde-08d5d0bcf18d X-MS-Exchange-CrossTenant-Network-Message-Id: 1a9fad69-ac86-456d-ccde-08d5d0bcf18d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 23:33:46.6933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2344 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 23:34:03 -0000 VG8gYmUgZmFpciwgR29vZ2xlJ3MgRkVDIGltcGxlbWVudGF0aW9uIHdhcy4uLi4gbmHDr3ZlIGF0 IGJlc3QuDQpJIHdvdWxkbid0IHNheSB0aGF0IGl0IHByb3ZlZCBGRUMgdW51c2VmdWwsIGJ1dCBy YXRoZXIgdGhhdCBpdCBwcm92ZWQgdGhhdCBGRUMgb3ZlciB0ZW1wb3JhbGx5LXByb3hpbWF0ZSBw YWNrZXRzIHdhc24ndCB0aGF0IHVzZWZ1bC4NCi09Ug0KDQrvu79PbiA2LzcvMTgsIDEyOjAzIFBN LCAiUVVJQyBvbiBiZWhhbGYgb2YgRG1pdHJpIFRpa2hvbm92IiA8cXVpYy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+IHdyb3RlOg0KDQog ICAgSGkgU3BlbmNlciwNCiAgICANCiAgICBPbiBUaHUsIEp1biAwNywgMjAxOCBhdCAxMTo1NToy M0FNIC0wNTAwLCBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiB3cm90ZToNCiAgICA+IFRoaXMgaXMg bWUgYXMgYW4gaW5kaXZpZHVhbCwgYXNraW5nIGEgcXVlc3Rpb24sIGFuZCBOT1QgbWFraW5nIGFu IGluZm9ybWVkDQogICAgPiBvYnNlcnZhdGlvbiBvciBzdWdnZXN0aW9uIC4uLiBidXQgSSB3YXMg Y3VyaW91cy4NCiAgICANCiAgICBbc25pcF0NCiAgICANCiAgICA+IEkgbm90ZSB0aGF0IFRTVldH ICBjdXJyZW50bHkgaGFzIHR3byBGRUNGUkFNRSBkb2NzIGluIFdHTEMgbm93Og0KICAgID4gDQog ICAgPiAoMSkgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEdHN2d2ctMkRmZWNm cmFtZS0yRGV4dF8mZD1Ed0lCQWcmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZO QmFZZnlvYUNzZjZUQSZtPUtjNU1heHBQY3FBeG9CZW0xUnNGdTJkNWpVeFJzdlNPRkFVMXRVb3Vq Qmsmcz1KXzBDTllmbEhoQnZVd0FmOW9CUDQwT0hrR0RrWjhyTkJzd0toeDdmeU9BJmU9DQogICAg PiANCiAgICA+ICgyKSBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkR0c3Z3Zy0y RHJsYy0yRGZlYy0yRHNjaGVtZV8mZD1Ed0lCQWcmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9 QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPUtjNU1heHBQY3FBeG9CZW0xUnNGdTJkNWpVeFJzdlNP RkFVMXRVb3VqQmsmcz0xZFdqYVBSc2U1QXJIVFVnQVF2c0VNSkVadFUxNXRzREVWNXc2WF9ER29N JmU9DQogICAgPiANCiAgICA+IFRoZSBpbnRlbnQgZm9yIHRoZXNlIGRvY3VtZW50cyBpcyB0byBh ZGQgc3VwcG9ydCBmb3Igc2xpZGluZyB3aW5kb3cgRkVDDQogICAgPiBjb2RlcyB0byB0aGUgUkZD IDYzNjMgRkVDIEZyYW1ld29yaywgd2hpY2ggd2FzIGxpbWl0ZWQgdG8gYmxvY2sgRkVDIGNvZGVz Lg0KICAgIA0KICAgIEkgaGF2ZSB0byBhZG1pdCwgSSBoYXZlIG5ldmVyIHNlZW4gUkZDIDYzNjMg b3IgdGhlIEZFQ0ZSQU1FIGRyYWZ0cyB1bnRpbA0KICAgIHRvZGF5LiAgV2l0aCB0aGF0IHNhaWQs IEkgYmVsaWV2ZSBJIHVuZGVyc3RhbmQgb24gaGlnaCBsZXZlbCB3aGF0IHRoZXkNCiAgICBhcmUg YWJvdXQgYWZ0ZXIgcmVhZGluZyB0aGUgYWJzdHJhY3RzLg0KICAgIA0KICAgID4gSSBkb24ndCBr bm93IHdoZXRoZXIgdGhlcmUgaXMgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHlvdXIgcHJvcG9z YWwNCiAgICA+IChtb3ZpbmcgZnJvbSBmcmFtaW5nIHRvIGEgc3RyZWFtIGZvciBjb21wcmVzc2lv bikgYW5kIHRoZSB3b3JrIGN1cnJlbnRseSBpbg0KICAgID4gVFNWV0cuIEkgaGF2ZSBzb21lIGd1 ZXNzZXMsIGJ1dCBub3Qgd2VsbC1pbmZvcm1lZCBndWVzc2VzLCBzbyB0aG91Z2h0IEkNCiAgICA+ IHNob3VsZCBhc2suDQogICAgDQogICAgVGhlcmUgaXMgbm8gcmVsYXRpb25zaGlwIHRvIHRoZSBR UEFDSyBmcmFtaW5nIGluIHF1ZXN0aW9uLiAgVGhlIFFQQUNLDQogICAgZnJhbWluZyBtZWNoYW5p c20gdXNlZCB0byB3cml0ZSBlbmNvZGVyIGluc3RydWN0aW9ucyB0byB0aGUgZW5jb2Rlcg0KICAg IFFVSUMgc3RyZWFtIGlzIHRoZXJlIHNvbGVseSBhcyBhbiBhaWQgdG8gdGhlIGRlY29kZXIgLS0g ZXZpZGVudGx5DQogICAgd2l0aCB0aGUgYWltIG9mIG1ha2luZyB0aGUgUVBBQ0sgZGVjb2RlciBl YXNpZXIgdG8gaW1wbGVtZW50IChvciB0bw0KICAgIHBvcnQgZXhpc3RpbmcgSFBBQ0sgZGVjb2Rl cnMpLg0KICAgIA0KICAgIEdvb2dsZSBleHBlcmltZW50ZWQgd2l0aCBGRUMgaW4gZ1FVSUMgYnV0 IHRoZSBiYW5kd2lkdGggb3ZlcmhlYWQNCiAgICBwcm92ZWQgdG8gb3V0d2VpZ2ggYW55IGFkdmFu dGFnZXMgb2ZmZXJlZCBieSBhYmlsaXR5IHRvIHJlY29uc3RydWN0DQogICAgbG9zdCBwYWNrZXRz IGFuZCB0aGUgZWZmb3J0IHdhcyBhYmFuZG9uZWQsIElNTVNNQywgaW4gMjAxNS4NCiAgICANCiAg ICBVc2luZyBGRUMgaW4gSUVURiBRVUlDIGlzIHNvbWV0aGluZyB0aGF0IGlzIGludGVyZXN0aW5n IHRvIHRoaW5rIGFib3V0Lg0KICAgIEZvciBleGFtcGxlLCBvbmUgY291bGQgZW52aXNpb24gYWRk aW5nIEZFQyB0byBhIGNyaXRpY2FsIHN0cmVhbSwgc3VjaA0KICAgIGFzIHRoZSBRUEFDSyBlbmNv ZGVyIHN0cmVhbSBhYm92ZSwgdG8gY29wZSB3aXRoIHBhY2tldCBsb3NzLiAgVGhlDQogICAgY2hh bGxlbmdlcyBwb3NlZCBieSBzdWNoIGFwcHJvYWNoIHdvdWxkIGJlIG5vbi10cml2aWFsIGFuZCBs aWtlbHkNCiAgICByZXF1aXJlIGNoYW5nZXMgdG8gdGhlIHRyYW5zcG9ydCBsYXllci4NCiAgICAN CiAgICAgIC0gRG1pdHJpLg0KICAgIA0KICAgIA0KDQo= From nobody Tue Jun 12 16:36:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0336130EF3 for ; Tue, 12 Jun 2018 16:36:13 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=A+SxYSXS; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=WPpbKI19 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 rRqbcsPQWqwu for ; Tue, 12 Jun 2018 16:36:09 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 ADFD5129619 for ; Tue, 12 Jun 2018 16:36:09 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w5CNWHJO017837; Tue, 12 Jun 2018 16:36:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=7OMzgV+2/qRxY0K0HU8QhYIidy6gSAlqeCubPWS0y54=; b=A+SxYSXSofkCAwe8dYmOU1sZPdZJDMZGYQI1OSsTOzr7kQPOxWVDs1k0wwTFIZNsNC4E AJaAfIybtghCCsQup/7vTu3M8vEZiRqRE9CYppzo5tp4WG3fRC+NSuAcjdEi9ae9gMZf XqkUkWFOZd+Isd4D+cV55kvS8YwK9o8yvq8= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 2jjp73g90a-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2018 16:36:07 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 12 Jun 2018 19:36:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7OMzgV+2/qRxY0K0HU8QhYIidy6gSAlqeCubPWS0y54=; b=WPpbKI19lUkND16Fli/C7FZYdBJqAT2gCrp+iP+Y7/4EbwYEiDI6z2dcL3D1gkC4t0XGNAlAYSLecF6BacLrZUHATZXX7QtIj7Yhb4IrmUfnGjjCZPnymCjjq1vzrQak0Y05tquTEcN+b/jpSw+eEhn7FDbS4HpaWi+4SiYQQ0o= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2264.namprd15.prod.outlook.com (52.135.197.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.15; Tue, 12 Jun 2018 23:36:04 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::949a:9cbd:277c:96e0%4]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 23:36:04 +0000 From: Roberto Peon To: Kazuho Oku , Alan Frindell CC: QUIC WG , Martin Thomson Subject: Re: Proposal: drop QPACK encoder stream framing Thread-Topic: Proposal: drop QPACK encoder stream framing Thread-Index: AQHT/nHnJassB3eSU02Rr8SQ8wAp5KRWJZAAgAAStYCAAJ9EgIAAD04AgAAcpYCAAYnyAIAETJaA Date: Tue, 12 Jun 2018 23:36:04 +0000 Message-ID: <535018A7-3DC1-448B-9A94-43B30211F10F@fb.com> References: <20180607151112.GA28823@ubuntu-dmitri> <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [2620:10d:c090:200::7:88c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2264; 7:PRp2gAw5L6U17gdPXOuJwmZlOV81wntuCqX1/tCrl53AW1qD/f7WNeBA6BgCjZehnv62z9D3iX9s+v6A5GjEjqdzScqd40h8dwj4+zgT1/BY39igrvu1F/0zyu+t1XfsftQasn2WOM43Y2JT6PHojUjRZaft20ae1ELVyg7lNd1N16k50oTHXFki4MrBgIOFeGhXujsbE2DHetp2LCGxM43+3n2ybZquwDAJWzgLURep7jHtXxcOPMpkBLoZQkqC; 20:0s4IP++AaGEqmuEYw1WwTc8XHNexGDBSUs3vei3auS9mJEYkpd/nHDkMrsbuq5R1bJ/wMpQmy8EftwBKKVewriyRGS94VUwQbV16q1Z02xEk4tz/5+gfSa7jXHcW6HuSlRoa56w6LLj3VwKYrJhWlRgAJz8kpLG7UmqqD21dN2k= x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(396003)(366004)(39380400002)(189003)(199004)(33656002)(81166006)(6506007)(99286004)(106356001)(59450400001)(8936002)(76176011)(6116002)(6246003)(6436002)(5250100002)(345774005)(11346002)(2616005)(316002)(446003)(6486002)(476003)(105586002)(25786009)(486006)(53936002)(6512007)(68736007)(229853002)(36756003)(39060400002)(58126008)(54906003)(110136005)(8676002)(2900100001)(4326008)(3660700001)(93886005)(3280700002)(46003)(97736004)(478600001)(81156014)(82746002)(5660300001)(86362001)(2906002)(7736002)(14454004)(6636002)(186003)(83716003)(102836004)(305945005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2264; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id: 996d37a4-115b-4464-4403-08d5d0bd43a1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(711017)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2264; x-ms-traffictypediagnostic: BYAPR15MB2264: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(11241501184)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2264; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2264; x-forefront-prvs: 07013D7479 received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: t9Oy5fseTcCNv4njswu79OKUQsNnBsGrO6TfiBf+z6SBGGD7bUgiV8JdrK2NIWEUaips+DeAIKLB4m000rSa7yKz8uG0ZPMctJ8UdB+/SDQu1Ehayrtm/sgY8E1BXDs0TFSvGHpgoJwoREQsl/8VDMkz+7WsrlIRPb6SFgWX1uS/Bq8qeKhrkaK7Tn64UBFm spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 996d37a4-115b-4464-4403-08d5d0bd43a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 23:36:04.3020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2264 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 23:36:14 -0000 V2VyZSBJIHRvIHB1dCBsZW5ndGhzIHNvbWV3aGVyZSwgaXQnZCBiZSBvbiBhbm90aGVyIHN0cmVh bSwgd2hpY2ggY29uc2lzdGVkIHNvbGVseSBvZiBmaXhlZC9jb25zdGFudC1zaXplZCBtZXRhZGF0 YSBhYm91dCB0aGUgaGVhZGVycy4NCi09Ug0KDQrvu79PbiA2LzkvMTgsIDM6NTcgUE0sICJRVUlD IG9uIGJlaGFsZiBvZiBLYXp1aG8gT2t1IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBrYXp1aG9va3VAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIDIwMTgtMDYtMDkgODoyNiBH TVQrMDk6MDAgQWxhbiBGcmluZGVsbCA8YWZyaW5kQGZiLmNvbT46DQogICAgPiAgICAgQmVjYXVz ZSBJIHRoaW5rIHJlcGFyc2luZyBpcyB0aGUgYmVzdCBzdHJhdGVneSBoZXJlLCBsZXQgbWUgYXJn dWUgdGhhdA0KICAgID4gICAgIHRoZSB3b3JzdCBjYXNlIGlzIG5vdCBPKE5eMikuDQogICAgPg0K ICAgID4gICAgIE9mIGNvdXJzZSwgaW4gdGhlb3J5IGl0IGlzIE8oTl4yKSwgYmVjYXVzZSB0aGVy ZSBpcyBubyB1cHBlciBib3VuZCBmb3INCiAgICA+ICAgICB0aGUgaW50ZWdlciByZXByZXNlbnRh dGlvbi4gQnV0IHRoZSByZWFsaXR5IGlzIHRoYXQgaW1wbGVtZW50YXRpb25zDQogICAgPiAgICAg YXJlIHJlcXVpcmVkIHRvIGhhdmUgYW4gdXBwZXIgYm91bmQuIEknZCBhc3N1bWUgdGhhdCB0aGV5 IHdvdWxkDQogICAgPiAgICAgdHlwaWNhbGx5IG9ubHkgcGVybWl0IHZhbHVlcyB0aGF0IGZpdCBp biBhIDMyLWJpdCAodSlpbnQgKDE2LWJpdCBpcw0KICAgID4gICAgIGFub3RoZXIgb3B0aW9uIGZv ciBzb21lKS4NCiAgICA+DQogICAgPiBUaGUgTyhOXjIpIHdvcmsgSSB3YXMgdGhpbmtpbmcgb2Yg d2FzIHNvbWV0aGluZyBsaWtlIHRoaXM6DQogICAgPg0KICAgID4gVGhlIGVuY29kZXIgc2VuZHMg YSB2ZXJ5IGxvbmcgSHVmZm1hbiBlbmNvZGVkIGhlYWRlciBuYW1lIGZvbGxvd2VkIGJ5IGEgbG9u ZyB2YWx1ZSwgYnV0IHRoZXkgc2VuZCB0aGUgdmFsdWUgb25lIGJ5dGUgYXQgYSB0aW1lLiAgSWYg dGhlIGRlY29kZXIgbmFpdmVseSByZXBhcnNlcyB0aGUgZW50aXJlIEluc2VydCBpbnN0cnVjdGlv biBldmVyeSB0aW1lIGEgYnl0ZSBhcnJpdmVzLCBpdCB3aWxsIGVuZCB1cCBIdWZmbWFuIGRlY29k aW5nIHRoZSBoZWFkZXIgbmFtZSBvbiBldmVyeSBuZXcgYnl0ZSBvZiB0aGUgdmFsdWUuICBUaGUg bmFtZSBjYW4gYmUgc2tpcHBlZCBvdmVyIHRvIHJlLXBhcnNlIHRoZSB2YWx1ZSBsZW5ndGgsIGFu ZCB2ZXJpZnkgaWYgdGhlIGZ1bGwgdmFsdWUgaXMgcHJlc2VudC4gIEhvd2V2ZXIsIGV2ZW4gc2tp cHBpbmcgb3ZlciBpdCBtYXkgYmUgYSBsaW5lYXIgb3BlcmF0aW9uIGluIGEgemVyby1jb3B5IGlt cGxlbWVudGF0aW9uIHRoYXQgbWFpbnRhaW5zIGEgbGlua2VkIGxpc3Qgb2YgZGF0YSBidWZmZXJz Lg0KICAgIA0KICAgIFRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFRoYXQgc291bmRz IGxpa2UgYW4gaW50ZXJlc3RpbmcNCiAgICBhdHRhY2sgdmVjdG9yIHRoYXQgd2UgbmVlZCB0byBi ZSBhd2FyZSBvZi4NCiAgICANCiAgICBPVE9ILCBJIGFtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8g Y29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mDQogICAgc3RyZWFtaW5nIEh1ZmZtYW4gZGVjb2Rp bmcgaW4gdGhpcyBkaXNjdXNzaW9uLCBjb25zaWRlcmluZyB0aGUgZmFjdA0KICAgIHRoYXQgdGhl IGNvbXByZXNzZWQgc3RyaW5ncyByZW1haW4gbGVuZ3RoLXByZWZpeGVkLg0KICAgIA0KICAgIEV2 ZW4gaWYgd2UgcmVtb3ZlIHRoZSBmcmFtaW5nIG9mIHRoZSBRQ0FDSyBpbnN0cnVjdGlvbnMsDQog ICAgaW1wbGVtZW50YXRpb25zIHdpbGwgY29udGludWUgdG8gaGF2ZSB0aGUgZnJlZWRvbSB0byBi dWZmZXIgYSBjb21wbGV0ZQ0KICAgIEh1ZmZtYW4tZW5jb2RlZCBzdHJpbmcgKHRoZSBsZW5ndGgg b2YgdGhlIHN0cmluZyBiZWluZyBpZGVudGlmaWVkIGJ5DQogICAgdGhlIGxlbmd0aCBvY3RldHMu DQogICAgDQogICAgPiAtQWxhbg0KICAgID4NCiAgICA+DQogICAgDQogICAgDQogICAgDQogICAg LS0gDQogICAgS2F6dWhvIE9rdQ0KICAgIA0KICAgIA0KDQo= From nobody Tue Jun 12 18:30:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5207B1310A8 for ; Tue, 12 Jun 2018 18:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 5nRAen3t9uNH for ; Tue, 12 Jun 2018 18:29:45 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 6F4ED130E95 for ; Tue, 12 Jun 2018 18:29:45 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id w74-v6so328479ybe.11 for ; Tue, 12 Jun 2018 18:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HU4Ne6tcgPS8lsHJ1A5ajh22YnNvvgdfkkdzWEePzqQ=; b=W5pvY/MrHnhyeSSGU56gLcUk4alM8hX33HK7R4og0aA7BdefpBSe9C8fb0jywMoZXI uE4rk/g8xL3g8YqZlrm9kzqIdtPymbxqBdDQNNgMVVy2l1O5nhjcCSb8d5gum0+/kBLd XQ+6TwTJp1u8XFl/vYNUFBZSfITphLV40eL2sTpke0xdgCtmoj8e0K1BFUEzAH4LruXg 84WhgZwkhITdG1nlqQxedgw8G2whey7PpnoEX87hyeS8lwSHrrZCzs4x49YwsOY/3spO l5LxASt95QVgr9d2pcDyy7jsmlaG/K+x3St3KTmmw1EcIAD/4RIoCMw9e6lnFulxTD4g XJbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HU4Ne6tcgPS8lsHJ1A5ajh22YnNvvgdfkkdzWEePzqQ=; b=B38vcH/cqAJ6wRtWMtGpFwoCD/cu7kD+pqTDN2Q9YkeyoE5SZ1gdvGpO0oZCVHc/dZ D+nbxwMH7ipVBLb/vvfptGm2a9jfJjtMKDV1w/91n4+5azQxRo6WtQQxyn/JJsLth2WG NWsQGSWzQ23gmCPTVqMpBNLCvaWE1oJvhzTnVWfLnw8dv0C7z5b5tpNRsYE5iBXm97/Z RM6390cMHwcq/SnItbPIi7iKEzZxjrPSHU41+pFZdduPTupupXvi00sGoaGxTSe6SJMB hAPP527k2lRJll4POA1Z9K/hKmEkIkznk8+KPePVdPTqdCxBWTPxgkgiZct+SIgeOIVD nLVA== X-Gm-Message-State: APt69E2Wc+Ia0oHifmWBv5J58fBeQTwgnuUcHriAu27ob0L9Wlmphnww k301oGGleaHxBE+EA+tUYIpBisQ7Wv/lzjWyRKDuLg== X-Google-Smtp-Source: ADUXVKLQfYD1L76KZwcUdQ1SednvXZ713CBi0kE+OJpjpgFbH85MrVPThT1rWGauOEAa5cVFLWMKg5x3C6bn4SFWUCs= X-Received: by 2002:a25:57d7:: with SMTP id l206-v6mr1403378ybb.206.1528853384309; Tue, 12 Jun 2018 18:29:44 -0700 (PDT) MIME-Version: 1.0 References: <20180607151112.GA28823@ubuntu-dmitri> <8616263A-31EF-4803-BEEF-1FE3FAEB23DB@fb.com> <535018A7-3DC1-448B-9A94-43B30211F10F@fb.com> In-Reply-To: <535018A7-3DC1-448B-9A94-43B30211F10F@fb.com> From: Ian Swett Date: Tue, 12 Jun 2018 21:29:32 -0400 Message-ID: Subject: Re: Proposal: drop QPACK encoder stream framing To: Roberto Peon Cc: Kazuho Oku , Alan Frindell , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000e37209056e7bea47" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 01:29:58 -0000 --000000000000e37209056e7bea47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a person who spent a fair amount of time both trying to make Google's FEC scheme work and subsequently analyzing why it didn't, a core issue was that losses were much more correlated than expected. The only FEC scheme tested had zero value if more than two packets were lost within an FEC block. Additionally, it was not wired up to the general purpose recovery code, so it failed to prevent spurious retransmits. That being said, if you have a few RTTs to play with, QUIC's fast retransmission works very well. If you're running a realtime application like WebRTC, the bandwidth overhead of FEC is well-justified. On Tue, Jun 12, 2018 at 7:36 PM Roberto Peon wrote: > Were I to put lengths somewhere, it'd be on another stream, which > consisted solely of fixed/constant-sized metadata about the headers. > -=3DR > > =EF=BB=BFOn 6/9/18, 3:57 PM, "QUIC on behalf of Kazuho Oku" on behalf of kazuhooku@gmail.com> wrote: > > 2018-06-09 8:26 GMT+09:00 Alan Frindell : > > Because I think reparsing is the best strategy here, let me > argue that > > the worst case is not O(N^2). > > > > Of course, in theory it is O(N^2), because there is no upper > bound for > > the integer representation. But the reality is that > implementations > > are required to have an upper bound. I'd assume that they would > > typically only permit values that fit in a 32-bit (u)int (16-bi= t > is > > another option for some). > > > > The O(N^2) work I was thinking of was something like this: > > > > The encoder sends a very long Huffman encoded header name followed > by a long value, but they send the value one byte at a time. If the > decoder naively reparses the entire Insert instruction every time a byte > arrives, it will end up Huffman decoding the header name on every new byt= e > of the value. The name can be skipped over to re-parse the value length, > and verify if the full value is present. However, even skipping over it > may be a linear operation in a zero-copy implementation that maintains a > linked list of data buffers. > > Thank you for the clarification. That sounds like an interesting > attack vector that we need to be aware of. > > OTOH, I am not sure if we need to consider the possibility of > streaming Huffman decoding in this discussion, considering the fact > that the compressed strings remain length-prefixed. > > Even if we remove the framing of the QCACK instructions, > implementations will continue to have the freedom to buffer a complet= e > Huffman-encoded string (the length of the string being identified by > the length octets. > > > -Alan > > > > > > > > -- > Kazuho Oku > > > > --000000000000e37209056e7bea47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a person who spent a fair amount of time both trying to= make Google's FEC scheme work and subsequently analyzing why it didn&#= 39;t, a core issue was that losses were much more correlated than expected.= =C2=A0 The only FEC scheme tested had zero value if more than two packets w= ere lost within an FEC block.

Additionally, it was n= ot wired up to the general purpose recovery code, so it failed to prevent s= purious retransmits.

That being said, if you have = a few RTTs to play with, QUIC's fast retransmission works very well.=C2= =A0 If you're running a realtime application like WebRTC, the bandwidth= overhead of FEC is well-justified.

On Tue, Jun 12, 2018 at 7:36 PM Roberto Peon <fenix@fb.com> wrote:
Were I to put lengths somewhere, it'd be on another = stream, which consisted solely of fixed/constant-sized metadata about the h= eaders.
-=3DR

=EF=BB=BFOn 6/9/18, 3:57 PM, "QUIC on behalf of Kazuho Oku" <<= a href=3D"mailto:quic-bounces@ietf.org" target=3D"_blank">quic-bounces@ietf= .org on behalf of kazuhooku@gmail.com> wrote:

=C2=A0 =C2=A0 2018-06-09 8:26 GMT+09:00 Alan Frindell <afrind@fb.com>:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Because I think reparsing is the best= strategy here, let me argue that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the worst case is not O(N^2).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Of course, in theory it is O(N^2), be= cause there is no upper bound for
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the integer representation. But the r= eality is that implementations
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0are required to have an upper bound. = I'd assume that they would
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0typically only permit values that fit= in a 32-bit (u)int (16-bit is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0another option for some).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The O(N^2) work I was thinking of was something like thi= s:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The encoder sends a very long Huffman encoded header nam= e followed by a long value, but they send the value one byte at a time.=C2= =A0 If the decoder naively reparses the entire Insert instruction every tim= e a byte arrives, it will end up Huffman decoding the header name on every = new byte of the value.=C2=A0 The name can be skipped over to re-parse the v= alue length, and verify if the full value is present.=C2=A0 However, even s= kipping over it may be a linear operation in a zero-copy implementation tha= t maintains a linked list of data buffers.

=C2=A0 =C2=A0 Thank you for the clarification. That sounds like an interest= ing
=C2=A0 =C2=A0 attack vector that we need to be aware of.

=C2=A0 =C2=A0 OTOH, I am not sure if we need to consider the possibility of=
=C2=A0 =C2=A0 streaming Huffman decoding in this discussion, considering th= e fact
=C2=A0 =C2=A0 that the compressed strings remain length-prefixed.

=C2=A0 =C2=A0 Even if we remove the framing of the QCACK instructions,
=C2=A0 =C2=A0 implementations will continue to have the freedom to buffer a= complete
=C2=A0 =C2=A0 Huffman-encoded string (the length of the string being identi= fied by
=C2=A0 =C2=A0 the length octets.

=C2=A0 =C2=A0 > -Alan
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Kazuho Oku



--000000000000e37209056e7bea47-- From nobody Tue Jun 12 22:00:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23F0130DDC for ; Tue, 12 Jun 2018 22:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GAPPY_SUBJECT=1.954, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DXWZlG+m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HF5INFYv 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 PVXBDnUqb_Yg for ; Tue, 12 Jun 2018 22:00:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A106130DCE for ; Tue, 12 Jun 2018 22:00:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 69BC521BA5; Wed, 13 Jun 2018 01:00:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 13 Jun 2018 01:00:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=uZFxNOxd0wDJwd/UYvZFt9wEL3CfgBUA5Ol19uXBNWQ=; b=DXWZlG+m 6wnz9ACjqt7rWxXy/58CYTVApexIPDgsIekLSZiZfB72EdSvlGO1uNT8RPhTOu+c rIE7Qh5T6Rmce4gGz3ZLaVV9c00Hr/A/soO5LB9WTGTuHUj4cuLIT1JshcUPt82P RRCiLBGLaJDbT69XkW0Oj5NwGlWKPfZ/xp8AGWCLwZeAS22OUwqPO9Bd8gSEfYGs XxZkVNnmva/aaRCT2MO06V1z8idL3AzmW4lN9r2nG3p0z37Ij8DtJ473HtI2cCRX yOm6Ugwv6DGyCd8P5tAkkuvrHOsUzz/FhintL1YWGMLAsF382QLluSYkl9Dg3CvI W26YyQi2IP+ZqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=uZFxNOxd0wDJwd/UYvZFt9wEL3Cfg BUA5Ol19uXBNWQ=; b=HF5INFYvFvJgmVbVxy3e10IAYzk4fmAUofg3XuUKWoZRu FA6cRIjtI1p47KLJvX63fMxF2LbeD2zCJB35afyFuAE1f4+xBhi0qSZjjrDKIw2P OlDxToT+v9n3oUL8xHhAn5k0A+USILr6FFJcn+4RJz9QT0Cf+hcXCHlBBkHMMee+ 4ddo8ZaC/qpL25f1h05yQnGbD+3dnRdS3j8ytUFYq6lFBlufFuJ6alVu2qswfJfw 7xHxrF0LibXA6IsKmwaLk/UIQ3tafSM2APbEXEnRjm3eT6LE+flB9QucVMSJqAj7 FwuzWjZ0VlqjX9g/vAYa1mQQs95/kpJqVJrTR7oFQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from macbook-pro.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 36AFC102A2; Wed, 13 Jun 2018 01:00:32 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: DRAFT minutes for the Stockholm^H^H^H^H^H^H^H^H^HKista Interim Meeting Message-Id: <2E67BE73-9D38-483B-81F2-B50BA43BEE23@mnot.net> Date: Wed, 13 Jun 2018 15:00:29 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.8.2) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 05:00:38 -0000 ... are at: = https://github.com/quicwg/wg-materials/blob/master/interim-18-06/minutes.m= d Special thanks to our scribes. As always, suggestions and corrections welcome, either as Pull Requests = or on the mailing list. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 13 07:04:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C82130DC0 for ; Wed, 13 Jun 2018 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z-IWTV5_ZWUa for ; Wed, 13 Jun 2018 07:04:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD8312F18C for ; Wed, 13 Jun 2018 07:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528898655; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: 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=aHagVZWSxVRU6IoKtf28uRhhqlFwO7yDgFcAx5YAr3k=; b=QbrcsXyYg1mxV+pztbCUSZ8GzG1UGwetxFSuWqeehNFv5sSMbod/TFN5FxLKjYuJ GLjxHnmTf6wQo4VhXnjPwcPFyBq6wU/5fcZvqR3LFTfKcJyxfyCUQAQQujYLt+Ln vcTXNbKwA7v0z+B+XsNr8fCLqDRDOQ6R+R7g24Vglhg=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-1b-5b21245f4c58 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.C2.22015.F54212B5; Wed, 13 Jun 2018 16:04:15 +0200 (CEST) Received: from [147.214.160.173] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 13 Jun 2018 16:03:28 +0200 Subject: Re: Adding ECN to Transport and Recovery From: Magnus Westerlund To: IETF QUIC WG References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> Message-ID: <2817ae09-99b7-82f1-94eb-7420e3a790c9@ericsson.com> Date: Wed, 13 Jun 2018 16:03:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2J7iG68imK0QfMmaYueBdwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4MpYMeUGa8EziYo5jzoZGxh7RboYOTkkBEwkZm+/xN7FyMUhJHCE UeLm+rlQzhZGie1nF7F0MXJwCAsYSuy46ADSwCZgIXHzRyMbSFhEQEFiTQMnSFhIwF7i4559 7CA2L5C96NQfFhCbRUBV4knnBSYQW1QgRmL1xstQNYISJ2c+AavhFHCQuPjxFzPISGag3gdb y0DCzALyEs1bZzND2OISTV9WskKs0pZoaOpghThfSeL6vOssExgFZyGZOgth0iwkk2YhmbSA kWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmCoHtzyW3cH4+rXjocYBTgYlXh4v8gqRgux JpYVV+YeYpTgYFYS4fV7oRAtxJuSWFmVWpQfX1Sak1p8iFGag0VJnFdv1Z4oIYH0xJLU7NTU gtQimCwTB6dUA6OP1Eb5OWp5yj4F9u793ncdMta6mAtMU0yfZy7rPOWq5ae89+VqlkUbps44 +afYN+WCAbvy6SVcBT+jJv9Q2PS9i/Hv/1lc0rI5XmIhS1x8M7p1fjBsNV19I0u95MHFbWdv 1Dgd9oza2fQlUMzGz+Mg6+P2YyerghIFNhzKjfhh+XX3NM9pM5VYijMSDbWYi4oTATukxbhR AgAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:04:25 -0000 Hi, I have just added one more paragraph to the pull request to deal with an issue that arises if there is persistent ACK loss such that the sender never receives an acknowledgement for some packet that was actually received by receiver and counted in the ECN counters. To make implementers aware of the issue I have added this paragraph in Section 6.6.1. Continuous Verification of ECN: If the acknowledgements from the receiver are lost such that one or more packet are received by the receiver, but never acknowledged to the sender an insensitivity to bleaching will be created. In this situation the ECN counters reported will have increase, but the sender side total for acknowledged packets will not have increased. Thus, a number of bleached packets equal to the number of packets that failed to be acknowledged can be received before triggering the continuous verification. To address this issue the sender detect the case when the ECN counters grows more than number of acknowledged packets when a ACK_ECN frame is received. In such cases a new comparison point is created by storing the current number of totally acknowledged packets and latest ECN counters. Then comparison are done by subtracting these stored values from the respective counters prior to the comparison. Note that any out-of-order ACK_ECN frames can't be used for determining any loss of acknowledgements. Please provide feedback on this addition. Cheers Magnus Den 2018-05-28 kl. 22:29, skrev Magnus Westerlund: > WG, > > I have been working on a Pull Request > (https://github.com/quicwg/base-drafts/pull/1372) that implements the > ECN proposal from the design team > (https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC) into > something reasonably well integrated into the current drafts. Thus, I > think it is time that people review and consider this proposal so that > any issues can be addressed. > > I would very much like to present at the interim this proposal, some > of the choices made, and determine if there are additional changes to > be made before merging this. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB                 | Phone  +46 10 7148287 > Torshamnsgatan 23           | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 14 11:40:41 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81687130E6B; Thu, 14 Jun 2018 11:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: quic@ietf.org, lflynn@amsl.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - Update to a Meeting Session Request for IETF 102 X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152900163845.26447.4705112286230693991.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2018 11:40:38 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 18:40:39 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch Second Priority: mptcp saag Third Priority: irtfopen maprg People who must be present: Sean Turner Mark Nottingham Patrick R. McManus Jana Iyengar Martin Thomson Spencer Dawkins Brian Trammell Lars Eggert Mike Bishop Ian Swett Alan Frindell Resources Requested: Special Requests: Two consecutive days early in the week, if possible; 2 hour slot(s) fine too, if that makes it easier. --------------------------------------------------------- From nobody Fri Jun 15 09:11:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8F812F18C for ; Fri, 15 Jun 2018 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 PRKtTEPXendF for ; Fri, 15 Jun 2018 09:11:43 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 031E8130E37 for ; Fri, 15 Jun 2018 09:11:43 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id q17-v6so11572855otg.2 for ; Fri, 15 Jun 2018 09:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0SFkjg2NgfmhyTUvjTs3L3MkZdgePf1aZttYfvtbtJE=; b=DCvDU3xacfD8pXUvCVq9M/OaLawhhV/dKHIsvDApGAr5ocOS4qLt8zgweZgARiXvO3 eP84EHWNt9rNKZXA59oBeDea27x8LvJztTA2x7RVrBu/fSbHqCQ3PElVTN+ZMyU7HcvN oCFAuDaVvDQdsLWaAqkw1sA02KyJyc4GamwvkV/W4gPa1MEweqfIe1XLyGXQXSZqHl38 HemExI8Ff8ri7PYNcOPY6iIpnvfVkJuGxkjqEQeZcD3QMTItRR8E278QAM24z3dhVMok 8sTrZukGPKNa8i+rx6Uuw+RYofhtRkxK502Ej71dyH3Z2lvHPRKdzB/8NAuLosnyRC3Q ytGA== 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=0SFkjg2NgfmhyTUvjTs3L3MkZdgePf1aZttYfvtbtJE=; b=jUDNBTg/3vOvxC/mlOWtbqu5tRA+3kL0czUq/PaXsiIVhBwearkyRZPuhIEVc0RZs2 YPKYxM5WQKmpuJtFMPPhNJFEHmEZqPwQfRcFXpOAXpCf0LXB552qpS2KFe/2v1D899m3 UjBdtf2HdCztViE5mkSd7tHN/mnqQqMlHv9RQnmZn9wk16w6V4HzaNJ1aiwAucuA9Lo1 4S48u8jS/tHGeg4Myuu1mmY4mC1eY0Tr/AxOokVYyajKKcriUKWaLcCqiHUeTul5Nj9G BtpifPccOxev0aFE4tOKe/fF6SduIqOuxbtZdM9lfKYTEbz7ZP4TheXbIZwKl1Mktd+h 9U3A== X-Gm-Message-State: APt69E2XMFXgH6M6I6xdKsJiLaX+y1/5vOTsvOaVtfnBbBCrg8HflPNS ipS3KXGskKx/RjqEF65GD04ff9xXncCKnsjxT2pqrg== X-Google-Smtp-Source: ADUXVKK/Pb21GPjmCCPbo/7Mtx39B5jVUYhY8HU72uU48ggSdYe7PhhFJNNODSHSSBKc3AwN636l32tXiXUPQ0+ft98= X-Received: by 2002:a9d:4905:: with SMTP id e5-v6mr1473920otf.101.1529079102344; Fri, 15 Jun 2018 09:11:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 09:11:01 -0700 (PDT) In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Eric Rescorla Date: Fri, 15 Jun 2018 09:11:01 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" Cc: Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="000000000000baa327056eb078ce" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:11:46 -0000 --000000000000baa327056eb078ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Manasi here. This change would allow ack frame parsing to be more self-contained, which is an advantage for the parser and also potentially for parallelism (because you can quickly find the frame and then process it in parallel). -Ekr On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi wrote: > In general, varints require some specific logic for parsing. To skip over > any header, I have to read every single varint. As the code sees Stream a= nd > ACK headers most frequently, that is my focus. The Stream frame has a > length in its third field. > > > > ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. > There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2= =80=98ACK delay=E2=80=99 and =E2=80=98ACK > block count=E2=80=99. The pain point is the total number of cycles parse = an ACK. If > I am processing 10M pps, where 10% - 30% of the packets have a piggybacke= d > ACK, these cycles becomes a significant bottleneck. > > > > Thanks, > > Manasi > > > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Monday, June 11, 2018 3:11 PM > *To:* Deval, Manasi ; QUIC WG > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > You're right that we no longer have the ability to skip an ACK frame, and > this crept in when we moved to varints. > > I believe your problem though is generally true of most frames not just > ACKs, since ids, packet numbers, and numbers in all frames are now all > varints. To skip any frame, you'll need to parse the varint fields in tho= se > frames. If you have logic to process and skip varints, then skipping the > ack block section is merely repeating this operation (2*num_block+1) time= s. > Do you see specific value in skipping ACK frames over the other control > frames? > > > > > > On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > > On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > > - Moving the ACK length to the front of the ACK allows the > > flexibility of either reading the entire ACK or reading the > > first 16 bits and skipping over the length. This is a useful > > feature for the case where ACK processing is split into > > multiple layers. Depending on the processor this is run on, > > there are different advantages - > > Just a note. In my experience, the cost of parsing an ACK frame is > negligible compared to the cost of processing an ACK frame: that is, > poking at various memory locations to discard newly ACKed packets. > > - Dmitri. > > --000000000000baa327056eb078ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Manasi here. This change would allow ack= frame parsing to be more self-contained, which is an advantage for the par= ser and also potentially for parallelism (because you can quickly find the = frame and then process it in parallel).

-Ekr


On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi &l= t;manasi.deval@= intel.com> wrote:

In general, varints require some specific logic for pa= rsing. To skip over any header, I have to read every single varint. As the code sees Stream and ACK headers most frequent= ly, that is my focus.=C2=A0 The Stream frame has a length in its third fiel= d.

=C2=A0

ACK parsing, however, needs 6 + 2*num_blocks reads to = identify length. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2=80=98ACK delay=E2=80=99 and = =E2=80=98ACK block count=E2=80=99. The pain point is the total number of cy= cles parse an ACK. If I am processing 10M pps, where 10% - 30% of the packe= ts have a piggybacked ACK, these cycles becomes a significant bottleneck.

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Monday, June 11, 2018 3:11 PM
To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG <quic@ietf.org>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

You're right that= we no longer have the ability to skip an ACK frame, and this crept in when= we moved to varints.

I believe your problem though is generally true of m= ost frames not just ACKs, since ids, packet numbers, and numbers in all fra= mes are now all varints. To skip any frame, you'll need to parse the va= rint fields in those frames. If you have logic to process and skip varints, then skipping the ack block section is = merely repeating this operation (2*num_block+1) times. Do you see specific = value in skipping ACK frames over the other control frames?

=C2=A0

=C2=A0

On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <= dtikhonov@= litespeedtech.com> wrote:

On Mon, Jun 11, 2018 = at 03:33:35PM +0000, Deval, Manasi wrote:
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the front of the= ACK allows the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either reading the en= tire ACK or reading the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping over the = length. This is a useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where ACK proce= ssing is split into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending on the pr= ocessor this is run on,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advantages -

Just a note.=C2=A0 In my experience, the cost of parsing an ACK frame is negligible compared to the cost of processing an ACK frame: that is,
poking at various memory locations to discard newly ACKed packets.

=C2=A0 - Dmitri.


--000000000000baa327056eb078ce-- From nobody Fri Jun 15 15:10:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F25130E77 for ; Fri, 15 Jun 2018 15:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WiHjMBw5CNE for ; Fri, 15 Jun 2018 15:10:25 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710098.outbound.protection.outlook.com [40.107.71.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA80130E6D for ; Fri, 15 Jun 2018 15:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VGO/5yCv0nk4CX3AIaBAIc9UY+WxwJ0o7eqINJkgdh8=; b=TXsXVCZgQeALQMg8HQEP58Gq99HbBx8sjQw19/QP2+eXCrS0NQkzuMxN7EG58PLuVViTqNsLXg8eYwdxpcfVH0YlKMs6B7P7MOjSFeIohtN2fQ2wnXAJZsyje2+pblmQraxhcCJT40IvHVe9UvTuiZerrFhsxNpx+PjIHeE6Bww= Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0783.namprd21.prod.outlook.com (10.173.51.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.14; Fri, 15 Jun 2018 22:10:23 +0000 Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::85d1:84f:573e:7afb]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::85d1:84f:573e:7afb%5]) with mapi id 15.20.0884.010; Fri, 15 Jun 2018 22:10:23 +0000 From: Praveen Balasubramanian To: Eric Rescorla , "Deval, Manasi" CC: Jana Iyengar , QUIC WG Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFON0uAAA2Oe4AABJAbAAC4BBWAAAAXlWA= Date: Fri, 15 Jun 2018 22:10:23 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:8:491e:330a:610c:ec8b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0783; 7:r+VsOcHeccTJcncx0iRtHE7ffL2JdBNB5jewsdC3NFxtmEhUyZlRKeulwf+ZZCEXrvxQLqEZevMtTRvFJHXMUiuGV8lYR5WPF0N/BdHY8CfBB+LloJ78/M0MJrg743zy4Ye2r+NdMc3Pk/6kJo3ODn20CaYjyYoNXw7rYy8yKaorhV0DtOLpbYgrGzspQCpZPrXYx+aRDJQa3siTAt0EfCKGMxskAqaSeAvt679H420Nz6rr2Ud9yJ3qbZL/OSpb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 162d5402-919d-46dd-28fa-08d5d30cca67 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MWHPR21MB0783; x-ms-traffictypediagnostic: MWHPR21MB0783: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(788757137089)(21748063052155)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0783; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0783; x-forefront-prvs: 0704670F76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39380400002)(39860400002)(199004)(189003)(19609705001)(106356001)(236005)(53936002)(105586002)(10290500003)(478600001)(4326008)(25786009)(5660300001)(68736007)(86612001)(186003)(476003)(486006)(2900100001)(97736004)(39060400002)(6246003)(86362001)(3660700001)(33656002)(9686003)(229853002)(76176011)(2906002)(6116002)(446003)(6306002)(6506007)(53546011)(561944003)(7736002)(99286004)(8936002)(102836004)(54896002)(3280700002)(81166006)(81156014)(8676002)(7696005)(790700001)(11346002)(10090500001)(5250100002)(8990500004)(14454004)(54906003)(74316002)(93886005)(55016002)(110136005)(22452003)(46003)(6436002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0783; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IGEU0q8+1+vZ2uI4fsttKdP3gDSE+dgnOrU7GRs9CJgI+CZU1B2NQO9VkLA8gJ7dzYoWm3YAdFtY67ncL2IpzQ/LLVWnVCWabWa4+qva/qB+u7m2bf10aFIKAKWpYBUzjmkKoLGl6D1gYb/hmhVevQlbrn6GEbD9/wRB9Loa3+fIGNibUM3xo/vEM40vQ1Ts spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0638068EFA850328793E55F6B67C0MWHPR21MB0638namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 162d5402-919d-46dd-28fa-08d5d30cca67 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2018 22:10:23.0959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0783 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 22:10:28 -0000 --_000_MWHPR21MB0638068EFA850328793E55F6B67C0MWHPR21MB0638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBhcyB3ZWxsIHNpbmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBlciBwYWNrZXQgcHJv Y2Vzc2luZyBvdmVyaGVhZC4gQUNLcyBhcmUgZ29pbmcgdG8gYmUgdGhlIHNlY29uZCBtb3N0IGNv bW1vbiBmcmFtZSB0eXBlIHNvIG5vIG9iamVjdGlvbnMgdG8gc3BlY2lhbCBjYXNpbmcuDQoNCkZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlj IFJlc2NvcmxhDQpTZW50OiBGcmlkYXksIEp1bmUgMTUsIDIwMTggOToxMSBBTQ0KVG86IERldmFs LCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmku aWV0ZkBnbWFpbC5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBy b3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KDQpJIGFn cmVlIHdpdGggTWFuYXNpIGhlcmUuIFRoaXMgY2hhbmdlIHdvdWxkIGFsbG93IGFjayBmcmFtZSBw YXJzaW5nIHRvIGJlIG1vcmUgc2VsZi1jb250YWluZWQsIHdoaWNoIGlzIGFuIGFkdmFudGFnZSBm b3IgdGhlIHBhcnNlciBhbmQgYWxzbyBwb3RlbnRpYWxseSBmb3IgcGFyYWxsZWxpc20gKGJlY2F1 c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhlIGZyYW1lIGFuZCB0aGVuIHByb2Nlc3MgaXQgaW4g cGFyYWxsZWwpLg0KDQotRWtyDQoNCg0KT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgNToyMiBQTSwg RGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFs QGludGVsLmNvbT4+IHdyb3RlOg0KSW4gZ2VuZXJhbCwgdmFyaW50cyByZXF1aXJlIHNvbWUgc3Bl Y2lmaWMgbG9naWMgZm9yIHBhcnNpbmcuIFRvIHNraXAgb3ZlciBhbnkgaGVhZGVyLCBJIGhhdmUg dG8gcmVhZCBldmVyeSBzaW5nbGUgdmFyaW50LiBBcyB0aGUgY29kZSBzZWVzIFN0cmVhbSBhbmQg QUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiAgVGhlIFN0cmVh bSBmcmFtZSBoYXMgYSBsZW5ndGggaW4gaXRzIHRoaXJkIGZpZWxkLg0KDQpBQ0sgcGFyc2luZywg aG93ZXZlciwgbmVlZHMgNiArIDIqbnVtX2Jsb2NrcyByZWFkcyB0byBpZGVudGlmeSBsZW5ndGgu IFRoZXJlIGFyZSB0d28gcmVhZHMgZWFjaCBmb3Ig4oCYbGFyZ2VzdCBhY2tub3dsZWRnZWTigJks IOKAmEFDSyBkZWxheeKAmSBhbmQg4oCYQUNLIGJsb2NrIGNvdW504oCZLiBUaGUgcGFpbiBwb2lu dCBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIGN5Y2xlcyBwYXJzZSBhbiBBQ0suIElmIEkgYW0gcHJv Y2Vzc2luZyAxME0gcHBzLCB3aGVyZSAxMCUgLSAzMCUgb2YgdGhlIHBhY2tldHMgaGF2ZSBhIHBp Z2d5YmFja2VkIEFDSywgdGhlc2UgY3ljbGVzIGJlY29tZXMgYSBzaWduaWZpY2FudCBib3R0bGVu ZWNrLg0KDQpUaGFua3MsDQpNYW5hc2kNCg0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLi5vcmc+XSBPbiBCZWhhbGYg T2YgSmFuYSBJeWVuZ2FyDQpTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTQ0KVG86 IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZh bEBpbnRlbC5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0 aCBBQ0sgbGVuZ3RoDQoNCllvdSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBoYXZlIHRoZSBh YmlsaXR5IHRvIHNraXAgYW4gQUNLIGZyYW1lLCBhbmQgdGhpcyBjcmVwdCBpbiB3aGVuIHdlIG1v dmVkIHRvIHZhcmludHMuDQpJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFs bHkgdHJ1ZSBvZiBtb3N0IGZyYW1lcyBub3QganVzdCBBQ0tzLCBzaW5jZSBpZHMsIHBhY2tldCBu dW1iZXJzLCBhbmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzIGFyZSBub3cgYWxsIHZhcmludHMuIFRv IHNraXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkcyBp biB0aG9zZSBmcmFtZXMuIElmIHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNraXAgdmFy aW50cywgdGhlbiBza2lwcGluZyB0aGUgYWNrIGJsb2NrIHNlY3Rpb24gaXMgbWVyZWx5IHJlcGVh dGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2srMSkgdGltZXMuIERvIHlvdSBzZWUgc3Bl Y2lmaWMgdmFsdWUgaW4gc2tpcHBpbmcgQUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhlciBjb250cm9s IGZyYW1lcz8NCg0KDQpPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRyaSBUaWto b25vdiA8ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPG1haWx0bzpkdGlraG9ub3ZAbGl0ZXNw ZWVkdGVjaC5jb20+PiB3cm90ZToNCk9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDAzOjMzOjM1UE0g KzAwMDAsIERldmFsLCBNYW5hc2kgd3JvdGU6DQo+IC0gICAgICAgIE1vdmluZyB0aGUgQUNLIGxl bmd0aCB0byB0aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3MgdGhlDQo+ICAgICAgICAgIGZsZXhp YmlsaXR5IG9mIGVpdGhlciByZWFkaW5nIHRoZSBlbnRpcmUgQUNLIG9yIHJlYWRpbmcgdGhlDQo+ ICAgICAgICAgIGZpcnN0IDE2IGJpdHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4gVGhp cyBpcyBhIHVzZWZ1bA0KPiAgICAgICAgICBmZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sg cHJvY2Vzc2luZyBpcyBzcGxpdCBpbnRvDQo+ICAgICAgICAgIG11bHRpcGxlIGxheWVycy4gRGVw ZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3IgdGhpcyBpcyBydW4gb24sDQo+ICAgICAgICAgIHRoZXJl IGFyZSBkaWZmZXJlbnQgYWR2YW50YWdlcyAtDQoNCkp1c3QgYSBub3RlLiAgSW4gbXkgZXhwZXJp ZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWUgaXMNCm5lZ2xpZ2libGUgY29t cGFyZWQgdG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQgaXMsDQpw b2tpbmcgYXQgdmFyaW91cyBtZW1vcnkgbG9jYXRpb25zIHRvIGRpc2NhcmQgbmV3bHkgQUNLZWQg cGFja2V0cy4NCg0KICAtIERtaXRyaS4NCg0K --_000_MWHPR21MB0638068EFA850328793E55F6B67C0MWHPR21MB0638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIGFzIHdl bGwgc2luY2UgdGhpcyBjYW4gaGVscCByZWR1Y2UgcGVyIHBhY2tldCBwcm9jZXNzaW5nIG92ZXJo ZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9uIGZyYW1lIHR5 cGUgc28gbm8gb2JqZWN0aW9ucyB0byBzcGVjaWFsIGNhc2luZy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZg0KPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdW5lIDE1LCAyMDE4IDk6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IERldmFsLCBNYW5hc2kgJmx0 O21hbmFzaS5kZXZhbEBpbnRlbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKYW5hIEl5ZW5nYXIg Jmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBj b3VudCB3aXRoIEFDSyBsZW5ndGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHdpdGggTWFuYXNpIGhlcmUuIFRoaXMgY2hhbmdlIHdvdWxkIGFsbG93IGFjayBm cmFtZSBwYXJzaW5nIHRvIGJlIG1vcmUgc2VsZi1jb250YWluZWQsIHdoaWNoIGlzIGFuIGFkdmFu dGFnZSBmb3IgdGhlIHBhcnNlciBhbmQgYWxzbyBwb3RlbnRpYWxseSBmb3IgcGFyYWxsZWxpc20g KGJlY2F1c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhlIGZyYW1lIGFuZCB0aGVuIHByb2Nlc3Mg aXQgaW4gcGFyYWxsZWwpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMTEsIDIwMTggYXQgNToyMiBQTSwgRGV2YWws IE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5JbiBnZW5lcmFsLCB2YXJpbnRzIHJlcXVpcmUg c29tZSBzcGVjaWZpYyBsb2dpYyBmb3IgcGFyc2luZy4gVG8gc2tpcCBvdmVyIGFueSBoZWFkZXIs IEkgaGF2ZSB0byByZWFkIGV2ZXJ5IHNpbmdsZSB2YXJpbnQuIEFzIHRoZSBjb2RlIHNlZXMgU3Ry ZWFtIGFuZA0KIEFDSyBoZWFkZXJzIG1vc3QgZnJlcXVlbnRseSwgdGhhdCBpcyBteSBmb2N1cy4m bmJzcDsgVGhlIFN0cmVhbSBmcmFtZSBoYXMgYSBsZW5ndGggaW4gaXRzIHRoaXJkIGZpZWxkLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNEU3OSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+QUNLIHBhcnNpbmcsIGhv d2V2ZXIsIG5lZWRzIDYgJiM0MzsgMipudW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5IGxlbmd0 aC4gVGhlcmUgYXJlIHR3byByZWFkcyBlYWNoIGZvciDigJhsYXJnZXN0IGFja25vd2xlZGdlZOKA mSwg4oCYQUNLIGRlbGF54oCZIGFuZCDigJhBQ0sgYmxvY2sNCiBjb3VudOKAmS4gVGhlIHBhaW4g cG9pbnQgaXMgdGhlIHRvdGFsIG51bWJlciBvZiBjeWNsZXMgcGFyc2UgYW4gQUNLLiBJZiBJIGFt IHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBwYWNrZXRzIGhhdmUg YSBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQgYm90 dGxlbmVjay4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjRFNzkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjRFNzkiPlRoYW5r cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0RTc5Ij5NYW5hc2k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIG5hbWU9Im1fODg0MTQ0NTU3ODExNDI5MzIyX19NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fODg0MTQ0NTU3ODExNDI5MzIyX19f X19fcmVwbHlzZXBhcmF0b3IiPjwvYT48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJeWVuZ2FyPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxMSwgMjAxOCAzOjExIFBNPGJyPg0KPGI+VG86PC9i PiBEZXZhbCwgTWFuYXNpICZsdDs8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+Jmd0OzsgUVVJQyBX RyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWlj QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByb3Bvc2FsIHRvIHJl cGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91J3JlIHJpZ2h0IHRoYXQgd2Ugbm8gbG9uZ2VyIGhh dmUgdGhlIGFiaWxpdHkgdG8gc2tpcCBhbiBBQ0sgZnJhbWUsIGFuZCB0aGlzIGNyZXB0IGluIHdo ZW4gd2UgbW92ZWQgdG8gdmFyaW50cy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBiZWxpZXZlIHlvdXIgcHJvYmxlbSB0aG91Z2ggaXMgZ2VuZXJhbGx5 IHRydWUgb2YgbW9zdCBmcmFtZXMgbm90IGp1c3QgQUNLcywgc2luY2UgaWRzLCBwYWNrZXQgbnVt YmVycywgYW5kIG51bWJlcnMgaW4gYWxsIGZyYW1lcyBhcmUgbm93IGFsbCB2YXJpbnRzLiBUbyBz a2lwIGFueSBmcmFtZSwgeW91J2xsDQogbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkcyBp biB0aG9zZSBmcmFtZXMuIElmIHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNraXAgdmFy aW50cywgdGhlbiBza2lwcGluZyB0aGUgYWNrIGJsb2NrIHNlY3Rpb24gaXMgbWVyZWx5IHJlcGVh dGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2smIzQzOzEpIHRpbWVzLiBEbyB5b3Ugc2Vl IHNwZWNpZmljIHZhbHVlIGluIHNraXBwaW5nIEFDSyBmcmFtZXMgb3ZlciB0aGUgb3RoZXIgY29u dHJvbA0KIGZyYW1lcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRy aSBUaWtob25vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gTW9uLCBKdW4gMTEsIDIw MTggYXQgMDM6MzM6MzVQTSAmIzQzOzAwMDAsIERldmFsLCBNYW5hc2kgd3JvdGU6PGJyPg0KJmd0 OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1vdmluZyB0aGUgQUNLIGxlbmd0aCB0byB0 aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3MgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZmxleGliaWxpdHkgb2YgZWl0aGVyIHJlYWRpbmcgdGhlIGVudGly ZSBBQ0sgb3IgcmVhZGluZyB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBmaXJzdCAxNiBiaXRzIGFuZCBza2lwcGluZyBvdmVyIHRoZSBsZW5ndGguIFRoaXMg aXMgYSB1c2VmdWw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBm ZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sgcHJvY2Vzc2luZyBpcyBzcGxpdCBpbnRvPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXVsdGlwbGUgbGF5ZXJz LiBEZXBlbmRpbmcgb24gdGhlIHByb2Nlc3NvciB0aGlzIGlzIHJ1biBvbiw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVyZSBhcmUgZGlmZmVyZW50IGFkdmFu dGFnZXMgLTxicj4NCjxicj4NCkp1c3QgYSBub3RlLiZuYnNwOyBJbiBteSBleHBlcmllbmNlLCB0 aGUgY29zdCBvZiBwYXJzaW5nIGFuIEFDSyBmcmFtZSBpczxicj4NCm5lZ2xpZ2libGUgY29tcGFy ZWQgdG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQgaXMsPGJyPg0K cG9raW5nIGF0IHZhcmlvdXMgbWVtb3J5IGxvY2F0aW9ucyB0byBkaXNjYXJkIG5ld2x5IEFDS2Vk IHBhY2tldHMuPGJyPg0KPGJyPg0KJm5ic3A7IC0gRG1pdHJpLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0638068EFA850328793E55F6B67C0MWHPR21MB0638namp_-- From nobody Fri Jun 15 15:50:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D555C130DFC for ; Fri, 15 Jun 2018 15:50:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aU0fcraCC5co for ; Fri, 15 Jun 2018 15:50:43 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 30C1112D949 for ; Fri, 15 Jun 2018 15:50:43 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 16-v6so4799858itl.5 for ; Fri, 15 Jun 2018 15:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nT0seu5GFrB/gmQKaTazEr4A95RvZPX7ANfHTmGbWqw=; b=gOSj/bfxJEcRykCr3V46uN3hk+Jp8dSVvDw0g8FOq2jLP1GohYGOkHa6mO2Wty1s87 aC6NBs6ge7OoGdWx32gPGfZ0uDtYsmJap2bYfwr8e8YfigXiDamxjVkkC+WaNK2JqVSI zNKOUimAH6cTzMepTAVuqciqAFB5CAnHCY9sDrA839bfcV0NtKkHk9mUvlNgK8UJ/Z1E FBYgWDi7XiECdXSSg1PC56/+nadMivNliHSOlNXPk0gPG7RK+BZuZvVmSu1q3ASZk+OL SGRWU8kPvfGbpdrTyltfbOAqisiE3RbV2rsMdEueN0lS48JHbK6+9GMbDonF9vU/990R DtQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nT0seu5GFrB/gmQKaTazEr4A95RvZPX7ANfHTmGbWqw=; b=IWdPSrlq8zTw4UNWUTFEcbkfVYaRbJ/VO0cVU7ZvxwJhim8mAv0RzYO8oYJ5NmEWto baOwaHZFlcH7FKfnvQi/xm/1rKvbfiCQ6AZKC9BWdOzGuZxPO9rJNl/RU4Y5RiiihuWy 2K3no9yI4Hw6y/vUz/SHnfzKQYb2UbkwK2JwnNmw3ypuQggYLxKRQRUZIQFh27S5rCOx 8wVMdfywEsrtn5WhsRxCTzdTfygmgFIxXj7kTq3r8RwqtF03/2t2OtKNZiCT1H008NpC A0YRHfYu0mLOcgO7QFAD5crMTEFPd1uTJveMyFVaU84lxnlQL4igQOlkGiUEL1R9en79 eCxg== X-Gm-Message-State: APt69E2ZC9gdloL9xy7yTaQXW1lFK99S25ynxmirzz7lGxjIYsLaUPfF xkkK7vyH71ZH5V/AcjxX8kwse0/cTBlQ8OCNMbM= X-Google-Smtp-Source: ADUXVKJsx8MICCFZDAXlFThEtRmYketdZj87zf4ZPcMgWtwNcR+3WqLbf/xTS91qkNg9FtlKwW2NJV+5J8mjmpJp+C8= X-Received: by 2002:a24:1643:: with SMTP id a64-v6mr3041485ita.101.1529103042284; Fri, 15 Jun 2018 15:50:42 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Jana Iyengar Date: Fri, 15 Jun 2018 15:50:31 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Praveen Balasubramanian Cc: Eric Rescorla , "Deval, Manasi" , QUIC WG Content-Type: multipart/alternative; boundary="000000000000a91290056eb60b52" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 22:50:47 -0000 --000000000000a91290056eb60b52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have a strong opinion on this. I'm certainly not opposed to it. Does anyone have a strong opposition? On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian wrote: > I agree as well since this can help reduce per packet processing overhead= . > ACKs are going to be the second most common frame type so no objections t= o > special casing. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Friday, June 15, 2018 9:11 AM > *To:* Deval, Manasi > *Cc:* Jana Iyengar ; QUIC WG > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > I agree with Manasi here. This change would allow ack frame parsing to be > more self-contained, which is an advantage for the parser and also > potentially for parallelism (because you can quickly find the frame and > then process it in parallel). > > > > -Ekr > > > > > > On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > wrote: > > In general, varints require some specific logic for parsing. To skip over > any header, I have to read every single varint. As the code sees Stream a= nd > ACK headers most frequently, that is my focus. The Stream frame has a > length in its third field. > > > > ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. > There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2= =80=98ACK delay=E2=80=99 and =E2=80=98ACK > block count=E2=80=99. The pain point is the total number of cycles parse = an ACK. If > I am processing 10M pps, where 10% - 30% of the packets have a piggybacke= d > ACK, these cycles becomes a significant bottleneck. > > > > Thanks, > > Manasi > > > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Jana Iyengar > *Sent:* Monday, June 11, 2018 3:11 PM > *To:* Deval, Manasi ; QUIC WG > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > You're right that we no longer have the ability to skip an ACK frame, and > this crept in when we moved to varints. > > I believe your problem though is generally true of most frames not just > ACKs, since ids, packet numbers, and numbers in all frames are now all > varints. To skip any frame, you'll need to parse the varint fields in tho= se > frames. If you have logic to process and skip varints, then skipping the > ack block section is merely repeating this operation (2*num_block+1) time= s. > Do you see specific value in skipping ACK frames over the other control > frames? > > > > > > On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > > On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > > - Moving the ACK length to the front of the ACK allows the > > flexibility of either reading the entire ACK or reading the > > first 16 bits and skipping over the length. This is a useful > > feature for the case where ACK processing is split into > > multiple layers. Depending on the processor this is run on, > > there are different advantages - > > Just a note. In my experience, the cost of parsing an ACK frame is > negligible compared to the cost of processing an ACK frame: that is, > poking at various memory locations to discard newly ACKed packets. > > - Dmitri. > > > --000000000000a91290056eb60b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have a strong opinion on this. I'm certain= ly not opposed to it.
Does anyone have a strong opposition?

On Fri, Jun 15, 2018 at= 3:10 PM Praveen Balasubramanian <pravb@microsoft.com> wrote:

I agree as well since this can help reduce per packe= t processing overhead. ACKs are going to be the second most common frame ty= pe so no objections to special casing.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, June 15, 2018 9:11 AM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

I agree with Manasi here. This change would allow ac= k frame parsing to be more self-contained, which is an advantage for the pa= rser and also potentially for parallelism (because you can quickly find the= frame and then process it in parallel).

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <<= a href=3D"mailto:manasi.deval@intel.com" target=3D"_blank">manasi.deval@int= el.com> wrote:

In general, varints re= quire some specific logic for parsing. To skip over any header, I have to r= ead every single varint. As the code sees Stream and ACK headers most frequently, that is my focus.=C2=A0 The Stream frame has = a length in its third field.

=C2=A0

ACK parsing, however, = needs 6 + 2*num_blocks reads to identify length. There are two reads each f= or =E2=80=98largest acknowledged=E2=80=99, =E2=80=98ACK delay=E2=80=99 and = =E2=80=98ACK block count=E2=80=99. The pain point is the total number of cycles parse an ACK.= If I am processing 10M pps, where 10% - 30% of the packets have a piggybac= ked ACK, these cycles becomes a significant bottleneck.

=C2=A0

Thanks,<= u>

Manasi

=C2=A0

=C2=A0

=C2=A0<= u>

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Monday, June 11, 2018 3:11 PM
To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG <quic@ietf.org>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

You're right that= we no longer have the ability to skip an ACK frame, and this crept in when= we moved to varints.

I believe your problem though is generally true of m= ost frames not just ACKs, since ids, packet numbers, and numbers in all fra= mes are now all varints. To skip any frame, you'll need to parse the varint fields in those frames. If you have logic to proc= ess and skip varints, then skipping the ack block section is merely repeati= ng this operation (2*num_block+1) times. Do you see specific value in skipp= ing ACK frames over the other control frames?

=C2=A0

=C2=A0

On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <= dtikhonov@= litespeedtech.com> wrote:

On Mon, Jun 11, 2018 = at 03:33:35PM +0000, Deval, Manasi wrote:
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the front of the= ACK allows the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either reading the en= tire ACK or reading the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping over the = length. This is a useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where ACK proce= ssing is split into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending on the pr= ocessor this is run on,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advantages -

Just a note.=C2=A0 In my experience, the cost of parsing an ACK frame is negligible compared to the cost of processing an ACK frame: that is,
poking at various memory locations to discard newly ACKed packets.

=C2=A0 - Dmitri.

=C2=A0

--000000000000a91290056eb60b52-- From nobody Fri Jun 15 16:19:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA554130E9C for ; Fri, 15 Jun 2018 16:19:28 -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 AbBZZHr6zIw3 for ; Fri, 15 Jun 2018 16:19:24 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 70827130E90 for ; Fri, 15 Jun 2018 16:19:24 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id 101-v6so12739358oth.4 for ; Fri, 15 Jun 2018 16:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SRM+0FIOKqHXwKFaF/tpdiQF1W3N+eZhlZ/H+fm60KI=; b=m+3z4o6ae2n15Arq7hBzoxsMjeKOTfzIvQVtmNhQX7H2JfvjGZtyl4oqQyXnByf974 /RqZ2zGTKlSq7kv1Yck35Qq2QDjClSbCvUUrUXaYWMOkfZJD7uqJrLRbnRHpqPv5vDgH uBUeVxIKxujvz8wTRDw9t2A/TQ+eXVmgWAyIZBkiMfVvRaPZn2NwKMe9I4O2uthW596d //lP5kYTexaTpqxPhoTL72lt1H5abTn0yuscbubXXPSUwtUYRANs7j+K4/QbF146QiKT NCyMFHNQnuFR9E/0LcqtMjhW9qHxw7S+jqOuhaXp9586mJjwFaqdCSqzXN791/Vjfics K51A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SRM+0FIOKqHXwKFaF/tpdiQF1W3N+eZhlZ/H+fm60KI=; b=NFJmb0y6rh2XamswJuwLvPWaMkIaumayTHyBLWGaHokoZHrEcKbzzANACJa479zC4S gk9nUMASNd3MQ5xS4laJxkEc3UvaX/n6HArMHgqJvy0htiVAQ4dn1mU9GHuBHp2uO7mr DqSRnHxTC4TwGC3hSl04dDjjtB5U0LQLwFN7/3pxT6+74aqnoYQpkkEtAVf5nj1wcxoh tXC10WormUdE08USKmeNeCHos1VtT8BD750rPx+s8OsK66hKelsscm8G8BqHNNOCqTku il2ts81ORUNUL/qLBR+VcjU1FEkvd0tFCx4QoD6tuM9a0UupirKp1NSo59OKTXE8tLq0 YO/Q== X-Gm-Message-State: APt69E3IJBe5ELw5JYoeZj7ioc1FTcHQmbMB3MBbzcJVlXvr56+cVZWq zn9w/rvhtXsFas6hl7rnLbv6otwEuRlGmqMBUbs= X-Google-Smtp-Source: ADUXVKLfp0MlkkrM4le0bb/T4z+DrtqghJXzX0fYISYnAPe7lCtlwzQmFfewdIBnqUbwf2gUcT3gnFl73dxTjNN+nS4= X-Received: by 2002:a9d:3666:: with SMTP id w93-v6mr2201519otb.394.1529104763660; Fri, 15 Jun 2018 16:19:23 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Martin Thomson Date: Fri, 15 Jun 2018 16:19:13 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Jana Iyengar Cc: Praveen Balasubramanian , Eric Rescorla , QUIC WG , "Deval, Manasi" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 23:19:38 -0000 When we discussed this before, some people observed that this creates a need to encode in two passes. That's the trade-off here. (Not expressing an opinion.) On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrote: > > I don't have a strong opinion on this. I'm certainly not opposed to it. > Does anyone have a strong opposition? > > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian wrote: >> >> I agree as well since this can help reduce per packet processing overhea= d. ACKs are going to be the second most common frame type so no objections = to special casing. >> >> >> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Friday, June 15, 2018 9:11 AM >> To: Deval, Manasi >> Cc: Jana Iyengar ; QUIC WG >> Subject: Re: Proposal to replace ACK block count with ACK length >> >> >> >> I agree with Manasi here. This change would allow ack frame parsing to b= e more self-contained, which is an advantage for the parser and also potent= ially for parallelism (because you can quickly find the frame and then proc= ess it in parallel). >> >> >> >> -Ekr >> >> >> >> >> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi = wrote: >> >> In general, varints require some specific logic for parsing. To skip ove= r any header, I have to read every single varint. As the code sees Stream a= nd ACK headers most frequently, that is my focus. The Stream frame has a l= ength in its third field. >> >> >> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. T= here are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2=80= =98ACK delay=E2=80=99 and =E2=80=98ACK block count=E2=80=99. The pain point= is the total number of cycles parse an ACK. If I am processing 10M pps, wh= ere 10% - 30% of the packets have a piggybacked ACK, these cycles becomes a= significant bottleneck. >> >> >> >> Thanks, >> >> Manasi >> >> >> >> >> >> >> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >> Sent: Monday, June 11, 2018 3:11 PM >> To: Deval, Manasi ; QUIC WG >> Subject: Re: Proposal to replace ACK block count with ACK length >> >> >> >> You're right that we no longer have the ability to skip an ACK frame, an= d this crept in when we moved to varints. >> >> I believe your problem though is generally true of most frames not just = ACKs, since ids, packet numbers, and numbers in all frames are now all vari= nts. To skip any frame, you'll need to parse the varint fields in those fra= mes. If you have logic to process and skip varints, then skipping the ack b= lock section is merely repeating this operation (2*num_block+1) times. Do y= ou see specific value in skipping ACK frames over the other control frames? >> >> >> >> >> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov wrote: >> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >> > - Moving the ACK length to the front of the ACK allows the >> > flexibility of either reading the entire ACK or reading the >> > first 16 bits and skipping over the length. This is a useful >> > feature for the case where ACK processing is split into >> > multiple layers. Depending on the processor this is run on, >> > there are different advantages - >> >> Just a note. In my experience, the cost of parsing an ACK frame is >> negligible compared to the cost of processing an ACK frame: that is, >> poking at various memory locations to discard newly ACKed packets. >> >> - Dmitri. >> >> From nobody Fri Jun 15 18:46:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA84130DC8 for ; Fri, 15 Jun 2018 18:46:20 -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 tOgeilMBnUd6 for ; Fri, 15 Jun 2018 18:46:18 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 EA64E1277CC for ; Fri, 15 Jun 2018 18:46:17 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g7-v6so12284806ioh.11 for ; Fri, 15 Jun 2018 18:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SPCU/tPKd38xYb+RD67d0EAEf9LuHMOFf9III7UHb9k=; b=bYN8SxVMgUTdRofcXWt4aG65hkPy3EYsDX95MrmHlJZeZlNZBvhi49mMssF/rMqTMN 1p26xTBiRAzASfBxlskTai9RJsRMwy7y228R2y5+rXD7DgYzY7aTYVfuCaCtgYM45e7l HfdSJu6NqqthC0gbADmhlPpXxWMMt0hmInWYZDKHbeO5PZ2tcERcKFsCvKBEK9iaKWu0 jCWOMHNjIa8LyA2Bjw5HBAtwPYGTm4Y5w1MI7Oun+dxzE6PIbKDMUKgOa9vuf9ybeDUD TZUHqrvKfn1d6nt8dSSj4UxeHyQz1F3efLWxcm9q3qMy+PNj91YAo/veXuAHcZe5b/tt qZEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SPCU/tPKd38xYb+RD67d0EAEf9LuHMOFf9III7UHb9k=; b=o9qEDaufDKJCkaWbWLTpLPjvrP5t4foE3BDS9h78HUJpR41qVxTN3gEQ2m1ImouZ8y Gr+XGEB9zXnHKTnzPw0AIMcGvCCaEK39qUKrKg7VhMvbkUj9Y4V68lfV6doDsmthco7z 5OapMEB82FA5dP41sH+L0bj+oMLz+07SFGwdoBqoaHcNmdQVJIhGmxpLEgPKRAKRawFz KLeWcGu4wNs6F2BBeDMqP2gvbjjNgtonE/IggvIWmmmyaGZqtGiNSxPQmo/6g2Vl47n6 PtX1w+vTQZSNAPz4zcPk0G1lI5I50tl2A3HharWgCSxQc+01XJWpSeI5mDPToJaL2Wgp F5Hw== X-Gm-Message-State: APt69E3bXIfH9DQNhmFObZPj67GcNO1pGC/PsDvzWk8CmYbFcplSEksh 2m5VIeYCfKyp+wVUEyU3PbgWBwEXOzyL3Dqrbxc= X-Google-Smtp-Source: ADUXVKJiTkfE8GsNG6jsiM2QUJtEQB9jc9sPcK5mNkaAU4jGOq7Oze8aFhBtUdkHEquFSjvBaK5FiT3V0S97u+Mxyn8= X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr3270535ioh.235.1529113577014; Fri, 15 Jun 2018 18:46:17 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Marten Seemann Date: Sat, 16 Jun 2018 08:46:05 +0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Martin Thomson Cc: Jana Iyengar , Praveen Balasubramanian , Eric Rescorla , QUIC WG , "Deval, Manasi" Content-Type: multipart/alternative; boundary="000000000000944888056eb87f9d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 01:46:21 -0000 --000000000000944888056eb87f9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This proposal increases the size of the ACK frame by 1 byte in the common case (less than 63 ACK ranges), since the ACK length field here always consumes 2 bytes, whereas the ACK Block Count is a variable-length integer. Considering how much work we put into minimising the size of the frames, this feels like a step in the wrong direction. Regarding the processing cost, I agree with Dmitri. Handling an ACK frame requires looping over and making changes to a data structure that keeps track of sent packets. This is much more expensive than simply parsing a bunch of varints in the ACK frame. It seems unlikely that a multi-threaded packet parser would offer any real-world performance benefits. On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson wrote: > When we discussed this before, some people observed that this creates > a need to encode in two passes. That's the trade-off here. (Not > expressing an opinion.) > On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrote: > > > > I don't have a strong opinion on this. I'm certainly not opposed to it. > > Does anyone have a strong opposition? > > > > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > >> > >> I agree as well since this can help reduce per packet processing > overhead. ACKs are going to be the second most common frame type so no > objections to special casing. > >> > >> > >> > >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla > >> Sent: Friday, June 15, 2018 9:11 AM > >> To: Deval, Manasi > >> Cc: Jana Iyengar ; QUIC WG > >> Subject: Re: Proposal to replace ACK block count with ACK length > >> > >> > >> > >> I agree with Manasi here. This change would allow ack frame parsing to > be more self-contained, which is an advantage for the parser and also > potentially for parallelism (because you can quickly find the frame and > then process it in parallel). > >> > >> > >> > >> -Ekr > >> > >> > >> > >> > >> > >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > wrote: > >> > >> In general, varints require some specific logic for parsing. To skip > over any header, I have to read every single varint. As the code sees > Stream and ACK headers most frequently, that is my focus. The Stream fra= me > has a length in its third field. > >> > >> > >> > >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. > There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2= =80=98ACK delay=E2=80=99 and =E2=80=98ACK > block count=E2=80=99. The pain point is the total number of cycles parse = an ACK. If > I am processing 10M pps, where 10% - 30% of the packets have a piggybacke= d > ACK, these cycles becomes a significant bottleneck. > >> > >> > >> > >> Thanks, > >> > >> Manasi > >> > >> > >> > >> > >> > >> > >> > >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar > >> Sent: Monday, June 11, 2018 3:11 PM > >> To: Deval, Manasi ; QUIC WG > >> Subject: Re: Proposal to replace ACK block count with ACK length > >> > >> > >> > >> You're right that we no longer have the ability to skip an ACK frame, > and this crept in when we moved to varints. > >> > >> I believe your problem though is generally true of most frames not jus= t > ACKs, since ids, packet numbers, and numbers in all frames are now all > varints. To skip any frame, you'll need to parse the varint fields in tho= se > frames. If you have logic to process and skip varints, then skipping the > ack block section is merely repeating this operation (2*num_block+1) time= s. > Do you see specific value in skipping ACK frames over the other control > frames? > >> > >> > >> > >> > >> > >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > wrote: > >> > >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >> > - Moving the ACK length to the front of the ACK allows the > >> > flexibility of either reading the entire ACK or reading the > >> > first 16 bits and skipping over the length. This is a usefu= l > >> > feature for the case where ACK processing is split into > >> > multiple layers. Depending on the processor this is run on, > >> > there are different advantages - > >> > >> Just a note. In my experience, the cost of parsing an ACK frame is > >> negligible compared to the cost of processing an ACK frame: that is, > >> poking at various memory locations to discard newly ACKed packets. > >> > >> - Dmitri. > >> > >> > > --000000000000944888056eb87f9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal increases the size of the ACK frame by = 1 byte in the common case (less than 63 ACK ranges), since the ACK length f= ield here always consumes 2 bytes, whereas the ACK Block Count is a variabl= e-length integer. Considering how much work we put into minimising the size= of the frames, this feels like a step in the wrong direction.

Regarding the processing cost, I agree with=C2=A0Dmitri. Handli= ng an ACK frame requires looping over and making changes to a data structur= e that keeps track of sent packets. This is much more expensive than simply= parsing a bunch of varints in the ACK frame. It seems unlikely that a mult= i-threaded packet parser would offer any real-world performance benefits.
On Sat, Jun 16, 2018 at= 6:19 AM Martin Thomson <mar= tin.thomson@gmail.com> wrote:
jri.ietf@gmail.com> wrote:
>
> I don't have a strong opinion on this. I'm certainly not oppos= ed to it.
> Does anyone have a strong opposition?
>
> On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian <pravb@microsoft.com> = wrote:
>>
>> I agree as well since this can help reduce per packet processing o= verhead. ACKs are going to be the second most common frame type so no objec= tions to special casing.
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Friday, June 15, 2018 9:11 AM
>> To: Deval, Manasi <manasi.deval@intel.com>
>> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> I agree with Manasi here. This change would allow ack frame parsin= g to be more self-contained, which is an advantage for the parser and also = potentially for parallelism (because you can quickly find the frame and the= n process it in parallel).
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <manasi.deval@intel.com>= wrote:
>>
>> In general, varints require some specific logic for parsing. To sk= ip over any header, I have to read every single varint. As the code sees St= ream and ACK headers most frequently, that is my focus.=C2=A0 The Stream fr= ame has a length in its third field.
>>
>>
>>
>> ACK parsing, however, needs 6 + 2*num_blocks reads to identify len= gth. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, = =E2=80=98ACK delay=E2=80=99 and =E2=80=98ACK block count=E2=80=99. The pain= point is the total number of cycles parse an ACK. If I am processing 10M p= ps, where 10% - 30% of the packets have a piggybacked ACK, these cycles bec= omes a significant bottleneck.
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>>
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
>> Sent: Monday, June 11, 2018 3:11 PM
>> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> You're right that we no longer have the ability to skip an ACK= frame, and this crept in when we moved to varints.
>>
>> I believe your problem though is generally true of most frames not= just ACKs, since ids, packet numbers, and numbers in all frames are now al= l varints. To skip any frame, you'll need to parse the varint fields in= those frames. If you have logic to process and skip varints, then skipping= the ack block section is merely repeating this operation (2*num_block+1) t= imes. Do you see specific value in skipping ACK frames over the other contr= ol frames?
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <dtikhonov@lite= speedtech..com> wrote:
>>
>> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the fro= nt of the ACK allows the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either readi= ng the entire ACK or reading the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping = over the length. This is a useful
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where = ACK processing is split into
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending = on the processor this is run on,
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advanta= ges -
>>
>> Just a note.=C2=A0 In my experience, the cost of parsing an ACK fr= ame is
>> negligible compared to the cost of processing an ACK frame: that i= s,
>> poking at various memory locations to discard newly ACKed packets.=
>>
>>=C2=A0 =C2=A0- Dmitri.
>>
>>

--000000000000944888056eb87f9d-- From nobody Fri Jun 15 18:57:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9143130EB4 for ; Fri, 15 Jun 2018 18:57:17 -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 B0sx4AanLWJZ for ; Fri, 15 Jun 2018 18:57:15 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 D5C93130EA4 for ; Fri, 15 Jun 2018 18:57:15 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id a22-v6so5639172pfo.12 for ; Fri, 15 Jun 2018 18:57:15 -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=w1bZU0flOLMSWK9SvLgfkRvKFRpvORZXlNuJL1PDHuw=; b=E5S/BKRyutqEhGBW5jG1pYmmphGS9vo0PBQjtV4nM915M1VNSve82recY8+Uat9Zda 6wRgWwWzlYsWf4JnKX1l9mYsBvs9WrVyUyORmJjMaTqGGFVNHyQzQxeDp0ds7P/o6IwB 3r7xTtsmu7y2NYTwxxDTm3+Vk00nBehgyEDis8pFDtQydIpBd1RxB8oLxndB6mPt8MxB R/vUq78cjoj9me4LJbFh0cegfBxk/jcVIbpBmcMkC69aZSIju+VWgVHv+rfFnrg1pz1F XcWYW3BNa6biFtHmGI8GJ/21cwh4PlVHk68VHSupzOEHRCrs+8eELSG6Bb/LiwgaxXGA MOSg== 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=w1bZU0flOLMSWK9SvLgfkRvKFRpvORZXlNuJL1PDHuw=; b=uirpnX9ynQid4gyJQO2Ih+6Bn8/swEMlqMIX9bykkMSWrAA89SkdQv85WgvNXS1u2x q2i3F+xbLKUwbnQVuahn0ugQoES8fjldXUwU0+tkBwFlewNaC+qQXck7H4m0yY8ehgyN T53BFCFfy82Ro+oeCuyrm/Bnw8k3v5+6UVbQpAl06/5mC8/eoFUjGvUvTcbC/mTKGcKi QH5GbSINE1gwtjC1AHW60mFfAlPa1la69K8AHhqbCe7q2+0mTSSiHliobTc0cRcpfoOB bAeLngaFeB/3MyKmzQYeCGLfcXMEJl3zgqX8NN9byrN7UYVftZJs7eOYc1Edw0MXbOvj 390g== X-Gm-Message-State: APt69E0x+IqLLCDZebjX/dHilvHu9rZMt2Yt4/iHN4U4tLAJGSBh4nik SSlt6x53QzX9KxR1JmybDlkvm/ccwtcyZ5tmRNI= X-Google-Smtp-Source: ADUXVKILGc+y3PrxCt0lBCDvxAZAm4UnnZO9IQLKdiCXl1/dsmcO/BBtI4JWra4JTSc7a2qo9mkEYyUz7yVprvQY9b8= X-Received: by 2002:a63:ba02:: with SMTP id k2-v6mr3710096pgf.179.1529114234226; Fri, 15 Jun 2018 18:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 15 Jun 2018 18:57:13 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Kazuho Oku Date: Sat, 16 Jun 2018 10:57:13 +0900 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Martin Thomson Cc: Jana Iyengar , Praveen Balasubramanian , Eric Rescorla , QUIC WG , "Deval, Manasi" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 01:57:18 -0000 2018-06-16 8:19 GMT+09:00 Martin Thomson : > When we discussed this before, some people observed that this creates > a need to encode in two passes. That's the trade-off here. (Not > expressing an opinion.) I am not sure if we have that trade-off. ACK frame as currently defined needs to be generated in two-pass because the size of the ACK Block Count field depends on the number of blocks you would actually emit, unless the QUIC stack maintains the number of gaps in the ACK queue. And I think that the proposed change would be fine because it does not necessary increase the size of the ACK frame, if we remove ACK Block Count field in exchange. Instead of relying on the field, a receiver of the ACK frame can read blocks until it consumes the number of bytes specified by the length of the frame. > On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrote: >> >> I don't have a strong opinion on this. I'm certainly not opposed to it. >> Does anyone have a strong opposition? >> >> On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian wrote: >>> >>> I agree as well since this can help reduce per packet processing overhe= ad. ACKs are going to be the second most common frame type so no objections= to special casing. >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla >>> Sent: Friday, June 15, 2018 9:11 AM >>> To: Deval, Manasi >>> Cc: Jana Iyengar ; QUIC WG >>> Subject: Re: Proposal to replace ACK block count with ACK length >>> >>> >>> >>> I agree with Manasi here. This change would allow ack frame parsing to = be more self-contained, which is an advantage for the parser and also poten= tially for parallelism (because you can quickly find the frame and then pro= cess it in parallel). >>> >>> >>> >>> -Ekr >>> >>> >>> >>> >>> >>> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi = wrote: >>> >>> In general, varints require some specific logic for parsing. To skip ov= er any header, I have to read every single varint. As the code sees Stream = and ACK headers most frequently, that is my focus. The Stream frame has a = length in its third field. >>> >>> >>> >>> ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. = There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2=80= =98ACK delay=E2=80=99 and =E2=80=98ACK block count=E2=80=99. The pain point= is the total number of cycles parse an ACK. If I am processing 10M pps, wh= ere 10% - 30% of the packets have a piggybacked ACK, these cycles becomes a= significant bottleneck. >>> >>> >>> >>> Thanks, >>> >>> Manasi >>> >>> >>> >>> >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>> Sent: Monday, June 11, 2018 3:11 PM >>> To: Deval, Manasi ; QUIC WG >>> Subject: Re: Proposal to replace ACK block count with ACK length >>> >>> >>> >>> You're right that we no longer have the ability to skip an ACK frame, a= nd this crept in when we moved to varints. >>> >>> I believe your problem though is generally true of most frames not just= ACKs, since ids, packet numbers, and numbers in all frames are now all var= ints. To skip any frame, you'll need to parse the varint fields in those fr= ames. If you have logic to process and skip varints, then skipping the ack = block section is merely repeating this operation (2*num_block+1) times. Do = you see specific value in skipping ACK frames over the other control frames= ? >>> >>> >>> >>> >>> >>> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov wrote: >>> >>> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >>> > - Moving the ACK length to the front of the ACK allows the >>> > flexibility of either reading the entire ACK or reading the >>> > first 16 bits and skipping over the length. This is a useful >>> > feature for the case where ACK processing is split into >>> > multiple layers. Depending on the processor this is run on, >>> > there are different advantages - >>> >>> Just a note. In my experience, the cost of parsing an ACK frame is >>> negligible compared to the cost of processing an ACK frame: that is, >>> poking at various memory locations to discard newly ACKed packets. >>> >>> - Dmitri. >>> >>> > --=20 Kazuho Oku From nobody Sat Jun 16 00:10:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0281277C8 for ; Sat, 16 Jun 2018 00:10:56 -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, 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 mPYEffyucyrQ for ; Sat, 16 Jun 2018 00:10:54 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 342D9127332 for ; Sat, 16 Jun 2018 00:10:53 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fU5MH-0006I7-Tk for quic@ietf.org; Sat, 16 Jun 2018 09:10:51 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fU5MG-0000Ne-5D for quic@ietf.org; Sat, 16 Jun 2018 03:10:48 -0400 Received: (qmail 15944 invoked from network); 16 Jun 2018 07:10:45 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.47]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Jun 2018 07:10:45 -0000 To: quic@ietf.org References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Sat, 16 Jun 2018 00:10:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: Proposal to replace ACK block count with ACK length X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.31) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vOOrUoy/ENN9wEXCxlBful602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViHa/e3K90nxBwryqThD4UMc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBcfHbpla9upwqbpLVZbiC0R/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpV4YM2GxQgsSyTO9ao59sey2DGLD98yPuDnvUg58pX+/sR4Lqp1cBCw eRbCTodYMqmU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRhK7unSGReaJhoESbMmiSIuggKW28pboyZCmKkHUYXanSZh8rytDIY1gL Cllydatcj1WvR1o7bHgReqnxkLzf+HtB4/4Pbrz2QtFuyl+Sh6eSMv+rdVKXDLDaTBj+LzkUfqb5 R4VemuUI6bcEARsm0KnLtMabt6P+t78klMitoc+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 07:10:57 -0000 On 6/15/2018 6:57 PM, Kazuho Oku wrote: > And I think that the proposed change would be fine because it does not > necessary increase the size of the ACK frame, if we remove ACK Block > Count field in exchange. Ack block count is generally one byte, the length would have to be two bytes most of the time, especially if one wants to avoid 2 passes. So that's one extra byte. > Instead of relying on the field, a receiver of the ACK frame can read > blocks until it consumes the number of bytes specified by the length > of the frame. Modulo handling of ECN counters, of course. In the ECN proposal, we have three varints at the end of the ack frame, and that would make parsing a variable number of ack blocks more interesting. So if we take the length proposal, we have to make sure that the ECN counters  get moved before the ack blocks. -- Christian Huitema From nobody Sat Jun 16 01:01:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176AB130DD6 for ; Sat, 16 Jun 2018 01:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.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 28i7kZbkckzP for ; Sat, 16 Jun 2018 01:01:32 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35964130DCF for ; Sat, 16 Jun 2018 01:01:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,229,1526367600"; d="asc'?scan'208";a="260065545" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx142-out.netapp.com with ESMTP; 16 Jun 2018 01:01:31 -0700 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 16 Jun 2018 01:01:31 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Sat, 16 Jun 2018 01:01:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oHBG5XQCQXXfwTb9JbrwsLf1vXbp85bZUEl2cdax5pU=; b=AdsEDhXSA02KgHnLNpMsWxEg4WHIKWNRACBSyyTHwuOIwH3jhzi/JdE/MO81RSGnCTYLkO26ztoPDOjbDzu9nsU9j9GUdQSTqX1Pcxs5CWX6z9rp0qjRWiaL/9qdWriPMcbLk+75u4shZ01Ejnj5Sx/S7uyHHOaHHwP0XeDQ2OU= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1876.namprd06.prod.outlook.com (10.162.225.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Sat, 16 Jun 2018 08:01:30 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::a578:7832:9d1c:5e04]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::a578:7832:9d1c:5e04%3]) with mapi id 15.20.0863.016; Sat, 16 Jun 2018 08:01:29 +0000 From: "Eggert, Lars" To: Marten Seemann CC: Martin Thomson , Janardhan Iyengar , Praveen Balasubramanian , "Eric Rescorla" , QUIC WG , "Deval, Manasi" Subject: Re: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFON0uAAA2Oe4AABJAbAAC4BBWAAAAXlWAADdw6gAABAJmAAAUhF4AADRwwAA== Date: Sat, 16 Jun 2018 08:01:29 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:2a37:2e00:c5ef:8161:73ca:bd25] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1876; 7:l7zwMH8hIWVKtQs3BvX+WGmunCplwiOz1m+rredVPkc/CzmXWT43joZ55HOQwnlJQ//E5Sm+M9cXjxbPaKU6fvgYNjWUDDZ71sLK2VjSnspXoAbD3vQPrxREBb82YYrVSiErsWZmTdwm0xpb0bwFCm8gharLtGJslRPbCMTNlyk2vJK9s1UrzJGGaaP7vfgVoJfAxnwvJc14Et/VWypRVOkNz/kjenwPsy9tYsQLbFROQjmZXMh3GuSgr8nkhPzf x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f27a01a1-21a4-4f88-d976-08d5d35f5e21 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB1876; x-ms-traffictypediagnostic: BLUPR06MB1876: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BLUPR06MB1876; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1876; x-forefront-prvs: 0705EB1700 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(39380400002)(376002)(396003)(189003)(199004)(6506007)(97736004)(11346002)(86362001)(486006)(6246003)(82746002)(25786009)(36756003)(6916009)(2900100001)(53936002)(476003)(102836004)(53546011)(186003)(8666007)(6436002)(4326008)(2616005)(83716003)(5250100002)(6512007)(39060400002)(6486002)(478600001)(4001150100001)(46003)(446003)(316002)(54906003)(93886005)(14454004)(105586002)(1411001)(99936001)(5660300001)(81166006)(81156014)(33656002)(3660700001)(50226002)(57306001)(2906002)(229853002)(8936002)(76176011)(8676002)(6116002)(68736007)(7736002)(3280700002)(305945005)(99286004)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1876; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fdE+qRcC4Qe2yokYcPcb7Qs9ZsPqo5/gybRnmqG+/lNerggu02e74ZUtZCMIjseiIwgLsu+xPrZCMVPtBhc7VnPW+Usa6o32iyDJme3hgyiXDSVPJfT7+ZLyVZblNwzcEDTDqpmKlLK7phTC2vShgbOFAlBUkB1ccqGtGtAruDmieRpM32zoiFjBlYjYy6BY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_26498A4A-D00F-46AB-8212-0F2EAF224BC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f27a01a1-21a4-4f88-d976-08d5d35f5e21 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2018 08:01:29.6452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1876 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 08:01:35 -0000 --Apple-Mail=_26498A4A-D00F-46AB-8212-0F2EAF224BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2018-6-16, at 3:46, Marten Seemann wrote: > Regarding the processing cost, I agree with Dmitri. Handling an ACK = frame requires looping over and making changes to a data structure that = keeps track of sent packets. This is much more expensive than simply = parsing a bunch of varints in the ACK frame. It seems unlikely that a = multi-threaded packet parser would offer any real-world performance = benefits. +1 Lars --Apple-Mail=_26498A4A-D00F-46AB-8212-0F2EAF224BC9 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlskw9gACgkQVLXDCb9w wVdB1RAAtpvl0EvKvxkmLKwFr8qCzWo1QmSziYkbAO+4iUKNVKXQQnXdmwSHpaC0 U8lPQpTfNTmC11jT9CNnAFRzL4XpRCau23icvlkiD+cC3PCC1QoklXP89H6d6zrs LqoBqM8gVMwRfPFzglrLlQwThlMK31zTLEvurik9Yenin3ghbtGc/Teg7EHsVA+w Be0uHcmInYcWJKjZdt0DQTh0eyBnOAmhme/URo+Zx1uKRMvy2JshOvR4dYmgZuOT S8FYR+JTgkNyed702eiC7BwZr+UB8Cv6GlZO+6ATcZpbVbKP/0aeap4v4wFeEFuC 98CYIgNvkQgcSbCjN6NhXgnTQajEzbQWRl2VqT+VmmHF6EM1ugtfXsNdmcF9PPs+ Y0TA6iKxUBZNezV3uJwddfkgU0llZDA9k9F3ajrEmpiZuiklkgaQdoDXHS0Ihs4A ibY4D695Hr1PQLNM+YCNygBX9aHdeYSWnu3Z9kc1t1kA+ezF/30kbXp6UpzShlil tJAKvc4EWFf/UQKuSQeo2tmjnb3bVqqzc/yXI56Lt8txRwVbCSq/OAD6B8VyRWbP hJszkzuTXOadc56ZauwStx0JFpQvEWhRlNAbBaDXx+QvGXd8b6kcA6p6CBBi10ME y7VXSHWLIEkYj3uX2O5ilMLRySjbALh7qA2CtZmLrdX+p4Ek/mk= =upOu -----END PGP SIGNATURE----- --Apple-Mail=_26498A4A-D00F-46AB-8212-0F2EAF224BC9-- From nobody Sat Jun 16 02:26:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DBA130FF0 for ; Sat, 16 Jun 2018 02:26: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 Ti3Hc5As_6M1 for ; Sat, 16 Jun 2018 02:25:59 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 DA93C130FEE for ; Sat, 16 Jun 2018 02:25:59 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id t12-v6so6539664plo.7 for ; Sat, 16 Jun 2018 02:25:59 -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=PKDAI9VQydw3kLCoZOwCPTJsPwxULyEVB2eg+wi+/nE=; b=SgEPxKqB5jGhayI3jvIyl9SWcsNNpFv3KDLIl9/lsRjik71KoSp9wPTq+O4jAmNCIe Xz/9xUsne9+dQDl3aU4Ex6ko+TtHPNGC3OyUsCvmyoBpmqem0OeuvURCQVEnBoZfY6Y5 txiwDGKToisjoUdSVBrwvQvreGF9qaRHUJdrf1bUN/zpS53JD/7QxriV4sxr7u+BzunV tgCm8tfccMuzszYbwJz9yZ34++Bp4vJ/fCpFiihxcxB9iN8hvlhaAEZF3Roq7ogoTpXd TYRTvHH1p8MSwWJWoYLYqtQU3sAeEtqIQP2Z/phH4zu7OVms9QhQ9WFWRDrx4zZ8Yqn7 uSKw== 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=PKDAI9VQydw3kLCoZOwCPTJsPwxULyEVB2eg+wi+/nE=; b=CwNnxjWYhfeNcYuGvh8/nAdltbcYd0bn0s8xGBrlgBBsMc68XB6SbdttR+ewCOpIRf m/rv9uyeBWqgvWaYDGa/FCd+0J2/c8vUhhw5TnHG0BDfeaSQ8ZyKNeMB1KXli3bYMy3R n0KkiFU6S1Y9qr7qJPEiov+S0wEmi2d56gp++d9CuiguIFZ4HftpGES/rb4aNNeTjhlY qV3sMCMNyawziAR4MXO+mpIweTO8t93lo/wGo4GO2ORvYkIxfnGFsseZZgF1zd5x93nD UdBiw7xZjwWYyTU4TlWXvF2nE4uijnP/2XGdZx0ZnV1QWCCAKq40fY683YabPQs8aHuI 7X7Q== X-Gm-Message-State: APt69E1d1aMdGptpmlW4PiXALb1Ylx3Xf+79UVrt8gwsvJLrSzK5uHWW z/l3iJpZy9y4njAGdMHU1RLLGMR7z2Z0WZqBcFo/+g== X-Google-Smtp-Source: ADUXVKLjGdSxd08zWVLUQoCaE0dMcgFtls1wNIGIf5zp3JatmrupDh6i5JTYcRajlNlCWr+8rAhzhZgBE+PlT6WLPOw= X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr5936884plb.208.1529141159252; Sat, 16 Jun 2018 02:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sat, 16 Jun 2018 02:25:58 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Kazuho Oku Date: Sat, 16 Jun 2018 18:25:58 +0900 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Christian Huitema Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 09:26:03 -0000 2018-06-16 16:10 GMT+09:00 Christian Huitema : > On 6/15/2018 6:57 PM, Kazuho Oku wrote: > >> And I think that the proposed change would be fine because it does not >> necessary increase the size of the ACK frame, if we remove ACK Block >> Count field in exchange. > Ack block count is generally one byte, the length would have to be two > bytes most of the time, especially if one wants to avoid 2 passes. So > that's one extra byte. I am not sure if that is true. I think that it would be safe to assume that most of the blocks or gaps will be smaller than 65. On a high bandwidth scenario, some of the blocks could become bigger than that, but IIUC having many big blocks with gaps within is unlikely. Therefore, we can assume that an ACK Length field of one-octet can hold up to nearly 30 pairs of blocks and gaps (whereas one-octet ACK Block Count can hold up to 63). I think that that would be enough. Or, I would argue that if we think that having nearly 30 pairs is not enough, I wonder that 63 could be not enough as well. Besides, I would like to note also that you can implement space-efficient one-pass encoding of an ACK frame even if we replace the Block Count field with a variable-length ACK Length field. For one-pass encoding, I'd assume that you retain the size of each block (or gap) and update that as new frames arrive. What you would do is as you update the size of the block (or gap), you update the expected size of the ACK frame as well. The size increments by one when the size of the block becomes greater than 63, or decrements by one when the size of the gap becomes smaller than 64. >> Instead of relying on the field, a receiver of the ACK frame can read >> blocks until it consumes the number of bytes specified by the length >> of the frame. > Modulo handling of ECN counters, of course. In the ECN proposal, we have > three varints at the end of the ack frame, and that would make parsing a > variable number of ack blocks more interesting. So if we take the length > proposal, we have to make sure that the ECN counters get moved before > the ack blocks. Agreed. > -- Christian Huitema > > -- Kazuho Oku From nobody Sat Jun 16 13:13:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18BC130E45 for ; Sat, 16 Jun 2018 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=rtfm-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 K_ZyMTgxbqfs for ; Sat, 16 Jun 2018 13:13:20 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 3A30E12785F for ; Sat, 16 Jun 2018 13:13:20 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id v24-v6so6043418otk.13 for ; Sat, 16 Jun 2018 13:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y9bfNKvJsC7x6gKyufeFZ4EEiTGN6jQVmI6hRm4tGs4=; b=oUzUGoFAXqNbynz71gKVlDnRS7xl2zXr2glcVUuW7fY4LWXPgpzRokD3IMgOGFPBsh QbNaEcXYRDboUZVFf1VR9jhXgEz+jQ3jWA+O5Fdfp4K09DvOmm5Sm2FPE+1dLQ8lvaxM KTsXK8wZtDjrEgaSTfKcCE1Y/um11JzSgyer4E3yhGA42G4Ab07Ft73RnBN59inxQZc6 NFgp5YbKvuhcVyasRkhGeVDXTWWZhcFoZzVk5SMO+Y+OLRvut4sCoOahiQ463KmGMjLa laoUx5xRfWUEPyJX4zg3w+lwgAY0ObIdfKN7Ezo26dRW5nsgMb73ZgESEXSJkcOYsnxn rKyg== 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=Y9bfNKvJsC7x6gKyufeFZ4EEiTGN6jQVmI6hRm4tGs4=; b=Yji41eiyAf9CdOUetonMFbPBXqgfRas0xculf9k6FhqXVCFQ+p+T1miWxyFVmBu632 V2nANrLye6jUxKiEyOXrdgqUPFnB09C8zzeJ2QIer0+X2S/AxB961OwtJ3eDJoEYR8w+ 0haIMBl/sVF04MBqYj6+CdbgCeIqANBt0Q9JxwvjnQJ3hU9xpWyl4xRW7mdJreiB6kHH Q/YaoTtzVLvkP79tBCRXHu8dvo8MVN3/9lkeKd4xpAU1gMShNdRGwrDy0a83v3LOKZsW i980lwndJkoWQ16D5NT6LEAai2JVGjzAucwZ0rGRMe/liEENA/JUbuPP4ZxgRcP0fWo2 2W8w== X-Gm-Message-State: APt69E0gO4WyMDrWQLB+x1gHvJtH8ALJR8kwZL0xgmbUAeg+hsHovJEe LHJ+0auwBTlPXkXmfMATr60xbYmRXDhkB0Xeu0r94g== X-Google-Smtp-Source: ADUXVKKgHDNhbUMJrWzQ/EUlA9LblOc4FwTi65qG/Gf3quzQwxQZzZmkIY8hXqXTk3bPhNtCSuU+NuNWwjnFKemoCPE= X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr3937904otb.214.1529179999579; Sat, 16 Jun 2018 13:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Sat, 16 Jun 2018 13:12:39 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Eric Rescorla Date: Sat, 16 Jun 2018 13:12:39 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Marten Seemann Cc: Martin Thomson , Jana Iyengar , Praveen Balasubramanian , QUIC WG , "Deval, Manasi" Content-Type: multipart/alternative; boundary="000000000000ac4908056ec7f629" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 20:13:22 -0000 --000000000000ac4908056ec7f629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann wrote: > This proposal increases the size of the ACK frame by 1 byte in the common > case (less than 63 ACK ranges), since the ACK length field here always > consumes 2 bytes, whereas the ACK Block Count is a variable-length intege= r. > Considering how much work we put into minimising the size of the frames, > this feels like a step in the wrong direction. > > Regarding the processing cost, I agree with Dmitri. Handling an ACK frame > requires looping over and making changes to a data structure that keeps > track of sent packets. This is much more expensive than simply parsing a > bunch of varints in the ACK frame. It seems unlikely that a multi-threade= d > packet parser would offer any real-world performance benefits. > I don't want to overstate the benefit here, but my point isn't that parsing is expensive but that if you want to have a multithreaded packet processing system, then it's nice to have a simpler data structure (the unparsed ACK block) to hand to the ACK processing thread. -Ekr > On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > wrote: > >> When we discussed this before, some people observed that this creates >> a need to encode in two passes. That's the trade-off here. (Not >> expressing an opinion.) >> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrote: >> > >> > I don't have a strong opinion on this. I'm certainly not opposed to it= . >> > Does anyone have a strong opposition? >> > >> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian < >> pravb@microsoft.com> wrote: >> >> >> >> I agree as well since this can help reduce per packet processing >> overhead. ACKs are going to be the second most common frame type so no >> objections to special casing. >> >> >> >> >> >> >> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla >> >> Sent: Friday, June 15, 2018 9:11 AM >> >> To: Deval, Manasi >> >> Cc: Jana Iyengar ; QUIC WG >> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >> >> >> >> >> >> >> I agree with Manasi here. This change would allow ack frame parsing t= o >> be more self-contained, which is an advantage for the parser and also >> potentially for parallelism (because you can quickly find the frame and >> then process it in parallel). >> >> >> >> >> >> >> >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >> wrote: >> >> >> >> In general, varints require some specific logic for parsing. To skip >> over any header, I have to read every single varint. As the code sees >> Stream and ACK headers most frequently, that is my focus. The Stream fr= ame >> has a length in its third field. >> >> >> >> >> >> >> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify length= . >> There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2= =80=98ACK delay=E2=80=99 and =E2=80=98ACK >> block count=E2=80=99. The pain point is the total number of cycles parse= an ACK. If >> I am processing 10M pps, where 10% - 30% of the packets have a piggyback= ed >> ACK, these cycles becomes a significant bottleneck. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Manasi >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >> >> Sent: Monday, June 11, 2018 3:11 PM >> >> To: Deval, Manasi ; QUIC WG >> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >> >> >> >> >> >> >> You're right that we no longer have the ability to skip an ACK frame, >> and this crept in when we moved to varints. >> >> >> >> I believe your problem though is generally true of most frames not >> just ACKs, since ids, packet numbers, and numbers in all frames are now = all >> varints. To skip any frame, you'll need to parse the varint fields in th= ose >> frames. If you have logic to process and skip varints, then skipping the >> ack block section is merely repeating this operation (2*num_block+1) tim= es. >> Do you see specific value in skipping ACK frames over the other control >> frames? >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >> wrote: >> >> >> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >> >> > - Moving the ACK length to the front of the ACK allows the >> >> > flexibility of either reading the entire ACK or reading th= e >> >> > first 16 bits and skipping over the length. This is a usef= ul >> >> > feature for the case where ACK processing is split into >> >> > multiple layers. Depending on the processor this is run on= , >> >> > there are different advantages - >> >> >> >> Just a note. In my experience, the cost of parsing an ACK frame is >> >> negligible compared to the cost of processing an ACK frame: that is, >> >> poking at various memory locations to discard newly ACKed packets. >> >> >> >> - Dmitri. >> >> >> >> >> >> --000000000000ac4908056ec7f629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann <m= artenseemann@gmail.com> wrote:
=
=
This proposal increases the size of the ACK frame by 1 byte in the com= mon case (less than 63 ACK ranges), since the ACK length field here always = consumes 2 bytes, whereas the ACK Block Count is a variable-length integer.= Considering how much work we put into minimising the size of the frames, t= his feels like a step in the wrong direction.

Regar= ding the processing cost, I agree with=C2=A0Dmitri. Handling an ACK frame r= equires looping over and making changes to a data structure that keeps trac= k of sent packets. This is much more expensive than simply parsing a bunch = of varints in the ACK frame. It seems unlikely that a multi-threaded packet= parser would offer any real-world performance benefits.
=

I don't want to overstate the benefit here, but my = point isn't that parsing is expensive but that if you want to have a mu= ltithreaded packet processing system, then it's nice to have a simpler = data structure (the unparsed ACK block) to hand to the ACK processing threa= d.

-Ekr



On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
When we discussed this before, some people obse= rved that this creates
a need to encode in two passes.=C2=A0 That's the trade-off here.=C2=A0 = (Not
expressing an opinion.)
On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
>
> I don't have a strong opinion on this. I'm certainly not oppos= ed to it.
> Does anyone have a strong opposition?
>
> On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian <pravb@microsoft.com> = wrote:
>>
>> I agree as well since this can help reduce per packet processing o= verhead. ACKs are going to be the second most common frame type so no objec= tions to special casing.
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Friday, June 15, 2018 9:11 AM
>> To: Deval, Manasi <manasi.deval@intel.com>
>> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> I agree with Manasi here. This change would allow ack frame parsin= g to be more self-contained, which is an advantage for the parser and also = potentially for parallelism (because you can quickly find the frame and the= n process it in parallel).
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <manasi.deval@intel.com>= wrote:
>>
>> In general, varints require some specific logic for parsing. To sk= ip over any header, I have to read every single varint. As the code sees St= ream and ACK headers most frequently, that is my focus.=C2=A0 The Stream fr= ame has a length in its third field.
>>
>>
>>
>> ACK parsing, however, needs 6 + 2*num_blocks reads to identify len= gth. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, = =E2=80=98ACK delay=E2=80=99 and =E2=80=98ACK block count=E2=80=99. The pain= point is the total number of cycles parse an ACK. If I am processing 10M p= ps, where 10% - 30% of the packets have a piggybacked ACK, these cycles bec= omes a significant bottleneck.
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>>
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
>> Sent: Monday, June 11, 2018 3:11 PM
>> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> You're right that we no longer have the ability to skip an ACK= frame, and this crept in when we moved to varints.
>>
>> I believe your problem though is generally true of most frames not= just ACKs, since ids, packet numbers, and numbers in all frames are now al= l varints. To skip any frame, you'll need to parse the varint fields in= those frames. If you have logic to process and skip varints, then skipping= the ack block section is merely repeating this operation (2*num_block+1) t= imes. Do you see specific value in skipping ACK frames over the other contr= ol frames?
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <dtikhonov@lite= speedtech..com> wrote:
>>
>> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the fro= nt of the ACK allows the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either readi= ng the entire ACK or reading the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping = over the length. This is a useful
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where = ACK processing is split into
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending = on the processor this is run on,
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advanta= ges -
>>
>> Just a note.=C2=A0 In my experience, the cost of parsing an ACK fr= ame is
>> negligible compared to the cost of processing an ACK frame: that i= s,
>> poking at various memory locations to discard newly ACKed packets.=
>>
>>=C2=A0 =C2=A0- Dmitri.
>>
>>


--000000000000ac4908056ec7f629-- From nobody Sat Jun 16 16:34:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5AE131151 for ; Sat, 16 Jun 2018 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 EkcI0ZYZ94Lm for ; Sat, 16 Jun 2018 16:34:42 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 8748113114A for ; Sat, 16 Jun 2018 16:34:42 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 81-v6so4543326ywb.6 for ; Sat, 16 Jun 2018 16:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=noU+SBAkJnUD+XZWMFSrPq/uL2Kc5+mIZEDETwUvqC4=; b=nDbVsbe8QgnN/f9WKiCr4CAV13oNS5HvMcHgelOifAmzPpWaC0T0w5ludqgCzNKtTo bPyDevdVOx1UwkGkfz8eMn1KmlpIDsHEhUZ6xDByon2NOVlS23YevvLnXtNuVxMJpBrO i7CPrO5VJmLUrBsWx9MYyhVTuFgGYTUeMAB1rNLR02cCOZj7dIdxVhqL5IA/MKvjTILz WnTxXQYxJqQnC5sB06jkoMnwvqABmGOrc3FJem9rinMxfYsawafVQbQ31w9oQvCXG1Ei YOTuF8M+8+IPOpnmAuIkkmRzKCjulSLBlu+V/PJAV6fj2OppAyR1b23/Xa3JyEKm00Lr +OYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=noU+SBAkJnUD+XZWMFSrPq/uL2Kc5+mIZEDETwUvqC4=; b=StB0RzqiEgBrp7FQrzNLSDMq6BqzIZgE1us0y2ska5Flkfnt+XKewZ1B+T9SdnRmcn 2qdJ+cUrCU7LkoDa8OupqNdBZFm4UX91TAIa9LpRrFuyjQX0VBp665ZYRc7Fv9eiEkyq FrJWYK9UrSghHZBYu15huAJAqlrxKt6tMiBbhuSEfR3SbPMQTL/AfDDNHr4i0X/ebaFd GBfVrsVt/6F1ixmDVmHL5UpM/8HDR4cxP1Lja47J6NTuEDQ1rkywS5/nbATFYQhMDQMd VLNSVk5Z4ggvilGJdRrEchsjrGdwN7AcwNHr00MLO8Ne/TCb33FNimHtA8iObPrkuXTg T+hA== X-Gm-Message-State: APt69E1Ahsqpd1DVfqzKTQn7B63q49PSmpAxCaG+habGYD0dKsmAw6EN d0mB5s1oFrt7QgU4/0UdS+hHe0cbxjaZjvwRU6gAww== X-Google-Smtp-Source: ADUXVKLjIc1d/mLZKf2kYPrmIDgHarrJmVIG97uXRBEKpSzr3qCmu78tYTc2GJFAEa4gGLVBi44E2iYkcRVJy/QkYa4= X-Received: by 2002:a0d:e849:: with SMTP id r70-v6mr3637448ywe.482.1529192081343; Sat, 16 Jun 2018 16:34:41 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Ian Swett Date: Sat, 16 Jun 2018 19:34:28 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Eric Rescorla Cc: Marten Seemann , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson , "Deval, Manasi" Content-Type: multipart/alternative; boundary="000000000000ce3632056ecac671" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 23:34:46 -0000 --000000000000ce3632056ecac671 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not a fan of this proposal, because I think it is impractical to drop the number of ack blocks, because with the ECN proposal it becomes impractically complex to parse. If we don't remove the number of ack blocks, then the ack frame is larger, but I don't think the extra size field is useful for most implementations. Also, it means the length can disagree with the actual length, which add complexity and the possibility of writing error-prone code. The idea of someone offloading ack processing and then proceeding to trust the length seems like someone could get wrong and cause some concerning issues. My experience is multithreaded packet processing is more cost and work than it's worth. Sure you can't fill a 100G NIC with one connection, but that seems like an academic problem, not one for workloads I've seen. Typically the extra cost of multithreading outweighs its value. To be clear, I don't think this is an awful idea, but I also don't see the value and it adds complexity. I read Manasi's email, but I don't think I understand why any of those matter in practice. On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > wrote: > >> This proposal increases the size of the ACK frame by 1 byte in the commo= n >> case (less than 63 ACK ranges), since the ACK length field here always >> consumes 2 bytes, whereas the ACK Block Count is a variable-length integ= er. >> Considering how much work we put into minimising the size of the frames, >> this feels like a step in the wrong direction. >> >> Regarding the processing cost, I agree with Dmitri. Handling an ACK fram= e >> requires looping over and making changes to a data structure that keeps >> track of sent packets. This is much more expensive than simply parsing a >> bunch of varints in the ACK frame. It seems unlikely that a multi-thread= ed >> packet parser would offer any real-world performance benefits. >> > > I don't want to overstate the benefit here, but my point isn't that > parsing is expensive but that if you want to have a multithreaded packet > processing system, then it's nice to have a simpler data structure (the > unparsed ACK block) to hand to the ACK processing thread. > > -Ekr > > > >> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >> wrote: >> >>> When we discussed this before, some people observed that this creates >>> a need to encode in two passes. That's the trade-off here. (Not >>> expressing an opinion.) >>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrote= : >>> > >>> > I don't have a strong opinion on this. I'm certainly not opposed to i= t. >>> > Does anyone have a strong opposition? >>> > >>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian < >>> pravb@microsoft.com> wrote: >>> >> >>> >> I agree as well since this can help reduce per packet processing >>> overhead. ACKs are going to be the second most common frame type so no >>> objections to special casing. >>> >> >>> >> >>> >> >>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla >>> >> Sent: Friday, June 15, 2018 9:11 AM >>> >> To: Deval, Manasi >>> >> Cc: Jana Iyengar ; QUIC WG >>> >> Subject: Re: Proposal to replace ACK block count with ACK length >>> >> >>> >> >>> >> >>> >> I agree with Manasi here. This change would allow ack frame parsing >>> to be more self-contained, which is an advantage for the parser and als= o >>> potentially for parallelism (because you can quickly find the frame and >>> then process it in parallel). >>> >> >>> >> >>> >> >>> >> -Ekr >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi < >>> manasi.deval@intel.com> wrote: >>> >> >>> >> In general, varints require some specific logic for parsing. To skip >>> over any header, I have to read every single varint. As the code sees >>> Stream and ACK headers most frequently, that is my focus. The Stream f= rame >>> has a length in its third field. >>> >> >>> >> >>> >> >>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify >>> length. There are two reads each for =E2=80=98largest acknowledged=E2= =80=99, =E2=80=98ACK delay=E2=80=99 >>> and =E2=80=98ACK block count=E2=80=99. The pain point is the total numb= er of cycles parse >>> an ACK. If I am processing 10M pps, where 10% - 30% of the packets have= a >>> piggybacked ACK, these cycles becomes a significant bottleneck. >>> >> >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> Manasi >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>> >> Sent: Monday, June 11, 2018 3:11 PM >>> >> To: Deval, Manasi ; QUIC WG >>> >> Subject: Re: Proposal to replace ACK block count with ACK length >>> >> >>> >> >>> >> >>> >> You're right that we no longer have the ability to skip an ACK frame= , >>> and this crept in when we moved to varints. >>> >> >>> >> I believe your problem though is generally true of most frames not >>> just ACKs, since ids, packet numbers, and numbers in all frames are now= all >>> varints. To skip any frame, you'll need to parse the varint fields in t= hose >>> frames. If you have logic to process and skip varints, then skipping th= e >>> ack block section is merely repeating this operation (2*num_block+1) ti= mes. >>> Do you see specific value in skipping ACK frames over the other control >>> frames? >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >>> wrote: >>> >> >>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >>> >> > - Moving the ACK length to the front of the ACK allows the >>> >> > flexibility of either reading the entire ACK or reading t= he >>> >> > first 16 bits and skipping over the length. This is a >>> useful >>> >> > feature for the case where ACK processing is split into >>> >> > multiple layers. Depending on the processor this is run o= n, >>> >> > there are different advantages - >>> >> >>> >> Just a note. In my experience, the cost of parsing an ACK frame is >>> >> negligible compared to the cost of processing an ACK frame: that is, >>> >> poking at various memory locations to discard newly ACKed packets. >>> >> >>> >> - Dmitri. >>> >> >>> >> >>> >>> > --000000000000ce3632056ecac671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not a fan of this proposal, because I think it is = impractical to drop the number of ack blocks, because with the ECN proposal= it becomes impractically complex to parse.

If we do= n't remove the number of ack blocks, then the ack frame is larger, but = I don't think the extra size field is useful for most implementations.= =C2=A0 Also, it means the length can disagree with the actual length, which= add complexity and the possibility of writing error-prone code.=C2=A0 The = idea of someone offloading ack processing and then proceeding to trust the = length seems like someone could get wrong and cause some concerning issues.=

My experience is multithreaded packet processing = is more cost and work than it's worth.=C2=A0 Sure you can't fill a = 100G NIC with one connection, but that seems like an academic problem, not = one for workloads I've seen.=C2=A0 Typically the extra cost of multithr= eading outweighs its value.

To be clear, I don'= ;t think this is an awful idea, but I also don't see the value and it a= dds complexity.=C2=A0 I read Manasi's email, but I don't think I un= derstand why any of those matter in practice.

On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla= <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Fri, Jun 15, 2018 at 6:46= PM, Marten Seemann <martenseemann@gmail.com> wrote:
This proposal increases the size of the= ACK frame by 1 byte in the common case (less than 63 ACK ranges), since th= e ACK length field here always consumes 2 bytes, whereas the ACK Block Coun= t is a variable-length integer. Considering how much work we put into minim= ising the size of the frames, this feels like a step in the wrong direction= .

Regarding the processing cost, I agree with=C2=A0= Dmitri. Handling an ACK frame requires looping over and making changes to a= data structure that keeps track of sent packets. This is much more expensi= ve than simply parsing a bunch of varints in the ACK frame. It seems unlike= ly that a multi-threaded packet parser would offer any real-world performan= ce benefits.

I don't want to over= state the benefit here, but my point isn't that parsing is expensive bu= t that if you want to have a multithreaded packet processing system, then i= t's nice to have a simpler data structure (the unparsed ACK block) to h= and to the ACK processing thread.

-Ekr



On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson <martin.thomson@gmail.com> w= rote:
When we discussed this before, some people obs= erved that this creates
a need to encode in two passes.=C2=A0 That's the trade-off here.=C2=A0 = (Not
expressing an opinion.)
On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
>
> I don't have a strong opinion on this. I'm certainly not oppos= ed to it.
> Does anyone have a strong opposition?
>
> On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian <pravb@microsoft.com> = wrote:
>>
>> I agree as well since this can help reduce per packet processing o= verhead. ACKs are going to be the second most common frame type so no objec= tions to special casing.
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Friday, June 15, 2018 9:11 AM
>> To: Deval, Manasi <manasi.deval@intel.com>
>> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> I agree with Manasi here. This change would allow ack frame parsin= g to be more self-contained, which is an advantage for the parser and also = potentially for parallelism (because you can quickly find the frame and the= n process it in parallel).
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <manasi.deval@intel.com>= wrote:
>>
>> In general, varints require some specific logic for parsing. To sk= ip over any header, I have to read every single varint. As the code sees St= ream and ACK headers most frequently, that is my focus.=C2=A0 The Stream fr= ame has a length in its third field.
>>
>>
>>
>> ACK parsing, however, needs 6 + 2*num_blocks reads to identify len= gth. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, = =E2=80=98ACK delay=E2=80=99 and =E2=80=98ACK block count=E2=80=99. The pain= point is the total number of cycles parse an ACK. If I am processing 10M p= ps, where 10% - 30% of the packets have a piggybacked ACK, these cycles bec= omes a significant bottleneck.
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>>
>>
>>
>>
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
>> Sent: Monday, June 11, 2018 3:11 PM
>> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG <quic@ietf.org>
>> Subject: Re: Proposal to replace ACK block count with ACK length >>
>>
>>
>> You're right that we no longer have the ability to skip an ACK= frame, and this crept in when we moved to varints.
>>
>> I believe your problem though is generally true of most frames not= just ACKs, since ids, packet numbers, and numbers in all frames are now al= l varints. To skip any frame, you'll need to parse the varint fields in= those frames. If you have logic to process and skip varints, then skipping= the ack block section is merely repeating this operation (2*num_block+1) t= imes. Do you see specific value in skipping ACK frames over the other contr= ol frames?
>>
>>
>>
>>
>>
>> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <dtikhonov@lite= speedtech..com> wrote:
>>
>> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the fro= nt of the ACK allows the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either readi= ng the entire ACK or reading the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping = over the length. This is a useful
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where = ACK processing is split into
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending = on the processor this is run on,
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advanta= ges -
>>
>> Just a note.=C2=A0 In my experience, the cost of parsing an ACK fr= ame is
>> negligible compared to the cost of processing an ACK frame: that i= s,
>> poking at various memory locations to discard newly ACKed packets.=
>>
>>=C2=A0 =C2=A0- Dmitri.
>>
>>


--000000000000ce3632056ecac671-- From nobody Sat Jun 16 17:45:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23E312D949 for ; Sat, 16 Jun 2018 17:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RRVamNYU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hCRtF8iv 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 aElQUXHOqigC for ; Sat, 16 Jun 2018 17:45:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A54130DFC for ; Sat, 16 Jun 2018 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 56CDE21751 for ; Sat, 16 Jun 2018 20:45:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 16 Jun 2018 20:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=G5UldzLcHUAgmVUUP MZ2R9IgyWULQNVNimfZc1rJ6A8=; b=RRVamNYUzmN6Uxfy0b3cEiN9VbMX+Gh1v NzA+IP2hTuCNoe2FJXMBOjtjEL9U3JC5USDraYfbWVg2AnjCPppxc9eWrrD2aHTJ 46yHFH8U3H+qWKSnyO0tz2HdmAl0WU+RFq3EP9Z920hHYLoowwp5889cdjkXTEER SF00SDjB1AupQsPUaTSiUBbdgRsRacq+OhvcTpPZiUoRDIEvWUwgReCH+QTA8cuQ 4QBo4mjZdpB8tTUn9Y6bBKe28Pdx0UNuKSBMfKFGPTW0oeUw7N0sUTj78L7Bz7Fv VjJcBGjCkxp9ndQm8BThduBpeWuMJDHiiSMSPzYApXrFEJh2cP7dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=G5UldzLcHUAgmVUUPMZ2R9IgyWULQNVNimfZc1rJ6A8=; b=hCRtF8iv GG/C53HCaXvIu/F1HUP7oMiYF3mfmOhQCp6kMTSYTioZR4oJJyIGlxQxhvSBR30E TFUkSL19lOIEKP9Aroyx+YLoHvs8F6VPifBKK1dCRIt57j1pI5TWajDc4LMotRt4 K/0ly9E/MeZrDt6HhhZPHt2s9/pgOSvMhMpbsfPug5ZYEWX8g+QJqS65lWE82K9s NpOLxZWOcRk1raMF28Niv1ZVqa45QkdYz68sBdLnzOjneFet9XoNxB0/nXCINe0B nqjeAxQ09DAYDeK5zRBxPjFcFdmIgJ92RMvSJLgaGg4zIT6/HjS221h4F1GP89ff Wn8w5r2SxgwbZw== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 595F210252 for ; Sat, 16 Jun 2018 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id B8D69C9EA7 for ; Sun, 17 Jun 2018 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1482987221413277015==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180617004517.B8D69C9EA7@cloud.mnot.net> Date: Sun, 17 Jun 2018 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 00:45:26 -0000 --===============1482987221413277015== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+7/-4/=F0=9F=92=AC59) 7 issues created: - QPACK sample encoder bug (by afrind) https://github.com/quicwg/base-drafts/issues/1455 [-qpack] = - QPACK could use some examples (by afrind) https://github.com/quicwg/base-drafts/issues/1454 [-qpack] = - Looping with multiple Retry packets (by martinthomson) https://github.com/quicwg/base-drafts/issues/1451 [-transport] [design] = - Clearer pseudocode/TLS syntax specification (by rmarx) https://github.com/quicwg/base-drafts/issues/1449 = - What if the packet number of a retry packet is not zero? (by huitema) https://github.com/quicwg/base-drafts/issues/1448 = - Stateless Reset Eternal Ping Pong (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1443 = - Current Code for Recovery period misscounts (by gloinul) https://github.com/quicwg/base-drafts/issues/1440 = 11 issues received 59 new comments: - #1439 Improve ACK_ECN frame encoding (e.g., use bit-vector) (32 by ad-l= , kazuho, mikkelfj, gloinul, larseggert, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/1439 = - #1429 Idle timeout interaction with RTO (5 by martinthomson, MikeBishop= , ianswett) https://github.com/quicwg/base-drafts/issues/1429 [-transport] [design] = - #1271 Connection migration optional? (5 by erickinnear, tfpauly, pravb,= MikeBishop) https://github.com/quicwg/base-drafts/issues/1271 [-transport] [has-pro= posal] = - #1451 Looping with multiple Retry packets (4 by martinthomson, nibanks,= mikkelfj) https://github.com/quicwg/base-drafts/issues/1451 [-transport] [design] = - #1449 Clearer pseudocode/TLS syntax specification (3 by rmarx, ekr, dti= khonov) https://github.com/quicwg/base-drafts/issues/1449 = - #1430 Interleaved Stream IDs are awkward (3 by kazuho, MikeBishop, mikk= elfj) https://github.com/quicwg/base-drafts/issues/1430 [-transport] [design] = - #1440 Current Code for Recovery period misscounts (2 by gloinul, ianswe= tt) https://github.com/quicwg/base-drafts/issues/1440 = - #1428 When the sender is using standard Reno congestion control, ack ev= ery ~2 packets (2 by mikkelfj, ianswett) https://github.com/quicwg/base-drafts/issues/1428 [-recovery] = - #1448 What if the packet number of a retry packet is not zero? (1 by mi= kkelfj) https://github.com/quicwg/base-drafts/issues/1448 = - #1454 QPACK could use some examples (1 by LPardue) https://github.com/quicwg/base-drafts/issues/1454 [-qpack] = - #1405 Handling of duplicate packets (1 by kazuho) https://github.com/quicwg/base-drafts/issues/1405 [-transport] [design] = 4 issues closed: - Tracking of header blocks for reset streams https://github.com/quicwg/b= ase-drafts/issues/1371 [-qpack] [design] = - Implicitly acknowledging table updates by acknowleding header blocks ht= tps://github.com/quicwg/base-drafts/issues/1370 [-qpack] [design] = - Current Code for Recovery period misscounts https://github.com/quicwg/b= ase-drafts/issues/1440 = - Order of Coalesced Packets https://github.com/quicwg/base-drafts/issues= /1287 [-transport] [design] [needs-discussion] = Pull requests ------------- * quicwg/base-drafts (+4/-4/=F0=9F=92=AC12) 4 pull requests submitted: - Expand CID ratchet text (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1453 [-transport] [design] = - Stream0 dt output for merge (by ekr) https://github.com/quicwg/base-drafts/pull/1450 = - Fix sentence: make clear what fails with PROTOCOL_VIOLATION code (by dt= ikhonov) https://github.com/quicwg/base-drafts/pull/1445 = - Remove reference to "End Header Block" (by kazuho) https://github.com/quicwg/base-drafts/pull/1442 = 5 pull requests received 12 new comments: - #1447 TP to disable migration (7 by martinthomson, nibanks, pravb, Mike= Bishop) https://github.com/quicwg/base-drafts/pull/1447 [-transport] [design] = - #1431 Move stream type into frame type (2 by martinthomson, MikeBishop) https://github.com/quicwg/base-drafts/pull/1431 [-transport] [design] = - #1410 Describe QPACK Feedback mechanisms (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1410 [-qpack] [design] = - #1445 Fix sentence: make clear what fails with PROTOCOL_VIOLATION code = (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1445 = - #1372 Proposal for adding ECN support to QUIC. (1 by gloinul) https://github.com/quicwg/base-drafts/pull/1372 = 4 pull requests merged: - Describe QPACK Feedback mechanisms https://github.com/quicwg/base-drafts/pull/1410 [-qpack] [design] = - Fix sentence: make clear what fails with PROTOCOL_VIOLATION code https://github.com/quicwg/base-drafts/pull/1445 = - Remove reference to "End Header Block" https://github.com/quicwg/base-drafts/pull/1442 = - Coalescing guidance https://github.com/quicwg/base-drafts/pull/1423 [-transport] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1482987221413277015== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 17, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+7/-4/=F0=9F=92=AC59)

7 issues created:

11 issues received 59 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+4/-4/=F0=9F=92=AC12)

4 pull requests submitted:

5 pull requests received 12 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============1482987221413277015==-- From nobody Sun Jun 17 05:54:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B09130DEC for ; Sun, 17 Jun 2018 05:54:09 -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=unavailable 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 GLjXnTmyUvhy for ; Sun, 17 Jun 2018 05:54:05 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 A487A1294D7 for ; Sun, 17 Jun 2018 05:54:05 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id t12-v6so7603751plo.7 for ; Sun, 17 Jun 2018 05:54:05 -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=x/Mw9irgvkGVpGQyQzQ/jDYS/fKTuQc0OlP91hJ/S6Y=; b=jEKu/ipDkfPwqm1VLMMS1FofGBFQ9xbuTvcYSzzxPC1TjyCyGNWj6UgJtF00fn9BxR Zkz2YDyNW+I4x6NUB3jPLaPrEFzZbJ5GYYmGlPa3XsA2orrD+u2l+XRZlypwancXzOiv /SXHAzt/J/un+Qsq7KusaUGbuOd34rPOcfMwMa+ywxOa45GXMRkFkpCT2By4SodF3t6t qXPuWYjsa8IaYPiWuZAK+DE60LzjjGoeXyMH1MlCjXFCGP8IbHlAIC1RPlfF2vsQUAFo Gai44XD2MDQm8mFz7apBdMbGgMAIFYzHM2mv3qO+DkvWdb/VhRMJ8vZvf1Ch7FLpS0jH 6BGw== 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=x/Mw9irgvkGVpGQyQzQ/jDYS/fKTuQc0OlP91hJ/S6Y=; b=dM51PWNb93VEWui8k/zMhxmzeGZJdRjRfzsiyWcLqhruXmwGFqEjQsCmF2F313oXgL rSXqZHY/Q8MbtsvAnDjQbfOOE9zuuilbMuazxgNgTCm1ZWl+JmEcQQwNoU4UM379wHRA 0MH9pLAR18jmKdC5PAhzvRStG9BAsfMBjPSHQ4o4otMGYHv3S7AbW5M309YGnx0NFdG8 f+HhNcM+jNnY0g5lixTv3uO4K7n3d/jBED5otDqTy8BbG+vzaiVIeU6vFBN4YaQVL8Of 5Bn0x9SDuJLvZ0pk7PJfUDus36ehBTv0z+k4t29Be07Q2z8NkB9idW3pF/b7XgXIt3jW 8GcA== X-Gm-Message-State: APt69E22sau45P338mrihSf1un389y9QrPSJrbOSwfpfmqkg9e22AOJm HP2R8HYoercMTSvZmX6KEWZsilNsFehKanf1YHM= X-Google-Smtp-Source: ADUXVKKSKYHMmurUYWA1Ento61PRzYf9j5qEVp/+SJmZmIauhlN9nek46CdFmJyjmg4Sw5UeL3ouHE//FpfaayOk9SU= X-Received: by 2002:a17:902:b08a:: with SMTP id p10-v6mr10261055plr.0.1529240045129; Sun, 17 Jun 2018 05:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sun, 17 Jun 2018 05:54:04 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Kazuho Oku Date: Sun, 17 Jun 2018 21:54:04 +0900 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Ian Swett Cc: Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , Marten Seemann , IETF QUIC WG , Martin Thomson , "Deval, Manasi" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 12:54:10 -0000 2018-06-17 8:34 GMT+09:00 Ian Swett : > I'm not a fan of this proposal, because I think it is impractical to drop > the number of ack blocks, because with the ECN proposal it becomes > impractically complex to parse. For the ECN proposal, as Christian has suggested, we can move the ECN counters before the ACK blocks. Then, it would not be complex to parse. And my view is that parsing becomes easier if we replace ACK Block Count with ACK Frame Length. Now, with ACK Block Count, we need to check the remaining number of blocks and the remaining space in the packet payload for every block that we parse. Failing to check either leads to a bug or a security issue. If we switch to ACK Frame Length, we need to only check the remaining space in the frame. I think that this is the biggest benefit of replacing ACK Block Count with ACK Frame Length. OTOH the downside is that you need extra one to two bits (one if the size of block / gap is expected to be below 65, two if they are expected to be above that) for encoding ACK Frame Length compared to ACK Block Count. Having said that, I honestly wonder if all the frames could have it's length being encoded (either explicitly or either as a signal that says "to the end of the packet"). Consider something like below: |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | or |1| frame-type (7) | frame-payload (*) | When MSB of the first octet set to zero, the length of the frame payload is designated by the varint that immediately follows the frame type. When MSB of the first octet set to one, the length of the frame payload spans to the end of the packet. In this encoding, we can always omit the Length field of a STREAM frame. So the overhead for carrying stream data will be indifferent in practice. For the ACK frame, we can omit the ACK Block Count field. And the overhead will be one to two bits if the ACK frame is sent in the middle of the packet (thereby using the encoding with explicit frame payload length), or one octet or more shorter if ACK is the last frame of the packet. We are likely to see increase of overhead for most of the other types of frames, but I do not think that would be an issue considering that they will be far seldom seen compared to STREAMs and ACKs. To summarize, my anticipation is that we can make all the frames self-contained (i.e. the length can be determined without the knowledge of how each frame is encoded) without any overhead, if we agree on making the frame type space 1 bit smaller. Finally, the biggest benefit of using a self-contained encoding of frames is that we would have the ability to introduce new optional frames without negotiation. By making the frames self-contained, QUIC endpoints will have the freedom of ignoring the frames that they do not understand. Being able to send QUIC frames defined in extensions without negotiating using Transport Parameters will be a win in both terms of security (because clients' TP is sent in clear) and flexibility (because we will be possible to send the extensions before we figure out whether the peer supports that extension). > If we don't remove the number of ack blocks, then the ack frame is larger= , > but I don't think the extra size field is useful for most implementations= . > Also, it means the length can disagree with the actual length, which add > complexity and the possibility of writing error-prone code. The idea of > someone offloading ack processing and then proceeding to trust the length > seems like someone could get wrong and cause some concerning issues. > > My experience is multithreaded packet processing is more cost and work th= an > it's worth. Sure you can't fill a 100G NIC with one connection, but that > seems like an academic problem, not one for workloads I've seen. Typical= ly > the extra cost of multithreading outweighs its value. > > To be clear, I don't think this is an awful idea, but I also don't see th= e > value and it adds complexity. I read Manasi's email, but I don't think I > understand why any of those matter in practice. > > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >> wrote: >>> >>> This proposal increases the size of the ACK frame by 1 byte in the comm= on >>> case (less than 63 ACK ranges), since the ACK length field here always >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length inte= ger. >>> Considering how much work we put into minimising the size of the frames= , >>> this feels like a step in the wrong direction.. >>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK fra= me >>> requires looping over and making changes to a data structure that keeps >>> track of sent packets. This is much more expensive than simply parsing = a >>> bunch of varints in the ACK frame. It seems unlikely that a multi-threa= ded >>> packet parser would offer any real-world performance benefits. >> >> >> I don't want to overstate the benefit here, but my point isn't that >> parsing is expensive but that if you want to have a multithreaded packet >> processing system, then it's nice to have a simpler data structure (the >> unparsed ACK block) to hand to the ACK processing thread. >> >> -Ekr >> >> >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >>> wrote: >>>> >>>> When we discussed this before, some people observed that this creates >>>> a need to encode in two passes. That's the trade-off here. (Not >>>> expressing an opinion.) >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar wrot= e: >>>> > >>>> > I don't have a strong opinion on this. I'm certainly not opposed to >>>> > it. >>>> > Does anyone have a strong opposition? >>>> > >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >>>> > wrote: >>>> >> >>>> >> I agree as well since this can help reduce per packet processing >>>> >> overhead. ACKs are going to be the second most common frame type so= no >>>> >> objections to special casing. >>>> >> >>>> >> >>>> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorl= a >>>> >> Sent: Friday, June 15, 2018 9:11 AM >>>> >> To: Deval, Manasi >>>> >> Cc: Jana Iyengar ; QUIC WG >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >>>> >> >>>> >> >>>> >> >>>> >> I agree with Manasi here. This change would allow ack frame parsing >>>> >> to be more self-contained, which is an advantage for the parser and= also >>>> >> potentially for parallelism (because you can quickly find the frame= and then >>>> >> process it in parallel). >>>> >> >>>> >> >>>> >> >>>> >> -Ekr >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >>>> >> wrote: >>>> >> >>>> >> In general, varints require some specific logic for parsing. To ski= p >>>> >> over any header, I have to read every single varint. As the code se= es Stream >>>> >> and ACK headers most frequently, that is my focus. The Stream fram= e has a >>>> >> length in its third field. >>>> >> >>>> >> >>>> >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify >>>> >> length. There are two reads each for =E2=80=98largest acknowledged= =E2=80=99, =E2=80=98ACK delay=E2=80=99 and >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total numb= er of cycles parse an >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets hav= e a >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck. >>>> >> >>>> >> >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Manasi >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>>> >> Sent: Monday, June 11, 2018 3:11 PM >>>> >> To: Deval, Manasi ; QUIC WG >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >>>> >> >>>> >> >>>> >> >>>> >> You're right that we no longer have the ability to skip an ACK fram= e, >>>> >> and this crept in when we moved to varints. >>>> >> >>>> >> I believe your problem though is generally true of most frames not >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames are= now all >>>> >> varints. To skip any frame, you'll need to parse the varint fields = in those >>>> >> frames. If you have logic to process and skip varints, then skippin= g the ack >>>> >> block section is merely repeating this operation (2*num_block+1) ti= mes. Do >>>> >> you see specific value in skipping ACK frames over the other contro= l frames? >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >>>> >> wrote: >>>> >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >>>> >> > - Moving the ACK length to the front of the ACK allows the >>>> >> > flexibility of either reading the entire ACK or reading >>>> >> > the >>>> >> > first 16 bits and skipping over the length. This is a >>>> >> > useful >>>> >> > feature for the case where ACK processing is split into >>>> >> > multiple layers. Depending on the processor this is run >>>> >> > on, >>>> >> > there are different advantages - >>>> >> >>>> >> Just a note. In my experience, the cost of parsing an ACK frame is >>>> >> negligible compared to the cost of processing an ACK frame: that is= , >>>> >> poking at various memory locations to discard newly ACKed packets. >>>> >> >>>> >> - Dmitri. >>>> >> >>>> >> >>>> >> > --=20 Kazuho Oku From nobody Sun Jun 17 06:36:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4017130DEF for ; Sun, 17 Jun 2018 06:36:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 3pFgFEQuL9Ms for ; Sun, 17 Jun 2018 06:36:36 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 BE6EC1274D0 for ; Sun, 17 Jun 2018 06:36:35 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id n7-v6so8575787itn.1 for ; Sun, 17 Jun 2018 06:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=enzMoXn89CljA4vdRI5EZRy5yz01FDnC2jn+938pp0M=; b=K+R1j4Y6NY3tOURucsPhYgn9RS/i2wITkD+tHLFQBmOfs6tpvjrlbM0gMAPLMOAi7e HGzsNVgyTAFD1VDSH7V0c/UGDlBnBfaE/tQdd6WnU6sx/46mgFCtuIEummqyOg9DYpmi ldDhec3iseBgjVnYuSaS58mtZ8KqjyWBDoYrIhAodTY64MJQIkJOwiE3aVzqfj0VyzY1 vOQEeb12HGHNztQmAcSVB5CfHZXIJ+cCcJjpIAoOpFbxgACLd9qiatc9z2wgwidcRZ9w 7hkU9kcQWqYOfPfwyWtJ8MJawMK2teAIAPIrKqvGmwhU7u7MFa/UHvZWoalg1Udbc2Ns HAUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=enzMoXn89CljA4vdRI5EZRy5yz01FDnC2jn+938pp0M=; b=DSJqR0v1enUOWxT3HVSXZikdcNNpL66TIJ5uraMiEHkakbtahhAi81nPF95qfgCyz7 9qU+TKQEpK2rTIca8cGwTDEQOrN78Sa75J2Sv/gXw/Oa8rzm6bPt8tJ2aSg+NTZ3dD0O moQRqDlnlfSMS3KWpZouoTiKbNJVQpzEc+i1an8Dnh0h+R2/ZMfXOb7hdXhLk3HB1muz C6DtzSn4FRx6H9jEZvGhWgakUG3xA84J7isBtrjx50wOdZKT93Z1EftZkzCPcYNb/7Gx wYzXcc9EE7q++ayvWu/o4uziYPUzmu+tttGB63S/D8XX+hSPxLUVFzrEH1uNkqBpgLZr ibsg== X-Gm-Message-State: APt69E0T/tebxCCqbKXGQjjLhgfF4yjFn5/SeW78OPt7GduhxrYdpdiZ U++c9BXf2BuzUfpgKf+uO9+4k67qfUd4X7UgVw4= X-Google-Smtp-Source: ADUXVKLURZATIOzDzIJ6JDU0a2Pq8XOcHaNWNBO+pa5QQeTr/IJyrcux+ureTK2lVMVlGqUsro0eGBBCIMmYGLf3xw8= X-Received: by 2002:a24:d105:: with SMTP id w5-v6mr6372137itg.64.1529242594777; Sun, 17 Jun 2018 06:36:34 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Marten Seemann Date: Sun, 17 Jun 2018 20:36:22 +0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Kazuho Oku Cc: Ian Swett , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson , "Deval, Manasi" Content-Type: multipart/alternative; boundary="000000000000a32240056ed6898a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 13:36:40 -0000 --000000000000a32240056ed6898a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At least for my implementation, parsing doesn't become easier, it becomes more complex with this proposal. My varint-parser always consumes as many bytes as the varint requires, so after parsing a varint, I'd have to introduce an additional check that this didn't overflow the ACK length (e.g. consider that I parsed the ACK frame so far that only 2 bytes are remaining according to ACK length field, but the next varint is 4 bytes long). In general, we've been moving the wire image towards making every encodable value valid. This proposal moves us away from that principle: * some small values are always invalid (the length can never be between 0 and 3) * a lot of intermediate values are invalid (if the boundary falls inside a varint, as described above) Both these cases can't occur with the current ACK frame format. On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: > 2018-06-17 8:34 GMT+09:00 Ian Swett >: > > I'm not a fan of this proposal, because I think it is impractical to dr= op > > the number of ack blocks, because with the ECN proposal it becomes > > impractically complex to parse. > > For the ECN proposal, as Christian has suggested, we can move the ECN > counters before the ACK blocks. Then, it would not be complex to > parse. > > And my view is that parsing becomes easier if we replace ACK Block > Count with ACK Frame Length. > > Now, with ACK Block Count, we need to check the remaining number of > blocks and the remaining space in the packet payload for every block > that we parse. Failing to check either leads to a bug or a security > issue. > > If we switch to ACK Frame Length, we need to only check the remaining > space in the frame. > > I think that this is the biggest benefit of replacing ACK Block Count > with ACK Frame Length. OTOH the downside is that you need extra one to > two bits (one if the size of block / gap is expected to be below 65, > two if they are expected to be above that) for encoding ACK Frame > Length compared to ACK Block Count. > > > > Having said that, I honestly wonder if all the frames could have it's > length being encoded (either explicitly or either as a signal that > says "to the end of the packet"). Consider something like below: > > |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > or > |1| frame-type (7) | frame-payload (*) | > > When MSB of the first octet set to zero, the length of the frame > payload is designated by the varint that immediately follows the frame > type. > When MSB of the first octet set to one, the length of the frame > payload spans to the end of the packet. > > In this encoding, we can always omit the Length field of a STREAM > frame. So the overhead for carrying stream data will be indifferent in > practice. > > For the ACK frame, we can omit the ACK Block Count field. And the > overhead will be one to two bits if the ACK frame is sent in the > middle of the packet (thereby using the encoding with explicit frame > payload length), or one octet or more shorter if ACK is the last frame > of the packet. > > We are likely to see increase of overhead for most of the other types > of frames, but I do not think that would be an issue considering that > they will be far seldom seen compared to STREAMs and ACKs. > > To summarize, my anticipation is that we can make all the frames > self-contained (i.e. the length can be determined without the > knowledge of how each frame is encoded) without any overhead, if we > agree on making the frame type space 1 bit smaller. > > Finally, the biggest benefit of using a self-contained encoding of > frames is that we would have the ability to introduce new optional > frames without negotiation. By making the frames self-contained, QUIC > endpoints will have the freedom of ignoring the frames that they do > not understand. > > Being able to send QUIC frames defined in extensions without > negotiating using Transport Parameters will be a win in both terms of > security (because clients' TP is sent in clear) and flexibility > (because we will be possible to send the extensions before we figure > out whether the peer supports that extension). > > > If we don't remove the number of ack blocks, then the ack frame is > larger, > > but I don't think the extra size field is useful for most > implementations. > > Also, it means the length can disagree with the actual length, which ad= d > > complexity and the possibility of writing error-prone code. The idea o= f > > someone offloading ack processing and then proceeding to trust the leng= th > > seems like someone could get wrong and cause some concerning issues. > > > > My experience is multithreaded packet processing is more cost and work > than > > it's worth. Sure you can't fill a 100G NIC with one connection, but th= at > > seems like an academic problem, not one for workloads I've seen. > Typically > > the extra cost of multithreading outweighs its value. > > > > To be clear, I don't think this is an awful idea, but I also don't see > the > > value and it adds complexity. I read Manasi's email, but I don't think= I > > understand why any of those matter in practice. > > > > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >> > >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann < > martenseemann@gmail.com> > >> wrote: > >>> > >>> This proposal increases the size of the ACK frame by 1 byte in the > common > >>> case (less than 63 ACK ranges), since the ACK length field here alway= s > >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length > integer. > >>> Considering how much work we put into minimising the size of the > frames, > >>> this feels like a step in the wrong direction.. > >>> > >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK > frame > >>> requires looping over and making changes to a data structure that kee= ps > >>> track of sent packets. This is much more expensive than simply parsin= g > a > >>> bunch of varints in the ACK frame. It seems unlikely that a > multi-threaded > >>> packet parser would offer any real-world performance benefits. > >> > >> > >> I don't want to overstate the benefit here, but my point isn't that > >> parsing is expensive but that if you want to have a multithreaded pack= et > >> processing system, then it's nice to have a simpler data structure (th= e > >> unparsed ACK block) to hand to the ACK processing thread. > >> > >> -Ekr > >> > >> > >>> > >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson < > martin.thomson@gmail.com> > >>> wrote: > >>>> > >>>> When we discussed this before, some people observed that this create= s > >>>> a need to encode in two passes. That's the trade-off here. (Not > >>>> expressing an opinion.) > >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > wrote: > >>>> > > >>>> > I don't have a strong opinion on this. I'm certainly not opposed t= o > >>>> > it. > >>>> > Does anyone have a strong opposition? > >>>> > > >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >>>> > wrote: > >>>> >> > >>>> >> I agree as well since this can help reduce per packet processing > >>>> >> overhead. ACKs are going to be the second most common frame type > so no > >>>> >> objections to special casing. > >>>> >> > >>>> >> > >>>> >> > >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > Rescorla > >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >>>> >> To: Deval, Manasi > >>>> >> Cc: Jana Iyengar ; QUIC WG > >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length > >>>> >> > >>>> >> > >>>> >> > >>>> >> I agree with Manasi here. This change would allow ack frame parsi= ng > >>>> >> to be more self-contained, which is an advantage for the parser > and also > >>>> >> potentially for parallelism (because you can quickly find the > frame and then > >>>> >> process it in parallel). > >>>> >> > >>>> >> > >>>> >> > >>>> >> -Ekr > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >>>> >> wrote: > >>>> >> > >>>> >> In general, varints require some specific logic for parsing. To > skip > >>>> >> over any header, I have to read every single varint. As the code > sees Stream > >>>> >> and ACK headers most frequently, that is my focus. The Stream > frame has a > >>>> >> length in its third field. > >>>> >> > >>>> >> > >>>> >> > >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify > >>>> >> length. There are two reads each for =E2=80=98largest acknowledge= d=E2=80=99, =E2=80=98ACK > delay=E2=80=99 and > >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total nu= mber of cycles > parse an > >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets > have a > >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck. > >>>> >> > >>>> >> > >>>> >> > >>>> >> Thanks, > >>>> >> > >>>> >> Manasi > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > Iyengar > >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >>>> >> To: Deval, Manasi ; QUIC WG > > >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length > >>>> >> > >>>> >> > >>>> >> > >>>> >> You're right that we no longer have the ability to skip an ACK > frame, > >>>> >> and this crept in when we moved to varints. > >>>> >> > >>>> >> I believe your problem though is generally true of most frames no= t > >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames > are now all > >>>> >> varints. To skip any frame, you'll need to parse the varint field= s > in those > >>>> >> frames. If you have logic to process and skip varints, then > skipping the ack > >>>> >> block section is merely repeating this operation (2*num_block+1) > times. Do > >>>> >> you see specific value in skipping ACK frames over the other > control frames? > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >>>> >> wrote: > >>>> >> > >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >>>> >> > - Moving the ACK length to the front of the ACK allows t= he > >>>> >> > flexibility of either reading the entire ACK or readin= g > >>>> >> > the > >>>> >> > first 16 bits and skipping over the length. This is a > >>>> >> > useful > >>>> >> > feature for the case where ACK processing is split int= o > >>>> >> > multiple layers. Depending on the processor this is ru= n > >>>> >> > on, > >>>> >> > there are different advantages - > >>>> >> > >>>> >> Just a note. In my experience, the cost of parsing an ACK frame = is > >>>> >> negligible compared to the cost of processing an ACK frame: that > is, > >>>> >> poking at various memory locations to discard newly ACKed packets= . > >>>> >> > >>>> >> - Dmitri. > >>>> >> > >>>> >> > >>>> > >> > > > > > > -- > Kazuho Oku > --000000000000a32240056ed6898a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At least for my implementation, parsing doesn't become= easier, it becomes more complex with this proposal. My varint-parser alway= s consumes as many bytes as the varint requires, so after parsing a varint,= I'd have to introduce an additional check that this didn't overflo= w the ACK length (e.g. consider that I parsed the ACK frame so far that onl= y 2 bytes are remaining according to ACK length field, but the next varint = is 4 bytes long).

In general, we've been moving the wire i= mage towards making every encodable value valid. This proposal moves us awa= y from that principle:
* some small values are always invalid (th= e length can never be between 0 and 3)
* a lot of intermediate va= lues are invalid (if the boundary falls inside a varint, as described above= )
Both these cases can't occur with the current ACK frame for= mat.

On Su= n, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-17 8:34 GMT+09:00 Ian Swett <ianswett=3D40google.com@dmarc.ietf.org<= /a>>:
> I'm not a fan of this proposal, because I think it is impractical = to drop
> the number of ack blocks, because with the ECN proposal it becomes
> impractically complex to parse.

For the ECN proposal, as Christian has suggested, we can move the ECN
counters before the ACK blocks. Then, it would not be complex to
parse.

And my view is that parsing becomes easier if we replace ACK Block
Count with ACK Frame Length.

Now, with ACK Block Count, we need to check the remaining number of
blocks and the remaining space in the packet payload for every block
that we parse. Failing to check either leads to a bug or a security
issue.

If we switch to ACK Frame Length, we need to only check the remaining
space in the frame.

I think that this is the biggest benefit of replacing ACK Block Count
with ACK Frame Length. OTOH the downside is that you need extra one to
two bits (one if the size of block / gap is expected to be below 65,
two if they are expected to be above that) for encoding ACK Frame
Length compared to ACK Block Count.



Having said that, I honestly wonder if all the frames could have it's length being encoded (either explicitly or either as a signal that
says "to the end of the packet"). Consider something like below:<= br>
|0| frame-type (7) | frame-payload-length (i) | frame-payload (*) |
=C2=A0or
|1| frame-type (7) | frame-payload (*) |

When MSB of the first octet set to zero, the length of the frame
payload is designated by the varint that immediately follows the frame
type.
When MSB of the first octet set to one, the length of the frame
payload spans to the end of the packet.

In this encoding, we can always omit the Length field of a STREAM
frame. So the overhead for carrying stream data will be indifferent in
practice.

For the ACK frame, we can omit the ACK Block Count field. And the
overhead will be one to two bits if the ACK frame is sent in the
middle of the packet (thereby using the encoding with explicit frame
payload length), or one octet or more shorter if ACK is the last frame
of the packet.

We are likely to see increase of overhead for most of the other types
of frames, but I do not think that would be an issue considering that
they will be far seldom seen compared to STREAMs and ACKs.

To summarize, my anticipation is that we can make all the frames
self-contained (i.e. the length can be determined without the
knowledge of how each frame is encoded) without any overhead, if we
agree on making the frame type space 1 bit smaller.

Finally, the biggest benefit of using a self-contained encoding of
frames is that we would have the ability to introduce new optional
frames without negotiation. By making the frames self-contained, QUIC
endpoints will have the freedom of ignoring the frames that they do
not understand.

Being able to send QUIC frames defined in extensions without
negotiating using Transport Parameters will be a win in both terms of
security (because clients' TP is sent in clear) and flexibility
(because we will be possible to send the extensions before we figure
out whether the peer supports that extension).

> If we don't remove the number of ack blocks, then the ack frame is= larger,
> but I don't think the extra size field is useful for most implemen= tations.
> Also, it means the length can disagree with the actual length, which a= dd
> complexity and the possibility of writing error-prone code.=C2=A0 The = idea of
> someone offloading ack processing and then proceeding to trust the len= gth
> seems like someone could get wrong and cause some concerning issues. >
> My experience is multithreaded packet processing is more cost and work= than
> it's worth.=C2=A0 Sure you can't fill a 100G NIC with one conn= ection, but that
> seems like an academic problem, not one for workloads I've seen.= =C2=A0 Typically
> the extra cost of multithreading outweighs its value.
>
> To be clear, I don't think this is an awful idea, but I also don&#= 39;t see the
> value and it adds complexity.=C2=A0 I read Manasi's email, but I d= on't think I
> understand why any of those matter in practice.
>
> On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann <martenseemann@gmail.com&= gt;
>> wrote:
>>>
>>> This proposal increases the size of the ACK frame by 1 byte in= the common
>>> case (less than 63 ACK ranges), since the ACK length field her= e always
>>> consumes 2 bytes, whereas the ACK Block Count is a variable-le= ngth integer.
>>> Considering how much work we put into minimising the size of t= he frames,
>>> this feels like a step in the wrong direction..
>>>
>>> Regarding the processing cost, I agree with Dmitri. Handling a= n ACK frame
>>> requires looping over and making changes to a data structure t= hat keeps
>>> track of sent packets. This is much more expensive than simply= parsing a
>>> bunch of varints in the ACK frame. It seems unlikely that a mu= lti-threaded
>>> packet parser would offer any real-world performance benefits.=
>>
>>
>> I don't want to overstate the benefit here, but my point isn&#= 39;t that
>> parsing is expensive but that if you want to have a multithreaded = packet
>> processing system, then it's nice to have a simpler data struc= ture (the
>> unparsed ACK block) to hand to the ACK processing thread.
>>
>> -Ekr
>>
>>
>>>
>>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson <martin.thomson@gmail.com= >
>>> wrote:
>>>>
>>>> When we discussed this before, some people observed that t= his creates
>>>> a need to encode in two passes.=C2=A0 That's the trade= -off here.=C2=A0 (Not
>>>> expressing an opinion.)
>>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <jri.ietf@gmail.com>= wrote:
>>>> >
>>>> > I don't have a strong opinion on this. I'm ce= rtainly not opposed to
>>>> > it.
>>>> > Does anyone have a strong opposition?
>>>> >
>>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramani= an
>>>> > <pravb@microsoft.com> wrote:
>>>> >>
>>>> >> I agree as well since this can help reduce per pa= cket processing
>>>> >> overhead. ACKs are going to be the second most co= mmon frame type so no
>>>> >> objections to special casing.
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric R= escorla
>>>> >> Sent: Friday, June 15, 2018 9:11 AM
>>>> >> To: Deval, Manasi <manasi.deval@intel.com>
>>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>>>> >> Subject: Re: Proposal to replace ACK block count = with ACK length
>>>> >>
>>>> >>
>>>> >>
>>>> >> I agree with Manasi here. This change would allow= ack frame parsing
>>>> >> to be more self-contained, which is an advantage = for the parser and also
>>>> >> potentially for parallelism (because you can quic= kly find the frame and then
>>>> >> process it in parallel).
>>>> >>
>>>> >>
>>>> >>
>>>> >> -Ekr
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >>>> >> <manasi.deval@intel.com> wrote:
>>>> >>
>>>> >> In general, varints require some specific logic f= or parsing. To skip
>>>> >> over any header, I have to read every single vari= nt. As the code sees Stream
>>>> >> and ACK headers most frequently, that is my focus= .=C2=A0 The Stream frame has a
>>>> >> length in its third field.
>>>> >>
>>>> >>
>>>> >>
>>>> >> ACK parsing, however, needs 6 + 2*num_blocks read= s to identify
>>>> >> length. There are two reads each for =E2=80=98lar= gest acknowledged=E2=80=99, =E2=80=98ACK delay=E2=80=99 and
>>>> >> =E2=80=98ACK block count=E2=80=99. The pain point= is the total number of cycles parse an
>>>> >> ACK. If I am processing 10M pps, where 10% - 30% = of the packets have a
>>>> >> piggybacked ACK, these cycles becomes a significa= nt bottleneck.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> Manasi
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana I= yengar
>>>> >> Sent: Monday, June 11, 2018 3:11 PM
>>>> >> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG &l= t;quic@ietf.org><= br> >>>> >> Subject: Re: Proposal to replace ACK block count = with ACK length
>>>> >>
>>>> >>
>>>> >>
>>>> >> You're right that we no longer have the abili= ty to skip an ACK frame,
>>>> >> and this crept in when we moved to varints.
>>>> >>
>>>> >> I believe your problem though is generally true o= f most frames not
>>>> >> just ACKs, since ids, packet numbers, and numbers= in all frames are now all
>>>> >> varints. To skip any frame, you'll need to pa= rse the varint fields in those
>>>> >> frames. If you have logic to process and skip var= ints, then skipping the ack
>>>> >> block section is merely repeating this operation = (2*num_block+1) times. Do
>>>> >> you see specific value in skipping ACK frames ove= r the other control frames?
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >>>> >> <dtikhonov@litespeedtech..com> wrote:
>>>> >>
>>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, = Manasi wrote:
>>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK = length to the front of the ACK allows the
>>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibilit= y of either reading the entire ACK or reading
>>>> >> > the
>>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 b= its and skipping over the length. This is a
>>>> >> > useful
>>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature fo= r the case where ACK processing is split into
>>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple l= ayers. Depending on the processor this is run
>>>> >> > on,
>>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are = different advantages -
>>>> >>
>>>> >> Just a note.=C2=A0 In my experience, the cost of = parsing an ACK frame is
>>>> >> negligible compared to the cost of processing an = ACK frame: that is,
>>>> >> poking at various memory locations to discard new= ly ACKed packets.
>>>> >>
>>>> >>=C2=A0 =C2=A0- Dmitri.
>>>> >>
>>>> >>
>>>>
>>
>



--
Kazuho Oku
--000000000000a32240056ed6898a-- From nobody Sun Jun 17 06:48:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2DB130E5C for ; Sun, 17 Jun 2018 06:48:28 -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=unavailable 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 btll8kFQmnvv for ; Sun, 17 Jun 2018 06:48:24 -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 355511274D0 for ; Sun, 17 Jun 2018 06:48:24 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id w12-v6so6359872pgc.6 for ; Sun, 17 Jun 2018 06:48:24 -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=ROAIJyjw2X5yCMlcx1rGTaWKT8UKLN6einZGbKW2xyU=; b=A7URSC2/exkQ9S3vVnOuI5uwneXPpP4Fg9XFOMX7tBmBh40tc/OEUxqq7ognqhJGif rcf5Sd4BVFUaIsJ5KJ4Z4aE26LjLyxuFXcsW116dEmC8UNsTu3mfsMPiA1SQS3H00gDS uNML6hJ+IvuLpVy65nLf/goIaLqBEGc6pI3SE+peeF+DwjBDLIg7Muq5h++np3z0KX3C g9vGQmNvIF+dJuLUT0XBR54TqJcrr0O89/SRbwEt4oNFZJqPsMgNZb0+F7bc8PXL9IBX oZLQ0vjnplw85KNmhsiWPksJCNJFStLQz+Sh0WihQBvK63zrL4A/1MPlFdHslBZXup38 Q4eg== 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=ROAIJyjw2X5yCMlcx1rGTaWKT8UKLN6einZGbKW2xyU=; b=ks/caxle+gLoHzbc+xCC+qmUqpd3gaTUc4zBnLRwGVBCB1nBprCd0f5vPYYgtJOgbO TLA9C7zfiajA1CQIZEHBQK+p9qe+q13tZcGN5WoD1qVfY5CnpqRGsvptBDDmhSw5mLSF 2Lq60ZWGlodYhR32NJzSCiY7TYCBtnN+WYi9uowPDqVMixJiGwVp+z9qKrckeSuYoRpL o3yAtAUnnxlitt2lafkXwCd7vd4UKkv5O3Khsq4iJd8pQZXnticO0KzwEUcIw49mRKya 8VKFogUjdR5sQ1yjRiXlOEPXDx34dwBa/orRRFaVDr1spAYX65SKzPjh/xwtAIxeuYE9 GFdg== X-Gm-Message-State: APt69E3HlH8g1xHLGRefcRER5x4LG+Uok1m8dMFC4qYeTSejqGtP6+Ic RQiWJmGveq/d/z6GYlw7RjIAwBxViRZlGF7UuD7f9A== X-Google-Smtp-Source: ADUXVKJuHTgTSbkEUfv/8aWkt9oiscLzFqxk7Y/80luyAwpaXoUhrmFcJVMFY/+Tz7covf6wP83bE6B25cWHXZCwM+g= X-Received: by 2002:a63:a902:: with SMTP id u2-v6mr7887299pge.67.1529243303721; Sun, 17 Jun 2018 06:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sun, 17 Jun 2018 06:48:23 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> From: Kazuho Oku Date: Sun, 17 Jun 2018 22:48:23 +0900 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Marten Seemann Cc: Ian Swett , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson , "Deval, Manasi" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 13:48:28 -0000 2018-06-17 22:36 GMT+09:00 Marten Seemann : > At least for my implementation, parsing doesn't become easier, it becomes > more complex with this proposal. My varint-parser always consumes as many > bytes as the varint requires, so after parsing a varint, I'd have to > introduce an additional check that this didn't overflow the ACK length (e= .g. > consider that I parsed the ACK frame so far that only 2 bytes are remaini= ng > according to ACK length field, but the next varint is 4 bytes long). Isn't your varint parser checking that it has not (or will not) run across the end of the packet payload for every ACK block it parses? I'd assume that you would be doing that, because I think that is necessary to avoid buffer overrun. What I am saying that that check could be converted to a overrun check against the end of the "frame payload", and that checking the remaining block count becomes unnecessary, in case we replace ACK Block Count with ACK Frame Length. > > In general, we've been moving the wire image towards making every encodab= le > value valid. This proposal moves us away from that principle: > * some small values are always invalid (the length can never be between 0 > and 3) > * a lot of intermediate values are invalid (if the boundary falls inside = a > varint, as described above) > Both these cases can't occur with the current ACK frame format. > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: >> >> 2018-06-17 8:34 GMT+09:00 Ian Swett >> : >> > I'm not a fan of this proposal, because I think it is impractical to >> > drop >> > the number of ack blocks, because with the ECN proposal it becomes >> > impractically complex to parse. >> >> For the ECN proposal, as Christian has suggested, we can move the ECN >> counters before the ACK blocks. Then, it would not be complex to >> parse. >> >> And my view is that parsing becomes easier if we replace ACK Block >> Count with ACK Frame Length. >> >> Now, with ACK Block Count, we need to check the remaining number of >> blocks and the remaining space in the packet payload for every block >> that we parse. Failing to check either leads to a bug or a security >> issue. >> >> If we switch to ACK Frame Length, we need to only check the remaining >> space in the frame. >> >> I think that this is the biggest benefit of replacing ACK Block Count >> with ACK Frame Length. OTOH the downside is that you need extra one to >> two bits (one if the size of block / gap is expected to be below 65, >> two if they are expected to be above that) for encoding ACK Frame >> Length compared to ACK Block Count. >> >> >> >> Having said that, I honestly wonder if all the frames could have it's >> length being encoded (either explicitly or either as a signal that >> says "to the end of the packet"). Consider something like below: >> >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | >> or >> |1| frame-type (7) | frame-payload (*) | >> >> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the frame >> type. >> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet. >> >> In this encoding, we can always omit the Length field of a STREAM >> frame. So the overhead for carrying stream data will be indifferent in >> practice. >> >> For the ACK frame, we can omit the ACK Block Count field. And the >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit frame >> payload length), or one octet or more shorter if ACK is the last frame >> of the packet. >> >> We are likely to see increase of overhead for most of the other types >> of frames, but I do not think that would be an issue considering that >> they will be far seldom seen compared to STREAMs and ACKs. >> >> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the >> knowledge of how each frame is encoded) without any overhead, if we >> agree on making the frame type space 1 bit smaller. >> >> Finally, the biggest benefit of using a self-contained encoding of >> frames is that we would have the ability to introduce new optional >> frames without negotiation. By making the frames self-contained, QUIC >> endpoints will have the freedom of ignoring the frames that they do >> not understand. >> >> Being able to send QUIC frames defined in extensions without >> negotiating using Transport Parameters will be a win in both terms of >> security (because clients' TP is sent in clear) and flexibility >> (because we will be possible to send the extensions before we figure >> out whether the peer supports that extension). >> >> > If we don't remove the number of ack blocks, then the ack frame is >> > larger, >> > but I don't think the extra size field is useful for most >> > implementations. >> > Also, it means the length can disagree with the actual length, which a= dd >> > complexity and the possibility of writing error-prone code. The idea = of >> > someone offloading ack processing and then proceeding to trust the >> > length >> > seems like someone could get wrong and cause some concerning issues. >> > >> > My experience is multithreaded packet processing is more cost and work >> > than >> > it's worth. Sure you can't fill a 100G NIC with one connection, but >> > that >> > seems like an academic problem, not one for workloads I've seen. >> > Typically >> > the extra cost of multithreading outweighs its value. >> > >> > To be clear, I don't think this is an awful idea, but I also don't see >> > the >> > value and it adds complexity. I read Manasi's email, but I don't thin= k >> > I >> > understand why any of those matter in practice. >> > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: >> >> >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >> >> >> >> wrote: >> >>> >> >>> This proposal increases the size of the ACK frame by 1 byte in the >> >>> common >> >>> case (less than 63 ACK ranges), since the ACK length field here alwa= ys >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length >> >>> integer. >> >>> Considering how much work we put into minimising the size of the >> >>> frames, >> >>> this feels like a step in the wrong direction.. >> >>> >> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK >> >>> frame >> >>> requires looping over and making changes to a data structure that >> >>> keeps >> >>> track of sent packets. This is much more expensive than simply parsi= ng >> >>> a >> >>> bunch of varints in the ACK frame. It seems unlikely that a >> >>> multi-threaded >> >>> packet parser would offer any real-world performance benefits. >> >> >> >> >> >> I don't want to overstate the benefit here, but my point isn't that >> >> parsing is expensive but that if you want to have a multithreaded >> >> packet >> >> processing system, then it's nice to have a simpler data structure (t= he >> >> unparsed ACK block) to hand to the ACK processing thread. >> >> >> >> -Ekr >> >> >> >> >> >>> >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >> >>> >> >>> wrote: >> >>>> >> >>>> When we discussed this before, some people observed that this creat= es >> >>>> a need to encode in two passes. That's the trade-off here. (Not >> >>>> expressing an opinion.) >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar >> >>>> wrote: >> >>>> > >> >>>> > I don't have a strong opinion on this. I'm certainly not opposed = to >> >>>> > it. >> >>>> > Does anyone have a strong opposition? >> >>>> > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >> >>>> > wrote: >> >>>> >> >> >>>> >> I agree as well since this can help reduce per packet processing >> >>>> >> overhead. ACKs are going to be the second most common frame type >> >>>> >> so no >> >>>> >> objections to special casing. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric >> >>>> >> Rescorla >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM >> >>>> >> To: Deval, Manasi >> >>>> >> Cc: Jana Iyengar ; QUIC WG >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> I agree with Manasi here. This change would allow ack frame >> >>>> >> parsing >> >>>> >> to be more self-contained, which is an advantage for the parser >> >>>> >> and also >> >>>> >> potentially for parallelism (because you can quickly find the >> >>>> >> frame and then >> >>>> >> process it in parallel). >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> -Ekr >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >> >>>> >> wrote: >> >>>> >> >> >>>> >> In general, varints require some specific logic for parsing. To >> >>>> >> skip >> >>>> >> over any header, I have to read every single varint. As the code >> >>>> >> sees Stream >> >>>> >> and ACK headers most frequently, that is my focus. The Stream >> >>>> >> frame has a >> >>>> >> length in its third field. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify >> >>>> >> length. There are two reads each for =E2=80=98largest acknowledg= ed=E2=80=99, =E2=80=98ACK >> >>>> >> delay=E2=80=99 and >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total n= umber of cycles >> >>>> >> parse an >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets >> >>>> >> have a >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> Thanks, >> >>>> >> >> >>>> >> Manasi >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana >> >>>> >> Iyengar >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM >> >>>> >> To: Deval, Manasi ; QUIC WG >> >>>> >> >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> You're right that we no longer have the ability to skip an ACK >> >>>> >> frame, >> >>>> >> and this crept in when we moved to varints. >> >>>> >> >> >>>> >> I believe your problem though is generally true of most frames n= ot >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames >> >>>> >> are now all >> >>>> >> varints. To skip any frame, you'll need to parse the varint fiel= ds >> >>>> >> in those >> >>>> >> frames. If you have logic to process and skip varints, then >> >>>> >> skipping the ack >> >>>> >> block section is merely repeating this operation (2*num_block+1) >> >>>> >> times. Do >> >>>> >> you see specific value in skipping ACK frames over the other >> >>>> >> control frames? >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >> >>>> >> wrote: >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >> >>>> >> > - Moving the ACK length to the front of the ACK allows >> >>>> >> > the >> >>>> >> > flexibility of either reading the entire ACK or readi= ng >> >>>> >> > the >> >>>> >> > first 16 bits and skipping over the length. This is a >> >>>> >> > useful >> >>>> >> > feature for the case where ACK processing is split in= to >> >>>> >> > multiple layers. Depending on the processor this is r= un >> >>>> >> > on, >> >>>> >> > there are different advantages - >> >>>> >> >> >>>> >> Just a note. In my experience, the cost of parsing an ACK frame >> >>>> >> is >> >>>> >> negligible compared to the cost of processing an ACK frame: that >> >>>> >> is, >> >>>> >> poking at various memory locations to discard newly ACKed packet= s. >> >>>> >> >> >>>> >> - Dmitri. >> >>>> >> >> >>>> >> >> >>>> >> >> >> > >> >> >> >> -- >> Kazuho Oku --=20 Kazuho Oku From nobody Sun Jun 17 06:59:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFFD130DEE for ; Sun, 17 Jun 2018 06:59:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 E4dbZ27Y34xJ for ; Sun, 17 Jun 2018 06:59:16 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 2CCD31274D0 for ; Sun, 17 Jun 2018 06:59:16 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id t5-v6so14611155ioa.8 for ; Sun, 17 Jun 2018 06:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1aKV5BbK8OdSO1YAcyPWT1jKsiJfYvINYRbuoJt6V88=; b=I4yLBM12R8Eq1ZP2e09FcoXjPtGbWvXmkNzvTJjkLdBUpeGPtx4sXfJnxR4GHCvKal 69UZbiv41Z+ox9HKJ6iWkCirJAGXEnzUNkWQCJsdm76tahaDiP4ZoHDfFYvz+6j9Ac10 E0UBLpb4bYhCAnMo5USbFGjGtmQLH9mIW7j7AXXdNVFi4m34R5EAUaJrPjSQEdkOQVFr wURMlMKuTKbggrrJTXoPb/LQhhUeUPFOKiAkFjbRrguKKjnNuVDixyVjfxYhp5Kmg1rj tuUfo7fcSH3xw57V+UFlw/0pavU5ewn27wQJhoQIDhzAsSLvRGd4PMWiIpgouYYY1cEC zbbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1aKV5BbK8OdSO1YAcyPWT1jKsiJfYvINYRbuoJt6V88=; b=raNOYyxrr72jBXurhofDhHVY8FGg6SLrVFYCJfk+k772Lw/VkSNhix6Z3tnHTWYRqn p6Ipf1ZyXDRU2afNtjVGWi4DJ5sUJBaEUWD7/byoxLk9mJSCK4enRiGZeP9Lm0cOTOVL VEEtfNV/cuHljWVyiuUYw2SU4bJcUKT4Eli1vzDBPtxhtjJEOh4bfTb/qesaGOg/Warf akVYngb9zKiGoU6q1CIFTDpvYkGcqzQ3p9t0nyHc/EZFcSbxVSIYs7TQXpZjXjNVQtyE qn8Ed1s6BEe7zEivWWynna6SNRkBXTGZooVyssYZgitgKLAJOqzvf6Ml3h8o7GbDnJu9 aIfQ== X-Gm-Message-State: APt69E1h2gL/RXi2kguMeISREaKTBPXf5nU5R/CoFZdM/CSsMO0c3Z/k H8TL9DPnxl9tmCRYOkFVUskc6x6LQTNhscvJKRw= X-Google-Smtp-Source: ADUXVKItQjoppne53AgDlDZfVVOvq2Dx+KztxEDEIj5ltJi88fTY5WsaBtmbt1Zpd1mifGINuL/MY58d3MEEZR1i+wM= X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr6979940ioh.235.1529243955164; Sun, 17 Jun 2018 06:59:15 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Marten Seemann Date: Sun, 17 Jun 2018 20:59:03 +0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Kazuho Oku Cc: Ian Swett , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson , "Deval, Manasi" Content-Type: multipart/alternative; boundary="000000000000b8f898056ed6daef" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 13:59:20 -0000 --000000000000b8f898056ed6daef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe it's specific to Go, but I'm using a single io.Reader for the whole packet, so as long as the packet payload is long enough, the varint parsing will not fail. I don't think that specifics of programming languages matter here though, and I'm sure both frame formats can be reasonably implemented in C as well as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us away from the principle that only reasonable values should be encodable, and that it increases the size of the ACK frame, for the questionable benefit of being able to parallelise the frame parser. On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > > At least for my implementation, parsing doesn't become easier, it becom= es > > more complex with this proposal. My varint-parser always consumes as ma= ny > > bytes as the varint requires, so after parsing a varint, I'd have to > > introduce an additional check that this didn't overflow the ACK length > (e.g. > > consider that I parsed the ACK frame so far that only 2 bytes are > remaining > > according to ACK length field, but the next varint is 4 bytes long). > > Isn't your varint parser checking that it has not (or will not) run > across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun. > > What I am saying that that check could be converted to a overrun check > against the end of the "frame payload", and that checking the > remaining block count becomes unnecessary, in case we replace ACK > Block Count with ACK Frame Length. > > > > > In general, we've been moving the wire image towards making every > encodable > > value valid. This proposal moves us away from that principle: > > * some small values are always invalid (the length can never be between= 0 > > and 3) > > * a lot of intermediate values are invalid (if the boundary falls insid= e > a > > varint, as described above) > > Both these cases can't occur with the current ACK frame format. > > > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: > >> > >> 2018-06-17 8:34 GMT+09:00 Ian Swett > >> : > >> > I'm not a fan of this proposal, because I think it is impractical to > >> > drop > >> > the number of ack blocks, because with the ECN proposal it becomes > >> > impractically complex to parse. > >> > >> For the ECN proposal, as Christian has suggested, we can move the ECN > >> counters before the ACK blocks. Then, it would not be complex to > >> parse. > >> > >> And my view is that parsing becomes easier if we replace ACK Block > >> Count with ACK Frame Length. > >> > >> Now, with ACK Block Count, we need to check the remaining number of > >> blocks and the remaining space in the packet payload for every block > >> that we parse. Failing to check either leads to a bug or a security > >> issue. > >> > >> If we switch to ACK Frame Length, we need to only check the remaining > >> space in the frame. > >> > >> I think that this is the biggest benefit of replacing ACK Block Count > >> with ACK Frame Length. OTOH the downside is that you need extra one to > >> two bits (one if the size of block / gap is expected to be below 65, > >> two if they are expected to be above that) for encoding ACK Frame > >> Length compared to ACK Block Count. > >> > >> > >> > >> Having said that, I honestly wonder if all the frames could have it's > >> length being encoded (either explicitly or either as a signal that > >> says "to the end of the packet"). Consider something like below: > >> > >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >> or > >> |1| frame-type (7) | frame-payload (*) | > >> > >> When MSB of the first octet set to zero, the length of the frame > >> payload is designated by the varint that immediately follows the frame > >> type. > >> When MSB of the first octet set to one, the length of the frame > >> payload spans to the end of the packet. > >> > >> In this encoding, we can always omit the Length field of a STREAM > >> frame. So the overhead for carrying stream data will be indifferent in > >> practice. > >> > >> For the ACK frame, we can omit the ACK Block Count field. And the > >> overhead will be one to two bits if the ACK frame is sent in the > >> middle of the packet (thereby using the encoding with explicit frame > >> payload length), or one octet or more shorter if ACK is the last frame > >> of the packet. > >> > >> We are likely to see increase of overhead for most of the other types > >> of frames, but I do not think that would be an issue considering that > >> they will be far seldom seen compared to STREAMs and ACKs. > >> > >> To summarize, my anticipation is that we can make all the frames > >> self-contained (i.e. the length can be determined without the > >> knowledge of how each frame is encoded) without any overhead, if we > >> agree on making the frame type space 1 bit smaller. > >> > >> Finally, the biggest benefit of using a self-contained encoding of > >> frames is that we would have the ability to introduce new optional > >> frames without negotiation. By making the frames self-contained, QUIC > >> endpoints will have the freedom of ignoring the frames that they do > >> not understand. > >> > >> Being able to send QUIC frames defined in extensions without > >> negotiating using Transport Parameters will be a win in both terms of > >> security (because clients' TP is sent in clear) and flexibility > >> (because we will be possible to send the extensions before we figure > >> out whether the peer supports that extension). > >> > >> > If we don't remove the number of ack blocks, then the ack frame is > >> > larger, > >> > but I don't think the extra size field is useful for most > >> > implementations. > >> > Also, it means the length can disagree with the actual length, which > add > >> > complexity and the possibility of writing error-prone code. The ide= a > of > >> > someone offloading ack processing and then proceeding to trust the > >> > length > >> > seems like someone could get wrong and cause some concerning issues. > >> > > >> > My experience is multithreaded packet processing is more cost and wo= rk > >> > than > >> > it's worth. Sure you can't fill a 100G NIC with one connection, but > >> > that > >> > seems like an academic problem, not one for workloads I've seen. > >> > Typically > >> > the extra cost of multithreading outweighs its value. > >> > > >> > To be clear, I don't think this is an awful idea, but I also don't s= ee > >> > the > >> > value and it adds complexity. I read Manasi's email, but I don't > think > >> > I > >> > understand why any of those matter in practice. > >> > > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >> >> > >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >> >> > >> >> wrote: > >> >>> > >> >>> This proposal increases the size of the ACK frame by 1 byte in the > >> >>> common > >> >>> case (less than 63 ACK ranges), since the ACK length field here > always > >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length > >> >>> integer. > >> >>> Considering how much work we put into minimising the size of the > >> >>> frames, > >> >>> this feels like a step in the wrong direction.. > >> >>> > >> >>> Regarding the processing cost, I agree with Dmitri. Handling an AC= K > >> >>> frame > >> >>> requires looping over and making changes to a data structure that > >> >>> keeps > >> >>> track of sent packets. This is much more expensive than simply > parsing > >> >>> a > >> >>> bunch of varints in the ACK frame. It seems unlikely that a > >> >>> multi-threaded > >> >>> packet parser would offer any real-world performance benefits. > >> >> > >> >> > >> >> I don't want to overstate the benefit here, but my point isn't that > >> >> parsing is expensive but that if you want to have a multithreaded > >> >> packet > >> >> processing system, then it's nice to have a simpler data structure > (the > >> >> unparsed ACK block) to hand to the ACK processing thread. > >> >> > >> >> -Ekr > >> >> > >> >> > >> >>> > >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> When we discussed this before, some people observed that this > creates > >> >>>> a need to encode in two passes. That's the trade-off here. (Not > >> >>>> expressing an opinion.) > >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >> >>>> wrote: > >> >>>> > > >> >>>> > I don't have a strong opinion on this. I'm certainly not oppose= d > to > >> >>>> > it. > >> >>>> > Does anyone have a strong opposition? > >> >>>> > > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> I agree as well since this can help reduce per packet processi= ng > >> >>>> >> overhead. ACKs are going to be the second most common frame ty= pe > >> >>>> >> so no > >> >>>> >> objections to special casing. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >> >>>> >> Rescorla > >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >> >>>> >> To: Deval, Manasi > >> >>>> >> Cc: Jana Iyengar ; QUIC WG > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> I agree with Manasi here. This change would allow ack frame > >> >>>> >> parsing > >> >>>> >> to be more self-contained, which is an advantage for the parse= r > >> >>>> >> and also > >> >>>> >> potentially for parallelism (because you can quickly find the > >> >>>> >> frame and then > >> >>>> >> process it in parallel). > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> -Ekr > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> In general, varints require some specific logic for parsing. T= o > >> >>>> >> skip > >> >>>> >> over any header, I have to read every single varint. As the co= de > >> >>>> >> sees Stream > >> >>>> >> and ACK headers most frequently, that is my focus. The Stream > >> >>>> >> frame has a > >> >>>> >> length in its third field. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify > >> >>>> >> length. There are two reads each for =E2=80=98largest acknowle= dged=E2=80=99, > =E2=80=98ACK > >> >>>> >> delay=E2=80=99 and > >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total= number of cycles > >> >>>> >> parse an > >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packet= s > >> >>>> >> have a > >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck= . > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> > >> >>>> >> Manasi > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >> >>>> >> Iyengar > >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >> >>>> >> To: Deval, Manasi ; QUIC WG > >> >>>> >> > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> You're right that we no longer have the ability to skip an ACK > >> >>>> >> frame, > >> >>>> >> and this crept in when we moved to varints. > >> >>>> >> > >> >>>> >> I believe your problem though is generally true of most frames > not > >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frame= s > >> >>>> >> are now all > >> >>>> >> varints. To skip any frame, you'll need to parse the varint > fields > >> >>>> >> in those > >> >>>> >> frames. If you have logic to process and skip varints, then > >> >>>> >> skipping the ack > >> >>>> >> block section is merely repeating this operation (2*num_block+= 1) > >> >>>> >> times. Do > >> >>>> >> you see specific value in skipping ACK frames over the other > >> >>>> >> control frames? > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >> >>>> >> > - Moving the ACK length to the front of the ACK allow= s > >> >>>> >> > the > >> >>>> >> > flexibility of either reading the entire ACK or > reading > >> >>>> >> > the > >> >>>> >> > first 16 bits and skipping over the length. This is= a > >> >>>> >> > useful > >> >>>> >> > feature for the case where ACK processing is split > into > >> >>>> >> > multiple layers. Depending on the processor this is > run > >> >>>> >> > on, > >> >>>> >> > there are different advantages - > >> >>>> >> > >> >>>> >> Just a note. In my experience, the cost of parsing an ACK fra= me > >> >>>> >> is > >> >>>> >> negligible compared to the cost of processing an ACK frame: th= at > >> >>>> >> is, > >> >>>> >> poking at various memory locations to discard newly ACKed > packets. > >> >>>> >> > >> >>>> >> - Dmitri. > >> >>>> >> > >> >>>> >> > >> >>>> > >> >> > >> > > >> > >> > >> > >> -- > >> Kazuho Oku > > > > -- > Kazuho Oku > --000000000000b8f898056ed6daef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe it's specific to Go, but I'm using a single = io.Reader for the whole packet, so as long as the packet payload is long en= ough, the varint parsing will not fail.
I don't think that specific= s of programming languages matter here though, and I'm sure both frame = formats can be reasonably implemented in C as well as in Go. The reasons I&= #39;m opposed to Manasi's proposal are that it moves us away from the p= rinciple that only reasonable values should be encodable, and that it incre= ases the size of the ACK frame, for the questionable benefit of being able = to parallelise the frame parser.

=
On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-17 22:36 GMT+09:00 Marten Seemann <<= a href=3D"mailto:martenseemann@gmail.com" target=3D"_blank">martenseemann@g= mail.com>:
> At least for my implementation, parsing doesn't become easier, it = becomes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have = to
> introduce an additional check that this didn't overflow the ACK le= ngth (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every = encodable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format. >
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is imp= ractical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>=C2=A0 or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibilit= y
>> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack= frame is
>> > larger,
>> > but I don't think the extra size field is useful for most=
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.= =C2=A0 The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with= one connection, but
>> > that
>> > seems like an academic problem, not one for workloads I'v= e seen.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I a= lso don't see
>> > the
>> > value and it adds complexity.=C2=A0 I read Manasi's email= , but I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my po= int isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler d= ata structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.=C2=A0 That's = the trade-off here.=C2=A0 (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I= 'm certainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.=C2=A0 The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*num_bl= ocks reads to identify
>> >>>> >> length. There are two reads each for =E2= =80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>> >>>> >> delay=E2=80=99 and
>> >>>> >> =E2=80=98ACK block count=E2=80=99. The p= ain point is the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have = the ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll n= eed to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wro= te:
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000= , Deval, Manasi wrote:
>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= eature for the case where ACK processing is split into
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.=C2=A0 In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku
--000000000000b8f898056ed6daef-- From nobody Sun Jun 17 14:24:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B07130E4D for ; Sun, 17 Jun 2018 14:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 SU5jK1T98vSy for ; Sun, 17 Jun 2018 14:24:41 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 1B2E6129385 for ; Sun, 17 Jun 2018 14:24:40 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2018 14:24:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.51,236,1526367600"; d="scan'208,217"; a="58346092" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga002.fm.intel.com with ESMTP; 17 Jun 2018 14:24:40 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX107.amr.corp.intel.com ([169.254.1.167]) with mapi id 14.03.0319.002; Sun, 17 Jun 2018 14:24:39 -0700 From: "Deval, Manasi" To: Marten Seemann , Kazuho Oku CC: Ian Swett , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10A== Date: Sun, 17 Jun 2018 21:24:39 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGEwMjMxZmItNjBhOS00YjM2LWFjOTAtNDVhYTVjMTM0NDc1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQndEZTVoQmltcHdcL0Z6TXRTc2dib0oyb1hDRnZZVGRuMitPdDBpM1wvTDRTcG9FSG5XV3VVNTNMbFU1VEZiME5mIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B83AB21ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 21:24:46 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B83AB21ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGhhdmUgbWFkZSBhIGxpc3Qgb2Ygb2JqZWN0aW9ucyB0byB0aGUgcHJvcG9z YWwgYW5kIHRoZSBzb2x1dGlvbnMgdG8gdGhvc2Ugb2JqZWN0aW9ucyBkaXNjdXNzZWQgb24gdGhp cyB0aHJlYWQuDQoNCg0KYS4gICAgICBDby1leGlzdGVuY2Ugb2YgbGVuZ3RoIGZpZWxkIHdpdGgg RUNOIGZpZWxkIGFuZCBBQ0sgYmxvY2tzLg0KDQoNCg0KQ2hyaXN0aWFuIHN1Z2dlc3RlZCB0byBt b3ZlIHRoZSBFQ04gZmllbGRzIHRvIHByZWNlZGUgdGhlIEFDSyBibG9ja3MuIFRoaXMgaXMgYW4g ZWxlZ2FudCBzb2x1dGlvbi4gUGFyc2luZyBlbnRpcmUgbGlzdCBvZiBBQ0sgYmxvY2tzIHRvIHJl dmlldyBFQ04gYml0cyB3b3VsZCBoYXZlIGJlZW4gYW5ub3lpbmcsIGV2ZW4gdGhvdWdoIGl0IGNh biB3b3JrLg0KDQoNCg0KYi4gICAgICBUaGVyZSBhcmUgdHdvIGNhc2VzIHRvIGJlIHBhcnNlZCDi gJMgZW50aXJlIEFDSyBhbmQgcGFyc2UgQUNLIHRvIGlkZW50aWZ5IGxlbmd0aC4gVGhlcmUgYXJl IHNvbWUgcmVzZXJ2YXRpb25zIHdoZW4gQUNLIHBhcnNpbmcgZ2V0cyBoYXJkZXIgZm9yIHRoZSBj YXNlIHdoZXJlIHRoZSBlbnRpcmUgaGVhZGVyIG5lZWRzIHRvIGJlIHBhcnNlZC4NCg0KDQoNCkFn cmVlbWVudCBmcm9tIHNldmVyYWwgZm9sa3MgaGVyZS4gSW4gdGhlIG9yaWdpbmFsIEFDSyBkZWZp bmVkIGluIGRyYWZ0IDEyIG9mIHRoZSBzbGlkZSwgb25lIHdvdWxkIGNvdW50IGRvd24gbnVtYmVy IG9mIEFDSyBibG9ja3MgdG8gZ2V0IHRvIHRoZSBlbmQgb2YgdGhlIHBhY2tldC4gSW4gdGhlIHBy b3Bvc2FsIEkgbWFkZSwgb25lIHdvdWxkIGNvdW50IGRvd24gdGhlIGxlbmd0aCB0byBpZGVudGlm eSB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuIFRoZSBsb2dpYyBpcyB2ZXJ5IHNpbWlsYXIgaW4gY3lj bGUgY291bnQgYW5kIGNvbXBsZXhpdHkuIFNldmVyYWwgZm9sa3MgYWxzbyBjb21tZW50ZWQgdG8g dGhpcyBlZmZlY3QuDQoNCg0KDQpjLiAgICAgIE11bHRpLXRocmVhZGVkIHBhY2tldCBwcm9jZXNz aW5nDQoNCg0KDQpJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIGFyZSAxMHMgb2YgMTAwMHMgb2Yg Y29ubmVjdGlvbnMgaW4gdXNlIGF0IGFueSB0aW1lIGZvciBhIHNlcnZlciB3aXRoIGEgaGlnaCBz cGVlZCBsaW5rLiBNdWx0aS10aHJlYWRpbmcgdG8gaGFuZGxlIGVhY2ggb2YgdGhlc2UgZmxvd3Mg LyBjb25uZWN0aW9ucyBpbiBwYXJhbGxlbCBpcyBuZWNlc3NpdHkgdG8gYmUgYWJsZSB0byBzdXBw b3J0IGxhcmdlIG51bWJlciBvZiBjb25uZWN0aW9ucyBvbiBhIGhpZ2ggc3BlZWQgbGluay4gVHgg c2VnbWVudGF0aW9uLCBSeCBjb2FsZXNjaW5nIGFyZSB3ZWxsIGtub3duIHN0cmF0ZWdpZXMgdG8g cmVkdWNlIHRoZSBwcm9jZXNzaW5nIGNvc3QuIEluIGluaXRpYWwgc3RhZ2VzLCBjb2RlIGlzIG9m dGVuIHdyaXR0ZW4gYXMgYSBzaW5nbGUtdGhyZWFkZWQgYW5kIHRoZW4gcmUtZmFjdG9yZWQgdG8g cGFyYWxsZWxpemUgY3ljbGUgaW50ZW5zaXZlIG9wZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93 IHRoaXMgcHJvdG9jb2wgdG8gc2NhbGUgaW4gZnV0dXJlLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgZG8g bm90IHByZWNsdWRlIHRoaXMgY2FzZS4NCg0KDQoNCmQuICAgICAgSW5jcmVhc2UgaW4gQUNLIHNp emUgYnkgMSBieXRlLg0KDQoNCg0KSSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzZXJpb3VzIGlzc3Vl IGJ1dCBpZiBmb2xrcyBidXQgd2UgY2FuIGNvbnNpZGVyIG1ha2luZyB0aGlzIGEgdmFyaW50LCBp ZiBvdGhlcnMgaGF2ZSBzdHJvbmcgZmVlbGluZ3MgYWJvdXQgaXQuIEl04oCZcyBhIHRyYWRlLW9m ZiA6IDIgcmVhZHMgdG8gc2F2ZSAxIGJ5dGUuDQoNCg0KDQplLiAgICAgIEV2ZXJ5IGVuY29kYWJs ZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQNCg0KTm90IGV2ZXJ5IGxlbmd0aCB3aWxsIGJlIHZhbGlk LiBUaGlzIGlzIGluaGVyZW50IHRvIGxlbmd0aHMuIFRoaXMgc2FtZSBpc3N1ZSBhaWxzIHRoZSDi gJhwYXlsb2FkIGxlbmd0aOKAmSBpbiBRVUlDIGhlYWRlci4gTm90IG9ubHkgZG9lcyB0aGUgaXNz dWUgZXhpc3QgZm9yIHNtYWxsIHZhbHVlcywgaXQgYWxzbyBhcHBsaWVzIHRvIGxhcmdlIHZhbHVl cyBzaW5jZSBkYXRhIHN0cmVhbSB3aWxsIGJlIHNlbnQgYWZ0ZXIgY3J5cHRvIG5lZ290aWF0aW9u LiAgRS5nLiAgLSBob3cgZG9lcyBvbmUgY3JhZnQgYSBwYXlsb2FkIHdpdGggNjIgYml0IHBheWxv YWQgbGVuZ3RoIGluIGEgbGFyZ2UgaGVhZGVyPw0KDQoNCg0KDQoNClRoYW5rcywNCg0KTWFuYXNp DQoNCg0KDQpGcm9tOiBNYXJ0ZW4gU2VlbWFubiBbbWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwu Y29tXQ0KU2VudDogU3VuZGF5LCBKdW5lIDE3LCAyMDE4IDY6NTkgQU0NClRvOiBLYXp1aG8gT2t1 IDxrYXp1aG9va3VAZ21haWwuY29tPg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYub3JnPjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgSmFuYSBJ eWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJh dmJAbWljcm9zb2Z0LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2ku ZGV2YWxAaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJs b2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KDQpNYXliZSBpdCdzIHNwZWNpZmljIHRvIEdvLCBi dXQgSSdtIHVzaW5nIGEgc2luZ2xlIGlvLlJlYWRlciBmb3IgdGhlIHdob2xlIHBhY2tldCwgc28g YXMgbG9uZyBhcyB0aGUgcGFja2V0IHBheWxvYWQgaXMgbG9uZyBlbm91Z2gsIHRoZSB2YXJpbnQg cGFyc2luZyB3aWxsIG5vdCBmYWlsLg0KSSBkb24ndCB0aGluayB0aGF0IHNwZWNpZmljcyBvZiBw cm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVyIGhlcmUgdGhvdWdoLCBhbmQgSSdtIHN1cmUgYm90 aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25hYmx5IGltcGxlbWVudGVkIGluIEMgYXMgd2Vs bCBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdtIG9wcG9zZWQgdG8gTWFuYXNpJ3MgcHJvcG9zYWwg YXJlIHRoYXQgaXQgbW92ZXMgdXMgYXdheSBmcm9tIHRoZSBwcmluY2lwbGUgdGhhdCBvbmx5IHJl YXNvbmFibGUgdmFsdWVzIHNob3VsZCBiZSBlbmNvZGFibGUsIGFuZCB0aGF0IGl0IGluY3JlYXNl cyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lLCBmb3IgdGhlIHF1ZXN0aW9uYWJsZSBiZW5lZml0 IG9mIGJlaW5nIGFibGUgdG8gcGFyYWxsZWxpc2UgdGhlIGZyYW1lIHBhcnNlci4NCg0KT24gU3Vu LCBKdW4gMTcsIDIwMTggYXQgODo0OCBQTSBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29t PG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4gd3JvdGU6DQoyMDE4LTA2LTE3IDIyOjM2IEdN VCswOTowMCBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1h cnRlbnNlZW1hbm5AZ21haWwuY29tPj46DQo+IEF0IGxlYXN0IGZvciBteSBpbXBsZW1lbnRhdGlv biwgcGFyc2luZyBkb2Vzbid0IGJlY29tZSBlYXNpZXIsIGl0IGJlY29tZXMNCj4gbW9yZSBjb21w bGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50LXBhcnNlciBhbHdheXMgY29uc3VtZXMg YXMgbWFueQ0KPiBieXRlcyBhcyB0aGUgdmFyaW50IHJlcXVpcmVzLCBzbyBhZnRlciBwYXJzaW5n IGEgdmFyaW50LCBJJ2QgaGF2ZSB0bw0KPiBpbnRyb2R1Y2UgYW4gYWRkaXRpb25hbCBjaGVjayB0 aGF0IHRoaXMgZGlkbid0IG92ZXJmbG93IHRoZSBBQ0sgbGVuZ3RoIChlLmcuDQo+IGNvbnNpZGVy IHRoYXQgSSBwYXJzZWQgdGhlIEFDSyBmcmFtZSBzbyBmYXIgdGhhdCBvbmx5IDIgYnl0ZXMgYXJl IHJlbWFpbmluZw0KPiBhY2NvcmRpbmcgdG8gQUNLIGxlbmd0aCBmaWVsZCwgYnV0IHRoZSBuZXh0 IHZhcmludCBpcyA0IGJ5dGVzIGxvbmcpLg0KDQpJc24ndCB5b3VyIHZhcmludCBwYXJzZXIgY2hl Y2tpbmcgdGhhdCBpdCBoYXMgbm90IChvciB3aWxsIG5vdCkgcnVuDQphY3Jvc3MgdGhlIGVuZCBv ZiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IEFDSyBibG9jayBpdCBwYXJzZXM/DQpJJ2Qg YXNzdW1lIHRoYXQgeW91IHdvdWxkIGJlIGRvaW5nIHRoYXQsIGJlY2F1c2UgSSB0aGluayB0aGF0 IGlzDQpuZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4uDQoNCldoYXQgSSBhbSBzYXlp bmcgdGhhdCB0aGF0IGNoZWNrIGNvdWxkIGJlIGNvbnZlcnRlZCB0byBhIG92ZXJydW4gY2hlY2sN CmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgImZyYW1lIHBheWxvYWQiLCBhbmQgdGhhdCBjaGVja2lu ZyB0aGUNCnJlbWFpbmluZyBibG9jayBjb3VudCBiZWNvbWVzIHVubmVjZXNzYXJ5LCBpbiBjYXNl IHdlIHJlcGxhY2UgQUNLDQpCbG9jayBDb3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguDQoNCj4N Cj4gSW4gZ2VuZXJhbCwgd2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdpcmUgaW1hZ2UgdG93YXJkcyBt YWtpbmcgZXZlcnkgZW5jb2RhYmxlDQo+IHZhbHVlIHZhbGlkLiBUaGlzIHByb3Bvc2FsIG1vdmVz IHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBsZToNCj4gKiBzb21lIHNtYWxsIHZhbHVlcyBhcmUg YWx3YXlzIGludmFsaWQgKHRoZSBsZW5ndGggY2FuIG5ldmVyIGJlIGJldHdlZW4gMA0KPiBhbmQg MykNCj4gKiBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFsdWVzIGFyZSBpbnZhbGlkIChpZiB0aGUg Ym91bmRhcnkgZmFsbHMgaW5zaWRlIGENCj4gdmFyaW50LCBhcyBkZXNjcmliZWQgYWJvdmUpDQo+ IEJvdGggdGhlc2UgY2FzZXMgY2FuJ3Qgb2NjdXIgd2l0aCB0aGUgY3VycmVudCBBQ0sgZnJhbWUg Zm9ybWF0Lg0KPg0KPiBPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA3OjU0IFBNIEthenVobyBPa3Ug PGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+PiB3cm90ZToN Cj4+DQo+PiAyMDE4LTA2LTE3IDg6MzQgR01UKzA5OjAwIElhbiBTd2V0dA0KPj4gPGlhbnN3ZXR0 PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPj46DQo+PiA+IEknbSBub3QgYSBmYW4gb2YgdGhpcyBwcm9wb3NhbCwgYmVjYXVzZSBJ IHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRvDQo+PiA+IGRyb3ANCj4+ID4gdGhlIG51bWJlciBv ZiBhY2sgYmxvY2tzLCBiZWNhdXNlIHdpdGggdGhlIEVDTiBwcm9wb3NhbCBpdCBiZWNvbWVzDQo+ PiA+IGltcHJhY3RpY2FsbHkgY29tcGxleCB0byBwYXJzZS4NCj4+DQo+PiBGb3IgdGhlIEVDTiBw cm9wb3NhbCwgYXMgQ2hyaXN0aWFuIGhhcyBzdWdnZXN0ZWQsIHdlIGNhbiBtb3ZlIHRoZSBFQ04N Cj4+IGNvdW50ZXJzIGJlZm9yZSB0aGUgQUNLIGJsb2Nrcy4gVGhlbiwgaXQgd291bGQgbm90IGJl IGNvbXBsZXggdG8NCj4+IHBhcnNlLg0KPj4NCj4+IEFuZCBteSB2aWV3IGlzIHRoYXQgcGFyc2lu ZyBiZWNvbWVzIGVhc2llciBpZiB3ZSByZXBsYWNlIEFDSyBCbG9jaw0KPj4gQ291bnQgd2l0aCBB Q0sgRnJhbWUgTGVuZ3RoLg0KPj4NCj4+IE5vdywgd2l0aCBBQ0sgQmxvY2sgQ291bnQsIHdlIG5l ZWQgdG8gY2hlY2sgdGhlIHJlbWFpbmluZyBudW1iZXIgb2YNCj4+IGJsb2NrcyBhbmQgdGhlIHJl bWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IGJsb2NrDQo+PiB0 aGF0IHdlIHBhcnNlLiBGYWlsaW5nIHRvIGNoZWNrIGVpdGhlciBsZWFkcyB0byBhIGJ1ZyBvciBh IHNlY3VyaXR5DQo+PiBpc3N1ZS4NCj4+DQo+PiBJZiB3ZSBzd2l0Y2ggdG8gQUNLIEZyYW1lIExl bmd0aCwgd2UgbmVlZCB0byBvbmx5IGNoZWNrIHRoZSByZW1haW5pbmcNCj4+IHNwYWNlIGluIHRo ZSBmcmFtZS4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgYmlnZ2VzdCBiZW5lZml0 IG9mIHJlcGxhY2luZyBBQ0sgQmxvY2sgQ291bnQNCj4+IHdpdGggQUNLIEZyYW1lIExlbmd0aC4g T1RPSCB0aGUgZG93bnNpZGUgaXMgdGhhdCB5b3UgbmVlZCBleHRyYSBvbmUgdG8NCj4+IHR3byBi aXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVs b3cgNjUsDQo+PiB0d28gaWYgdGhleSBhcmUgZXhwZWN0ZWQgdG8gYmUgYWJvdmUgdGhhdCkgZm9y IGVuY29kaW5nIEFDSyBGcmFtZQ0KPj4gTGVuZ3RoIGNvbXBhcmVkIHRvIEFDSyBCbG9jayBDb3Vu dC4NCj4+DQo+Pg0KPj4NCj4+IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlm IGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUgaXQncw0KPj4gbGVuZ3RoIGJlaW5nIGVuY29kZWQg KGVpdGhlciBleHBsaWNpdGx5IG9yIGVpdGhlciBhcyBhIHNpZ25hbCB0aGF0DQo+PiBzYXlzICJ0 byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQiKS4gQ29uc2lkZXIgc29tZXRoaW5nIGxpa2UgYmVsb3c6 DQo+Pg0KPj4gfDB8IGZyYW1lLXR5cGUgKDcpIHwgZnJhbWUtcGF5bG9hZC1sZW5ndGggKGkpIHwg ZnJhbWUtcGF5bG9hZCAoKikgfA0KPj4gIG9yDQo+PiB8MXwgZnJhbWUtdHlwZSAoNykgfCBmcmFt ZS1wYXlsb2FkICgqKSB8DQo+Pg0KPj4gV2hlbiBNU0Igb2YgdGhlIGZpcnN0IG9jdGV0IHNldCB0 byB6ZXJvLCB0aGUgbGVuZ3RoIG9mIHRoZSBmcmFtZQ0KPj4gcGF5bG9hZCBpcyBkZXNpZ25hdGVk IGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZQ0KPj4gdHlw ZS4NCj4+IFdoZW4gTVNCIG9mIHRoZSBmaXJzdCBvY3RldCBzZXQgdG8gb25lLCB0aGUgbGVuZ3Ro IG9mIHRoZSBmcmFtZQ0KPj4gcGF5bG9hZCBzcGFucyB0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQu DQo+Pg0KPj4gSW4gdGhpcyBlbmNvZGluZywgd2UgY2FuIGFsd2F5cyBvbWl0IHRoZSBMZW5ndGgg ZmllbGQgb2YgYSBTVFJFQU0NCj4+IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5n IHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW4NCj4+IHByYWN0aWNlLg0KPj4NCj4+ IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNLIEJsb2NrIENvdW50IGZpZWxk LiBBbmQgdGhlDQo+PiBvdmVyaGVhZCB3aWxsIGJlIG9uZSB0byB0d28gYml0cyBpZiB0aGUgQUNL IGZyYW1lIGlzIHNlbnQgaW4gdGhlDQo+PiBtaWRkbGUgb2YgdGhlIHBhY2tldCAodGhlcmVieSB1 c2luZyB0aGUgZW5jb2Rpbmcgd2l0aCBleHBsaWNpdCBmcmFtZQ0KPj4gcGF5bG9hZCBsZW5ndGgp LCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFzdCBmcmFtZQ0K Pj4gb2YgdGhlIHBhY2tldC4NCj4+DQo+PiBXZSBhcmUgbGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBv ZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3RoZXIgdHlwZXMNCj4+IG9mIGZyYW1lcywgYnV0 IEkgZG8gbm90IHRoaW5rIHRoYXQgd291bGQgYmUgYW4gaXNzdWUgY29uc2lkZXJpbmcgdGhhdA0K Pj4gdGhleSB3aWxsIGJlIGZhciBzZWxkb20gc2VlbiBjb21wYXJlZCB0byBTVFJFQU1zIGFuZCBB Q0tzLg0KPj4NCj4+IFRvIHN1bW1hcml6ZSwgbXkgYW50aWNpcGF0aW9uIGlzIHRoYXQgd2UgY2Fu IG1ha2UgYWxsIHRoZSBmcmFtZXMNCj4+IHNlbGYtY29udGFpbmVkIChpLmUuIHRoZSBsZW5ndGgg Y2FuIGJlIGRldGVybWluZWQgd2l0aG91dCB0aGUNCj4+IGtub3dsZWRnZSBvZiBob3cgZWFjaCBm cmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVhZCwgaWYgd2UNCj4+IGFncmVlIG9u IG1ha2luZyB0aGUgZnJhbWUgdHlwZSBzcGFjZSAxIGJpdCBzbWFsbGVyLg0KPj4NCj4+IEZpbmFs bHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRhaW5lZCBlbmNvZGlu ZyBvZg0KPj4gZnJhbWVzIGlzIHRoYXQgd2Ugd291bGQgaGF2ZSB0aGUgYWJpbGl0eSB0byBpbnRy b2R1Y2UgbmV3IG9wdGlvbmFsDQo+PiBmcmFtZXMgd2l0aG91dCBuZWdvdGlhdGlvbi4gQnkgbWFr aW5nIHRoZSBmcmFtZXMgc2VsZi1jb250YWluZWQsIFFVSUMNCj4+IGVuZHBvaW50cyB3aWxsIGhh dmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZyYW1lcyB0aGF0IHRoZXkgZG8NCj4+IG5v dCB1bmRlcnN0YW5kLg0KPj4NCj4+IEJlaW5nIGFibGUgdG8gc2VuZCBRVUlDIGZyYW1lcyBkZWZp bmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dA0KPj4gbmVnb3RpYXRpbmcgdXNpbmcgVHJhbnNwb3J0 IFBhcmFtZXRlcnMgd2lsbCBiZSBhIHdpbiBpbiBib3RoIHRlcm1zIG9mDQo+PiBzZWN1cml0eSAo YmVjYXVzZSBjbGllbnRzJyBUUCBpcyBzZW50IGluIGNsZWFyKSBhbmQgZmxleGliaWxpdHkNCj4+ IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2libGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZv cmUgd2UgZmlndXJlDQo+PiBvdXQgd2hldGhlciB0aGUgcGVlciBzdXBwb3J0cyB0aGF0IGV4dGVu c2lvbikuDQo+Pg0KPj4gPiBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sgYmxv Y2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMNCj4+ID4gbGFyZ2VyLA0KPj4gPiBidXQgSSBkb24n dCB0aGluayB0aGUgZXh0cmEgc2l6ZSBmaWVsZCBpcyB1c2VmdWwgZm9yIG1vc3QNCj4+ID4gaW1w bGVtZW50YXRpb25zLg0KPj4gPiBBbHNvLCBpdCBtZWFucyB0aGUgbGVuZ3RoIGNhbiBkaXNhZ3Jl ZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBhZGQNCj4+ID4gY29tcGxleGl0eSBhbmQg dGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29kZS4gIFRoZSBpZGVhIG9m DQo+PiA+IHNvbWVvbmUgb2ZmbG9hZGluZyBhY2sgcHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVk aW5nIHRvIHRydXN0IHRoZQ0KPj4gPiBsZW5ndGgNCj4+ID4gc2VlbXMgbGlrZSBzb21lb25lIGNv dWxkIGdldCB3cm9uZyBhbmQgY2F1c2Ugc29tZSBjb25jZXJuaW5nIGlzc3Vlcy4NCj4+ID4NCj4+ ID4gTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1v cmUgY29zdCBhbmQgd29yaw0KPj4gPiB0aGFuDQo+PiA+IGl0J3Mgd29ydGguICBTdXJlIHlvdSBj YW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0aCBvbmUgY29ubmVjdGlvbiwgYnV0DQo+PiA+IHRoYXQN Cj4+ID4gc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3JrbG9h ZHMgSSd2ZSBzZWVuLg0KPj4gPiBUeXBpY2FsbHkNCj4+ID4gdGhlIGV4dHJhIGNvc3Qgb2YgbXVs dGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4NCj4+ID4NCj4+ID4gVG8gYmUgY2xlYXIs IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBhd2Z1bCBpZGVhLCBidXQgSSBhbHNvIGRvbid0IHNl ZQ0KPj4gPiB0aGUNCj4+ID4gdmFsdWUgYW5kIGl0IGFkZHMgY29tcGxleGl0eS4gIEkgcmVhZCBN YW5hc2kncyBlbWFpbCwgYnV0IEkgZG9uJ3QgdGhpbmsNCj4+ID4gSQ0KPj4gPiB1bmRlcnN0YW5k IHdoeSBhbnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0aWNlLg0KPj4gPg0KPj4gPiBPbiBTYXQs IEp1biAxNiwgMjAxOCBhdCA0OjEzIFBNIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQo+PiA+Pg0KPj4gPj4gT24gRnJpLCBKdW4gMTUsIDIw MTggYXQgNjo0NiBQTSwgTWFydGVuIFNlZW1hbm4NCj4+ID4+IDxtYXJ0ZW5zZWVtYW5uQGdtYWls LmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+Pg0KPj4gPj4gd3JvdGU6DQo+PiA+ Pj4NCj4+ID4+PiBUaGlzIHByb3Bvc2FsIGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZy YW1lIGJ5IDEgYnl0ZSBpbiB0aGUNCj4+ID4+PiBjb21tb24NCj4+ID4+PiBjYXNlIChsZXNzIHRo YW4gNjMgQUNLIHJhbmdlcyksIHNpbmNlIHRoZSBBQ0sgbGVuZ3RoIGZpZWxkIGhlcmUgYWx3YXlz DQo+PiA+Pj4gY29uc3VtZXMgMiBieXRlcywgd2hlcmVhcyB0aGUgQUNLIEJsb2NrIENvdW50IGlz IGEgdmFyaWFibGUtbGVuZ3RoDQo+PiA+Pj4gaW50ZWdlci4NCj4+ID4+PiBDb25zaWRlcmluZyBo b3cgbXVjaCB3b3JrIHdlIHB1dCBpbnRvIG1pbmltaXNpbmcgdGhlIHNpemUgb2YgdGhlDQo+PiA+ Pj4gZnJhbWVzLA0KPj4gPj4+IHRoaXMgZmVlbHMgbGlrZSBhIHN0ZXAgaW4gdGhlIHdyb25nIGRp cmVjdGlvbi4uDQo+PiA+Pj4NCj4+ID4+PiBSZWdhcmRpbmcgdGhlIHByb2Nlc3NpbmcgY29zdCwg SSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4gQUNLDQo+PiA+Pj4gZnJhbWUNCj4+ID4+ PiByZXF1aXJlcyBsb29waW5nIG92ZXIgYW5kIG1ha2luZyBjaGFuZ2VzIHRvIGEgZGF0YSBzdHJ1 Y3R1cmUgdGhhdA0KPj4gPj4+IGtlZXBzDQo+PiA+Pj4gdHJhY2sgb2Ygc2VudCBwYWNrZXRzLiBU aGlzIGlzIG11Y2ggbW9yZSBleHBlbnNpdmUgdGhhbiBzaW1wbHkgcGFyc2luZw0KPj4gPj4+IGEN Cj4+ID4+PiBidW5jaCBvZiB2YXJpbnRzIGluIHRoZSBBQ0sgZnJhbWUuIEl0IHNlZW1zIHVubGlr ZWx5IHRoYXQgYQ0KPj4gPj4+IG11bHRpLXRocmVhZGVkDQo+PiA+Pj4gcGFja2V0IHBhcnNlciB3 b3VsZCBvZmZlciBhbnkgcmVhbC13b3JsZCBwZXJmb3JtYW5jZSBiZW5lZml0cy4NCj4+ID4+DQo+ PiA+Pg0KPj4gPj4gSSBkb24ndCB3YW50IHRvIG92ZXJzdGF0ZSB0aGUgYmVuZWZpdCBoZXJlLCBi dXQgbXkgcG9pbnQgaXNuJ3QgdGhhdA0KPj4gPj4gcGFyc2luZyBpcyBleHBlbnNpdmUgYnV0IHRo YXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBhIG11bHRpdGhyZWFkZWQNCj4+ID4+IHBhY2tldA0KPj4g Pj4gcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQncyBuaWNlIHRvIGhhdmUgYSBzaW1wbGVyIGRh dGEgc3RydWN0dXJlICh0aGUNCj4+ID4+IHVucGFyc2VkIEFDSyBibG9jaykgdG8gaGFuZCB0byB0 aGUgQUNLIHByb2Nlc3NpbmcgdGhyZWFkLg0KPj4gPj4NCj4+ID4+IC1Fa3INCj4+ID4+DQo+PiA+ Pg0KPj4gPj4+DQo+PiA+Pj4gT24gU2F0LCBKdW4gMTYsIDIwMTggYXQgNjoxOSBBTSBNYXJ0aW4g VGhvbXNvbg0KPj4gPj4+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4+DQo+PiA+Pj4gd3JvdGU6DQo+PiA+Pj4+DQo+PiA+Pj4+IFdoZW4g d2UgZGlzY3Vzc2VkIHRoaXMgYmVmb3JlLCBzb21lIHBlb3BsZSBvYnNlcnZlZCB0aGF0IHRoaXMg Y3JlYXRlcw0KPj4gPj4+PiBhIG5lZWQgdG8gZW5jb2RlIGluIHR3byBwYXNzZXMuICBUaGF0J3Mg dGhlIHRyYWRlLW9mZiBoZXJlLiAgKE5vdA0KPj4gPj4+PiBleHByZXNzaW5nIGFuIG9waW5pb24u KQ0KPj4gPj4+PiBPbiBGcmksIEp1biAxNSwgMjAxOCBhdCAzOjUxIFBNIEphbmEgSXllbmdhciA8 anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+Pg0KPj4gPj4+PiB3 cm90ZToNCj4+ID4+Pj4gPg0KPj4gPj4+PiA+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9u IG9uIHRoaXMuIEknbSBjZXJ0YWlubHkgbm90IG9wcG9zZWQgdG8NCj4+ID4+Pj4gPiBpdC4NCj4+ ID4+Pj4gPiBEb2VzIGFueW9uZSBoYXZlIGEgc3Ryb25nIG9wcG9zaXRpb24/DQo+PiA+Pj4+ID4N Cj4+ID4+Pj4gPiBPbiBGcmksIEp1biAxNSwgMjAxOCBhdCAzOjEwIFBNIFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuDQo+PiA+Pj4+ID4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1p Y3Jvc29mdC5jb20+PiB3cm90ZToNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gSSBhZ3JlZSBhcyB3 ZWxsIHNpbmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBlciBwYWNrZXQgcHJvY2Vzc2luZw0KPj4g Pj4+PiA+PiBvdmVyaGVhZC4gQUNLcyBhcmUgZ29pbmcgdG8gYmUgdGhlIHNlY29uZCBtb3N0IGNv bW1vbiBmcmFtZSB0eXBlDQo+PiA+Pj4+ID4+IHNvIG5vDQo+PiA+Pj4+ID4+IG9iamVjdGlvbnMg dG8gc3BlY2lhbCBjYXNpbmcuDQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+ PiA+Pj4+ID4+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBFcmljDQo+PiA+Pj4+ID4+IFJl c2NvcmxhDQo+PiA+Pj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNSwgMjAxOCA5OjExIEFNDQo+ PiA+Pj4+ID4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPG1haWx0 bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4+ID4+Pj4gPj4gQ2M6IEphbmEgSXllbmdhciA8 anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+PjsgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQo+PiA+Pj4+ID4+IFN1YmplY3Q6 IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgN Cj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gSSBhZ3JlZSB3 aXRoIE1hbmFzaSBoZXJlLiBUaGlzIGNoYW5nZSB3b3VsZCBhbGxvdyBhY2sgZnJhbWUNCj4+ID4+ Pj4gPj4gcGFyc2luZw0KPj4gPj4+PiA+PiB0byBiZSBtb3JlIHNlbGYtY29udGFpbmVkLCB3aGlj aCBpcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBwYXJzZXINCj4+ID4+Pj4gPj4gYW5kIGFsc28NCj4+ ID4+Pj4gPj4gcG90ZW50aWFsbHkgZm9yIHBhcmFsbGVsaXNtIChiZWNhdXNlIHlvdSBjYW4gcXVp Y2tseSBmaW5kIHRoZQ0KPj4gPj4+PiA+PiBmcmFtZSBhbmQgdGhlbg0KPj4gPj4+PiA+PiBwcm9j ZXNzIGl0IGluIHBhcmFsbGVsKS4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4N Cj4+ID4+Pj4gPj4gLUVrcg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4g Pj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA1 OjIyIFBNLCBEZXZhbCwgTWFuYXNpDQo+PiA+Pj4+ID4+IDxtYW5hc2kuZGV2YWxAaW50ZWwuY29t PG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4gd3JvdGU6DQo+PiA+Pj4+ID4+DQo+PiA+ Pj4+ID4+IEluIGdlbmVyYWwsIHZhcmludHMgcmVxdWlyZSBzb21lIHNwZWNpZmljIGxvZ2ljIGZv ciBwYXJzaW5nLiBUbw0KPj4gPj4+PiA+PiBza2lwDQo+PiA+Pj4+ID4+IG92ZXIgYW55IGhlYWRl ciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkgc2luZ2xlIHZhcmludC4gQXMgdGhlIGNvZGUNCj4+ID4+ Pj4gPj4gc2VlcyBTdHJlYW0NCj4+ID4+Pj4gPj4gYW5kIEFDSyBoZWFkZXJzIG1vc3QgZnJlcXVl bnRseSwgdGhhdCBpcyBteSBmb2N1cy4gIFRoZSBTdHJlYW0NCj4+ID4+Pj4gPj4gZnJhbWUgaGFz IGENCj4+ID4+Pj4gPj4gbGVuZ3RoIGluIGl0cyB0aGlyZCBmaWVsZC4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gQUNLIHBhcnNpbmcsIGhvd2V2ZXIsIG5l ZWRzIDYgKyAyKm51bV9ibG9ja3MgcmVhZHMgdG8gaWRlbnRpZnkNCj4+ID4+Pj4gPj4gbGVuZ3Ro LiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKAmGxhcmdlc3QgYWNrbm93bGVkZ2Vk4oCZ LCDigJhBQ0sNCj4+ID4+Pj4gPj4gZGVsYXnigJkgYW5kDQo+PiA+Pj4+ID4+IOKAmEFDSyBibG9j ayBjb3VudOKAmS4gVGhlIHBhaW4gcG9pbnQgaXMgdGhlIHRvdGFsIG51bWJlciBvZiBjeWNsZXMN Cj4+ID4+Pj4gPj4gcGFyc2UgYW4NCj4+ID4+Pj4gPj4gQUNLLiBJZiBJIGFtIHByb2Nlc3Npbmcg MTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBwYWNrZXRzDQo+PiA+Pj4+ID4+IGhhdmUg YQ0KPj4gPj4+PiA+PiBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2ln bmlmaWNhbnQgYm90dGxlbmVjay4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4N Cj4+ID4+Pj4gPj4gVGhhbmtzLA0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBNYW5hc2kNCj4+ID4+ Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIEphbmENCj4+ID4+Pj4gPj4gSXllbmdhcg0KPj4gPj4+PiA+PiBTZW50OiBNb25kYXksIEp1 bmUgMTEsIDIwMTggMzoxMSBQTQ0KPj4gPj4+PiA+PiBUbzogRGV2YWwsIE1hbmFzaSA8bWFuYXNp LmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbT4+OyBRVUlDIFdH DQo+PiA+Pj4+ID4+IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NCj4+ID4+ Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdp dGggQUNLIGxlbmd0aA0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+PiBZb3UncmUgcmlnaHQgdGhhdCB3ZSBubyBsb25nZXIgaGF2ZSB0aGUgYWJpbGl0eSB0byBz a2lwIGFuIEFDSw0KPj4gPj4+PiA+PiBmcmFtZSwNCj4+ID4+Pj4gPj4gYW5kIHRoaXMgY3JlcHQg aW4gd2hlbiB3ZSBtb3ZlZCB0byB2YXJpbnRzLg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBJIGJl bGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1l cyBub3QNCj4+ID4+Pj4gPj4ganVzdCBBQ0tzLCBzaW5jZSBpZHMsIHBhY2tldCBudW1iZXJzLCBh bmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzDQo+PiA+Pj4+ID4+IGFyZSBub3cgYWxsDQo+PiA+Pj4+ ID4+IHZhcmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUg dmFyaW50IGZpZWxkcw0KPj4gPj4+PiA+PiBpbiB0aG9zZQ0KPj4gPj4+PiA+PiBmcmFtZXMuIElm IHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNraXAgdmFyaW50cywgdGhlbg0KPj4gPj4+ PiA+PiBza2lwcGluZyB0aGUgYWNrDQo+PiA+Pj4+ID4+IGJsb2NrIHNlY3Rpb24gaXMgbWVyZWx5 IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2srMSkNCj4+ID4+Pj4gPj4gdGlt ZXMuIERvDQo+PiA+Pj4+ID4+IHlvdSBzZWUgc3BlY2lmaWMgdmFsdWUgaW4gc2tpcHBpbmcgQUNL IGZyYW1lcyBvdmVyIHRoZSBvdGhlcg0KPj4gPj4+PiA+PiBjb250cm9sIGZyYW1lcz8NCj4+ID4+ Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgODo0MyBBTSBEbWl0cmkgVGlraG9ub3YN Cj4+ID4+Pj4gPj4gPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb208bWFpbHRvOmR0aWtob25v dkBsaXRlc3BlZWR0ZWNoLi5jb20+PiB3cm90ZToNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gT24g TW9uLCBKdW4gMTEsIDIwMTggYXQgMDM6MzM6MzVQTSArMDAwMCwgRGV2YWwsIE1hbmFzaSB3cm90 ZToNCj4+ID4+Pj4gPj4gPiAtICAgICAgICBNb3ZpbmcgdGhlIEFDSyBsZW5ndGggdG8gdGhlIGZy b250IG9mIHRoZSBBQ0sgYWxsb3dzDQo+PiA+Pj4+ID4+ID4gdGhlDQo+PiA+Pj4+ID4+ID4gICAg ICAgICAgZmxleGliaWxpdHkgb2YgZWl0aGVyIHJlYWRpbmcgdGhlIGVudGlyZSBBQ0sgb3IgcmVh ZGluZw0KPj4gPj4+PiA+PiA+IHRoZQ0KPj4gPj4+PiA+PiA+ICAgICAgICAgIGZpcnN0IDE2IGJp dHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4gVGhpcyBpcyBhDQo+PiA+Pj4+ID4+ID4g dXNlZnVsDQo+PiA+Pj4+ID4+ID4gICAgICAgICAgZmVhdHVyZSBmb3IgdGhlIGNhc2Ugd2hlcmUg QUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQgaW50bw0KPj4gPj4+PiA+PiA+ICAgICAgICAgIG11bHRp cGxlIGxheWVycy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3IgdGhpcyBpcyBydW4NCj4+ID4+ Pj4gPj4gPiBvbiwNCj4+ID4+Pj4gPj4gPiAgICAgICAgICB0aGVyZSBhcmUgZGlmZmVyZW50IGFk dmFudGFnZXMgLQ0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBKdXN0IGEgbm90ZS4gIEluIG15IGV4 cGVyaWVuY2UsIHRoZSBjb3N0IG9mIHBhcnNpbmcgYW4gQUNLIGZyYW1lDQo+PiA+Pj4+ID4+IGlz DQo+PiA+Pj4+ID4+IG5lZ2xpZ2libGUgY29tcGFyZWQgdG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2lu ZyBhbiBBQ0sgZnJhbWU6IHRoYXQNCj4+ID4+Pj4gPj4gaXMsDQo+PiA+Pj4+ID4+IHBva2luZyBh dCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBuZXdseSBBQ0tlZCBwYWNrZXRz Lg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiAgIC0gRG1pdHJpLg0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+Pg0KPj4gPj4+Pg0KPj4gPj4NCj4+ID4NCj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiBLYXp1aG8g T2t1DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0K --_000_1F436ED13A22A246A59CA374CBC543998B83AB21ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjU0MjEzNzIwOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4ODc2MTYzOCA2NzY5ODcx MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTc3OTA2Mjc4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4ODc2MTYzOCA2NzY5 ODcxMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkhpIEFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkkgaGF2ZSBtYWRlIGEgbGlzdCBv ZiBvYmplY3Rpb25zIHRvIHRoZSBwcm9wb3NhbCBhbmQgdGhlIHNvbHV0aW9ucyB0byB0aG9zZSBv YmplY3Rpb25zIGRpc2N1c3NlZCBvbiB0aGlzIHRocmVhZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Q28t ZXhpc3RlbmNlIG9mIGxlbmd0aCBmaWVsZCB3aXRoIEVDTiBmaWVsZCBhbmQgQUNLIGJsb2Nrcy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMw Ij5DaHJpc3RpYW4gc3VnZ2VzdGVkIHRvIG1vdmUgdGhlIEVDTiBmaWVsZHMgdG8gcHJlY2VkZSB0 aGUgQUNLIGJsb2Nrcy4gVGhpcyBpcyBhbiBlbGVnYW50IHNvbHV0aW9uLiBQYXJzaW5nIGVudGly ZSBsaXN0IG9mIEFDSyBibG9ja3MgdG8gcmV2aWV3IEVDTiBiaXRzDQogd291bGQgaGF2ZSBiZWVu IGFubm95aW5nLCBldmVuIHRob3VnaCBpdCBjYW4gd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMw Ij5UaGVyZSBhcmUgdHdvIGNhc2VzIHRvIGJlIHBhcnNlZCDigJMgZW50aXJlIEFDSyBhbmQgcGFy c2UgQUNLIHRvIGlkZW50aWZ5IGxlbmd0aC4gVGhlcmUgYXJlIHNvbWUgcmVzZXJ2YXRpb25zIHdo ZW4gQUNLIHBhcnNpbmcgZ2V0cyBoYXJkZXIgZm9yIHRoZSBjYXNlDQogd2hlcmUgdGhlIGVudGly ZSBoZWFkZXIgbmVlZHMgdG8gYmUgcGFyc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5BZ3JlZW1lbnQgZnJvbSBzZXZlcmFsIGZvbGtz IGhlcmUuIEluIHRoZSBvcmlnaW5hbCBBQ0sgZGVmaW5lZCBpbiBkcmFmdCAxMiBvZiB0aGUgc2xp ZGUsIG9uZSB3b3VsZCBjb3VudCBkb3duIG51bWJlciBvZiBBQ0sgYmxvY2tzIHRvIGdldCB0byB0 aGUgZW5kIG9mDQogdGhlIHBhY2tldC4gSW4gdGhlIHByb3Bvc2FsIEkgbWFkZSwgb25lIHdvdWxk IGNvdW50IGRvd24gdGhlIGxlbmd0aCB0byBpZGVudGlmeSB0aGUgZW5kIG9mIHRoZSBwYWNrZXQu IFRoZSBsb2dpYyBpcyB2ZXJ5IHNpbWlsYXIgaW4gY3ljbGUgY291bnQgYW5kIGNvbXBsZXhpdHku IFNldmVyYWwgZm9sa3MgYWxzbyBjb21tZW50ZWQgdG8gdGhpcyBlZmZlY3QuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw NzBDMCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3MEMwIj5NdWx0aS10aHJlYWRlZCBwYWNrZXQgcHJvY2Vzc2luZw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkkgd291bGQg ZXhwZWN0IHRoYXQgdGhlcmUgYXJlIDEwcyBvZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1c2Ug YXQgYW55IHRpbWUgZm9yIGEgc2VydmVyIHdpdGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRpLXRo cmVhZGluZyB0byBoYW5kbGUgZWFjaCBvZiB0aGVzZQ0KIGZsb3dzIC8gY29ubmVjdGlvbnMgaW4g cGFyYWxsZWwgaXMgbmVjZXNzaXR5IHRvIGJlIGFibGUgdG8gc3VwcG9ydCBsYXJnZSBudW1iZXIg b2YgY29ubmVjdGlvbnMgb24gYSBoaWdoIHNwZWVkIGxpbmsuIFR4IHNlZ21lbnRhdGlvbiwgUngg Y29hbGVzY2luZyBhcmUgd2VsbCBrbm93biBzdHJhdGVnaWVzIHRvIHJlZHVjZSB0aGUgcHJvY2Vz c2luZyBjb3N0LiBJbiBpbml0aWFsIHN0YWdlcywgY29kZSBpcyBvZnRlbiB3cml0dGVuIGFzIGEg c2luZ2xlLXRocmVhZGVkDQogYW5kIHRoZW4gcmUtZmFjdG9yZWQgdG8gcGFyYWxsZWxpemUgY3lj bGUgaW50ZW5zaXZlIG9wZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93IHRoaXMgcHJvdG9jb2wg dG8gc2NhbGUgaW4gZnV0dXJlLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgZG8gbm90IHByZWNsdWRlIHRo aXMgY2FzZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5k LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkluY3JlYXNlIGluIEFDSyBzaXplIGJ5 IDEgYnl0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwNzBDMCI+SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzZXJpb3VzIGlzc3VlIGJ1dCBpZiBmb2xr cyBidXQgd2UgY2FuIGNvbnNpZGVyIG1ha2luZyB0aGlzIGEgdmFyaW50LCBpZiBvdGhlcnMgaGF2 ZSBzdHJvbmcgZmVlbGluZ3MgYWJvdXQgaXQuIEl04oCZcyBhIHRyYWRlLW9mZiA6DQogMiByZWFk cyB0byBzYXZlIDEgYnl0ZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPmUuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+RXZlcnkg PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5lbmNvZGFibGUgdmFsdWUgc2hvdWxk IGJlIHZhbGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5Ob3Qg ZXZlcnkgbGVuZ3RoIHdpbGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVuZ3Rocy4g VGhpcyBzYW1lIGlzc3VlIGFpbHMgdGhlIOKAmHBheWxvYWQgbGVuZ3Ro4oCZIGluIFFVSUMgaGVh ZGVyLiBOb3Qgb25seSBkb2VzIHRoZSBpc3N1ZSBleGlzdCBmb3Igc21hbGwgdmFsdWVzLCBpdCBh bHNvIGFwcGxpZXMNCiB0byBsYXJnZSB2YWx1ZXMgc2luY2UgZGF0YSBzdHJlYW0gd2lsbCBiZSBz ZW50IGFmdGVyIGNyeXB0byBuZWdvdGlhdGlvbi4gJm5ic3A7RS5nLiAmbmJzcDstIGhvdyBkb2Vz IG9uZSBjcmFmdCBhIHBheWxvYWQgd2l0aCA2MiBiaXQgcGF5bG9hZCBsZW5ndGggaW4gYSBsYXJn ZSBoZWFkZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5NYW5hc2k8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9fX19fcmVwbHlzZXBhcmF0b3IiPjwvYT48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0ZW4gU2VlbWFubiBbbWFp bHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwg SnVuZSAxNywgMjAxOCA2OjU5IEFNPGJyPg0KPGI+VG86PC9iPiBLYXp1aG8gT2t1ICZsdDtrYXp1 aG9va3VAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0 dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBFcmljIFJlc2NvcmxhICZsdDtla3JA cnRmbS5jb20mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs7IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50 aG9tc29uQGdtYWlsLmNvbSZndDs7IERldmFsLCBNYW5hc2kNCiAmbHQ7bWFuYXNpLmRldmFsQGlu dGVsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2Ug QUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1heWJlIGl0J3Mgc3BlY2lmaWMgdG8gR28sIGJ1dCBJJ20gdXNpbmcgYSBz aW5nbGUgaW8uUmVhZGVyIGZvciB0aGUgd2hvbGUgcGFja2V0LCBzbyBhcyBsb25nIGFzIHRoZSBw YWNrZXQgcGF5bG9hZCBpcyBsb25nIGVub3VnaCwgdGhlIHZhcmludCBwYXJzaW5nIHdpbGwgbm90 IGZhaWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24n dCB0aGluayB0aGF0IHNwZWNpZmljcyBvZiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVyIGhl cmUgdGhvdWdoLCBhbmQgSSdtIHN1cmUgYm90aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25h Ymx5IGltcGxlbWVudGVkIGluIEMgYXMgd2VsbCBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdtIG9w cG9zZWQgdG8gTWFuYXNpJ3MgcHJvcG9zYWwgYXJlIHRoYXQgaXQgbW92ZXMgdXMgYXdheSBmcm9t IHRoZQ0KIHByaW5jaXBsZSB0aGF0IG9ubHkgcmVhc29uYWJsZSB2YWx1ZXMgc2hvdWxkIGJlIGVu Y29kYWJsZSwgYW5kIHRoYXQgaXQgaW5jcmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUs IGZvciB0aGUgcXVlc3Rpb25hYmxlIGJlbmVmaXQgb2YgYmVpbmcgYWJsZSB0byBwYXJhbGxlbGlz ZSB0aGUgZnJhbWUgcGFyc2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEthenVobyBP a3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIj5rYXp1aG9va3VAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE4LTA2LTE3IDIyOjM2IEdNVCYjNDM7MDk6MDAgTWFy dGVuIFNlZW1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0 OyBBdCBsZWFzdCBmb3IgbXkgaW1wbGVtZW50YXRpb24sIHBhcnNpbmcgZG9lc24ndCBiZWNvbWUg ZWFzaWVyLCBpdCBiZWNvbWVzPGJyPg0KJmd0OyBtb3JlIGNvbXBsZXggd2l0aCB0aGlzIHByb3Bv c2FsLiBNeSB2YXJpbnQtcGFyc2VyIGFsd2F5cyBjb25zdW1lcyBhcyBtYW55PGJyPg0KJmd0OyBi eXRlcyBhcyB0aGUgdmFyaW50IHJlcXVpcmVzLCBzbyBhZnRlciBwYXJzaW5nIGEgdmFyaW50LCBJ J2QgaGF2ZSB0bzxicj4NCiZndDsgaW50cm9kdWNlIGFuIGFkZGl0aW9uYWwgY2hlY2sgdGhhdCB0 aGlzIGRpZG4ndCBvdmVyZmxvdyB0aGUgQUNLIGxlbmd0aCAoZS5nLjxicj4NCiZndDsgY29uc2lk ZXIgdGhhdCBJIHBhcnNlZCB0aGUgQUNLIGZyYW1lIHNvIGZhciB0aGF0IG9ubHkgMiBieXRlcyBh cmUgcmVtYWluaW5nPGJyPg0KJmd0OyBhY2NvcmRpbmcgdG8gQUNLIGxlbmd0aCBmaWVsZCwgYnV0 IHRoZSBuZXh0IHZhcmludCBpcyA0IGJ5dGVzIGxvbmcpLjxicj4NCjxicj4NCklzbid0IHlvdXIg dmFyaW50IHBhcnNlciBjaGVja2luZyB0aGF0IGl0IGhhcyBub3QgKG9yIHdpbGwgbm90KSBydW48 YnI+DQphY3Jvc3MgdGhlIGVuZCBvZiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IEFDSyBi bG9jayBpdCBwYXJzZXM/PGJyPg0KSSdkIGFzc3VtZSB0aGF0IHlvdSB3b3VsZCBiZSBkb2luZyB0 aGF0LCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpczxicj4NCm5lY2Vzc2FyeSB0byBhdm9pZCBidWZm ZXIgb3ZlcnJ1bi48YnI+DQo8YnI+DQpXaGF0IEkgYW0gc2F5aW5nIHRoYXQgdGhhdCBjaGVjayBj b3VsZCBiZSBjb252ZXJ0ZWQgdG8gYSBvdmVycnVuIGNoZWNrPGJyPg0KYWdhaW5zdCB0aGUgZW5k IG9mIHRoZSAmcXVvdDtmcmFtZSBwYXlsb2FkJnF1b3Q7LCBhbmQgdGhhdCBjaGVja2luZyB0aGU8 YnI+DQpyZW1haW5pbmcgYmxvY2sgY291bnQgYmVjb21lcyB1bm5lY2Vzc2FyeSwgaW4gY2FzZSB3 ZSByZXBsYWNlIEFDSzxicj4NCkJsb2NrIENvdW50IHdpdGggQUNLIEZyYW1lIExlbmd0aC48YnI+ DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiBnZW5lcmFsLCB3ZSd2ZSBiZWVuIG1vdmluZyB0aGUg d2lyZSBpbWFnZSB0b3dhcmRzIG1ha2luZyBldmVyeSBlbmNvZGFibGU8YnI+DQomZ3Q7IHZhbHVl IHZhbGlkLiBUaGlzIHByb3Bvc2FsIG1vdmVzIHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBsZTo8 YnI+DQomZ3Q7ICogc29tZSBzbWFsbCB2YWx1ZXMgYXJlIGFsd2F5cyBpbnZhbGlkICh0aGUgbGVu Z3RoIGNhbiBuZXZlciBiZSBiZXR3ZWVuIDA8YnI+DQomZ3Q7IGFuZCAzKTxicj4NCiZndDsgKiBh IGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFsdWVzIGFyZSBpbnZhbGlkIChpZiB0aGUgYm91bmRhcnkg ZmFsbHMgaW5zaWRlIGE8YnI+DQomZ3Q7IHZhcmludCwgYXMgZGVzY3JpYmVkIGFib3ZlKTxicj4N CiZndDsgQm90aCB0aGVzZSBjYXNlcyBjYW4ndCBvY2N1ciB3aXRoIHRoZSBjdXJyZW50IEFDSyBm cmFtZSBmb3JtYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gU3VuLCBKdW4gMTcsIDIwMTggYXQg Nzo1NCBQTSBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIwMTgtMDYtMTcgODozNCBHTVQmIzQzOzA5OjAwIElh biBTd2V0dDxicj4NCiZndDsmZ3Q7ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs6PGJyPg0KJmd0OyZndDsgJmd0OyBJJ20gbm90IGEgZmFuIG9mIHRo aXMgcHJvcG9zYWwsIGJlY2F1c2UgSSB0aGluayBpdCBpcyBpbXByYWN0aWNhbCB0bzxicj4NCiZn dDsmZ3Q7ICZndDsgZHJvcDxicj4NCiZndDsmZ3Q7ICZndDsgdGhlIG51bWJlciBvZiBhY2sgYmxv Y2tzLCBiZWNhdXNlIHdpdGggdGhlIEVDTiBwcm9wb3NhbCBpdCBiZWNvbWVzPGJyPg0KJmd0OyZn dDsgJmd0OyBpbXByYWN0aWNhbGx5IGNvbXBsZXggdG8gcGFyc2UuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBGb3IgdGhlIEVDTiBwcm9wb3NhbCwgYXMgQ2hyaXN0aWFuIGhhcyBzdWdnZXN0 ZWQsIHdlIGNhbiBtb3ZlIHRoZSBFQ048YnI+DQomZ3Q7Jmd0OyBjb3VudGVycyBiZWZvcmUgdGhl IEFDSyBibG9ja3MuIFRoZW4sIGl0IHdvdWxkIG5vdCBiZSBjb21wbGV4IHRvPGJyPg0KJmd0OyZn dDsgcGFyc2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbmQgbXkgdmlldyBpcyB0aGF0 IHBhcnNpbmcgYmVjb21lcyBlYXNpZXIgaWYgd2UgcmVwbGFjZSBBQ0sgQmxvY2s8YnI+DQomZ3Q7 Jmd0OyBDb3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBOb3csIHdpdGggQUNLIEJsb2NrIENvdW50LCB3ZSBuZWVkIHRvIGNoZWNrIHRoZSByZW1h aW5pbmcgbnVtYmVyIG9mPGJyPg0KJmd0OyZndDsgYmxvY2tzIGFuZCB0aGUgcmVtYWluaW5nIHNw YWNlIGluIHRoZSBwYWNrZXQgcGF5bG9hZCBmb3IgZXZlcnkgYmxvY2s8YnI+DQomZ3Q7Jmd0OyB0 aGF0IHdlIHBhcnNlLiBGYWlsaW5nIHRvIGNoZWNrIGVpdGhlciBsZWFkcyB0byBhIGJ1ZyBvciBh IHNlY3VyaXR5PGJyPg0KJmd0OyZndDsgaXNzdWUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJZiB3ZSBzd2l0Y2ggdG8gQUNLIEZyYW1lIExlbmd0aCwgd2UgbmVlZCB0byBvbmx5IGNoZWNr IHRoZSByZW1haW5pbmc8YnI+DQomZ3Q7Jmd0OyBzcGFjZSBpbiB0aGUgZnJhbWUuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgYmlnZ2VzdCBiZW5l Zml0IG9mIHJlcGxhY2luZyBBQ0sgQmxvY2sgQ291bnQ8YnI+DQomZ3Q7Jmd0OyB3aXRoIEFDSyBG cmFtZSBMZW5ndGguIE9UT0ggdGhlIGRvd25zaWRlIGlzIHRoYXQgeW91IG5lZWQgZXh0cmEgb25l IHRvPGJyPg0KJmd0OyZndDsgdHdvIGJpdHMgKG9uZSBpZiB0aGUgc2l6ZSBvZiBibG9jayAvIGdh cCBpcyBleHBlY3RlZCB0byBiZSBiZWxvdyA2NSw8YnI+DQomZ3Q7Jmd0OyB0d28gaWYgdGhleSBh cmUgZXhwZWN0ZWQgdG8gYmUgYWJvdmUgdGhhdCkgZm9yIGVuY29kaW5nIEFDSyBGcmFtZTxicj4N CiZndDsmZ3Q7IExlbmd0aCBjb21wYXJlZCB0byBBQ0sgQmxvY2sgQ291bnQuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGF2aW5nIHNhaWQg dGhhdCwgSSBob25lc3RseSB3b25kZXIgaWYgYWxsIHRoZSBmcmFtZXMgY291bGQgaGF2ZSBpdCdz PGJyPg0KJmd0OyZndDsgbGVuZ3RoIGJlaW5nIGVuY29kZWQgKGVpdGhlciBleHBsaWNpdGx5IG9y IGVpdGhlciBhcyBhIHNpZ25hbCB0aGF0PGJyPg0KJmd0OyZndDsgc2F5cyAmcXVvdDt0byB0aGUg ZW5kIG9mIHRoZSBwYWNrZXQmcXVvdDspLiBDb25zaWRlciBzb21ldGhpbmcgbGlrZSBiZWxvdzo8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHwwfCBmcmFtZS10eXBlICg3KSB8IGZyYW1lLXBh eWxvYWQtbGVuZ3RoIChpKSB8IGZyYW1lLXBheWxvYWQgKCopIHw8YnI+DQomZ3Q7Jmd0OyZuYnNw OyBvcjxicj4NCiZndDsmZ3Q7IHwxfCBmcmFtZS10eXBlICg3KSB8IGZyYW1lLXBheWxvYWQgKCop IHw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdoZW4gTVNCIG9mIHRoZSBmaXJzdCBvY3Rl dCBzZXQgdG8gemVybywgdGhlIGxlbmd0aCBvZiB0aGUgZnJhbWU8YnI+DQomZ3Q7Jmd0OyBwYXls b2FkIGlzIGRlc2lnbmF0ZWQgYnkgdGhlIHZhcmludCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3Mg dGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgdHlwZS48YnI+DQomZ3Q7Jmd0OyBXaGVuIE1TQiBvZiB0 aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIG9uZSwgdGhlIGxlbmd0aCBvZiB0aGUgZnJhbWU8YnI+DQom Z3Q7Jmd0OyBwYXlsb2FkIHNwYW5zIHRvIHRoZSBlbmQgb2YgdGhlIHBhY2tldC48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEluIHRoaXMgZW5jb2RpbmcsIHdlIGNhbiBhbHdheXMgb21pdCB0 aGUgTGVuZ3RoIGZpZWxkIG9mIGEgU1RSRUFNPGJyPg0KJmd0OyZndDsgZnJhbWUuIFNvIHRoZSBv dmVyaGVhZCBmb3IgY2Fycnlpbmcgc3RyZWFtIGRhdGEgd2lsbCBiZSBpbmRpZmZlcmVudCBpbjxi cj4NCiZndDsmZ3Q7IHByYWN0aWNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRm9yIHRo ZSBBQ0sgZnJhbWUsIHdlIGNhbiBvbWl0IHRoZSBBQ0sgQmxvY2sgQ291bnQgZmllbGQuIEFuZCB0 aGU8YnI+DQomZ3Q7Jmd0OyBvdmVyaGVhZCB3aWxsIGJlIG9uZSB0byB0d28gYml0cyBpZiB0aGUg QUNLIGZyYW1lIGlzIHNlbnQgaW4gdGhlPGJyPg0KJmd0OyZndDsgbWlkZGxlIG9mIHRoZSBwYWNr ZXQgKHRoZXJlYnkgdXNpbmcgdGhlIGVuY29kaW5nIHdpdGggZXhwbGljaXQgZnJhbWU8YnI+DQom Z3Q7Jmd0OyBwYXlsb2FkIGxlbmd0aCksIG9yIG9uZSBvY3RldCBvciBtb3JlIHNob3J0ZXIgaWYg QUNLIGlzIHRoZSBsYXN0IGZyYW1lPGJyPg0KJmd0OyZndDsgb2YgdGhlIHBhY2tldC48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIGFyZSBsaWtlbHkgdG8gc2VlIGluY3JlYXNlIG9mIG92 ZXJoZWFkIGZvciBtb3N0IG9mIHRoZSBvdGhlciB0eXBlczxicj4NCiZndDsmZ3Q7IG9mIGZyYW1l cywgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgd291bGQgYmUgYW4gaXNzdWUgY29uc2lkZXJpbmcg dGhhdDxicj4NCiZndDsmZ3Q7IHRoZXkgd2lsbCBiZSBmYXIgc2VsZG9tIHNlZW4gY29tcGFyZWQg dG8gU1RSRUFNcyBhbmQgQUNLcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRvIHN1bW1h cml6ZSwgbXkgYW50aWNpcGF0aW9uIGlzIHRoYXQgd2UgY2FuIG1ha2UgYWxsIHRoZSBmcmFtZXM8 YnI+DQomZ3Q7Jmd0OyBzZWxmLWNvbnRhaW5lZCAoaS5lLiB0aGUgbGVuZ3RoIGNhbiBiZSBkZXRl cm1pbmVkIHdpdGhvdXQgdGhlPGJyPg0KJmd0OyZndDsga25vd2xlZGdlIG9mIGhvdyBlYWNoIGZy YW1lIGlzIGVuY29kZWQpIHdpdGhvdXQgYW55IG92ZXJoZWFkLCBpZiB3ZTxicj4NCiZndDsmZ3Q7 IGFncmVlIG9uIG1ha2luZyB0aGUgZnJhbWUgdHlwZSBzcGFjZSAxIGJpdCBzbWFsbGVyLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRmluYWxseSwgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiB1 c2luZyBhIHNlbGYtY29udGFpbmVkIGVuY29kaW5nIG9mPGJyPg0KJmd0OyZndDsgZnJhbWVzIGlz IHRoYXQgd2Ugd291bGQgaGF2ZSB0aGUgYWJpbGl0eSB0byBpbnRyb2R1Y2UgbmV3IG9wdGlvbmFs PGJyPg0KJmd0OyZndDsgZnJhbWVzIHdpdGhvdXQgbmVnb3RpYXRpb24uIEJ5IG1ha2luZyB0aGUg ZnJhbWVzIHNlbGYtY29udGFpbmVkLCBRVUlDPGJyPg0KJmd0OyZndDsgZW5kcG9pbnRzIHdpbGwg aGF2ZSB0aGUgZnJlZWRvbSBvZiBpZ25vcmluZyB0aGUgZnJhbWVzIHRoYXQgdGhleSBkbzxicj4N CiZndDsmZ3Q7IG5vdCB1bmRlcnN0YW5kLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmVp bmcgYWJsZSB0byBzZW5kIFFVSUMgZnJhbWVzIGRlZmluZWQgaW4gZXh0ZW5zaW9ucyB3aXRob3V0 PGJyPg0KJmd0OyZndDsgbmVnb3RpYXRpbmcgdXNpbmcgVHJhbnNwb3J0IFBhcmFtZXRlcnMgd2ls bCBiZSBhIHdpbiBpbiBib3RoIHRlcm1zIG9mPGJyPg0KJmd0OyZndDsgc2VjdXJpdHkgKGJlY2F1 c2UgY2xpZW50cycgVFAgaXMgc2VudCBpbiBjbGVhcikgYW5kIGZsZXhpYmlsaXR5PGJyPg0KJmd0 OyZndDsgKGJlY2F1c2Ugd2Ugd2lsbCBiZSBwb3NzaWJsZSB0byBzZW5kIHRoZSBleHRlbnNpb25z IGJlZm9yZSB3ZSBmaWd1cmU8YnI+DQomZ3Q7Jmd0OyBvdXQgd2hldGhlciB0aGUgcGVlciBzdXBw b3J0cyB0aGF0IGV4dGVuc2lvbikuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IElm IHdlIGRvbid0IHJlbW92ZSB0aGUgbnVtYmVyIG9mIGFjayBibG9ja3MsIHRoZW4gdGhlIGFjayBm cmFtZSBpczxicj4NCiZndDsmZ3Q7ICZndDsgbGFyZ2VyLDxicj4NCiZndDsmZ3Q7ICZndDsgYnV0 IEkgZG9uJ3QgdGhpbmsgdGhlIGV4dHJhIHNpemUgZmllbGQgaXMgdXNlZnVsIGZvciBtb3N0PGJy Pg0KJmd0OyZndDsgJmd0OyBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyBBbHNv LCBpdCBtZWFucyB0aGUgbGVuZ3RoIGNhbiBkaXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3Ro LCB3aGljaCBhZGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGNvbXBsZXhpdHkgYW5kIHRoZSBwb3NzaWJp bGl0eSBvZiB3cml0aW5nIGVycm9yLXByb25lIGNvZGUuJm5ic3A7IFRoZSBpZGVhIG9mPGJyPg0K Jmd0OyZndDsgJmd0OyBzb21lb25lIG9mZmxvYWRpbmcgYWNrIHByb2Nlc3NpbmcgYW5kIHRoZW4g cHJvY2VlZGluZyB0byB0cnVzdCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGxlbmd0aDxicj4NCiZn dDsmZ3Q7ICZndDsgc2VlbXMgbGlrZSBzb21lb25lIGNvdWxkIGdldCB3cm9uZyBhbmQgY2F1c2Ug c29tZSBjb25jZXJuaW5nIGlzc3Vlcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyBNeSBleHBlcmllbmNlIGlzIG11bHRpdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgaXMg bW9yZSBjb3N0IGFuZCB3b3JrPGJyPg0KJmd0OyZndDsgJmd0OyB0aGFuPGJyPg0KJmd0OyZndDsg Jmd0OyBpdCdzIHdvcnRoLiZuYnNwOyBTdXJlIHlvdSBjYW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0 aCBvbmUgY29ubmVjdGlvbiwgYnV0PGJyPg0KJmd0OyZndDsgJmd0OyB0aGF0PGJyPg0KJmd0OyZn dDsgJmd0OyBzZWVtcyBsaWtlIGFuIGFjYWRlbWljIHByb2JsZW0sIG5vdCBvbmUgZm9yIHdvcmts b2FkcyBJJ3ZlIHNlZW4uPGJyPg0KJmd0OyZndDsgJmd0OyBUeXBpY2FsbHk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IHRoZSBleHRyYSBjb3N0IG9mIG11bHRpdGhyZWFkaW5nIG91dHdlaWdocyBpdHMgdmFs dWUuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgVG8gYmUgY2xlYXIsIEkg ZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBhd2Z1bCBpZGVhLCBidXQgSSBhbHNvIGRvbid0IHNlZTxi cj4NCiZndDsmZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyB2YWx1ZSBhbmQgaXQgYWRk cyBjb21wbGV4aXR5LiZuYnNwOyBJIHJlYWQgTWFuYXNpJ3MgZW1haWwsIGJ1dCBJIGRvbid0IHRo aW5rPGJyPg0KJmd0OyZndDsgJmd0OyBJPGJyPg0KJmd0OyZndDsgJmd0OyB1bmRlcnN0YW5kIHdo eSBhbnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0aWNlLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDQ6MTMgUE0gRXJpYyBSZXNj b3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVr ckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgT24gRnJpLCBKdW4gMTUsIDIwMTggYXQgNjo0NiBQTSwgTWFydGVuIFNl ZW1hbm48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNl ZW1hbm5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGVuc2VlbWFubkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIHByb3Bvc2FsIGluY3JlYXNl cyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lIGJ5IDEgYnl0ZSBpbiB0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgY29tbW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNhc2UgKGxl c3MgdGhhbiA2MyBBQ0sgcmFuZ2VzKSwgc2luY2UgdGhlIEFDSyBsZW5ndGggZmllbGQgaGVyZSBh bHdheXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3VtZXMgMiBieXRlcywgd2hlcmVh cyB0aGUgQUNLIEJsb2NrIENvdW50IGlzIGEgdmFyaWFibGUtbGVuZ3RoPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGludGVnZXIuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IENvbnNpZGVy aW5nIGhvdyBtdWNoIHdvcmsgd2UgcHV0IGludG8gbWluaW1pc2luZyB0aGUgc2l6ZSBvZiB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZnJhbWVzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyB0aGlzIGZlZWxzIGxpa2UgYSBzdGVwIGluIHRoZSB3cm9uZyBkaXJlY3Rpb24uLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRp bmcgdGhlIHByb2Nlc3NpbmcgY29zdCwgSSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4g QUNLPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGZyYW1lPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IHJlcXVpcmVzIGxvb3Bpbmcgb3ZlciBhbmQgbWFraW5nIGNoYW5nZXMgdG8gYSBkYXRh IHN0cnVjdHVyZSB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGtlZXBzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IHRyYWNrIG9mIHNlbnQgcGFja2V0cy4gVGhpcyBpcyBtdWNoIG1v cmUgZXhwZW5zaXZlIHRoYW4gc2ltcGx5IHBhcnNpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBidW5jaCBvZiB2YXJpbnRzIGluIHRoZSBB Q0sgZnJhbWUuIEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBtdWx0aS10aHJlYWRlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGFy c2VyIHdvdWxkIG9mZmVyIGFueSByZWFsLXdvcmxkIHBlcmZvcm1hbmNlIGJlbmVmaXRzLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBJIGRvbid0IHdhbnQgdG8gb3ZlcnN0YXRlIHRoZSBiZW5lZml0IGhlcmUsIGJ1dCBt eSBwb2ludCBpc24ndCB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcGFyc2luZyBpcyBleHBl bnNpdmUgYnV0IHRoYXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBhIG11bHRpdGhyZWFkZWQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBwYWNrZXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwcm9jZXNzaW5n IHN5c3RlbSwgdGhlbiBpdCdzIG5pY2UgdG8gaGF2ZSBhIHNpbXBsZXIgZGF0YSBzdHJ1Y3R1cmUg KHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHVucGFyc2VkIEFDSyBibG9jaykgdG8gaGFuZCB0 byB0aGUgQUNLIHByb2Nlc3NpbmcgdGhyZWFkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgLUVrcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgT24gU2F0LCBKdW4gMTYsIDIwMTggYXQgNjoxOSBBTSBNYXJ0aW4gVGhvbXNvbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gd2UgZGlz Y3Vzc2VkIHRoaXMgYmVmb3JlLCBzb21lIHBlb3BsZSBvYnNlcnZlZCB0aGF0IHRoaXMgY3JlYXRl czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYSBuZWVkIHRvIGVuY29kZSBpbiB0d28g cGFzc2VzLiZuYnNwOyBUaGF0J3MgdGhlIHRyYWRlLW9mZiBoZXJlLiZuYnNwOyAoTm90PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBleHByZXNzaW5nIGFuIG9waW5pb24uKTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT24gRnJpLCBKdW4gMTUsIDIwMTggYXQgMzo1MSBQTSBK YW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5qcmkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBv cGluaW9uIG9uIHRoaXMuIEknbSBjZXJ0YWlubHkgbm90IG9wcG9zZWQgdG88YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgaXQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7IERvZXMgYW55b25lIGhhdmUgYSBzdHJvbmcgb3Bwb3NpdGlvbj88YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsgT24gRnJpLCBKdW4gMTUsIDIwMTggYXQgMzoxMCBQTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh bjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSSBhZ3JlZSBhcyB3ZWxsIHNp bmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBlciBwYWNrZXQgcHJvY2Vzc2luZzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgb3ZlcmhlYWQuIEFDS3MgYXJlIGdvaW5nIHRv IGJlIHRoZSBzZWNvbmQgbW9zdCBjb21tb24gZnJhbWUgdHlwZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgc28gbm88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IG9iamVjdGlvbnMgdG8gc3BlY2lhbCBjYXNpbmcuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBRVUlDIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBFcmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBSZXNjb3JsYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgU2VudDogRnJpZGF5LCBKdW5lIDE1LCAyMDE4IDk6MTEgQU08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBEZXZhbCwgTWFuYXNpICZsdDs8YSBocmVm PSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5k ZXZhbEBpbnRlbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgQ2M6IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBRVUlDIFdH ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg U3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNL IGxlbmd0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSSBh Z3JlZSB3aXRoIE1hbmFzaSBoZXJlLiBUaGlzIGNoYW5nZSB3b3VsZCBhbGxvdyBhY2sgZnJhbWU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHBhcnNpbmc8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRvIGJlIG1vcmUgc2VsZi1jb250YWluZWQs IHdoaWNoIGlzIGFuIGFkdmFudGFnZSBmb3IgdGhlIHBhcnNlcjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgYW5kIGFsc288YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IHBvdGVudGlhbGx5IGZvciBwYXJhbGxlbGlzbSAoYmVjYXVzZSB5b3UgY2Fu IHF1aWNrbHkgZmluZCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IGZyYW1lIGFuZCB0aGVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBw cm9jZXNzIGl0IGluIHBhcmFsbGVsKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgNToy MiBQTSwgRGV2YWwsIE1hbmFzaTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bWFuYXNpLmRldmFsQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IEluIGdlbmVyYWwsIHZhcmludHMgcmVxdWlyZSBzb21lIHNwZWNpZmljIGxvZ2lj IGZvciBwYXJzaW5nLiBUbzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg c2tpcDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgb3ZlciBhbnkgaGVh ZGVyLCBJIGhhdmUgdG8gcmVhZCBldmVyeSBzaW5nbGUgdmFyaW50LiBBcyB0aGUgY29kZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgc2VlcyBTdHJlYW08YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCBBQ0sgaGVhZGVycyBtb3N0IGZyZXF1 ZW50bHksIHRoYXQgaXMgbXkgZm9jdXMuJm5ic3A7IFRoZSBTdHJlYW08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lIGhhcyBhPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsZW5ndGggaW4gaXRzIHRoaXJkIGZpZWxkLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgQUNLIHBhcnNpbmcsIGhvd2V2ZXIs IG5lZWRzIDYgJiM0MzsgMipudW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsZW5ndGguIFRoZXJlIGFyZSB0d28gcmVhZHMg ZWFjaCBmb3Ig4oCYbGFyZ2VzdCBhY2tub3dsZWRnZWTigJksIOKAmEFDSzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZGVsYXnigJkgYW5kPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyDigJhBQ0sgYmxvY2sgY291bnTigJkuIFRoZSBwYWluIHBv aW50IGlzIHRoZSB0b3RhbCBudW1iZXIgb2YgY3ljbGVzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBwYXJzZSBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgQUNLLiBJZiBJIGFtIHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAl IG9mIHRoZSBwYWNrZXRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBo YXZlIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHBpZ2d5YmFja2Vk IEFDSywgdGhlc2UgY3ljbGVzIGJlY29tZXMgYSBzaWduaWZpY2FudCBib3R0bGVuZWNrLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgVGhhbmtzLDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IE1hbmFzaTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IEZyb206IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IEphbmE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEl5ZW5nYXI8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgSnVuZSAx MSwgMjAxOCAzOjExIFBNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBU bzogRGV2YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5j b20iIHRhcmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDs7IFFVSUMg V0c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IFBy b3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgWW91J3JlIHJpZ2h0IHRoYXQg d2Ugbm8gbG9uZ2VyIGhhdmUgdGhlIGFiaWxpdHkgdG8gc2tpcCBhbiBBQ0s8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgYW5kIHRoaXMgY3JlcHQgaW4gd2hlbiB3ZSBtb3ZlZCB0byB2YXJp bnRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEkgYmVsaWV2ZSB5b3VyIHByb2JsZW0gdGhvdWdo IGlzIGdlbmVyYWxseSB0cnVlIG9mIG1vc3QgZnJhbWVzIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsganVzdCBBQ0tzLCBzaW5jZSBpZHMsIHBhY2tldCBudW1iZXJz LCBhbmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBhcmUgbm93IGFsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgdmFyaW50cy4gVG8gc2tpcCBhbnkgZnJhbWUsIHlvdSdsbCBuZWVkIHRvIHBhcnNlIHRo ZSB2YXJpbnQgZmllbGRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBp biB0aG9zZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZnJhbWVzLiBJ ZiB5b3UgaGF2ZSBsb2dpYyB0byBwcm9jZXNzIGFuZCBza2lwIHZhcmludHMsIHRoZW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNraXBwaW5nIHRoZSBhY2s8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGJsb2NrIHNlY3Rpb24gaXMgbWVyZWx5 IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2smIzQzOzEpPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aW1lcy4gRG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHlvdSBzZWUgc3BlY2lmaWMgdmFsdWUgaW4gc2tpcHBpbmcg QUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgY29udHJvbCBmcmFtZXM/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIE1vbiwgSnVuIDExLCAyMDE4 IGF0IDg6NDMgQU0gRG1pdHJpIFRpa2hvbm92PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5j b20iPmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCAwMzozMzozNVBNICYjNDM7MDAw MCwgRGV2YWwsIE1hbmFzaSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsgLSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNb3ZpbmcgdGhlIEFDSyBs ZW5ndGggdG8gdGhlIGZyb250IG9mIHRoZSBBQ0sgYWxsb3dzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZmxleGli aWxpdHkgb2YgZWl0aGVyIHJlYWRpbmcgdGhlIGVudGlyZSBBQ0sgb3IgcmVhZGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGZpcnN0IDE2IGJpdHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4gVGhpcyBp cyBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHVzZWZ1bDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZmVhdHVyZSBmb3IgdGhlIGNhc2Ugd2hlcmUgQUNLIHByb2Nl c3NpbmcgaXMgc3BsaXQgaW50bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXVsdGlwbGUgbGF5ZXJz LiBEZXBlbmRpbmcgb24gdGhlIHByb2Nlc3NvciB0aGlzIGlzIHJ1bjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyBvbiw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRo ZXJlIGFyZSBkaWZmZXJlbnQgYWR2YW50YWdlcyAtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSnVz dCBhIG5vdGUuJm5ic3A7IEluIG15IGV4cGVyaWVuY2UsIHRoZSBjb3N0IG9mIHBhcnNpbmcgYW4g QUNLIGZyYW1lPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbmVnbGlnaWJsZSBjb21wYXJlZCB0 byB0aGUgY29zdCBvZiBwcm9jZXNzaW5nIGFuIEFDSyBmcmFtZTogdGhhdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaXMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBwb2tpbmcgYXQgdmFyaW91cyBtZW1vcnkgbG9jYXRpb25zIHRvIGRpc2Nh cmQgbmV3bHkgQUNLZWQgcGFja2V0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDstIERtaXRyaS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLTxicj4N CiZndDsmZ3Q7IEthenVobyBPa3U8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpLYXp1 aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_1F436ED13A22A246A59CA374CBC543998B83AB21ORSMSX111amrcor_-- From nobody Tue Jun 19 11:21:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608361311C4 for ; Tue, 19 Jun 2018 11:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHhjqj_6YGv5 for ; Tue, 19 Jun 2018 11:21:40 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 C385D130E1F for ; Tue, 19 Jun 2018 11:21:40 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 11:21:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,243,1526367600"; d="scan'208,217";a="238526399" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 19 Jun 2018 11:21:36 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Jun 2018 11:21:36 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX157.amr.corp.intel.com ([169.254.9.202]) with mapi id 14.03.0319.002; Tue, 19 Jun 2018 11:21:35 -0700 From: "Deval, Manasi" To: 'Marten Seemann' , 'Kazuho Oku' CC: 'Ian Swett' , 'Eric Rescorla' , 'Jana Iyengar' , "'Praveen Balasubramanian'" , 'IETF QUIC WG' , 'Martin Thomson' Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFyw Date: Tue, 19 Jun 2018 18:21:35 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGEwMjMxZmItNjBhOS00YjM2LWFjOTAtNDVhYTVjMTM0NDc1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQndEZTVoQmltcHdcL0Z6TXRTc2dib0oyb1hDRnZZVGRuMitPdDBpM1wvTDRTcG9FSG5XV3VVNTNMbFU1VEZiME5mIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B83EC27ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:21:47 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B83EC27ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpEbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRvIGNyZWF0ZSBhIG5ldyBQUj8N Cg0KVGhhbmtzLA0KTWFuYXNpDQoNCkZyb206IERldmFsLCBNYW5hc2kNClNlbnQ6IFN1bmRheSwg SnVuZSAxNywgMjAxOCAyOjI1IFBNDQpUbzogTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5A Z21haWwuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT4NCkNjOiBJYW4gU3dl dHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47IEVyaWMgUmVzY29ybGEg PGVrckBydGZtLmNvbT47IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPjsgUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0K U3ViamVjdDogUkU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNL IGxlbmd0aA0KDQpIaSBBbGwsDQoNCkkgaGF2ZSBtYWRlIGEgbGlzdCBvZiBvYmplY3Rpb25zIHRv IHRoZSBwcm9wb3NhbCBhbmQgdGhlIHNvbHV0aW9ucyB0byB0aG9zZSBvYmplY3Rpb25zIGRpc2N1 c3NlZCBvbiB0aGlzIHRocmVhZC4NCg0KDQphLiAgICAgIENvLWV4aXN0ZW5jZSBvZiBsZW5ndGgg ZmllbGQgd2l0aCBFQ04gZmllbGQgYW5kIEFDSyBibG9ja3MuDQoNCg0KDQpDaHJpc3RpYW4gc3Vn Z2VzdGVkIHRvIG1vdmUgdGhlIEVDTiBmaWVsZHMgdG8gcHJlY2VkZSB0aGUgQUNLIGJsb2Nrcy4g VGhpcyBpcyBhbiBlbGVnYW50IHNvbHV0aW9uLiBQYXJzaW5nIGVudGlyZSBsaXN0IG9mIEFDSyBi bG9ja3MgdG8gcmV2aWV3IEVDTiBiaXRzIHdvdWxkIGhhdmUgYmVlbiBhbm5veWluZywgZXZlbiB0 aG91Z2ggaXQgY2FuIHdvcmsuDQoNCg0KDQpiLiAgICAgIFRoZXJlIGFyZSB0d28gY2FzZXMgdG8g YmUgcGFyc2VkIOKAkyBlbnRpcmUgQUNLIGFuZCBwYXJzZSBBQ0sgdG8gaWRlbnRpZnkgbGVuZ3Ro LiBUaGVyZSBhcmUgc29tZSByZXNlcnZhdGlvbnMgd2hlbiBBQ0sgcGFyc2luZyBnZXRzIGhhcmRl ciBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGVudGlyZSBoZWFkZXIgbmVlZHMgdG8gYmUgcGFyc2Vk Lg0KDQoNCg0KQWdyZWVtZW50IGZyb20gc2V2ZXJhbCBmb2xrcyBoZXJlLiBJbiB0aGUgb3JpZ2lu YWwgQUNLIGRlZmluZWQgaW4gZHJhZnQgMTIgb2YgdGhlIHNsaWRlLCBvbmUgd291bGQgY291bnQg ZG93biBudW1iZXIgb2YgQUNLIGJsb2NrcyB0byBnZXQgdG8gdGhlIGVuZCBvZiB0aGUgcGFja2V0 LiBJbiB0aGUgcHJvcG9zYWwgSSBtYWRlLCBvbmUgd291bGQgY291bnQgZG93biB0aGUgbGVuZ3Ro IHRvIGlkZW50aWZ5IHRoZSBlbmQgb2YgdGhlIHBhY2tldC4gVGhlIGxvZ2ljIGlzIHZlcnkgc2lt aWxhciBpbiBjeWNsZSBjb3VudCBhbmQgY29tcGxleGl0eS4gU2V2ZXJhbCBmb2xrcyBhbHNvIGNv bW1lbnRlZCB0byB0aGlzIGVmZmVjdC4NCg0KDQoNCmMuICAgICAgTXVsdGktdGhyZWFkZWQgcGFj a2V0IHByb2Nlc3NpbmcNCg0KDQoNCkkgd291bGQgZXhwZWN0IHRoYXQgdGhlcmUgYXJlIDEwcyBv ZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1c2UgYXQgYW55IHRpbWUgZm9yIGEgc2VydmVyIHdp dGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRpLXRocmVhZGluZyB0byBoYW5kbGUgZWFjaCBvZiB0 aGVzZSBmbG93cyAvIGNvbm5lY3Rpb25zIGluIHBhcmFsbGVsIGlzIG5lY2Vzc2l0eSB0byBiZSBh YmxlIHRvIHN1cHBvcnQgbGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIG9uIGEgaGlnaCBzcGVl ZCBsaW5rLiBUeCBzZWdtZW50YXRpb24sIFJ4IGNvYWxlc2NpbmcgYXJlIHdlbGwga25vd24gc3Ry YXRlZ2llcyB0byByZWR1Y2UgdGhlIHByb2Nlc3NpbmcgY29zdC4gSW4gaW5pdGlhbCBzdGFnZXMs IGNvZGUgaXMgb2Z0ZW4gd3JpdHRlbiBhcyBhIHNpbmdsZS10aHJlYWRlZCBhbmQgdGhlbiByZS1m YWN0b3JlZCB0byBwYXJhbGxlbGl6ZSBjeWNsZSBpbnRlbnNpdmUgb3BlcmF0aW9ucy4gSW4gb3Jk ZXIgdG8gYWxsb3cgdGhpcyBwcm90b2NvbCB0byBzY2FsZSBpbiBmdXR1cmUsIEkgd291bGQgc3Vn Z2VzdCB3ZSBkbyBub3QgcHJlY2x1ZGUgdGhpcyBjYXNlLg0KDQoNCg0KZC4gICAgICBJbmNyZWFz ZSBpbiBBQ0sgc2l6ZSBieSAxIGJ5dGUuDQoNCg0KDQpJIGRvIG5vdCBzZWUgdGhpcyBhcyBhIHNl cmlvdXMgaXNzdWUgYnV0IGlmIGZvbGtzIGJ1dCB3ZSBjYW4gY29uc2lkZXIgbWFraW5nIHRoaXMg YSB2YXJpbnQsIGlmIG90aGVycyBoYXZlIHN0cm9uZyBmZWVsaW5ncyBhYm91dCBpdC4gSXTigJlz IGEgdHJhZGUtb2ZmIDogMiByZWFkcyB0byBzYXZlIDEgYnl0ZS4NCg0KDQoNCmUuICAgICAgRXZl cnkgZW5jb2RhYmxlIHZhbHVlIHNob3VsZCBiZSB2YWxpZA0KDQpOb3QgZXZlcnkgbGVuZ3RoIHdp bGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVuZ3Rocy4gVGhpcyBzYW1lIGlzc3Vl IGFpbHMgdGhlIOKAmHBheWxvYWQgbGVuZ3Ro4oCZIGluIFFVSUMgaGVhZGVyLiBOb3Qgb25seSBk b2VzIHRoZSBpc3N1ZSBleGlzdCBmb3Igc21hbGwgdmFsdWVzLCBpdCBhbHNvIGFwcGxpZXMgdG8g bGFyZ2UgdmFsdWVzIHNpbmNlIGRhdGEgc3RyZWFtIHdpbGwgYmUgc2VudCBhZnRlciBjcnlwdG8g bmVnb3RpYXRpb24uICBFLmcuICAtIGhvdyBkb2VzIG9uZSBjcmFmdCBhIHBheWxvYWQgd2l0aCA2 MiBiaXQgcGF5bG9hZCBsZW5ndGggaW4gYSBsYXJnZSBoZWFkZXI/DQoNCg0KDQoNCg0KVGhhbmtz LA0KDQpNYW5hc2kNCg0KDQoNCkZyb206IE1hcnRlbiBTZWVtYW5uIFttYWlsdG86bWFydGVuc2Vl bWFubkBnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIEp1bmUgMTcsIDIwMTggNjo1OSBBTQ0KVG86 IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5j b20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgSmFuYSBJeWVuZ2FyIDxq cmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbT4+OyBQcmF2ZWVuIEJh bGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+ PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj47IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5j b208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+Pg0KU3ViamVjdDogUmU6IFByb3Bvc2Fs IHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KDQpNYXliZSBpdCdz IHNwZWNpZmljIHRvIEdvLCBidXQgSSdtIHVzaW5nIGEgc2luZ2xlIGlvLlJlYWRlciBmb3IgdGhl IHdob2xlIHBhY2tldCwgc28gYXMgbG9uZyBhcyB0aGUgcGFja2V0IHBheWxvYWQgaXMgbG9uZyBl bm91Z2gsIHRoZSB2YXJpbnQgcGFyc2luZyB3aWxsIG5vdCBmYWlsLg0KSSBkb24ndCB0aGluayB0 aGF0IHNwZWNpZmljcyBvZiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVyIGhlcmUgdGhvdWdo LCBhbmQgSSdtIHN1cmUgYm90aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25hYmx5IGltcGxl bWVudGVkIGluIEMgYXMgd2VsbCBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdtIG9wcG9zZWQgdG8g TWFuYXNpJ3MgcHJvcG9zYWwgYXJlIHRoYXQgaXQgbW92ZXMgdXMgYXdheSBmcm9tIHRoZSBwcmlu Y2lwbGUgdGhhdCBvbmx5IHJlYXNvbmFibGUgdmFsdWVzIHNob3VsZCBiZSBlbmNvZGFibGUsIGFu ZCB0aGF0IGl0IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lLCBmb3IgdGhlIHF1 ZXN0aW9uYWJsZSBiZW5lZml0IG9mIGJlaW5nIGFibGUgdG8gcGFyYWxsZWxpc2UgdGhlIGZyYW1l IHBhcnNlci4NCg0KT24gU3VuLCBKdW4gMTcsIDIwMTggYXQgODo0OCBQTSBLYXp1aG8gT2t1IDxr YXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4gd3JvdGU6DQoy MDE4LTA2LTE3IDIyOjM2IEdNVCswOTowMCBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFubkBn bWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj46DQo+IEF0IGxlYXN0IGZv ciBteSBpbXBsZW1lbnRhdGlvbiwgcGFyc2luZyBkb2Vzbid0IGJlY29tZSBlYXNpZXIsIGl0IGJl Y29tZXMNCj4gbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50LXBhcnNl ciBhbHdheXMgY29uc3VtZXMgYXMgbWFueQ0KPiBieXRlcyBhcyB0aGUgdmFyaW50IHJlcXVpcmVz LCBzbyBhZnRlciBwYXJzaW5nIGEgdmFyaW50LCBJJ2QgaGF2ZSB0bw0KPiBpbnRyb2R1Y2UgYW4g YWRkaXRpb25hbCBjaGVjayB0aGF0IHRoaXMgZGlkbid0IG92ZXJmbG93IHRoZSBBQ0sgbGVuZ3Ro IChlLmcuDQo+IGNvbnNpZGVyIHRoYXQgSSBwYXJzZWQgdGhlIEFDSyBmcmFtZSBzbyBmYXIgdGhh dCBvbmx5IDIgYnl0ZXMgYXJlIHJlbWFpbmluZw0KPiBhY2NvcmRpbmcgdG8gQUNLIGxlbmd0aCBm aWVsZCwgYnV0IHRoZSBuZXh0IHZhcmludCBpcyA0IGJ5dGVzIGxvbmcpLg0KDQpJc24ndCB5b3Vy IHZhcmludCBwYXJzZXIgY2hlY2tpbmcgdGhhdCBpdCBoYXMgbm90IChvciB3aWxsIG5vdCkgcnVu DQphY3Jvc3MgdGhlIGVuZCBvZiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IEFDSyBibG9j ayBpdCBwYXJzZXM/DQpJJ2QgYXNzdW1lIHRoYXQgeW91IHdvdWxkIGJlIGRvaW5nIHRoYXQsIGJl Y2F1c2UgSSB0aGluayB0aGF0IGlzDQpuZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4u DQoNCldoYXQgSSBhbSBzYXlpbmcgdGhhdCB0aGF0IGNoZWNrIGNvdWxkIGJlIGNvbnZlcnRlZCB0 byBhIG92ZXJydW4gY2hlY2sNCmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgImZyYW1lIHBheWxvYWQi LCBhbmQgdGhhdCBjaGVja2luZyB0aGUNCnJlbWFpbmluZyBibG9jayBjb3VudCBiZWNvbWVzIHVu bmVjZXNzYXJ5LCBpbiBjYXNlIHdlIHJlcGxhY2UgQUNLDQpCbG9jayBDb3VudCB3aXRoIEFDSyBG cmFtZSBMZW5ndGguDQoNCj4NCj4gSW4gZ2VuZXJhbCwgd2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdp cmUgaW1hZ2UgdG93YXJkcyBtYWtpbmcgZXZlcnkgZW5jb2RhYmxlDQo+IHZhbHVlIHZhbGlkLiBU aGlzIHByb3Bvc2FsIG1vdmVzIHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBsZToNCj4gKiBzb21l IHNtYWxsIHZhbHVlcyBhcmUgYWx3YXlzIGludmFsaWQgKHRoZSBsZW5ndGggY2FuIG5ldmVyIGJl IGJldHdlZW4gMA0KPiBhbmQgMykNCj4gKiBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFsdWVzIGFy ZSBpbnZhbGlkIChpZiB0aGUgYm91bmRhcnkgZmFsbHMgaW5zaWRlIGENCj4gdmFyaW50LCBhcyBk ZXNjcmliZWQgYWJvdmUpDQo+IEJvdGggdGhlc2UgY2FzZXMgY2FuJ3Qgb2NjdXIgd2l0aCB0aGUg Y3VycmVudCBBQ0sgZnJhbWUgZm9ybWF0Lg0KPg0KPiBPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA3 OjU0IFBNIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBn bWFpbC5jb20+PiB3cm90ZToNCj4+DQo+PiAyMDE4LTA2LTE3IDg6MzQgR01UKzA5OjAwIElhbiBT d2V0dA0KPj4gPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPj46DQo+PiA+IEknbSBub3QgYSBmYW4gb2YgdGhpcyBw cm9wb3NhbCwgYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRvDQo+PiA+IGRyb3AN Cj4+ID4gdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCBiZWNhdXNlIHdpdGggdGhlIEVDTiBwcm9w b3NhbCBpdCBiZWNvbWVzDQo+PiA+IGltcHJhY3RpY2FsbHkgY29tcGxleCB0byBwYXJzZS4NCj4+ DQo+PiBGb3IgdGhlIEVDTiBwcm9wb3NhbCwgYXMgQ2hyaXN0aWFuIGhhcyBzdWdnZXN0ZWQsIHdl IGNhbiBtb3ZlIHRoZSBFQ04NCj4+IGNvdW50ZXJzIGJlZm9yZSB0aGUgQUNLIGJsb2Nrcy4gVGhl biwgaXQgd291bGQgbm90IGJlIGNvbXBsZXggdG8NCj4+IHBhcnNlLg0KPj4NCj4+IEFuZCBteSB2 aWV3IGlzIHRoYXQgcGFyc2luZyBiZWNvbWVzIGVhc2llciBpZiB3ZSByZXBsYWNlIEFDSyBCbG9j aw0KPj4gQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLg0KPj4NCj4+IE5vdywgd2l0aCBBQ0sg QmxvY2sgQ291bnQsIHdlIG5lZWQgdG8gY2hlY2sgdGhlIHJlbWFpbmluZyBudW1iZXIgb2YNCj4+ IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0IHBheWxvYWQgZm9y IGV2ZXJ5IGJsb2NrDQo+PiB0aGF0IHdlIHBhcnNlLiBGYWlsaW5nIHRvIGNoZWNrIGVpdGhlciBs ZWFkcyB0byBhIGJ1ZyBvciBhIHNlY3VyaXR5DQo+PiBpc3N1ZS4NCj4+DQo+PiBJZiB3ZSBzd2l0 Y2ggdG8gQUNLIEZyYW1lIExlbmd0aCwgd2UgbmVlZCB0byBvbmx5IGNoZWNrIHRoZSByZW1haW5p bmcNCj4+IHNwYWNlIGluIHRoZSBmcmFtZS4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0 aGUgYmlnZ2VzdCBiZW5lZml0IG9mIHJlcGxhY2luZyBBQ0sgQmxvY2sgQ291bnQNCj4+IHdpdGgg QUNLIEZyYW1lIExlbmd0aC4gT1RPSCB0aGUgZG93bnNpZGUgaXMgdGhhdCB5b3UgbmVlZCBleHRy YSBvbmUgdG8NCj4+IHR3byBiaXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMg ZXhwZWN0ZWQgdG8gYmUgYmVsb3cgNjUsDQo+PiB0d28gaWYgdGhleSBhcmUgZXhwZWN0ZWQgdG8g YmUgYWJvdmUgdGhhdCkgZm9yIGVuY29kaW5nIEFDSyBGcmFtZQ0KPj4gTGVuZ3RoIGNvbXBhcmVk IHRvIEFDSyBCbG9jayBDb3VudC4NCj4+DQo+Pg0KPj4NCj4+IEhhdmluZyBzYWlkIHRoYXQsIEkg aG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUgaXQncw0KPj4gbGVu Z3RoIGJlaW5nIGVuY29kZWQgKGVpdGhlciBleHBsaWNpdGx5IG9yIGVpdGhlciBhcyBhIHNpZ25h bCB0aGF0DQo+PiBzYXlzICJ0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQiKS4gQ29uc2lkZXIgc29t ZXRoaW5nIGxpa2UgYmVsb3c6DQo+Pg0KPj4gfDB8IGZyYW1lLXR5cGUgKDcpIHwgZnJhbWUtcGF5 bG9hZC1sZW5ndGggKGkpIHwgZnJhbWUtcGF5bG9hZCAoKikgfA0KPj4gIG9yDQo+PiB8MXwgZnJh bWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8DQo+Pg0KPj4gV2hlbiBNU0Igb2YgdGhl IGZpcnN0IG9jdGV0IHNldCB0byB6ZXJvLCB0aGUgbGVuZ3RoIG9mIHRoZSBmcmFtZQ0KPj4gcGF5 bG9hZCBpcyBkZXNpZ25hdGVkIGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dz IHRoZSBmcmFtZQ0KPj4gdHlwZS4NCj4+IFdoZW4gTVNCIG9mIHRoZSBmaXJzdCBvY3RldCBzZXQg dG8gb25lLCB0aGUgbGVuZ3RoIG9mIHRoZSBmcmFtZQ0KPj4gcGF5bG9hZCBzcGFucyB0byB0aGUg ZW5kIG9mIHRoZSBwYWNrZXQuDQo+Pg0KPj4gSW4gdGhpcyBlbmNvZGluZywgd2UgY2FuIGFsd2F5 cyBvbWl0IHRoZSBMZW5ndGggZmllbGQgb2YgYSBTVFJFQU0NCj4+IGZyYW1lLiBTbyB0aGUgb3Zl cmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW4NCj4+ IHByYWN0aWNlLg0KPj4NCj4+IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNL IEJsb2NrIENvdW50IGZpZWxkLiBBbmQgdGhlDQo+PiBvdmVyaGVhZCB3aWxsIGJlIG9uZSB0byB0 d28gYml0cyBpZiB0aGUgQUNLIGZyYW1lIGlzIHNlbnQgaW4gdGhlDQo+PiBtaWRkbGUgb2YgdGhl IHBhY2tldCAodGhlcmVieSB1c2luZyB0aGUgZW5jb2Rpbmcgd2l0aCBleHBsaWNpdCBmcmFtZQ0K Pj4gcGF5bG9hZCBsZW5ndGgpLCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBp cyB0aGUgbGFzdCBmcmFtZQ0KPj4gb2YgdGhlIHBhY2tldC4NCj4+DQo+PiBXZSBhcmUgbGlrZWx5 IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3RoZXIgdHlwZXMN Cj4+IG9mIGZyYW1lcywgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgd291bGQgYmUgYW4gaXNzdWUg Y29uc2lkZXJpbmcgdGhhdA0KPj4gdGhleSB3aWxsIGJlIGZhciBzZWxkb20gc2VlbiBjb21wYXJl ZCB0byBTVFJFQU1zIGFuZCBBQ0tzLg0KPj4NCj4+IFRvIHN1bW1hcml6ZSwgbXkgYW50aWNpcGF0 aW9uIGlzIHRoYXQgd2UgY2FuIG1ha2UgYWxsIHRoZSBmcmFtZXMNCj4+IHNlbGYtY29udGFpbmVk IChpLmUuIHRoZSBsZW5ndGggY2FuIGJlIGRldGVybWluZWQgd2l0aG91dCB0aGUNCj4+IGtub3ds ZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVhZCwg aWYgd2UNCj4+IGFncmVlIG9uIG1ha2luZyB0aGUgZnJhbWUgdHlwZSBzcGFjZSAxIGJpdCBzbWFs bGVyLg0KPj4NCj4+IEZpbmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxm LWNvbnRhaW5lZCBlbmNvZGluZyBvZg0KPj4gZnJhbWVzIGlzIHRoYXQgd2Ugd291bGQgaGF2ZSB0 aGUgYWJpbGl0eSB0byBpbnRyb2R1Y2UgbmV3IG9wdGlvbmFsDQo+PiBmcmFtZXMgd2l0aG91dCBu ZWdvdGlhdGlvbi4gQnkgbWFraW5nIHRoZSBmcmFtZXMgc2VsZi1jb250YWluZWQsIFFVSUMNCj4+ IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZyYW1lcyB0 aGF0IHRoZXkgZG8NCj4+IG5vdCB1bmRlcnN0YW5kLg0KPj4NCj4+IEJlaW5nIGFibGUgdG8gc2Vu ZCBRVUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dA0KPj4gbmVnb3RpYXRp bmcgdXNpbmcgVHJhbnNwb3J0IFBhcmFtZXRlcnMgd2lsbCBiZSBhIHdpbiBpbiBib3RoIHRlcm1z IG9mDQo+PiBzZWN1cml0eSAoYmVjYXVzZSBjbGllbnRzJyBUUCBpcyBzZW50IGluIGNsZWFyKSBh bmQgZmxleGliaWxpdHkNCj4+IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2libGUgdG8gc2VuZCB0 aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJlDQo+PiBvdXQgd2hldGhlciB0aGUgcGVlciBz dXBwb3J0cyB0aGF0IGV4dGVuc2lvbikuDQo+Pg0KPj4gPiBJZiB3ZSBkb24ndCByZW1vdmUgdGhl IG51bWJlciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMNCj4+ID4gbGFyZ2Vy LA0KPj4gPiBidXQgSSBkb24ndCB0aGluayB0aGUgZXh0cmEgc2l6ZSBmaWVsZCBpcyB1c2VmdWwg Zm9yIG1vc3QNCj4+ID4gaW1wbGVtZW50YXRpb25zLg0KPj4gPiBBbHNvLCBpdCBtZWFucyB0aGUg bGVuZ3RoIGNhbiBkaXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBhZGQNCj4+ ID4gY29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUg Y29kZS4gIFRoZSBpZGVhIG9mDQo+PiA+IHNvbWVvbmUgb2ZmbG9hZGluZyBhY2sgcHJvY2Vzc2lu ZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZQ0KPj4gPiBsZW5ndGgNCj4+ID4gc2Vl bXMgbGlrZSBzb21lb25lIGNvdWxkIGdldCB3cm9uZyBhbmQgY2F1c2Ugc29tZSBjb25jZXJuaW5n IGlzc3Vlcy4NCj4+ID4NCj4+ID4gTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tl dCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yaw0KPj4gPiB0aGFuDQo+PiA+IGl0J3Mg d29ydGguICBTdXJlIHlvdSBjYW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0aCBvbmUgY29ubmVjdGlv biwgYnV0DQo+PiA+IHRoYXQNCj4+ID4gc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBu b3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLg0KPj4gPiBUeXBpY2FsbHkNCj4+ID4gdGhl IGV4dHJhIGNvc3Qgb2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4NCj4+ID4N Cj4+ID4gVG8gYmUgY2xlYXIsIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBhd2Z1bCBpZGVhLCBi dXQgSSBhbHNvIGRvbid0IHNlZQ0KPj4gPiB0aGUNCj4+ID4gdmFsdWUgYW5kIGl0IGFkZHMgY29t cGxleGl0eS4gIEkgcmVhZCBNYW5hc2kncyBlbWFpbCwgYnV0IEkgZG9uJ3QgdGhpbmsNCj4+ID4g SQ0KPj4gPiB1bmRlcnN0YW5kIHdoeSBhbnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0aWNlLg0K Pj4gPg0KPj4gPiBPbiBTYXQsIEp1biAxNiwgMjAxOCBhdCA0OjEzIFBNIEVyaWMgUmVzY29ybGEg PGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQo+PiA+Pg0KPj4gPj4g T24gRnJpLCBKdW4gMTUsIDIwMTggYXQgNjo0NiBQTSwgTWFydGVuIFNlZW1hbm4NCj4+ID4+IDxt YXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+Pg0K Pj4gPj4gd3JvdGU6DQo+PiA+Pj4NCj4+ID4+PiBUaGlzIHByb3Bvc2FsIGluY3JlYXNlcyB0aGUg c2l6ZSBvZiB0aGUgQUNLIGZyYW1lIGJ5IDEgYnl0ZSBpbiB0aGUNCj4+ID4+PiBjb21tb24NCj4+ ID4+PiBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJhbmdlcyksIHNpbmNlIHRoZSBBQ0sgbGVuZ3Ro IGZpZWxkIGhlcmUgYWx3YXlzDQo+PiA+Pj4gY29uc3VtZXMgMiBieXRlcywgd2hlcmVhcyB0aGUg QUNLIEJsb2NrIENvdW50IGlzIGEgdmFyaWFibGUtbGVuZ3RoDQo+PiA+Pj4gaW50ZWdlci4NCj4+ ID4+PiBDb25zaWRlcmluZyBob3cgbXVjaCB3b3JrIHdlIHB1dCBpbnRvIG1pbmltaXNpbmcgdGhl IHNpemUgb2YgdGhlDQo+PiA+Pj4gZnJhbWVzLA0KPj4gPj4+IHRoaXMgZmVlbHMgbGlrZSBhIHN0 ZXAgaW4gdGhlIHdyb25nIGRpcmVjdGlvbi4uDQo+PiA+Pj4NCj4+ID4+PiBSZWdhcmRpbmcgdGhl IHByb2Nlc3NpbmcgY29zdCwgSSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4gQUNLDQo+ PiA+Pj4gZnJhbWUNCj4+ID4+PiByZXF1aXJlcyBsb29waW5nIG92ZXIgYW5kIG1ha2luZyBjaGFu Z2VzIHRvIGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdA0KPj4gPj4+IGtlZXBzDQo+PiA+Pj4gdHJhY2sg b2Ygc2VudCBwYWNrZXRzLiBUaGlzIGlzIG11Y2ggbW9yZSBleHBlbnNpdmUgdGhhbiBzaW1wbHkg cGFyc2luZw0KPj4gPj4+IGENCj4+ID4+PiBidW5jaCBvZiB2YXJpbnRzIGluIHRoZSBBQ0sgZnJh bWUuIEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgYQ0KPj4gPj4+IG11bHRpLXRocmVhZGVkDQo+PiA+ Pj4gcGFja2V0IHBhcnNlciB3b3VsZCBvZmZlciBhbnkgcmVhbC13b3JsZCBwZXJmb3JtYW5jZSBi ZW5lZml0cy4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gSSBkb24ndCB3YW50IHRvIG92ZXJzdGF0ZSB0 aGUgYmVuZWZpdCBoZXJlLCBidXQgbXkgcG9pbnQgaXNuJ3QgdGhhdA0KPj4gPj4gcGFyc2luZyBp cyBleHBlbnNpdmUgYnV0IHRoYXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBhIG11bHRpdGhyZWFkZWQN Cj4+ID4+IHBhY2tldA0KPj4gPj4gcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQncyBuaWNlIHRv IGhhdmUgYSBzaW1wbGVyIGRhdGEgc3RydWN0dXJlICh0aGUNCj4+ID4+IHVucGFyc2VkIEFDSyBi bG9jaykgdG8gaGFuZCB0byB0aGUgQUNLIHByb2Nlc3NpbmcgdGhyZWFkLg0KPj4gPj4NCj4+ID4+ IC1Fa3INCj4+ID4+DQo+PiA+Pg0KPj4gPj4+DQo+PiA+Pj4gT24gU2F0LCBKdW4gMTYsIDIwMTgg YXQgNjoxOSBBTSBNYXJ0aW4gVGhvbXNvbg0KPj4gPj4+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5j b208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQo+PiA+Pj4gd3JvdGU6DQo+PiA+ Pj4+DQo+PiA+Pj4+IFdoZW4gd2UgZGlzY3Vzc2VkIHRoaXMgYmVmb3JlLCBzb21lIHBlb3BsZSBv YnNlcnZlZCB0aGF0IHRoaXMgY3JlYXRlcw0KPj4gPj4+PiBhIG5lZWQgdG8gZW5jb2RlIGluIHR3 byBwYXNzZXMuICBUaGF0J3MgdGhlIHRyYWRlLW9mZiBoZXJlLiAgKE5vdA0KPj4gPj4+PiBleHBy ZXNzaW5nIGFuIG9waW5pb24uKQ0KPj4gPj4+PiBPbiBGcmksIEp1biAxNSwgMjAxOCBhdCAzOjUx IFBNIEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFp bC5jb20+Pg0KPj4gPj4+PiB3cm90ZToNCj4+ID4+Pj4gPg0KPj4gPj4+PiA+IEkgZG9uJ3QgaGF2 ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHRoaXMuIEknbSBjZXJ0YWlubHkgbm90IG9wcG9zZWQgdG8N Cj4+ID4+Pj4gPiBpdC4NCj4+ID4+Pj4gPiBEb2VzIGFueW9uZSBoYXZlIGEgc3Ryb25nIG9wcG9z aXRpb24/DQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiBPbiBGcmksIEp1biAxNSwgMjAxOCBhdCAzOjEw IFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQo+PiA+Pj4+ID4gPHByYXZiQG1pY3Jvc29mdC5j b208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+ID4+Pj4gPj4NCj4+ID4+ Pj4gPj4gSSBhZ3JlZSBhcyB3ZWxsIHNpbmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBlciBwYWNr ZXQgcHJvY2Vzc2luZw0KPj4gPj4+PiA+PiBvdmVyaGVhZC4gQUNLcyBhcmUgZ29pbmcgdG8gYmUg dGhlIHNlY29uZCBtb3N0IGNvbW1vbiBmcmFtZSB0eXBlDQo+PiA+Pj4+ID4+IHNvIG5vDQo+PiA+ Pj4+ID4+IG9iamVjdGlvbnMgdG8gc3BlY2lhbCBjYXNpbmcuDQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBF cmljDQo+PiA+Pj4+ID4+IFJlc2NvcmxhDQo+PiA+Pj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVuZSAx NSwgMjAxOCA5OjExIEFNDQo+PiA+Pj4+ID4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2 YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4+ID4+Pj4gPj4g Q2M6IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFp bC5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQo+ PiA+Pj4+ID4+IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3Vu dCB3aXRoIEFDSyBsZW5ndGgNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4gSSBhZ3JlZSB3aXRoIE1hbmFzaSBoZXJlLiBUaGlzIGNoYW5nZSB3b3VsZCBhbGxv dyBhY2sgZnJhbWUNCj4+ID4+Pj4gPj4gcGFyc2luZw0KPj4gPj4+PiA+PiB0byBiZSBtb3JlIHNl bGYtY29udGFpbmVkLCB3aGljaCBpcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBwYXJzZXINCj4+ID4+ Pj4gPj4gYW5kIGFsc28NCj4+ID4+Pj4gPj4gcG90ZW50aWFsbHkgZm9yIHBhcmFsbGVsaXNtIChi ZWNhdXNlIHlvdSBjYW4gcXVpY2tseSBmaW5kIHRoZQ0KPj4gPj4+PiA+PiBmcmFtZSBhbmQgdGhl bg0KPj4gPj4+PiA+PiBwcm9jZXNzIGl0IGluIHBhcmFsbGVsKS4NCj4+ID4+Pj4gPj4NCj4+ID4+ Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gLUVrcg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+ Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBPbiBNb24s IEp1biAxMSwgMjAxOCBhdCA1OjIyIFBNLCBEZXZhbCwgTWFuYXNpDQo+PiA+Pj4+ID4+IDxtYW5h c2kuZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4gd3JvdGU6 DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IEluIGdlbmVyYWwsIHZhcmludHMgcmVxdWlyZSBzb21l IHNwZWNpZmljIGxvZ2ljIGZvciBwYXJzaW5nLiBUbw0KPj4gPj4+PiA+PiBza2lwDQo+PiA+Pj4+ ID4+IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkgc2luZ2xlIHZhcmludC4g QXMgdGhlIGNvZGUNCj4+ID4+Pj4gPj4gc2VlcyBTdHJlYW0NCj4+ID4+Pj4gPj4gYW5kIEFDSyBo ZWFkZXJzIG1vc3QgZnJlcXVlbnRseSwgdGhhdCBpcyBteSBmb2N1cy4gIFRoZSBTdHJlYW0NCj4+ ID4+Pj4gPj4gZnJhbWUgaGFzIGENCj4+ID4+Pj4gPj4gbGVuZ3RoIGluIGl0cyB0aGlyZCBmaWVs ZC4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gQUNLIHBh cnNpbmcsIGhvd2V2ZXIsIG5lZWRzIDYgKyAyKm51bV9ibG9ja3MgcmVhZHMgdG8gaWRlbnRpZnkN Cj4+ID4+Pj4gPj4gbGVuZ3RoLiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKAmGxhcmdl c3QgYWNrbm93bGVkZ2Vk4oCZLCDigJhBQ0sNCj4+ID4+Pj4gPj4gZGVsYXnigJkgYW5kDQo+PiA+ Pj4+ID4+IOKAmEFDSyBibG9jayBjb3VudOKAmS4gVGhlIHBhaW4gcG9pbnQgaXMgdGhlIHRvdGFs IG51bWJlciBvZiBjeWNsZXMNCj4+ID4+Pj4gPj4gcGFyc2UgYW4NCj4+ID4+Pj4gPj4gQUNLLiBJ ZiBJIGFtIHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBwYWNrZXRz DQo+PiA+Pj4+ID4+IGhhdmUgYQ0KPj4gPj4+PiA+PiBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5 Y2xlcyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQgYm90dGxlbmVjay4NCj4+ID4+Pj4gPj4NCj4+ID4+ Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gVGhhbmtzLA0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+PiBNYW5hc2kNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4g Pj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIEphbmENCj4+ID4+Pj4gPj4gSXllbmdhcg0KPj4gPj4+PiA+ PiBTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTQ0KPj4gPj4+PiA+PiBUbzogRGV2 YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGlu dGVsLmNvbT4+OyBRVUlDIFdHDQo+PiA+Pj4+ID4+IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPj4NCj4+ID4+Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2Ug QUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0K Pj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBZb3UncmUgcmlnaHQgdGhhdCB3ZSBubyBsb25nZXIgaGF2 ZSB0aGUgYWJpbGl0eSB0byBza2lwIGFuIEFDSw0KPj4gPj4+PiA+PiBmcmFtZSwNCj4+ID4+Pj4g Pj4gYW5kIHRoaXMgY3JlcHQgaW4gd2hlbiB3ZSBtb3ZlZCB0byB2YXJpbnRzLg0KPj4gPj4+PiA+ Pg0KPj4gPj4+PiA+PiBJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkg dHJ1ZSBvZiBtb3N0IGZyYW1lcyBub3QNCj4+ID4+Pj4gPj4ganVzdCBBQ0tzLCBzaW5jZSBpZHMs IHBhY2tldCBudW1iZXJzLCBhbmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzDQo+PiA+Pj4+ID4+IGFy ZSBub3cgYWxsDQo+PiA+Pj4+ID4+IHZhcmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5b3UnbGwg bmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkcw0KPj4gPj4+PiA+PiBpbiB0aG9zZQ0KPj4g Pj4+PiA+PiBmcmFtZXMuIElmIHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNraXAgdmFy aW50cywgdGhlbg0KPj4gPj4+PiA+PiBza2lwcGluZyB0aGUgYWNrDQo+PiA+Pj4+ID4+IGJsb2Nr IHNlY3Rpb24gaXMgbWVyZWx5IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2sr MSkNCj4+ID4+Pj4gPj4gdGltZXMuIERvDQo+PiA+Pj4+ID4+IHlvdSBzZWUgc3BlY2lmaWMgdmFs dWUgaW4gc2tpcHBpbmcgQUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhlcg0KPj4gPj4+PiA+PiBjb250 cm9sIGZyYW1lcz8NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4g Pj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgODo0MyBB TSBEbWl0cmkgVGlraG9ub3YNCj4+ID4+Pj4gPj4gPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5j b208bWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb20+PiB3cm90ZToNCj4+ID4+Pj4g Pj4NCj4+ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgMDM6MzM6MzVQTSArMDAwMCwg RGV2YWwsIE1hbmFzaSB3cm90ZToNCj4+ID4+Pj4gPj4gPiAtICAgICAgICBNb3ZpbmcgdGhlIEFD SyBsZW5ndGggdG8gdGhlIGZyb250IG9mIHRoZSBBQ0sgYWxsb3dzDQo+PiA+Pj4+ID4+ID4gdGhl DQo+PiA+Pj4+ID4+ID4gICAgICAgICAgZmxleGliaWxpdHkgb2YgZWl0aGVyIHJlYWRpbmcgdGhl IGVudGlyZSBBQ0sgb3IgcmVhZGluZw0KPj4gPj4+PiA+PiA+IHRoZQ0KPj4gPj4+PiA+PiA+ICAg ICAgICAgIGZpcnN0IDE2IGJpdHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4gVGhpcyBp cyBhDQo+PiA+Pj4+ID4+ID4gdXNlZnVsDQo+PiA+Pj4+ID4+ID4gICAgICAgICAgZmVhdHVyZSBm b3IgdGhlIGNhc2Ugd2hlcmUgQUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQgaW50bw0KPj4gPj4+PiA+ PiA+ICAgICAgICAgIG11bHRpcGxlIGxheWVycy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3Ig dGhpcyBpcyBydW4NCj4+ID4+Pj4gPj4gPiBvbiwNCj4+ID4+Pj4gPj4gPiAgICAgICAgICB0aGVy ZSBhcmUgZGlmZmVyZW50IGFkdmFudGFnZXMgLQ0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBKdXN0 IGEgbm90ZS4gIEluIG15IGV4cGVyaWVuY2UsIHRoZSBjb3N0IG9mIHBhcnNpbmcgYW4gQUNLIGZy YW1lDQo+PiA+Pj4+ID4+IGlzDQo+PiA+Pj4+ID4+IG5lZ2xpZ2libGUgY29tcGFyZWQgdG8gdGhl IGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQNCj4+ID4+Pj4gPj4gaXMsDQo+ PiA+Pj4+ID4+IHBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBu ZXdseSBBQ0tlZCBwYWNrZXRzLg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiAgIC0gRG1pdHJpLg0K Pj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+Pg0KPj4gPj4NCj4+ID4NCj4+DQo+Pg0KPj4N Cj4+IC0tDQo+PiBLYXp1aG8gT2t1DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0K --_000_1F436ED13A22A246A59CA374CBC543998B83EC27ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTk3NzkwNjI3ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6ODg3NjE2MzggNjc2OTg3MTMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5EbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRvIGNyZWF0ZSBhIG5ldyBQUj88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+TWFuYXNpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19fX3JlcGx5c2VwYXJh dG9yIj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gRGV2YWwsIE1hbmFzaQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVuZSAxNywg MjAxOCAyOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVuc2Vl bWFubkBnbWFpbC5jb20mZ3Q7OyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7OyBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7OyBKYW5h IEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGll dGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2Nr IGNvdW50IHdpdGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5IaSBBbGwsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5JIGhhdmUgbWFkZSBhIGxpc3Qg b2Ygb2JqZWN0aW9ucyB0byB0aGUgcHJvcG9zYWwgYW5kIHRoZSBzb2x1dGlvbnMgdG8gdGhvc2Ug b2JqZWN0aW9ucyBkaXNjdXNzZWQgb24gdGhpcyB0aHJlYWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkNv LWV4aXN0ZW5jZSBvZiBsZW5ndGggZmllbGQgd2l0aCBFQ04gZmllbGQgYW5kIEFDSyBibG9ja3Mu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBD MCI+Q2hyaXN0aWFuIHN1Z2dlc3RlZCB0byBtb3ZlIHRoZSBFQ04gZmllbGRzIHRvIHByZWNlZGUg dGhlIEFDSyBibG9ja3MuIFRoaXMgaXMgYW4gZWxlZ2FudCBzb2x1dGlvbi4gUGFyc2luZyBlbnRp cmUgbGlzdCBvZiBBQ0sgYmxvY2tzIHRvIHJldmlldyBFQ04gYml0cw0KIHdvdWxkIGhhdmUgYmVl biBhbm5veWluZywgZXZlbiB0aG91Z2ggaXQgY2FuIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBD MCI+VGhlcmUgYXJlIHR3byBjYXNlcyB0byBiZSBwYXJzZWQg4oCTIGVudGlyZSBBQ0sgYW5kIHBh cnNlIEFDSyB0byBpZGVudGlmeSBsZW5ndGguIFRoZXJlIGFyZSBzb21lIHJlc2VydmF0aW9ucyB3 aGVuIEFDSyBwYXJzaW5nIGdldHMgaGFyZGVyIGZvciB0aGUgY2FzZQ0KIHdoZXJlIHRoZSBlbnRp cmUgaGVhZGVyIG5lZWRzIHRvIGJlIHBhcnNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+QWdyZWVtZW50IGZyb20gc2V2ZXJhbCBmb2xr cyBoZXJlLiBJbiB0aGUgb3JpZ2luYWwgQUNLIGRlZmluZWQgaW4gZHJhZnQgMTIgb2YgdGhlIHNs aWRlLCBvbmUgd291bGQgY291bnQgZG93biBudW1iZXIgb2YgQUNLIGJsb2NrcyB0byBnZXQgdG8g dGhlIGVuZCBvZg0KIHRoZSBwYWNrZXQuIEluIHRoZSBwcm9wb3NhbCBJIG1hZGUsIG9uZSB3b3Vs ZCBjb3VudCBkb3duIHRoZSBsZW5ndGggdG8gaWRlbnRpZnkgdGhlIGVuZCBvZiB0aGUgcGFja2V0 LiBUaGUgbG9naWMgaXMgdmVyeSBzaW1pbGFyIGluIGN5Y2xlIGNvdW50IGFuZCBjb21wbGV4aXR5 LiBTZXZlcmFsIGZvbGtzIGFsc28gY29tbWVudGVkIHRvIHRoaXMgZWZmZWN0Lg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDcwQzAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+TXVsdGktdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5JIHdvdWxk IGV4cGVjdCB0aGF0IHRoZXJlIGFyZSAxMHMgb2YgMTAwMHMgb2YgY29ubmVjdGlvbnMgaW4gdXNl IGF0IGFueSB0aW1lIGZvciBhIHNlcnZlciB3aXRoIGEgaGlnaCBzcGVlZCBsaW5rLiBNdWx0aS10 aHJlYWRpbmcgdG8gaGFuZGxlIGVhY2ggb2YgdGhlc2UNCiBmbG93cyAvIGNvbm5lY3Rpb25zIGlu IHBhcmFsbGVsIGlzIG5lY2Vzc2l0eSB0byBiZSBhYmxlIHRvIHN1cHBvcnQgbGFyZ2UgbnVtYmVy IG9mIGNvbm5lY3Rpb25zIG9uIGEgaGlnaCBzcGVlZCBsaW5rLiBUeCBzZWdtZW50YXRpb24sIFJ4 IGNvYWxlc2NpbmcgYXJlIHdlbGwga25vd24gc3RyYXRlZ2llcyB0byByZWR1Y2UgdGhlIHByb2Nl c3NpbmcgY29zdC4gSW4gaW5pdGlhbCBzdGFnZXMsIGNvZGUgaXMgb2Z0ZW4gd3JpdHRlbiBhcyBh IHNpbmdsZS10aHJlYWRlZA0KIGFuZCB0aGVuIHJlLWZhY3RvcmVkIHRvIHBhcmFsbGVsaXplIGN5 Y2xlIGludGVuc2l2ZSBvcGVyYXRpb25zLiBJbiBvcmRlciB0byBhbGxvdyB0aGlzIHByb3RvY29s IHRvIHNjYWxlIGluIGZ1dHVyZSwgSSB3b3VsZCBzdWdnZXN0IHdlIGRvIG5vdCBwcmVjbHVkZSB0 aGlzIGNhc2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ ZC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5JbmNyZWFzZSBpbiBBQ0sgc2l6ZSBi eSAxIGJ5dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPkkgZG8gbm90IHNlZSB0aGlzIGFzIGEgc2VyaW91cyBpc3N1ZSBidXQgaWYgZm9s a3MgYnV0IHdlIGNhbiBjb25zaWRlciBtYWtpbmcgdGhpcyBhIHZhcmludCwgaWYgb3RoZXJzIGhh dmUgc3Ryb25nIGZlZWxpbmdzIGFib3V0IGl0LiBJdOKAmXMgYSB0cmFkZS1vZmYgOg0KIDIgcmVh ZHMgdG8gc2F2ZSAxIGJ5dGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5lLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPkV2ZXJ5 IGVuY29kYWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPk5vdCBldmVyeSBsZW5ndGggd2lsbCBiZSB2YWxpZC4gVGhpcyBp cyBpbmhlcmVudCB0byBsZW5ndGhzLiBUaGlzIHNhbWUgaXNzdWUgYWlscyB0aGUg4oCYcGF5bG9h ZCBsZW5ndGjigJkgaW4gUVVJQyBoZWFkZXIuIE5vdCBvbmx5IGRvZXMgdGhlIGlzc3VlIGV4aXN0 IGZvciBzbWFsbCB2YWx1ZXMsIGl0IGFsc28gYXBwbGllcw0KIHRvIGxhcmdlIHZhbHVlcyBzaW5j ZSBkYXRhIHN0cmVhbSB3aWxsIGJlIHNlbnQgYWZ0ZXIgY3J5cHRvIG5lZ290aWF0aW9uLiAmbmJz cDtFLmcuICZuYnNwOy0gaG93IGRvZXMgb25lIGNyYWZ0IGEgcGF5bG9hZCB3aXRoIDYyIGJpdCBw YXlsb2FkIGxlbmd0aCBpbiBhIGxhcmdlIGhlYWRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDcwQzAiPk1hbmFzaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFy dGVuIFNlZW1hbm4gWzxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSI+bWFp bHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5k YXksIEp1bmUgMTcsIDIwMTggNjo1OSBBTTxicj4NCjxiPlRvOjwvYj4gS2F6dWhvIE9rdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iPmthenVob29rdUBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFu c3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5pYW5zd2V0dD00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs7IEphbmEgSXllbmdhciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSI+anJpLmlldGZAZ21haWwuY29tPC9hPiZn dDs7DQogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBt aWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozsg TWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBEZXZhbCwgTWFuYXNpDQogJmx0 OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIj5tYW5hc2kuZGV2YWxAaW50 ZWwuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByb3Bvc2FsIHRvIHJlcGxh Y2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1heWJlIGl0J3Mgc3BlY2lmaWMgdG8gR28sIGJ1dCBJJ20gdXNpbmcg YSBzaW5nbGUgaW8uUmVhZGVyIGZvciB0aGUgd2hvbGUgcGFja2V0LCBzbyBhcyBsb25nIGFzIHRo ZSBwYWNrZXQgcGF5bG9hZCBpcyBsb25nIGVub3VnaCwgdGhlIHZhcmludCBwYXJzaW5nIHdpbGwg bm90IGZhaWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBk b24ndCB0aGluayB0aGF0IHNwZWNpZmljcyBvZiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVy IGhlcmUgdGhvdWdoLCBhbmQgSSdtIHN1cmUgYm90aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFz b25hYmx5IGltcGxlbWVudGVkIGluIEMgYXMgd2VsbCBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdt IG9wcG9zZWQgdG8gTWFuYXNpJ3MgcHJvcG9zYWwgYXJlIHRoYXQgaXQgbW92ZXMgdXMgYXdheSBm cm9tIHRoZQ0KIHByaW5jaXBsZSB0aGF0IG9ubHkgcmVhc29uYWJsZSB2YWx1ZXMgc2hvdWxkIGJl IGVuY29kYWJsZSwgYW5kIHRoYXQgaXQgaW5jcmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJh bWUsIGZvciB0aGUgcXVlc3Rpb25hYmxlIGJlbmVmaXQgb2YgYmVpbmcgYWJsZSB0byBwYXJhbGxl bGlzZSB0aGUgZnJhbWUgcGFyc2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEthenVo byBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIj5rYXp1aG9va3VA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MjAxOC0wNi0xNyAyMjozNiBHTVQmIzQzOzA5OjAwIE1hcnRlbiBTZWVtYW5uICZsdDs8 YSBocmVmPSJtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t YXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsgQXQgbGVhc3QgZm9yIG15 IGltcGxlbWVudGF0aW9uLCBwYXJzaW5nIGRvZXNuJ3QgYmVjb21lIGVhc2llciwgaXQgYmVjb21l czxicj4NCiZndDsgbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50LXBh cnNlciBhbHdheXMgY29uc3VtZXMgYXMgbWFueTxicj4NCiZndDsgYnl0ZXMgYXMgdGhlIHZhcmlu dCByZXF1aXJlcywgc28gYWZ0ZXIgcGFyc2luZyBhIHZhcmludCwgSSdkIGhhdmUgdG88YnI+DQom Z3Q7IGludHJvZHVjZSBhbiBhZGRpdGlvbmFsIGNoZWNrIHRoYXQgdGhpcyBkaWRuJ3Qgb3ZlcmZs b3cgdGhlIEFDSyBsZW5ndGggKGUuZy48YnI+DQomZ3Q7IGNvbnNpZGVyIHRoYXQgSSBwYXJzZWQg dGhlIEFDSyBmcmFtZSBzbyBmYXIgdGhhdCBvbmx5IDIgYnl0ZXMgYXJlIHJlbWFpbmluZzxicj4N CiZndDsgYWNjb3JkaW5nIHRvIEFDSyBsZW5ndGggZmllbGQsIGJ1dCB0aGUgbmV4dCB2YXJpbnQg aXMgNCBieXRlcyBsb25nKS48YnI+DQo8YnI+DQpJc24ndCB5b3VyIHZhcmludCBwYXJzZXIgY2hl Y2tpbmcgdGhhdCBpdCBoYXMgbm90IChvciB3aWxsIG5vdCkgcnVuPGJyPg0KYWNyb3NzIHRoZSBl bmQgb2YgdGhlIHBhY2tldCBwYXlsb2FkIGZvciBldmVyeSBBQ0sgYmxvY2sgaXQgcGFyc2VzPzxi cj4NCkknZCBhc3N1bWUgdGhhdCB5b3Ugd291bGQgYmUgZG9pbmcgdGhhdCwgYmVjYXVzZSBJIHRo aW5rIHRoYXQgaXM8YnI+DQpuZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4uPGJyPg0K PGJyPg0KV2hhdCBJIGFtIHNheWluZyB0aGF0IHRoYXQgY2hlY2sgY291bGQgYmUgY29udmVydGVk IHRvIGEgb3ZlcnJ1biBjaGVjazxicj4NCmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgJnF1b3Q7ZnJh bWUgcGF5bG9hZCZxdW90OywgYW5kIHRoYXQgY2hlY2tpbmcgdGhlPGJyPg0KcmVtYWluaW5nIGJs b2NrIGNvdW50IGJlY29tZXMgdW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0s8YnI+ DQpCbG9jayBDb3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguPGJyPg0KPGJyPg0KJmd0Ozxicj4N CiZndDsgSW4gZ2VuZXJhbCwgd2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdpcmUgaW1hZ2UgdG93YXJk cyBtYWtpbmcgZXZlcnkgZW5jb2RhYmxlPGJyPg0KJmd0OyB2YWx1ZSB2YWxpZC4gVGhpcyBwcm9w b3NhbCBtb3ZlcyB1cyBhd2F5IGZyb20gdGhhdCBwcmluY2lwbGU6PGJyPg0KJmd0OyAqIHNvbWUg c21hbGwgdmFsdWVzIGFyZSBhbHdheXMgaW52YWxpZCAodGhlIGxlbmd0aCBjYW4gbmV2ZXIgYmUg YmV0d2VlbiAwPGJyPg0KJmd0OyBhbmQgMyk8YnI+DQomZ3Q7ICogYSBsb3Qgb2YgaW50ZXJtZWRp YXRlIHZhbHVlcyBhcmUgaW52YWxpZCAoaWYgdGhlIGJvdW5kYXJ5IGZhbGxzIGluc2lkZSBhPGJy Pg0KJmd0OyB2YXJpbnQsIGFzIGRlc2NyaWJlZCBhYm92ZSk8YnI+DQomZ3Q7IEJvdGggdGhlc2Ug Y2FzZXMgY2FuJ3Qgb2NjdXIgd2l0aCB0aGUgY3VycmVudCBBQ0sgZnJhbWUgZm9ybWF0Ljxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFN1biwgSnVuIDE3LCAyMDE4IGF0IDc6NTQgUE0gS2F6dWhvIE9r dSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAyMDE4LTA2LTE3IDg6MzQgR01UJiM0MzswOTowMCBJYW4gU3dldHQ8YnI+DQomZ3Q7 Jmd0OyAmbHQ7aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7 Ojxicj4NCiZndDsmZ3Q7ICZndDsgSSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBiZWNh dXNlIEkgdGhpbmsgaXQgaXMgaW1wcmFjdGljYWwgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGRyb3A8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRo IHRoZSBFQ04gcHJvcG9zYWwgaXQgYmVjb21lczxicj4NCiZndDsmZ3Q7ICZndDsgaW1wcmFjdGlj YWxseSBjb21wbGV4IHRvIHBhcnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRm9yIHRo ZSBFQ04gcHJvcG9zYWwsIGFzIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkLCB3ZSBjYW4gbW92ZSB0 aGUgRUNOPGJyPg0KJmd0OyZndDsgY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sgYmxvY2tzLiBUaGVu LCBpdCB3b3VsZCBub3QgYmUgY29tcGxleCB0bzxicj4NCiZndDsmZ3Q7IHBhcnNlLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgQW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMg ZWFzaWVyIGlmIHdlIHJlcGxhY2UgQUNLIEJsb2NrPGJyPg0KJmd0OyZndDsgQ291bnQgd2l0aCBB Q0sgRnJhbWUgTGVuZ3RoLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTm93LCB3aXRoIEFD SyBCbG9jayBDb3VudCwgd2UgbmVlZCB0byBjaGVjayB0aGUgcmVtYWluaW5nIG51bWJlciBvZjxi cj4NCiZndDsmZ3Q7IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0 IHBheWxvYWQgZm9yIGV2ZXJ5IGJsb2NrPGJyPg0KJmd0OyZndDsgdGhhdCB3ZSBwYXJzZS4gRmFp bGluZyB0byBjaGVjayBlaXRoZXIgbGVhZHMgdG8gYSBidWcgb3IgYSBzZWN1cml0eTxicj4NCiZn dDsmZ3Q7IGlzc3VlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYgd2Ugc3dpdGNoIHRv IEFDSyBGcmFtZSBMZW5ndGgsIHdlIG5lZWQgdG8gb25seSBjaGVjayB0aGUgcmVtYWluaW5nPGJy Pg0KJmd0OyZndDsgc3BhY2UgaW4gdGhlIGZyYW1lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgSSB0aGluayB0aGF0IHRoaXMgaXMgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiByZXBsYWNpbmcg QUNLIEJsb2NrIENvdW50PGJyPg0KJmd0OyZndDsgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9I IHRoZSBkb3duc2lkZSBpcyB0aGF0IHlvdSBuZWVkIGV4dHJhIG9uZSB0bzxicj4NCiZndDsmZ3Q7 IHR3byBiaXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8g YmUgYmVsb3cgNjUsPGJyPg0KJmd0OyZndDsgdHdvIGlmIHRoZXkgYXJlIGV4cGVjdGVkIHRvIGJl IGFib3ZlIHRoYXQpIGZvciBlbmNvZGluZyBBQ0sgRnJhbWU8YnI+DQomZ3Q7Jmd0OyBMZW5ndGgg Y29tcGFyZWQgdG8gQUNLIEJsb2NrIENvdW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkg d29uZGVyIGlmIGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUgaXQnczxicj4NCiZndDsmZ3Q7IGxl bmd0aCBiZWluZyBlbmNvZGVkIChlaXRoZXIgZXhwbGljaXRseSBvciBlaXRoZXIgYXMgYSBzaWdu YWwgdGhhdDxicj4NCiZndDsmZ3Q7IHNheXMgJnF1b3Q7dG8gdGhlIGVuZCBvZiB0aGUgcGFja2V0 JnF1b3Q7KS4gQ29uc2lkZXIgc29tZXRoaW5nIGxpa2UgYmVsb3c6PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyB8MHwgZnJhbWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkLWxlbmd0aCAoaSkg fCBmcmFtZS1wYXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDsmbmJzcDsgb3I8YnI+DQomZ3Q7Jmd0 OyB8MXwgZnJhbWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBXaGVuIE1TQiBvZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHplcm8sIHRo ZSBsZW5ndGggb2YgdGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBpcyBkZXNpZ25hdGVk IGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZTxicj4NCiZn dDsmZ3Q7IHR5cGUuPGJyPg0KJmd0OyZndDsgV2hlbiBNU0Igb2YgdGhlIGZpcnN0IG9jdGV0IHNl dCB0byBvbmUsIHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBz cGFucyB0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJbiB0aGlzIGVuY29kaW5nLCB3ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0aCBmaWVsZCBv ZiBhIFNUUkVBTTxicj4NCiZndDsmZ3Q7IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5 aW5nIHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW48YnI+DQomZ3Q7Jmd0OyBwcmFj dGljZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBj YW4gb21pdCB0aGUgQUNLIEJsb2NrIENvdW50IGZpZWxkLiBBbmQgdGhlPGJyPg0KJmd0OyZndDsg b3ZlcmhlYWQgd2lsbCBiZSBvbmUgdG8gdHdvIGJpdHMgaWYgdGhlIEFDSyBmcmFtZSBpcyBzZW50 IGluIHRoZTxicj4NCiZndDsmZ3Q7IG1pZGRsZSBvZiB0aGUgcGFja2V0ICh0aGVyZWJ5IHVzaW5n IHRoZSBlbmNvZGluZyB3aXRoIGV4cGxpY2l0IGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBs ZW5ndGgpLCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFzdCBm cmFtZTxicj4NCiZndDsmZ3Q7IG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBXZSBhcmUgbGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBv ZiB0aGUgb3RoZXIgdHlwZXM8YnI+DQomZ3Q7Jmd0OyBvZiBmcmFtZXMsIGJ1dCBJIGRvIG5vdCB0 aGluayB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlIGNvbnNpZGVyaW5nIHRoYXQ8YnI+DQomZ3Q7Jmd0 OyB0aGV5IHdpbGwgYmUgZmFyIHNlbGRvbSBzZWVuIGNvbXBhcmVkIHRvIFNUUkVBTXMgYW5kIEFD S3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUbyBzdW1tYXJpemUsIG15IGFudGljaXBh dGlvbiBpcyB0aGF0IHdlIGNhbiBtYWtlIGFsbCB0aGUgZnJhbWVzPGJyPg0KJmd0OyZndDsgc2Vs Zi1jb250YWluZWQgKGkuZS4gdGhlIGxlbmd0aCBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHRo ZTxicj4NCiZndDsmZ3Q7IGtub3dsZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3 aXRob3V0IGFueSBvdmVyaGVhZCwgaWYgd2U8YnI+DQomZ3Q7Jmd0OyBhZ3JlZSBvbiBtYWtpbmcg dGhlIGZyYW1lIHR5cGUgc3BhY2UgMSBiaXQgc21hbGxlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEZpbmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRh aW5lZCBlbmNvZGluZyBvZjxicj4NCiZndDsmZ3Q7IGZyYW1lcyBpcyB0aGF0IHdlIHdvdWxkIGhh dmUgdGhlIGFiaWxpdHkgdG8gaW50cm9kdWNlIG5ldyBvcHRpb25hbDxicj4NCiZndDsmZ3Q7IGZy YW1lcyB3aXRob3V0IG5lZ290aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRh aW5lZCwgUVVJQzxicj4NCiZndDsmZ3Q7IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20g b2YgaWdub3JpbmcgdGhlIGZyYW1lcyB0aGF0IHRoZXkgZG88YnI+DQomZ3Q7Jmd0OyBub3QgdW5k ZXJzdGFuZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlaW5nIGFibGUgdG8gc2VuZCBR VUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dDxicj4NCiZndDsmZ3Q7IG5l Z290aWF0aW5nIHVzaW5nIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIHdpbGwgYmUgYSB3aW4gaW4gYm90 aCB0ZXJtcyBvZjxicj4NCiZndDsmZ3Q7IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMnIFRQIGlz IHNlbnQgaW4gY2xlYXIpIGFuZCBmbGV4aWJpbGl0eTxicj4NCiZndDsmZ3Q7IChiZWNhdXNlIHdl IHdpbGwgYmUgcG9zc2libGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJl PGJyPg0KJmd0OyZndDsgb3V0IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydHMgdGhhdCBleHRlbnNp b24pLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJZiB3ZSBkb24ndCByZW1vdmUg dGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IGxhcmdlciw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGJ1dCBJIGRvbid0IHRoaW5rIHRo ZSBleHRyYSBzaXplIGZpZWxkIGlzIHVzZWZ1bCBmb3IgbW9zdDxicj4NCiZndDsmZ3Q7ICZndDsg aW1wbGVtZW50YXRpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsgQWxzbywgaXQgbWVhbnMgdGhlIGxl bmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxlbmd0aCwgd2hpY2ggYWRkPGJyPg0K Jmd0OyZndDsgJmd0OyBjb21wbGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3JpdGluZyBl cnJvci1wcm9uZSBjb2RlLiZuYnNwOyBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7ICZndDsgc29t ZW9uZSBvZmZsb2FkaW5nIGFjayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcgdG8gdHJ1 c3QgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHNlZW1z IGxpa2Ugc29tZW9uZSBjb3VsZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBp c3N1ZXMuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgTXkgZXhwZXJpZW5j ZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29y azxicj4NCiZndDsmZ3Q7ICZndDsgdGhhbjxicj4NCiZndDsmZ3Q7ICZndDsgaXQncyB3b3J0aC4m bmJzcDsgU3VyZSB5b3UgY2FuJ3QgZmlsbCBhIDEwMEcgTklDIHdpdGggb25lIGNvbm5lY3Rpb24s IGJ1dDxicj4NCiZndDsmZ3Q7ICZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsgc2VlbXMgbGlr ZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLjxi cj4NCiZndDsmZ3Q7ICZndDsgVHlwaWNhbGx5PGJyPg0KJmd0OyZndDsgJmd0OyB0aGUgZXh0cmEg Y29zdCBvZiBtdWx0aXRocmVhZGluZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLjxicj4NCiZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFRvIGJlIGNsZWFyLCBJIGRvbid0IHRoaW5rIHRoaXMg aXMgYW4gYXdmdWwgaWRlYSwgYnV0IEkgYWxzbyBkb24ndCBzZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsgdmFsdWUgYW5kIGl0IGFkZHMgY29tcGxleGl0eS4mbmJz cDsgSSByZWFkIE1hbmFzaSdzIGVtYWlsLCBidXQgSSBkb24ndCB0aGluazxicj4NCiZndDsmZ3Q7 ICZndDsgSTxicj4NCiZndDsmZ3Q7ICZndDsgdW5kZXJzdGFuZCB3aHkgYW55IG9mIHRob3NlIG1h dHRlciBpbiBwcmFjdGljZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBP biBTYXQsIEp1biAxNiwgMjAxOCBhdCA0OjEzIFBNIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9 Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE9u IEZyaSwgSnVuIDE1LCAyMDE4IGF0IDY6NDYgUE0sIE1hcnRlbiBTZWVtYW5uPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBwcm9wb3NhbCBpbmNyZWFzZXMgdGhlIHNpemUgb2YgdGhl IEFDSyBmcmFtZSBieSAxIGJ5dGUgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNv bW1vbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJh bmdlcyksIHNpbmNlIHRoZSBBQ0sgbGVuZ3RoIGZpZWxkIGhlcmUgYWx3YXlzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IGNvbnN1bWVzIDIgYnl0ZXMsIHdoZXJlYXMgdGhlIEFDSyBCbG9jayBD b3VudCBpcyBhIHZhcmlhYmxlLWxlbmd0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbnRl Z2VyLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBDb25zaWRlcmluZyBob3cgbXVjaCB3b3Jr IHdlIHB1dCBpbnRvIG1pbmltaXNpbmcgdGhlIHNpemUgb2YgdGhlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IGZyYW1lcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhpcyBmZWVscyBs aWtlIGEgc3RlcCBpbiB0aGUgd3JvbmcgZGlyZWN0aW9uLi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgUmVnYXJkaW5nIHRoZSBwcm9jZXNzaW5n IGNvc3QsIEkgYWdyZWUgd2l0aCBEbWl0cmkuIEhhbmRsaW5nIGFuIEFDSzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBmcmFtZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlcyBs b29waW5nIG92ZXIgYW5kIG1ha2luZyBjaGFuZ2VzIHRvIGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBrZWVwczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyB0cmFjayBvZiBzZW50IHBhY2tldHMuIFRoaXMgaXMgbXVjaCBtb3JlIGV4cGVuc2l2ZSB0aGFu IHNpbXBseSBwYXJzaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgYnVuY2ggb2YgdmFyaW50cyBpbiB0aGUgQUNLIGZyYW1lLiBJdCBzZWVt cyB1bmxpa2VseSB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbXVsdGktdGhyZWFk ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcGFja2V0IHBhcnNlciB3b3VsZCBvZmZlciBh bnkgcmVhbC13b3JsZCBwZXJmb3JtYW5jZSBiZW5lZml0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSSBkb24ndCB3 YW50IHRvIG92ZXJzdGF0ZSB0aGUgYmVuZWZpdCBoZXJlLCBidXQgbXkgcG9pbnQgaXNuJ3QgdGhh dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHBhcnNpbmcgaXMgZXhwZW5zaXZlIGJ1dCB0aGF0IGlm IHlvdSB3YW50IHRvIGhhdmUgYSBtdWx0aXRocmVhZGVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg cGFja2V0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQn cyBuaWNlIHRvIGhhdmUgYSBzaW1wbGVyIGRhdGEgc3RydWN0dXJlICh0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB1bnBhcnNlZCBBQ0sgYmxvY2spIHRvIGhhbmQgdG8gdGhlIEFDSyBwcm9jZXNz aW5nIHRocmVhZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IC1Fa3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIFNhdCwg SnVuIDE2LCAyMDE4IGF0IDY6MTkgQU0gTWFydGluIFRob21zb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBXaGVuIHdlIGRpc2N1c3NlZCB0aGlzIGJlZm9y ZSwgc29tZSBwZW9wbGUgb2JzZXJ2ZWQgdGhhdCB0aGlzIGNyZWF0ZXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IGEgbmVlZCB0byBlbmNvZGUgaW4gdHdvIHBhc3Nlcy4mbmJzcDsgVGhh dCdzIHRoZSB0cmFkZS1vZmYgaGVyZS4mbmJzcDsgKE5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgZXhwcmVzc2luZyBhbiBvcGluaW9uLik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDM6NTEgUE0gSmFuYSBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmll dGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyBJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLiBJ J20gY2VydGFpbmx5IG5vdCBvcHBvc2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7IGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBEb2VzIGFueW9u ZSBoYXZlIGEgc3Ryb25nIG9wcG9zaXRpb24/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IE9uIEZyaSwgSnVuIDE1 LCAyMDE4IGF0IDM6MTAgUE0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEkgYWdyZWUgYXMgd2VsbCBzaW5jZSB0aGlzIGNhbiBoZWxw IHJlZHVjZSBwZXIgcGFja2V0IHByb2Nlc3Npbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IG92ZXJoZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1v c3QgY29tbW9uIGZyYW1lIHR5cGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IHNvIG5vPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvYmplY3Rp b25zIHRvIHNwZWNpYWwgY2FzaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgRnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YgRXJpYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg UmVzY29ybGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZy aWRheSwgSnVuZSAxNSwgMjAxOCA5OjExIEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBUbzogRGV2YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5k ZXZhbEBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9h PiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IENjOiBKYW5hIEl5 ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5qcmkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9w b3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEkgYWdyZWUgd2l0aCBNYW5hc2kg aGVyZS4gVGhpcyBjaGFuZ2Ugd291bGQgYWxsb3cgYWNrIGZyYW1lPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwYXJzaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB0byBiZSBtb3JlIHNlbGYtY29udGFpbmVkLCB3aGljaCBpcyBhbiBhZHZh bnRhZ2UgZm9yIHRoZSBwYXJzZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IGFuZCBhbHNvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwb3Rl bnRpYWxseSBmb3IgcGFyYWxsZWxpc20gKGJlY2F1c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSBhbmQgdGhlbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcHJvY2VzcyBpdCBpbiBwYXJh bGxlbCkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtRWty PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDU6MjIgUE0sIERldmFsLCBNYW5h c2k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZh bEBpbnRlbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJbiBnZW5l cmFsLCB2YXJpbnRzIHJlcXVpcmUgc29tZSBzcGVjaWZpYyBsb2dpYyBmb3IgcGFyc2luZy4gVG88 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNraXA8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJl YWQgZXZlcnkgc2luZ2xlIHZhcmludC4gQXMgdGhlIGNvZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IHNlZXMgU3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBhbmQgQUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15 IGZvY3VzLiZuYnNwOyBUaGUgU3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBmcmFtZSBoYXMgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgbGVuZ3RoIGluIGl0cyB0aGlyZCBmaWVsZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IEFDSyBwYXJzaW5nLCBob3dldmVyLCBuZWVkcyA2ICYjNDM7IDIq bnVtX2Jsb2NrcyByZWFkcyB0byBpZGVudGlmeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgbGVuZ3RoLiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKAmGxhcmdl c3QgYWNrbm93bGVkZ2Vk4oCZLCDigJhBQ0s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IGRlbGF54oCZIGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsg4oCYQUNLIGJsb2NrIGNvdW504oCZLiBUaGUgcGFpbiBwb2ludCBpcyB0aGUgdG90YWwg bnVtYmVyIG9mIGN5Y2xlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg cGFyc2UgYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEFDSy4gSWYg SSBhbSBwcm9jZXNzaW5nIDEwTSBwcHMsIHdoZXJlIDEwJSAtIDMwJSBvZiB0aGUgcGFja2V0czxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaGF2ZSBhPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xl cyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQgYm90dGxlbmVjay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBN YW5hc2k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBRVUlDIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKYW5hPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJeWVuZ2FyPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgVG86IERldmFsLCBNYW5hc2kg Jmx0OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFuYXNpLmRldmFsQGludGVsLmNvbTwvYT4mZ3Q7OyBRVUlDIFdHPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNl IEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFlvdSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBoYXZl IHRoZSBhYmlsaXR5IHRvIHNraXAgYW4gQUNLPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBmcmFtZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IGFuZCB0aGlzIGNyZXB0IGluIHdoZW4gd2UgbW92ZWQgdG8gdmFyaW50cy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1 ZSBvZiBtb3N0IGZyYW1lcyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IGp1c3QgQUNLcywgc2luY2UgaWRzLCBwYWNrZXQgbnVtYmVycywgYW5kIG51bWJlcnMgaW4g YWxsIGZyYW1lczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgYXJlIG5v dyBhbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHZhcmludHMuIFRv IHNraXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaW4gdGhvc2U8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lcy4gSWYgeW91IGhhdmUgbG9naWMg dG8gcHJvY2VzcyBhbmQgc2tpcCB2YXJpbnRzLCB0aGVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBza2lwcGluZyB0aGUgYWNrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBibG9jayBzZWN0aW9uIGlzIG1lcmVseSByZXBlYXRpbmcgdGhpcyBv cGVyYXRpb24gKDIqbnVtX2Jsb2NrJiM0MzsxKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgdGltZXMuIERvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB5b3Ugc2VlIHNwZWNpZmljIHZhbHVlIGluIHNraXBwaW5nIEFDSyBmcmFtZXMgb3ZlciB0 aGUgb3RoZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wg ZnJhbWVzPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRy aSBUaWtob25vdjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC4uY29tIj5kdGlraG9ub3ZAbGl0 ZXNwZWVkdGVjaC4uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24g TW9uLCBKdW4gMTEsIDIwMTggYXQgMDM6MzM6MzVQTSAmIzQzOzAwMDAsIERldmFsLCBNYW5hc2kg d3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IC0mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTW92aW5nIHRoZSBBQ0sgbGVuZ3RoIHRvIHRoZSBmcm9u dCBvZiB0aGUgQUNLIGFsbG93czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZsZXhpYmlsaXR5IG9mIGVpdGhlciBy ZWFkaW5nIHRoZSBlbnRpcmUgQUNLIG9yIHJlYWRpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmaXJzdCAxNiBi aXRzIGFuZCBza2lwcGluZyBvdmVyIHRoZSBsZW5ndGguIFRoaXMgaXMgYTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyB1c2VmdWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGZlYXR1cmUgZm9yIHRoZSBjYXNlIHdoZXJlIEFDSyBwcm9jZXNzaW5nIGlzIHNwbGl0IGlu dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG11bHRpcGxlIGxheWVycy4gRGVwZW5kaW5nIG9uIHRo ZSBwcm9jZXNzb3IgdGhpcyBpcyBydW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsgb24sPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVyZSBhcmUgZGlmZmVyZW50 IGFkdmFudGFnZXMgLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEp1c3QgYSBub3RlLiZuYnNwOyBJ biBteSBleHBlcmllbmNlLCB0aGUgY29zdCBvZiBwYXJzaW5nIGFuIEFDSyBmcmFtZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IG5lZ2xpZ2libGUgY29tcGFyZWQgdG8gdGhlIGNvc3Qgb2YgcHJv Y2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IGlzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcG9r aW5nIGF0IHZhcmlvdXMgbWVtb3J5IGxvY2F0aW9ucyB0byBkaXNjYXJkIG5ld2x5IEFDS2VkIHBh Y2tldHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7LSBEbWl0cmkuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyBLYXp1aG8g T2t1PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KS2F6dWhvIE9rdTxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1F436ED13A22A246A59CA374CBC543998B83EC27ORSMSX111amrcor_-- From nobody Tue Jun 19 11:25:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A103C130E10 for ; Tue, 19 Jun 2018 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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 S1XPWfd4A1VZ for ; Tue, 19 Jun 2018 11:25:49 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 866B6130DF6 for ; Tue, 19 Jun 2018 11:25:49 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l25-v6so1083954ioh.12 for ; Tue, 19 Jun 2018 11:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=amyh2LkS78pU6WFLOKl5fZd4v9JNjqWRBoq+g4zcQyM=; b=uPR6Rjy9+an6jM2VQTEEk3RVbH4tMTpEw1VL5lf84CaYOOvPeqOnkUQ9YbPTTpf5S/ eFFQBcI3jqQHs7RwP82f63sQ0qtcVfqZ+JCyYOKf7Le/kkoCcal9HG+6V/Y9xjeVGXoG eeQaHSSXfNpBwbO2JH4HUlBpYD+F5Sp4a8C40Ww3T1RGghjFAiXTxMQrCzjme5yVwY9D bupklt7f+rW0tWxlPLN/DyPtJXGG6yJgveb714TSacy2dyvzY1kOs5lnjqcA+VI6wIT9 OLikFQ4nrBLKDCV1Nc6qLZrf9E/oNoRLSXDbiEavpE8kuTk5cRG7NpXpu4qG3w2MeG3z YhOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=amyh2LkS78pU6WFLOKl5fZd4v9JNjqWRBoq+g4zcQyM=; b=rcDnoFOgoGID8cHw4DIVWyObOK25gJfq9eNFp+cpHULsNYl59GnR5AGSfdw+xD6fKH b5T3kh8XWziB1lz0fVqVRpWmlRQZqfhVDNKTkmz7cNnPBudrHJpwYwX0ZBN8UkMbCRqg 2mvqOH7qUb5Vk6S1FnJkhThG44lx6YyMwUh2fxOELcXlEGaF9UawmELbc1Vw17UYWDrQ Y8PoeIeuPn6pwACU+Q1YgNe8CWGPAT6H3o3VUjCEV7/iMbbB84UEVKOGQEOoSMPEPGGe hKOBtEBpWuiHif/IeT2BUcet8dL6PZhutg7xZiSUAl6/hT2ps8AbJivjBTf++xSedtp2 AEuQ== X-Gm-Message-State: APt69E2QSVNnFK2R4c37WYp/ahx9YBkrVQ8Di9ITF1Gd1SkUyuK7VjiG DA22HZNg8O64B9j3nFQuv6gV8oD6g6gGyO1AXK0= X-Google-Smtp-Source: ADUXVKK2A6ymSH86D7zMgBW8UlQ2GReC7+Zf3gyTzSn4eBHD3aq+xlqbxN6Lhu/3i1NkcY61tE8w2vCj6WjnWshukds= X-Received: by 2002:a6b:1e91:: with SMTP id e139-v6mr15147699ioe.36.1529432748947; Tue, 19 Jun 2018 11:25:48 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Jun 2018 11:25:48 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Jun 2018 11:25:47 -0700 Message-ID: Subject: RE: Proposal to replace ACK block count with ACK length To: Kazuho Oku , "Deval, Manasi" , Marten Seemann Cc: Praveen Balasubramanian , Eric Rescorla , Jana Iyengar , IETF QUIC WG , Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary="000000000000b57d9b056f02cf58" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:25:52 -0000 --000000000000b57d9b056f02cf58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think you addressed e) at all. Clearly there is an end of b= uffer check, but that is not the same as requiring additonal checks at many other levels. On 19 June 2018 at 20.22.03, Deval, Manasi (manasi.deval@intel.com) wrote: e. Every encodable value should be valid Not every length will be valid. This is inherent to lengths. This same issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only do= es the issue exist for small values, it also applies to large values since data stream will be sent after crypto negotiation. E.g. - how does one craft a payload with 62 bit payload length in a large header? --000000000000b57d9b056f02cf58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I don=E2=80=99t think you addressed e) at all= . Clearly there is an end of buffer check, but that is not the same as requ= iring additonal checks at many other levels.

On 19 June 2018 at 20.22.03, Deval, Manasi (manasi.deval@intel.com) wrote:

=

=C2=A0

e.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0= Every encodable value should be valid<= /span>

Not e= very length will be valid. This is inherent to lengths. This same issue ail= s the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does the is= sue exist for small values, it also applies to large values since data stre= am will be sent after crypto negotiation.=C2=A0 E.g. =C2=A0- how does one c= raft a payload with 62 bit payload length in a large header?

--000000000000b57d9b056f02cf58-- From nobody Tue Jun 19 11:26:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43F0130F09 for ; Tue, 19 Jun 2018 11:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 KYE_0jMUH-ED for ; Tue, 19 Jun 2018 11:26:03 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 424FF130F37 for ; Tue, 19 Jun 2018 11:26:03 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id i2-v6so256697ybg.6 for ; Tue, 19 Jun 2018 11:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pR1YvslHc1EFBdh/dc3/IPGKga3WjyxOPqWaWMqU9jQ=; b=vmf2dP5x0546QRI/lj3ieO3b/2lHQgsPDNRn8m7nsa6xgFQgJM46z7giY+DpgpqRmX wQBUsC84xMiiSMHmEW7x4FS444G+IXmDTJ8tjVYwh5CRtFK7y0yeDY6jU46+joNCpCQ4 kzhDoQFhDKpiQi6vH1yQ51uE9YS00kEXq2UYTFGvfuFAJS9SXudNek7GtgGIs4BvtGeg wj6Ai/YKxyaKIUJ4cgmH0VcApGPXGOUh7qev9G8uBBOkbxS3iqPGU3baZKdjqTRNN8A3 0hFjhuX1oKbnRCLRsXqSS74oaSzw6fFDW7ubbW0WQnlLh7bo12hjpDrN/qK+Ubgo8sPv mr9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pR1YvslHc1EFBdh/dc3/IPGKga3WjyxOPqWaWMqU9jQ=; b=himGiT3BcebTfVetZNqRWWvmTqKR0S5/IhAO0BwLPwqU74I/l/Os4FZNWGm2kjQoGz UTsedAVFBxFefDimtb66frRUgtZKugfGtDBscrm8Ajh/iCqoVOdq++o7HqaH1qE1gKjz otPIS9QZ9hdbnmXIP0zBoFPtWO9gVGM9Q1wfduSDSyqJzbam/DWEzOzypbKHTTDYmT/2 D00N6jkOZnm0ji/hdVIJAokNTY+8M46Ai80Qkmo2WB0NZ7xsU3Yr9o1do3CHldfqwehv ByZcegy3i/V6q0IY5OhEddxcsatmr36S6+h6rKOw51F/hVG0DUNI9kJ5YvCsc+8fex6d JUhQ== X-Gm-Message-State: APt69E3RZe7jmXv1Av13Cyef/PM2vyrKoNQ0ANsV1EtRVynIXMDpX4qO kQpzm448wKvDLK8oqdbfT55SRCaxTyi48EgVQOwqag== X-Google-Smtp-Source: ADUXVKJS2pDKBjN7MPRUHE9u2jH9sg6ZzgdDY/2Whorujj+lVaE7aNh9cl3TqKzUSHwvYeCMytTdinvjCE3uTlWNsvM= X-Received: by 2002:a25:3c84:: with SMTP id j126-v6mr9165686yba.178.1529432761954; Tue, 19 Jun 2018 11:26:01 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> From: Ian Swett Date: Tue, 19 Jun 2018 14:25:49 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" Cc: Marten Seemann , Kazuho Oku , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000007cce86056f02d0ad" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:26:17 -0000 --0000000000007cce86056f02d0ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm still not interested in this change, for the reasons I stated above. On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi wrote: > Hi All, > > > > Do we have agreement here to create a new PR? > > > > Thanks, > > Manasi > > > > *From:* Deval, Manasi > *Sent:* Sunday, June 17, 2018 2:25 PM > *To:* Marten Seemann ; Kazuho Oku < > kazuhooku@gmail.com> > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* RE: Proposal to replace ACK block count with ACK length > > > > Hi All, > > > > I have made a list of objections to the proposal and the solutions to > those objections discussed on this thread. > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > Christian suggested to move the ECN fields to precede the ACK blocks. Thi= s > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits would have been annoying, even though it can work. > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse A= CK to > identify length. There are some reservations when ACK parsing gets harder > for the case where the entire header needs to be parsed. > > > > Agreement from several folks here. In the original ACK defined in draft 1= 2 > of the slide, one would count down number of ACK blocks to get to the end > of the packet. In the proposal I made, one would count down the length to > identify the end of the packet. The logic is very similar in cycle count > and complexity. Several folks also commented to this effect. > > > > c. Multi-threaded packet processing > > > > I would expect that there are 10s of 1000s of connections in use at any > time for a server with a high speed link. Multi-threading to handle each = of > these flows / connections in parallel is necessity to be able to support > large number of connections on a high speed link. Tx segmentation, Rx > coalescing are well known strategies to reduce the processing cost. In > initial stages, code is often written as a single-threaded and then > re-factored to parallelize cycle intensive operations. In order to allow > this protocol to scale in future, I would suggest we do not preclude this > case. > > > > d. Increase in ACK size by 1 byte. > > > > I do not see this as a serious issue but if folks but we can consider > making this a varint, if others have strong feelings about it. It=E2=80= =99s a > trade-off : 2 reads to save 1 byte. > > > > e. Every encodable value should be valid > > Not every length will be valid. This is inherent to lengths. This same > issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue > exist for small values, it also applies to large values since data stream > will be sent after crypto negotiation. E.g. - how does one craft a > payload with 62 bit payload length in a large header? > > > > > > Thanks, > > Manasi > > > > > > *From:* Marten Seemann [mailto:martenseemann@gmail.com > ] > *Sent:* Sunday, June 17, 2018 6:59 AM > *To:* Kazuho Oku > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com>; Deval, Manasi > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the whole > packet, so as long as the packet payload is long enough, the varint parsi= ng > will not fail. > > I don't think that specifics of programming languages matter here though, > and I'm sure both frame formats can be reasonably implemented in C as wel= l > as in Go. The reasons I'm opposed to Manasi's proposal are that it moves = us > away from the principle that only reasonable values should be encodable, > and that it increases the size of the ACK frame, for the questionable > benefit of being able to parallelise the frame parser. > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > > At least for my implementation, parsing doesn't become easier, it becom= es > > more complex with this proposal. My varint-parser always consumes as ma= ny > > bytes as the varint requires, so after parsing a varint, I'd have to > > introduce an additional check that this didn't overflow the ACK length > (e.g. > > consider that I parsed the ACK frame so far that only 2 bytes are > remaining > > according to ACK length field, but the next varint is 4 bytes long). > > Isn't your varint parser checking that it has not (or will not) run > across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun. > > What I am saying that that check could be converted to a overrun check > against the end of the "frame payload", and that checking the > remaining block count becomes unnecessary, in case we replace ACK > Block Count with ACK Frame Length. > > > > > In general, we've been moving the wire image towards making every > encodable > > value valid. This proposal moves us away from that principle: > > * some small values are always invalid (the length can never be between= 0 > > and 3) > > * a lot of intermediate values are invalid (if the boundary falls insid= e > a > > varint, as described above) > > Both these cases can't occur with the current ACK frame format. > > > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: > >> > >> 2018-06-17 8:34 GMT+09:00 Ian Swett > >> : > >> > I'm not a fan of this proposal, because I think it is impractical to > >> > drop > >> > the number of ack blocks, because with the ECN proposal it becomes > >> > impractically complex to parse. > >> > >> For the ECN proposal, as Christian has suggested, we can move the ECN > >> counters before the ACK blocks. Then, it would not be complex to > >> parse. > >> > >> And my view is that parsing becomes easier if we replace ACK Block > >> Count with ACK Frame Length. > >> > >> Now, with ACK Block Count, we need to check the remaining number of > >> blocks and the remaining space in the packet payload for every block > >> that we parse. Failing to check either leads to a bug or a security > >> issue. > >> > >> If we switch to ACK Frame Length, we need to only check the remaining > >> space in the frame. > >> > >> I think that this is the biggest benefit of replacing ACK Block Count > >> with ACK Frame Length. OTOH the downside is that you need extra one to > >> two bits (one if the size of block / gap is expected to be below 65, > >> two if they are expected to be above that) for encoding ACK Frame > >> Length compared to ACK Block Count. > >> > >> > >> > >> Having said that, I honestly wonder if all the frames could have it's > >> length being encoded (either explicitly or either as a signal that > >> says "to the end of the packet"). Consider something like below: > >> > >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >> or > >> |1| frame-type (7) | frame-payload (*) | > >> > >> When MSB of the first octet set to zero, the length of the frame > >> payload is designated by the varint that immediately follows the frame > >> type. > >> When MSB of the first octet set to one, the length of the frame > >> payload spans to the end of the packet. > >> > >> In this encoding, we can always omit the Length field of a STREAM > >> frame. So the overhead for carrying stream data will be indifferent in > >> practice. > >> > >> For the ACK frame, we can omit the ACK Block Count field. And the > >> overhead will be one to two bits if the ACK frame is sent in the > >> middle of the packet (thereby using the encoding with explicit frame > >> payload length), or one octet or more shorter if ACK is the last frame > >> of the packet. > >> > >> We are likely to see increase of overhead for most of the other types > >> of frames, but I do not think that would be an issue considering that > >> they will be far seldom seen compared to STREAMs and ACKs. > >> > >> To summarize, my anticipation is that we can make all the frames > >> self-contained (i.e. the length can be determined without the > >> knowledge of how each frame is encoded) without any overhead, if we > >> agree on making the frame type space 1 bit smaller. > >> > >> Finally, the biggest benefit of using a self-contained encoding of > >> frames is that we would have the ability to introduce new optional > >> frames without negotiation. By making the frames self-contained, QUIC > >> endpoints will have the freedom of ignoring the frames that they do > >> not understand. > >> > >> Being able to send QUIC frames defined in extensions without > >> negotiating using Transport Parameters will be a win in both terms of > >> security (because clients' TP is sent in clear) and flexibility > >> (because we will be possible to send the extensions before we figure > >> out whether the peer supports that extension). > >> > >> > If we don't remove the number of ack blocks, then the ack frame is > >> > larger, > >> > but I don't think the extra size field is useful for most > >> > implementations. > >> > Also, it means the length can disagree with the actual length, which > add > >> > complexity and the possibility of writing error-prone code. The ide= a > of > >> > someone offloading ack processing and then proceeding to trust the > >> > length > >> > seems like someone could get wrong and cause some concerning issues. > >> > > >> > My experience is multithreaded packet processing is more cost and wo= rk > >> > than > >> > it's worth. Sure you can't fill a 100G NIC with one connection, but > >> > that > >> > seems like an academic problem, not one for workloads I've seen. > >> > Typically > >> > the extra cost of multithreading outweighs its value. > >> > > >> > To be clear, I don't think this is an awful idea, but I also don't s= ee > >> > the > >> > value and it adds complexity. I read Manasi's email, but I don't > think > >> > I > >> > understand why any of those matter in practice. > >> > > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >> >> > >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >> >> > >> >> wrote: > >> >>> > >> >>> This proposal increases the size of the ACK frame by 1 byte in the > >> >>> common > >> >>> case (less than 63 ACK ranges), since the ACK length field here > always > >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length > >> >>> integer. > >> >>> Considering how much work we put into minimising the size of the > >> >>> frames, > >> >>> this feels like a step in the wrong direction.. > >> >>> > >> >>> Regarding the processing cost, I agree with Dmitri. Handling an AC= K > >> >>> frame > >> >>> requires looping over and making changes to a data structure that > >> >>> keeps > >> >>> track of sent packets. This is much more expensive than simply > parsing > >> >>> a > >> >>> bunch of varints in the ACK frame. It seems unlikely that a > >> >>> multi-threaded > >> >>> packet parser would offer any real-world performance benefits. > >> >> > >> >> > >> >> I don't want to overstate the benefit here, but my point isn't that > >> >> parsing is expensive but that if you want to have a multithreaded > >> >> packet > >> >> processing system, then it's nice to have a simpler data structure > (the > >> >> unparsed ACK block) to hand to the ACK processing thread. > >> >> > >> >> -Ekr > >> >> > >> >> > >> >>> > >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> When we discussed this before, some people observed that this > creates > >> >>>> a need to encode in two passes. That's the trade-off here. (Not > >> >>>> expressing an opinion.) > >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >> >>>> wrote: > >> >>>> > > >> >>>> > I don't have a strong opinion on this. I'm certainly not oppose= d > to > >> >>>> > it. > >> >>>> > Does anyone have a strong opposition? > >> >>>> > > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> I agree as well since this can help reduce per packet processi= ng > >> >>>> >> overhead. ACKs are going to be the second most common frame ty= pe > >> >>>> >> so no > >> >>>> >> objections to special casing. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >> >>>> >> Rescorla > >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >> >>>> >> To: Deval, Manasi > >> >>>> >> Cc: Jana Iyengar ; QUIC WG > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> I agree with Manasi here. This change would allow ack frame > >> >>>> >> parsing > >> >>>> >> to be more self-contained, which is an advantage for the parse= r > >> >>>> >> and also > >> >>>> >> potentially for parallelism (because you can quickly find the > >> >>>> >> frame and then > >> >>>> >> process it in parallel). > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> -Ekr > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> In general, varints require some specific logic for parsing. T= o > >> >>>> >> skip > >> >>>> >> over any header, I have to read every single varint. As the co= de > >> >>>> >> sees Stream > >> >>>> >> and ACK headers most frequently, that is my focus. The Stream > >> >>>> >> frame has a > >> >>>> >> length in its third field. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify > >> >>>> >> length. There are two reads each for =E2=80=98largest acknowle= dged=E2=80=99, > =E2=80=98ACK > >> >>>> >> delay=E2=80=99 and > >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total= number of cycles > >> >>>> >> parse an > >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packet= s > >> >>>> >> have a > >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck= . > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> > >> >>>> >> Manasi > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >> >>>> >> Iyengar > >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >> >>>> >> To: Deval, Manasi ; QUIC WG > >> >>>> >> > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> You're right that we no longer have the ability to skip an ACK > >> >>>> >> frame, > >> >>>> >> and this crept in when we moved to varints. > >> >>>> >> > >> >>>> >> I believe your problem though is generally true of most frames > not > >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frame= s > >> >>>> >> are now all > >> >>>> >> varints. To skip any frame, you'll need to parse the varint > fields > >> >>>> >> in those > >> >>>> >> frames. If you have logic to process and skip varints, then > >> >>>> >> skipping the ack > >> >>>> >> block section is merely repeating this operation (2*num_block+= 1) > >> >>>> >> times. Do > >> >>>> >> you see specific value in skipping ACK frames over the other > >> >>>> >> control frames? > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >> >>>> >> > - Moving the ACK length to the front of the ACK allow= s > >> >>>> >> > the > >> >>>> >> > flexibility of either reading the entire ACK or > reading > >> >>>> >> > the > >> >>>> >> > first 16 bits and skipping over the length. This is= a > >> >>>> >> > useful > >> >>>> >> > feature for the case where ACK processing is split > into > >> >>>> >> > multiple layers. Depending on the processor this is > run > >> >>>> >> > on, > >> >>>> >> > there are different advantages - > >> >>>> >> > >> >>>> >> Just a note. In my experience, the cost of parsing an ACK fra= me > >> >>>> >> is > >> >>>> >> negligible compared to the cost of processing an ACK frame: th= at > >> >>>> >> is, > >> >>>> >> poking at various memory locations to discard newly ACKed > packets. > >> >>>> >> > >> >>>> >> - Dmitri. > >> >>>> >> > >> >>>> >> > >> >>>> > >> >> > >> > > >> > >> > >> > >> -- > >> Kazuho Oku > > > > -- > Kazuho Oku > > --0000000000007cce86056f02d0ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm still not interested in this change, for the reaso= ns I stated above.

On = Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com> wrote:

Hi All,

=C2=A0

Do we have agreement here to create a= new PR?

=C2=A0

Thanks,

Manasi

=C2=A0

From: Deval, Manasi
Sent: Sunday, June 17, 2018 2:25 PM
To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <kazuhooku@gmail.com> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorl= a <ekr@rtfm.com>= ;; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QU= IC WG <quic@ietf.org<= /a>>; Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

Hi All,

=C2=A0

I have made a list of objections to t= he proposal and the solutions to those objections discussed on this thread.

=C2=A0

a.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Co-existence of length field wit= h ECN field and ACK blocks.

= =C2=A0

Christian= suggested to move the ECN fields to precede the ACK blocks. This is an ele= gant solution. Parsing entire list of ACK blocks to review ECN bits would have been annoying, even though it can work.

= =C2=A0

b.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 There are two cases to be parsed= =E2=80=93 entire ACK and parse ACK to identify length. There are some rese= rvations when ACK parsing gets harder for the case where the entire header needs to be parsed.

= =C2=A0

Agreement= from several folks here. In the original ACK defined in draft 12 of the sl= ide, one would count down number of ACK blocks to get to the end of the packet. In the proposal I made, one would count down the length to ide= ntify the end of the packet. The logic is very similar in cycle count and c= omplexity. Several folks also commented to this effect.

= =C2=A0

c.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Multi-threaded packet processing

= =C2=A0

I would e= xpect that there are 10s of 1000s of connections in use at any time for a s= erver with a high speed link. Multi-threading to handle each of these flows / connections in parallel is necessity to be able to support large n= umber of connections on a high speed link. Tx segmentation, Rx coalescing a= re well known strategies to reduce the processing cost. In initial stages, = code is often written as a single-threaded and then re-factored to parallelize cycle intensive operations. In order t= o allow this protocol to scale in future, I would suggest we do not preclud= e this case.

= =C2=A0

d.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Increase in ACK size by 1 byte.<= u>

= =C2=A0

I do not = see this as a serious issue but if folks but we can consider making this a = varint, if others have strong feelings about it. It=E2=80=99s a trade-off : 2 reads to save 1 byte.

= =C2=A0

e.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every encodable v= alue should be valid

<= span style=3D"color:#0070c0">Not every length will be valid. This is inhere= nt to lengths. This same issue ails the =E2=80=98payload length=E2=80=99 in= QUIC header. Not only does the issue exist for small values, it also appli= es to large values since data stream will be sent after crypto negotiation.= =C2=A0 E.g. =C2=A0- how does one craft a payload with 62 bit payload length= in a large header?

=C2=A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: Marten Seemann [mailto:martenseemann@gmail.c= om]
Sent: Sunday, June 17, 2018 6:59 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; E= ric Rescorla <ekr@rtfm= .com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= ;martin.thoms= on@gmail.com>; Deval, Manasi <manasi.dev= al@intel.com>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

Maybe it's specific to Go, but I'm using a s= ingle io.Reader for the whole packet, so as long as the packet payload is l= ong enough, the varint parsing will not fail.

I don't think that specifics of programming lang= uages matter here though, and I'm sure both frame formats can be reason= ably implemented in C as well as in Go. The reasons I'm opposed to Mana= si's proposal are that it moves us away from the principle that only reasonable values should be encodable, and that it inc= reases the size of the ACK frame, for the questionable benefit of being abl= e to parallelise the frame parser.

=C2=A0

On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com= > wrote:

2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.= com>:
> At least for my implementation, parsing doesn't become easier, it = becomes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have = to
> introduce an additional check that this didn't overflow the ACK le= ngth (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every = encodable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format. >
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is imp= ractical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>=C2=A0 or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibilit= y
>> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack= frame is
>> > larger,
>> > but I don't think the extra size field is useful for most=
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.= =C2=A0 The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with= one connection, but
>> > that
>> > seems like an academic problem, not one for workloads I'v= e seen.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I a= lso don't see
>> > the
>> > value and it adds complexity.=C2=A0 I read Manasi's email= , but I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my po= int isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler d= ata structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.=C2=A0 That's = the trade-off here.=C2=A0 (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I= 'm certainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.=C2=A0 The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*num_bl= ocks reads to identify
>> >>>> >> length. There are two reads each for =E2= =80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>> >>>> >> delay=E2=80=99 and
>> >>>> >> =E2=80=98ACK block count=E2=80=99. The p= ain point is the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have = the ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll n= eed to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wrote: >> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000= , Deval, Manasi wrote:
>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= eature for the case where ACK processing is split into
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.=C2=A0 In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku

--0000000000007cce86056f02d0ad-- From nobody Tue Jun 19 12:12:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2B130E1E for ; Tue, 19 Jun 2018 12:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 LQ39jWfvIzL5 for ; Tue, 19 Jun 2018 12:12:13 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 BB5D7130DED for ; Tue, 19 Jun 2018 12:12:13 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id q17-v6so945104otg.2 for ; Tue, 19 Jun 2018 12:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WwEVWf3OM61j7LTvcShF9Z2iR7sFGqz/GJgJjJ9u5dg=; b=2BFcCNx7FPAtUc+sp7LHbkBaOwsk3w3O0UIdhVzf3plYSSMG3MOZi/Ud6g/v65JIhQ LaRuQUWFtWurwS93hmUBQw0yVmbXTPyFubcB+dMHfPB4ZpnFa3BhyXWBRZYb8oFEXOcZ zEgI8lR+Ina29tfrPoANrYuNgDJmoUg78FqMfM90Hp8J7OAeBr997qQaBGJumymmNyy4 EqdX9gCv8FatjgcmlCZDcmWffA/ZQA07cvduLjYoFXIi8pn28vZf530Ip55BQOI9JnKJ ogvFTJZdpYQQSi1BbdLUFINT2SLfm2SunFl5jKABYgm8Fpe5jj1alBjYCBPKJp2ZTudw xrYA== 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=WwEVWf3OM61j7LTvcShF9Z2iR7sFGqz/GJgJjJ9u5dg=; b=PXqhve2AKE9F7NOpkD3sU/k2P6xe2PZLcPsCvljjjVNBPU2yo0OLYk5crUpZj6Uy1d A0wvzwpoxdPdimQLYQNsPyOsf/vQNG5tPLd0ZZFD/q6HrFd1A3GLjdmqg09c/mAyhxuG naSOo8RA+ptbC8wnKLbhnyMDYU0Km5VAh21jS13iNjwzOEqOgLjgZe/SsAPA9ffItyzE HO9UBx1R7PBy8fdIYhilds8a6B4egNEHqSHAScW7biGzbsRk1YK4c+taeofsqHwTaRKG Kjq4yfbrLamh07dX6VrKLtpUcK0TTVX9UVIeQDsEhO1uP1ASE7fpfJo8EA1XXR43MDNz VcJA== X-Gm-Message-State: APt69E0/TPaTjE6NUU6dAv7Md+WHZ7yAhANQ5Md7ff6VqfzUsr2NCdhb Z4KA47Pzj0sQgF2HL/Rng5gOu9I68gOiLhK9Y7mBig== X-Google-Smtp-Source: ADUXVKJyhGspILb74lovGrxokd7G2uaml7ND80+UOsgdzWXOZ6EuUvuCN9GMALATrXP9bLJ8Mph3yXhp9nWfWucZ8ng= X-Received: by 2002:a9d:55d0:: with SMTP id z16-v6mr11890223oti.176.1529435533101; Tue, 19 Jun 2018 12:12:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:11:32 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> From: Eric Rescorla Date: Tue, 19 Jun 2018 12:11:32 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Kazuho Oku , "Deval, Manasi" , Marten Seemann , Praveen Balasubramanian , Jana Iyengar , IETF QUIC WG , Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary="000000000000a85fdb056f0375d2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:12:17 -0000 --000000000000a85fdb056f0375d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 19, 2018 at 11:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: > I don=E2=80=99t think you addressed e) at all. Clearly there is an end of= buffer > check, but that is not the same as requiring additonal checks at many oth= er > levels. > Not Manasi, but I don't understand (e). Here's the relevant section of the Minq decoder. func (f *ackFrame) unmarshal(buf []byte) (int, error) { // Omitted the section that decoded the header // Now decode each block for i :=3D uint64(0); i < f.AckBlockCount; i++ { blk :=3D &ackBlock{} n, err :=3D syntax.Unmarshal(buf, blk) if err !=3D nil { return 0, err } buf =3D buf[n:] read +=3D n f.AckBlockSection =3D append(f.AckBlockSection, blk) } return read, nil } You pass in the entire remainder of the packet and then it parses out the ACK frame and then returns the amount consumed. If we were to change to what Manasi proposes, it would look like: func (f *ackFrame) unmarshal(buf []byte) (int, error) { // Omitted the section that decoded the header // Trim the buffer to the remainder length if f.AckLength > len(buf) { return 0, ProtocolInvalidError } buf =3D buf[f.AckLength:] for len(buf) > 0 { blk :=3D &ackBlock{} n, err :=3D syntax.Unmarshal(buf, blk) if err !=3D nil { return 0, err } buf =3D buf[n:] read +=3D n f.AckBlockSection =3D append(f.AckBlockSection, blk) } return read, nil } Is your concern here the additional length check after the comment "Trim the buffer"? Something else? -Ekr > > On 19 June 2018 at 20.22.03, Deval, Manasi (manasi.deval@intel.com) wrote= : > > > > e. Every encodable value should be valid > > Not every length will be valid. This is inherent to lengths. This same > issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue > exist for small values, it also applies to large values since data stream > will be sent after crypto negotiation. E.g. - how does one craft a > payload with 62 bit payload length in a large header? > > --000000000000a85fdb056f0375d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Jun 19, 2018 at 11:25 AM, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com> wrote:
I don=E2= =80=99t think you addressed e) at all. Clearly there is an end of buffer ch= eck, but that is not the same as requiring additonal checks at many other l= evels.


Not= Manasi, but I don't understand (e).

Here's the relevant sec= tion of the Minq decoder.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2= =A0=C2=A0=C2=A0 func (f *ackFrame) unmarshal(buf []byte) (int, error) {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Omitted the section that deco= ded the header
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 // Now decode each block
=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 for i :=3D uint64(0); i < f.AckBlockCoun= t; i++ {
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 blk := =3D &ackBlock{}
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 n, err :=3D syntax.Unmarshal(buf, blk)
=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if err !=3D nil {
=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return 0, err
=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 buf =3D buf[n:]
=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 read +=3D n
=C2=A0=C2=A0=C2= =A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 f.AckBlock= Section =3D append(f.AckBlockSection, blk)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 }
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= return read, nil
=C2=A0=C2=A0=C2=A0 }

You pass in the entire rem= ainder of the packet and then it parses
out the ACK frame and then retur= ns the amount consumed.

If we were to change to what Manasi proposes= , it would look like:

=C2=A0=C2=A0=C2=A0 func (f *ackFrame) unmarsha= l(buf []byte) (int, error) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = // Omitted the section that decoded the header
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 //= Trim the buffer to the remainder length
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 if f.AckLength > len(buf) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 0, P= rotocolInvalidError
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 buf =3D buf[f.AckLength:]

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for len(buf) > 0 {
=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 blk :=3D &ackBlock{}=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 n, err :=3D sy= ntax.Unmarshal(buf, blk)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 if err !=3D nil {
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return 0, err
=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 buf =3D buf[n:]
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 read +=3D n
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 f.AckBlockSection =3D append(f.Ac= kBlockSection, blk)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return read, nil
=C2= =A0=C2=A0=C2=A0 }

Is your concern here the additional length check a= fter the
comment "Trim the buffer"? Something else?

-E= kr



=C2=A0

=

On 19 June 2018 at 20.22= .03, Deval, Manasi (manasi.deval@intel.com) wrote:

=C2=A0

e.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Every encodable value should be valid<= /span>

Not every length will be valid. This is inherent to l= engths. This same issue ails the =E2=80=98payload length=E2=80=99 in QUIC h= eader. Not only does the issue exist for small values, it also applies to l= arge values since data stream will be sent after crypto negotiation.=C2=A0 = E.g. =C2=A0- how does one craft a payload with 62 bit payload length in a l= arge header?


--000000000000a85fdb056f0375d2-- From nobody Tue Jun 19 13:19:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2D6130ECB for ; Tue, 19 Jun 2018 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 oe9dzHBtRaXk for ; Tue, 19 Jun 2018 13:19:07 -0700 (PDT) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 27948130E30 for ; Tue, 19 Jun 2018 13:19:07 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 13:19:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,244,1526367600"; d="scan'208,217";a="233912253" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga005.jf.intel.com with ESMTP; 19 Jun 2018 13:19:05 -0700 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Jun 2018 13:19:05 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX153.amr.corp.intel.com ([10.22.226.247]) with mapi id 14.03.0319.002; Tue, 19 Jun 2018 13:19:05 -0700 From: "Deval, Manasi" To: Eric Rescorla , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Kazuho Oku , Marten Seemann , Praveen Balasubramanian , Jana Iyengar , IETF QUIC WG , "Martin Thomson" , Ian Swett Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7XrIAAAZkJAAAMVqCA Date: Tue, 19 Jun 2018 20:19:05 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B83EEFC@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGQ2NWFlZWMtODQyNC00NTVkLThlMTctOWU1YWM5NWQyYmExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicjhjSFwvcllXV2lINWFiTmY4bzBLWmNHVGhLUTFoVFJCeXJDNFpoM0lidFl4a0hrYlhMd2VqbFwvMURrdGNwSjhjIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B83EEFCORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:19:13 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B83EEFCORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHRoZSBzYW1lIHF1ZXN0aW9uIGFzIEVyaWMuDQoNCkZyb206IEVyaWMgUmVzY29ybGEg W21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDEyOjEy IFBNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0K Q2M6IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+OyBEZXZhbCwgTWFuYXNpIDxtYW5h c2kuZGV2YWxAaW50ZWwuY29tPjsgTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwu Y29tPjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBKYW5h IEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBJYW4gU3dldHQg PGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQcm9w b3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCg0KDQoNCg0K T24gVHVlLCBKdW4gMTksIDIwMTggYXQgMTE6MjUgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6 DQpJIGRvbuKAmXQgdGhpbmsgeW91IGFkZHJlc3NlZCBlKSBhdCBhbGwuIENsZWFybHkgdGhlcmUg aXMgYW4gZW5kIG9mIGJ1ZmZlciBjaGVjaywgYnV0IHRoYXQgaXMgbm90IHRoZSBzYW1lIGFzIHJl cXVpcmluZyBhZGRpdG9uYWwgY2hlY2tzIGF0IG1hbnkgb3RoZXIgbGV2ZWxzLg0KDQoNCk5vdCBN YW5hc2ksIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgKGUpLg0KDQpIZXJlJ3MgdGhlIHJlbGV2YW50 IHNlY3Rpb24gb2YgdGhlIE1pbnEgZGVjb2Rlci4NCg0KICAgIGZ1bmMgKGYgKmFja0ZyYW1lKSB1 bm1hcnNoYWwoYnVmIFtdYnl0ZSkgKGludCwgZXJyb3IpIHsNCiAgICAgICAgLy8gT21pdHRlZCB0 aGUgc2VjdGlvbiB0aGF0IGRlY29kZWQgdGhlIGhlYWRlcg0KDQogICAgICAgIC8vIE5vdyBkZWNv ZGUgZWFjaCBibG9jaw0KICAgICAgICBmb3IgaSA6PSB1aW50NjQoMCk7IGkgPCBmLkFja0Jsb2Nr Q291bnQ7IGkrKyB7DQogICAgICAgICAgICBibGsgOj0gJmFja0Jsb2Nre30NCiAgICAgICAgICAg IG4sIGVyciA6PSBzeW50YXguVW5tYXJzaGFsKGJ1ZiwgYmxrKQ0KICAgICAgICAgICAgaWYgZXJy ICE9IG5pbCB7DQogICAgICAgICAgICAgICAgcmV0dXJuIDAsIGVycg0KICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgYnVmID0gYnVmW246XQ0KICAgICAgICAgICAgcmVhZCArPSBuDQoNCiAgICAg ICAgICAgIGYuQWNrQmxvY2tTZWN0aW9uID0gYXBwZW5kKGYuQWNrQmxvY2tTZWN0aW9uLCBibGsp DQogICAgICAgIH0NCg0KICAgICAgICByZXR1cm4gcmVhZCwgbmlsDQogICAgfQ0KDQpZb3UgcGFz cyBpbiB0aGUgZW50aXJlIHJlbWFpbmRlciBvZiB0aGUgcGFja2V0IGFuZCB0aGVuIGl0IHBhcnNl cw0Kb3V0IHRoZSBBQ0sgZnJhbWUgYW5kIHRoZW4gcmV0dXJucyB0aGUgYW1vdW50IGNvbnN1bWVk Lg0KDQpJZiB3ZSB3ZXJlIHRvIGNoYW5nZSB0byB3aGF0IE1hbmFzaSBwcm9wb3NlcywgaXQgd291 bGQgbG9vayBsaWtlOg0KDQogICAgZnVuYyAoZiAqYWNrRnJhbWUpIHVubWFyc2hhbChidWYgW11i eXRlKSAoaW50LCBlcnJvcikgew0KICAgICAgICAvLyBPbWl0dGVkIHRoZSBzZWN0aW9uIHRoYXQg ZGVjb2RlZCB0aGUgaGVhZGVyDQoNCiAgICAgICAgLy8gVHJpbSB0aGUgYnVmZmVyIHRvIHRoZSBy ZW1haW5kZXIgbGVuZ3RoDQogICAgICAgIGlmIGYuQWNrTGVuZ3RoID4gbGVuKGJ1Zikgew0KICAg ICAgICAgICAgICAgIHJldHVybiAwLCBQcm90b2NvbEludmFsaWRFcnJvcg0KICAgICAgICB9DQog ICAgICAgIGJ1ZiA9IGJ1ZltmLkFja0xlbmd0aDpdDQoNCiAgICAgICAgZm9yIGxlbihidWYpID4g MCB7DQogICAgICAgICAgICBibGsgOj0gJmFja0Jsb2Nre30NCiAgICAgICAgICAgIG4sIGVyciA6 PSBzeW50YXguVW5tYXJzaGFsKGJ1ZiwgYmxrKQ0KICAgICAgICAgICAgaWYgZXJyICE9IG5pbCB7 DQogICAgICAgICAgICAgICAgcmV0dXJuIDAsIGVycg0KICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgYnVmID0gYnVmW246XQ0KICAgICAgICAgICAgcmVhZCArPSBuDQoNCiAgICAgICAgICAgIGYu QWNrQmxvY2tTZWN0aW9uID0gYXBwZW5kKGYuQWNrQmxvY2tTZWN0aW9uLCBibGspDQogICAgICAg IH0NCg0KICAgICAgICByZXR1cm4gcmVhZCwgbmlsDQogICAgfQ0KDQpJcyB5b3VyIGNvbmNlcm4g aGVyZSB0aGUgYWRkaXRpb25hbCBsZW5ndGggY2hlY2sgYWZ0ZXIgdGhlDQpjb21tZW50ICJUcmlt IHRoZSBidWZmZXIiPyBTb21ldGhpbmcgZWxzZT8NCg0KLUVrcg0KDQoNCg0KDQoNCg0KT24gMTkg SnVuZSAyMDE4IGF0IDIwLjIyLjAzLCBEZXZhbCwgTWFuYXNpIChtYW5hc2kuZGV2YWxAaW50ZWwu Y29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPikgd3JvdGU6DQoNCg0KDQplLiAgICAg IEV2ZXJ5IGVuY29kYWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQNCg0KTm90IGV2ZXJ5IGxlbmd0 aCB3aWxsIGJlIHZhbGlkLiBUaGlzIGlzIGluaGVyZW50IHRvIGxlbmd0aHMuIFRoaXMgc2FtZSBp c3N1ZSBhaWxzIHRoZSDigJhwYXlsb2FkIGxlbmd0aOKAmSBpbiBRVUlDIGhlYWRlci4gTm90IG9u bHkgZG9lcyB0aGUgaXNzdWUgZXhpc3QgZm9yIHNtYWxsIHZhbHVlcywgaXQgYWxzbyBhcHBsaWVz IHRvIGxhcmdlIHZhbHVlcyBzaW5jZSBkYXRhIHN0cmVhbSB3aWxsIGJlIHNlbnQgYWZ0ZXIgY3J5 cHRvIG5lZ290aWF0aW9uLiAgRS5nLiAgLSBob3cgZG9lcyBvbmUgY3JhZnQgYSBwYXlsb2FkIHdp dGggNjIgYml0IHBheWxvYWQgbGVuZ3RoIGluIGEgbGFyZ2UgaGVhZGVyPw0KDQo= --_000_1F436ED13A22A246A59CA374CBC543998B83EEFCORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LmdtYWlsLQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC07fQ0KcC5nbWFpbC1tMzIwMzYxNDE4Nzk3 MDc1MjU1M2Fpcm1haWxvbiwgbGkuZ21haWwtbTMyMDM2MTQxODc5NzA3NTI1NTNhaXJtYWlsb24s IGRpdi5nbWFpbC1tMzIwMzYxNDE4Nzk3MDc1MjU1M2Fpcm1haWxvbg0KCXttc28tc3R5bGUtbmFt ZTpnbWFpbC1tXzMyMDM2MTQxODc5NzA3NTI1NTNhaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5nbWFpbC1tMzIwMzYxNDE4Nzk3MDc1MjU1M21z b2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0zMjAzNjE0MTg3OTcwNzUyNTUzbXNvbGlzdHBhcmFn cmFwaCwgZGl2LmdtYWlsLW0zMjAzNjE0MTg3OTcwNzUyNTUzbXNvbGlzdHBhcmFncmFwaA0KCXtt c28tc3R5bGUtbmFtZTpnbWFpbC1tXzMyMDM2MTQxODc5NzA3NTI1NTNtc29saXN0cGFyYWdyYXBo Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5nbWFpbC1tMzIw MzYxNDE4Nzk3MDc1MjU1M21zb3BsYWludGV4dCwgbGkuZ21haWwtbTMyMDM2MTQxODc5NzA3NTI1 NTNtc29wbGFpbnRleHQsIGRpdi5nbWFpbC1tMzIwMzYxNDE4Nzk3MDc1MjU1M21zb3BsYWludGV4 dA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzMyMDM2MTQxODc5NzA3NTI1NTNtc29wbGFpbnRl eHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmdtYWls LW0zMjAzNjE0MTg3OTcwNzUyNTUzYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOmdtYWlsLW1fMzIwMzYxNDE4Nzk3MDc1MjU1M2FwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSB0 aGUgc2FtZSBxdWVzdGlvbiBhcyBFcmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfX19fX3JlcGx5c2VwYXJhdG9yIj48L2E+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBb bWFpbHRvOmVrckBydGZtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDE5 LCAyMDE4IDEyOjEyIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu ICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLYXp1aG8gT2t1ICZs dDtrYXp1aG9va3VAZ21haWwuY29tJmd0OzsgRGV2YWwsIE1hbmFzaSAmbHQ7bWFuYXNpLmRldmFs QGludGVsLmNvbSZndDs7IE1hcnRlbiBTZWVtYW5uICZsdDttYXJ0ZW5zZWVtYW5uQGdtYWlsLmNv bSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0 OzsgSmFuYSBJeWVuZ2FyICZsdDtqcmkuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25A Z21haWwuY29tJmd0OzsNCiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFByb3Bvc2FsIHRvIHJlcGxh Y2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBKdW4gMTksIDIwMTggYXQgMTE6MjUgQU0sIE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8zMjAzNjE0MTg3OTcwNzUyNTUz Ymxvb3BfY3VzdG9tZm9udCI+DQo8ZGl2IGlkPSJnbWFpbC1tXzMyMDM2MTQxODc5NzA3NTI1NTNi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5JIGRvbuKAmXQgdGhpbmsgeW91IGFkZHJlc3NlZCBlKSBhdCBhbGwuIENs ZWFybHkgdGhlcmUgaXMgYW4gZW5kIG9mIGJ1ZmZlciBjaGVjaywgYnV0IHRoYXQgaXMgbm90IHRo ZSBzYW1lIGFzIHJlcXVpcmluZyBhZGRpdG9uYWwgY2hlY2tzIGF0IG1hbnkgb3RoZXIgbGV2ZWxz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IE1hbmFzaSwgYnV0IEkg ZG9uJ3QgdW5kZXJzdGFuZCAoZSkuPGJyPg0KPGJyPg0KSGVyZSdzIHRoZSByZWxldmFudCBzZWN0 aW9uIG9mIHRoZSBNaW5xIGRlY29kZXIuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBmdW5jIChmICphY2tGcmFtZSkgdW5t YXJzaGFsKGJ1ZiBbXWJ5dGUpIChpbnQsIGVycm9yKSB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIE9taXR0ZWQgdGhlIHNlY3Rpb24gdGhhdCBkZWNv ZGVkIHRoZSBoZWFkZXI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAvLyBOb3cgZGVjb2RlIGVhY2ggYmxvY2s8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7IGZvciBpIDo9IHVpbnQ2NCgwKTsgaSAmbHQ7IGYuQWNrQmxvY2tDb3Vu dDsgaSYjNDM7JiM0Mzsgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGJsayA6PSAmYW1wO2Fja0Jsb2Nre308YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBuLCBlcnIg Oj0gc3ludGF4LlVubWFyc2hhbChidWYsIGJsayk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBpZiBlcnIgIT0gbmlsIHs8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIDAsIGVycjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBidWYgPSBidWZbbjpd PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsgcmVhZCAmIzQzOz0gbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBmLkFja0Js b2NrU2VjdGlvbiA9IGFwcGVuZChmLkFja0Jsb2NrU2VjdGlvbiwgYmxrKTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiByZWFkLCBu aWw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCjxicj4NCllvdSBwYXNzIGluIHRoZSBl bnRpcmUgcmVtYWluZGVyIG9mIHRoZSBwYWNrZXQgYW5kIHRoZW4gaXQgcGFyc2VzPGJyPg0Kb3V0 IHRoZSBBQ0sgZnJhbWUgYW5kIHRoZW4gcmV0dXJucyB0aGUgYW1vdW50IGNvbnN1bWVkLjxicj4N Cjxicj4NCklmIHdlIHdlcmUgdG8gY2hhbmdlIHRvIHdoYXQgTWFuYXNpIHByb3Bvc2VzLCBpdCB3 b3VsZCBsb29rIGxpa2U6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGZ1bmMgKGYgKmFj a0ZyYW1lKSB1bm1hcnNoYWwoYnVmIFtdYnl0ZSkgKGludCwgZXJyb3IpIHs8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gT21pdHRlZCB0aGUgc2VjdGlv biB0aGF0IGRlY29kZWQgdGhlIGhlYWRlcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7IC8vIFRyaW0gdGhlIGJ1ZmZlciB0byB0aGUgcmVtYWluZGVyIGxlbmd0 aDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiBmLkFj a0xlbmd0aCAmZ3Q7IGxlbihidWYpIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmV0dXJuIDAsIFByb3RvY29sSW52YWxpZEVycm9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYnVmID0gYnVmW2YuQWNrTGVuZ3RoOl08YnI+DQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGxlbihidWYpICZn dDsgMCB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsgYmxrIDo9ICZhbXA7YWNrQmxvY2t7fTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IG4sIGVyciA6PSBzeW50YXgu VW5tYXJzaGFsKGJ1ZiwgYmxrKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIGVyciAhPSBuaWwgezxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyByZXR1cm4gMCwgZXJyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGJ1ZiA9IGJ1ZltuOl08YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyByZWFk ICYjNDM7PSBuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGYuQWNrQmxvY2tTZWN0aW9u ID0gYXBwZW5kKGYuQWNrQmxvY2tTZWN0aW9uLCBibGspPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIHJlYWQsIG5pbDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KPGJyPg0KSXMgeW91ciBjb25jZXJuIGhlcmUgdGhlIGFk ZGl0aW9uYWwgbGVuZ3RoIGNoZWNrIGFmdGVyIHRoZTxicj4NCmNvbW1lbnQgJnF1b3Q7VHJpbSB0 aGUgYnVmZmVyJnF1b3Q7PyBTb21ldGhpbmcgZWxzZT8gPGJyPg0KPGJyPg0KLUVrcjxicj4NCjxi cj4NCjxicj4NCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbC0iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tMzIwMzYxNDE4Nzk3MDc1 MjU1M2Fpcm1haWxvbiI+T24gMTkgSnVuZSAyMDE4IGF0IDIwLjIyLjAzLCBEZXZhbCwgTWFuYXNp ICg8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJnbWFpbC1tMzIwMzYxNDE4Nzk3MDc1MjU1M21zb2xpc3RwYXJhZ3JhcGgi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0zMjAzNjE0 MTg3OTcwNzUyNTUzbXNvcGxhaW50ZXh0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPmUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW0zMjAzNjE0MTg3OTcwNzUy NTUzYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDA3MEMwIj5FdmVyeQ0KIGVuY29kYWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFs aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iZ21haWwtbTMyMDM2MTQxODc5NzA3NTI1NTNtc29wbGFpbnRleHQiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Tm90IGV2ZXJ5IGxlbmd0aCB3aWxsIGJlIHZhbGlkLiBU aGlzIGlzIGluaGVyZW50IHRvIGxlbmd0aHMuIFRoaXMgc2FtZSBpc3N1ZSBhaWxzIHRoZSDigJhw YXlsb2FkIGxlbmd0aOKAmSBpbiBRVUlDIGhlYWRlci4gTm90IG9ubHkgZG9lcyB0aGUgaXNzdWUg ZXhpc3QgZm9yIHNtYWxsIHZhbHVlcywgaXQgYWxzbyBhcHBsaWVzDQogdG8gbGFyZ2UgdmFsdWVz IHNpbmNlIGRhdGEgc3RyZWFtIHdpbGwgYmUgc2VudCBhZnRlciBjcnlwdG8gbmVnb3RpYXRpb24u Jm5ic3A7IEUuZy4gJm5ic3A7LSBob3cgZG9lcyBvbmUgY3JhZnQgYSBwYXlsb2FkIHdpdGggNjIg Yml0IHBheWxvYWQgbGVuZ3RoIGluIGEgbGFyZ2UgaGVhZGVyPzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_1F436ED13A22A246A59CA374CBC543998B83EEFCORSMSX111amrcor_-- From nobody Tue Jun 19 13:21:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8C130ECB for ; Tue, 19 Jun 2018 13:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17E4xfHSXy0Y for ; Tue, 19 Jun 2018 13:21:22 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 1CF04130E6E for ; Tue, 19 Jun 2018 13:21:22 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 13:21:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.51,244,1526367600"; d="scan'208,217"; a="65526294" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 19 Jun 2018 13:21:20 -0700 Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Jun 2018 13:21:20 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX159.amr.corp.intel.com ([169.254.11.44]) with mapi id 14.03.0319.002; Tue, 19 Jun 2018 13:21:20 -0700 From: "Deval, Manasi" To: Ian Swett CC: Marten Seemann , Kazuho Oku , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , "IETF QUIC WG" , Martin Thomson Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7X+IAADpdCoA== Date: Tue, 19 Jun 2018 20:21:19 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzJjNDNiZjUtZjUxNy00YjFjLTg3MGMtMjA2YjQ3ZjY2ZjM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiY2FNRmdtNVFzdnpYWmhtZUtTNkR4Q2RxRkduYXJCN3ZUSlB2R0Jpb21odmVGYnNOeTBxa2IyUldDNDFHUUlcL2UifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B83EF15ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:21:27 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B83EF15ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuLA0KDQpIZXJlIGlzIGFub3RoZXIgYXR0ZW1wdCB0byBzb2x2ZSB0aGUgb2JqZWN0aW9u cyB5b3UgcmFpc2VkOg0KDQo+SSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBiZWNhdXNl IEkgdGhpbmsgaXQgaXMgaW1wcmFjdGljYWwgdG8gZHJvcCB0aGUgbnVtYmVyIG9mIGFjayBibG9j a3MsIGJlY2F1c2Ugd2l0aCB0aGUgRUNOIHByb3Bvc2FsIGl0IGJlY29tZXMgaW1wcmFjdGljYWxs eSBjb21wbGV4IHRvIHBhcnNlLg0KSXMgdGhlcmUgYSByZWFzb24gdGhlIHByb3Bvc2FsIGZyb20g Q2hyaXN0aWFuIGRvZXMgbm90IHNvbHZlIHRoaXMgcHJvYmxlbT8NCg0KPklmIHdlIGRvbid0IHJl bW92ZSB0aGUgbnVtYmVyIG9mIGFjayBibG9ja3MsIHRoZW4gdGhlIGFjayBmcmFtZSBpcyBsYXJn ZXIsIGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzaXplIGZpZWxkIGlzIHVzZWZ1bCBmb3Ig bW9zdCBpbXBsZW1lbnRhdGlvbnMuICBBbHNvLCBpdCBtZWFucyB0aGUgbGVuZ3RoIGNhbiBkaXNh Z3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBhZGQgY29tcGxleGl0eSBhbmQgdGhl IHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29kZS4gIFRoZSBpZGVhIG9mIHNv bWVvbmUgb2ZmbG9hZGluZyBhY2sgcHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRy dXN0IHRoZSBsZW5ndGggc2VlbXMgbGlrZSBzb21lb25lIGNvdWxkIGdldCB3cm9uZyBhbmQgY2F1 c2Ugc29tZSBjb25jZXJuaW5nIGlzc3Vlcy4NClRoZSByaXNrIG9mIGRpc2FncmVlbWVudCBiZXR3 ZWVuIGFjayBibG9ja3MgYW5kIGFjayBibG9jayBjb3VudCBpcyBzYW1lIGFzIHRoZSByaXNrIG9m IGRpc2FncmVlbWVudCBiZXR3ZWVuIGFjayBibG9ja3MgYW5kIGFjayBsZW5ndGguIEVpdGhlciB3 YXkgdGhpcyBuZWVkcyB0byBiZSBjb3VudGVkIHVwIHdoaWxlIGNyZWF0aW5nIHRoZSBBQ0sgYW5k IGNvdW50ZWQgZG93biB3aGlsZSBwYXJzaW5nIGl0LiBUaGUgcG9zc2liaWxpdHkgb2YgZXJyb3Ig aXMgdGhlIHNhbWUuIEdldHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9uZyBpcyBhcyBwcm9i bGVtYXRpYyBhcyBnZXR0aW5nIHRoZSBhY2sgbGVuZ3RoIHdyb25nLiBEbyB5b3UgYWdyZWU/DQoN Cj5NeSBleHBlcmllbmNlIGlzIG11bHRpdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgaXMgbW9y ZSBjb3N0IGFuZCB3b3JrIHRoYW4gaXQncyB3b3J0aC4gIFN1cmUgeW91IGNhbid0IGZpbGwgYSAx MDBHIE5JQyB3aXRoIG9uZSBjb25uZWN0aW9uLCBidXQgdGhhdCBzZWVtcyBsaWtlIGFuIGFjYWRl bWljIHByb2JsZW0sIG5vdCBvbmUgZm9yIHdvcmtsb2FkcyBJJ3ZlIHNlZW4uICBUeXBpY2FsbHkg dGhlIGV4dHJhIGNvc3Qgb2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4NClRo ZSB2YWx1ZSBpcyB0d28gZm9sZCDigJMgcHJlLXByb2Nlc3NpbmcgYW5kIG11bHRpLXRocmVhZGlu Zy4gSWYgd2UgcHJlLXByb2Nlc3MgdGhlIHJlY2VpdmVkIHBhY2tldHMgc3VjaCB0aGF0IEFDS3Mg YW5kIHN0cmVhbXMgY2FuIGJlIGNvYWxlc2NlZCwgdGhlIHJlY2VpdmUgc2lkZSBjYW4gaW5kaWNh dGUgYSBsYXJnZSBjaHVuayBvZiBpbmZvcm1hdGlvbiB0aG91Z2ggdGhlIGtlcm5lbCwgcmVkdWNp bmcgdGhlIGNvc3Qgb2Ygc3lzdGVtIGNhbGwgYW5kIHByb3RvY29sIG92ZXJoZWFkLiBUaGlzIGlz IHRoZSBzYW1lIGNvbmNlcHQgYXMgVURQIHNlZ21lbnRhdGlvbiB0YWtlbiBhIHN0ZXAgZnVydGhl ciBvbiByZWNlaXZlIHNpZGUuIEFmdGVyIHRoaXMgY2h1bmsgaXMgaW5kaWNhdGVkIGludG8gdGhl IFFVSUMgcHJvdG9jb2wsIHRoZSBwcm90b2NvbCBtYXkgcHJvY2VzcyBzdHJlYW0gYW5kIEFDSyBp biBwYXJhbGxlbC4gV2hpbGUgZm9sa3MgbWF5IG9yIG1heSBub3QgdXRpbGl6ZSB0aGlzLCB0aGVy ZSBpcyBhbiBhZHZhbnRhZ2UgaGVyZS4NCg0KVGhhbmtzLA0KTWFuYXNpDQoNCg0KRnJvbTogSWFu IFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bmUg MTksIDIwMTggMTE6MjYgQU0NClRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwu Y29tPg0KQ2M6IE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT47IEthenVo byBPa3UgPGthenVob29rdUBnbWFpbC5jb20+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+ OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBQ cm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCg0KSSdt IHN0aWxsIG5vdCBpbnRlcmVzdGVkIGluIHRoaXMgY2hhbmdlLCBmb3IgdGhlIHJlYXNvbnMgSSBz dGF0ZWQgYWJvdmUuDQoNCk9uIFR1ZSwgSnVuIDE5LCAyMDE4IGF0IDI6MjEgUE0gRGV2YWwsIE1h bmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNv bT4+IHdyb3RlOg0KSGkgQWxsLA0KDQpEbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRvIGNyZWF0 ZSBhIG5ldyBQUj8NCg0KVGhhbmtzLA0KTWFuYXNpDQoNCkZyb206IERldmFsLCBNYW5hc2kNClNl bnQ6IFN1bmRheSwgSnVuZSAxNywgMjAxOCAyOjI1IFBNDQpUbzogTWFydGVuIFNlZW1hbm4gPG1h cnRlbnNlZW1hbm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT4+OyBL YXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29t Pj4NCkNjOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj47IEVyaWMgUmVzY29ybGEgPGVrckBy dGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj47IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21h aWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+PjsgUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVU RiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4+DQpTdWJqZWN0OiBSRTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291 bnQgd2l0aCBBQ0sgbGVuZ3RoDQoNCkhpIEFsbCwNCg0KSSBoYXZlIG1hZGUgYSBsaXN0IG9mIG9i amVjdGlvbnMgdG8gdGhlIHByb3Bvc2FsIGFuZCB0aGUgc29sdXRpb25zIHRvIHRob3NlIG9iamVj dGlvbnMgZGlzY3Vzc2VkIG9uIHRoaXMgdGhyZWFkLg0KDQoNCmEuICAgICAgQ28tZXhpc3RlbmNl IG9mIGxlbmd0aCBmaWVsZCB3aXRoIEVDTiBmaWVsZCBhbmQgQUNLIGJsb2Nrcy4NCg0KDQoNCkNo cmlzdGlhbiBzdWdnZXN0ZWQgdG8gbW92ZSB0aGUgRUNOIGZpZWxkcyB0byBwcmVjZWRlIHRoZSBB Q0sgYmxvY2tzLiBUaGlzIGlzIGFuIGVsZWdhbnQgc29sdXRpb24uIFBhcnNpbmcgZW50aXJlIGxp c3Qgb2YgQUNLIGJsb2NrcyB0byByZXZpZXcgRUNOIGJpdHMgd291bGQgaGF2ZSBiZWVuIGFubm95 aW5nLCBldmVuIHRob3VnaCBpdCBjYW4gd29yay4NCg0KDQoNCmIuICAgICAgVGhlcmUgYXJlIHR3 byBjYXNlcyB0byBiZSBwYXJzZWQg4oCTIGVudGlyZSBBQ0sgYW5kIHBhcnNlIEFDSyB0byBpZGVu dGlmeSBsZW5ndGguIFRoZXJlIGFyZSBzb21lIHJlc2VydmF0aW9ucyB3aGVuIEFDSyBwYXJzaW5n IGdldHMgaGFyZGVyIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUgZW50aXJlIGhlYWRlciBuZWVkcyB0 byBiZSBwYXJzZWQuDQoNCg0KDQpBZ3JlZW1lbnQgZnJvbSBzZXZlcmFsIGZvbGtzIGhlcmUuIElu IHRoZSBvcmlnaW5hbCBBQ0sgZGVmaW5lZCBpbiBkcmFmdCAxMiBvZiB0aGUgc2xpZGUsIG9uZSB3 b3VsZCBjb3VudCBkb3duIG51bWJlciBvZiBBQ0sgYmxvY2tzIHRvIGdldCB0byB0aGUgZW5kIG9m IHRoZSBwYWNrZXQuIEluIHRoZSBwcm9wb3NhbCBJIG1hZGUsIG9uZSB3b3VsZCBjb3VudCBkb3du IHRoZSBsZW5ndGggdG8gaWRlbnRpZnkgdGhlIGVuZCBvZiB0aGUgcGFja2V0LiBUaGUgbG9naWMg aXMgdmVyeSBzaW1pbGFyIGluIGN5Y2xlIGNvdW50IGFuZCBjb21wbGV4aXR5LiBTZXZlcmFsIGZv bGtzIGFsc28gY29tbWVudGVkIHRvIHRoaXMgZWZmZWN0Lg0KDQoNCg0KYy4gICAgICBNdWx0aS10 aHJlYWRlZCBwYWNrZXQgcHJvY2Vzc2luZw0KDQoNCg0KSSB3b3VsZCBleHBlY3QgdGhhdCB0aGVy ZSBhcmUgMTBzIG9mIDEwMDBzIG9mIGNvbm5lY3Rpb25zIGluIHVzZSBhdCBhbnkgdGltZSBmb3Ig YSBzZXJ2ZXIgd2l0aCBhIGhpZ2ggc3BlZWQgbGluay4gTXVsdGktdGhyZWFkaW5nIHRvIGhhbmRs ZSBlYWNoIG9mIHRoZXNlIGZsb3dzIC8gY29ubmVjdGlvbnMgaW4gcGFyYWxsZWwgaXMgbmVjZXNz aXR5IHRvIGJlIGFibGUgdG8gc3VwcG9ydCBsYXJnZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgb24g YSBoaWdoIHNwZWVkIGxpbmsuIFR4IHNlZ21lbnRhdGlvbiwgUnggY29hbGVzY2luZyBhcmUgd2Vs bCBrbm93biBzdHJhdGVnaWVzIHRvIHJlZHVjZSB0aGUgcHJvY2Vzc2luZyBjb3N0LiBJbiBpbml0 aWFsIHN0YWdlcywgY29kZSBpcyBvZnRlbiB3cml0dGVuIGFzIGEgc2luZ2xlLXRocmVhZGVkIGFu ZCB0aGVuIHJlLWZhY3RvcmVkIHRvIHBhcmFsbGVsaXplIGN5Y2xlIGludGVuc2l2ZSBvcGVyYXRp b25zLiBJbiBvcmRlciB0byBhbGxvdyB0aGlzIHByb3RvY29sIHRvIHNjYWxlIGluIGZ1dHVyZSwg SSB3b3VsZCBzdWdnZXN0IHdlIGRvIG5vdCBwcmVjbHVkZSB0aGlzIGNhc2UuDQoNCg0KDQpkLiAg ICAgIEluY3JlYXNlIGluIEFDSyBzaXplIGJ5IDEgYnl0ZS4NCg0KDQoNCkkgZG8gbm90IHNlZSB0 aGlzIGFzIGEgc2VyaW91cyBpc3N1ZSBidXQgaWYgZm9sa3MgYnV0IHdlIGNhbiBjb25zaWRlciBt YWtpbmcgdGhpcyBhIHZhcmludCwgaWYgb3RoZXJzIGhhdmUgc3Ryb25nIGZlZWxpbmdzIGFib3V0 IGl0LiBJdOKAmXMgYSB0cmFkZS1vZmYgOiAyIHJlYWRzIHRvIHNhdmUgMSBieXRlLg0KDQoNCg0K ZS4gICAgICBFdmVyeSBlbmNvZGFibGUgdmFsdWUgc2hvdWxkIGJlIHZhbGlkDQoNCk5vdCBldmVy eSBsZW5ndGggd2lsbCBiZSB2YWxpZC4gVGhpcyBpcyBpbmhlcmVudCB0byBsZW5ndGhzLiBUaGlz IHNhbWUgaXNzdWUgYWlscyB0aGUg4oCYcGF5bG9hZCBsZW5ndGjigJkgaW4gUVVJQyBoZWFkZXIu IE5vdCBvbmx5IGRvZXMgdGhlIGlzc3VlIGV4aXN0IGZvciBzbWFsbCB2YWx1ZXMsIGl0IGFsc28g YXBwbGllcyB0byBsYXJnZSB2YWx1ZXMgc2luY2UgZGF0YSBzdHJlYW0gd2lsbCBiZSBzZW50IGFm dGVyIGNyeXB0byBuZWdvdGlhdGlvbi4gIEUuZy4gIC0gaG93IGRvZXMgb25lIGNyYWZ0IGEgcGF5 bG9hZCB3aXRoIDYyIGJpdCBwYXlsb2FkIGxlbmd0aCBpbiBhIGxhcmdlIGhlYWRlcj8NCg0KDQoN Cg0KDQpUaGFua3MsDQoNCk1hbmFzaQ0KDQoNCg0KRnJvbTogTWFydGVuIFNlZW1hbm4gW21haWx0 bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgSnVuZSAxNywgMjAxOCA2 OjU5IEFNDQpUbzogS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhv b2t1QGdtYWlsLmNvbT4+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+ OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBKYW5h IEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21haWwuY29tPj47 IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2 YkBtaWNyb3NvZnQuY29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjsgRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRl dmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbT4+DQpTdWJqZWN0OiBS ZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoDQoN Ck1heWJlIGl0J3Mgc3BlY2lmaWMgdG8gR28sIGJ1dCBJJ20gdXNpbmcgYSBzaW5nbGUgaW8uUmVh ZGVyIGZvciB0aGUgd2hvbGUgcGFja2V0LCBzbyBhcyBsb25nIGFzIHRoZSBwYWNrZXQgcGF5bG9h ZCBpcyBsb25nIGVub3VnaCwgdGhlIHZhcmludCBwYXJzaW5nIHdpbGwgbm90IGZhaWwuDQpJIGRv bid0IHRoaW5rIHRoYXQgc3BlY2lmaWNzIG9mIHByb2dyYW1taW5nIGxhbmd1YWdlcyBtYXR0ZXIg aGVyZSB0aG91Z2gsIGFuZCBJJ20gc3VyZSBib3RoIGZyYW1lIGZvcm1hdHMgY2FuIGJlIHJlYXNv bmFibHkgaW1wbGVtZW50ZWQgaW4gQyBhcyB3ZWxsIGFzIGluIEdvLiBUaGUgcmVhc29ucyBJJ20g b3Bwb3NlZCB0byBNYW5hc2kncyBwcm9wb3NhbCBhcmUgdGhhdCBpdCBtb3ZlcyB1cyBhd2F5IGZy b20gdGhlIHByaW5jaXBsZSB0aGF0IG9ubHkgcmVhc29uYWJsZSB2YWx1ZXMgc2hvdWxkIGJlIGVu Y29kYWJsZSwgYW5kIHRoYXQgaXQgaW5jcmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUs IGZvciB0aGUgcXVlc3Rpb25hYmxlIGJlbmVmaXQgb2YgYmVpbmcgYWJsZSB0byBwYXJhbGxlbGlz ZSB0aGUgZnJhbWUgcGFyc2VyLg0KDQpPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+ PiB3cm90ZToNCjIwMTgtMDYtMTcgMjI6MzYgR01UKzA5OjAwIE1hcnRlbiBTZWVtYW5uIDxtYXJ0 ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+PjoNCj4g QXQgbGVhc3QgZm9yIG15IGltcGxlbWVudGF0aW9uLCBwYXJzaW5nIGRvZXNuJ3QgYmVjb21lIGVh c2llciwgaXQgYmVjb21lcw0KPiBtb3JlIGNvbXBsZXggd2l0aCB0aGlzIHByb3Bvc2FsLiBNeSB2 YXJpbnQtcGFyc2VyIGFsd2F5cyBjb25zdW1lcyBhcyBtYW55DQo+IGJ5dGVzIGFzIHRoZSB2YXJp bnQgcmVxdWlyZXMsIHNvIGFmdGVyIHBhcnNpbmcgYSB2YXJpbnQsIEknZCBoYXZlIHRvDQo+IGlu dHJvZHVjZSBhbiBhZGRpdGlvbmFsIGNoZWNrIHRoYXQgdGhpcyBkaWRuJ3Qgb3ZlcmZsb3cgdGhl IEFDSyBsZW5ndGggKGUuZy4NCj4gY29uc2lkZXIgdGhhdCBJIHBhcnNlZCB0aGUgQUNLIGZyYW1l IHNvIGZhciB0aGF0IG9ubHkgMiBieXRlcyBhcmUgcmVtYWluaW5nDQo+IGFjY29yZGluZyB0byBB Q0sgbGVuZ3RoIGZpZWxkLCBidXQgdGhlIG5leHQgdmFyaW50IGlzIDQgYnl0ZXMgbG9uZykuDQoN Cklzbid0IHlvdXIgdmFyaW50IHBhcnNlciBjaGVja2luZyB0aGF0IGl0IGhhcyBub3QgKG9yIHdp bGwgbm90KSBydW4NCmFjcm9zcyB0aGUgZW5kIG9mIHRoZSBwYWNrZXQgcGF5bG9hZCBmb3IgZXZl cnkgQUNLIGJsb2NrIGl0IHBhcnNlcz8NCkknZCBhc3N1bWUgdGhhdCB5b3Ugd291bGQgYmUgZG9p bmcgdGhhdCwgYmVjYXVzZSBJIHRoaW5rIHRoYXQgaXMNCm5lY2Vzc2FyeSB0byBhdm9pZCBidWZm ZXIgb3ZlcnJ1bi4NCg0KV2hhdCBJIGFtIHNheWluZyB0aGF0IHRoYXQgY2hlY2sgY291bGQgYmUg Y29udmVydGVkIHRvIGEgb3ZlcnJ1biBjaGVjaw0KYWdhaW5zdCB0aGUgZW5kIG9mIHRoZSAiZnJh bWUgcGF5bG9hZCIsIGFuZCB0aGF0IGNoZWNraW5nIHRoZQ0KcmVtYWluaW5nIGJsb2NrIGNvdW50 IGJlY29tZXMgdW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0sNCkJsb2NrIENvdW50 IHdpdGggQUNLIEZyYW1lIExlbmd0aC4NCg0KPg0KPiBJbiBnZW5lcmFsLCB3ZSd2ZSBiZWVuIG1v dmluZyB0aGUgd2lyZSBpbWFnZSB0b3dhcmRzIG1ha2luZyBldmVyeSBlbmNvZGFibGUNCj4gdmFs dWUgdmFsaWQuIFRoaXMgcHJvcG9zYWwgbW92ZXMgdXMgYXdheSBmcm9tIHRoYXQgcHJpbmNpcGxl Og0KPiAqIHNvbWUgc21hbGwgdmFsdWVzIGFyZSBhbHdheXMgaW52YWxpZCAodGhlIGxlbmd0aCBj YW4gbmV2ZXIgYmUgYmV0d2VlbiAwDQo+IGFuZCAzKQ0KPiAqIGEgbG90IG9mIGludGVybWVkaWF0 ZSB2YWx1ZXMgYXJlIGludmFsaWQgKGlmIHRoZSBib3VuZGFyeSBmYWxscyBpbnNpZGUgYQ0KPiB2 YXJpbnQsIGFzIGRlc2NyaWJlZCBhYm92ZSkNCj4gQm90aCB0aGVzZSBjYXNlcyBjYW4ndCBvY2N1 ciB3aXRoIHRoZSBjdXJyZW50IEFDSyBmcmFtZSBmb3JtYXQuDQo+DQo+IE9uIFN1biwgSnVuIDE3 LCAyMDE4IGF0IDc6NTQgUE0gS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+IDIwMTgtMDYtMTcgODozNCBHTVQr MDk6MDAgSWFuIFN3ZXR0DQo+PiA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PjoNCj4+ID4gSSdtIG5vdCBhIGZh biBvZiB0aGlzIHByb3Bvc2FsLCBiZWNhdXNlIEkgdGhpbmsgaXQgaXMgaW1wcmFjdGljYWwgdG8N Cj4+ID4gZHJvcA0KPj4gPiB0aGUgbnVtYmVyIG9mIGFjayBibG9ja3MsIGJlY2F1c2Ugd2l0aCB0 aGUgRUNOIHByb3Bvc2FsIGl0IGJlY29tZXMNCj4+ID4gaW1wcmFjdGljYWxseSBjb21wbGV4IHRv IHBhcnNlLg0KPj4NCj4+IEZvciB0aGUgRUNOIHByb3Bvc2FsLCBhcyBDaHJpc3RpYW4gaGFzIHN1 Z2dlc3RlZCwgd2UgY2FuIG1vdmUgdGhlIEVDTg0KPj4gY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sg YmxvY2tzLiBUaGVuLCBpdCB3b3VsZCBub3QgYmUgY29tcGxleCB0bw0KPj4gcGFyc2UuDQo+Pg0K Pj4gQW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMgZWFzaWVyIGlmIHdlIHJlcGxh Y2UgQUNLIEJsb2NrDQo+PiBDb3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguDQo+Pg0KPj4gTm93 LCB3aXRoIEFDSyBCbG9jayBDb3VudCwgd2UgbmVlZCB0byBjaGVjayB0aGUgcmVtYWluaW5nIG51 bWJlciBvZg0KPj4gYmxvY2tzIGFuZCB0aGUgcmVtYWluaW5nIHNwYWNlIGluIHRoZSBwYWNrZXQg cGF5bG9hZCBmb3IgZXZlcnkgYmxvY2sNCj4+IHRoYXQgd2UgcGFyc2UuIEZhaWxpbmcgdG8gY2hl Y2sgZWl0aGVyIGxlYWRzIHRvIGEgYnVnIG9yIGEgc2VjdXJpdHkNCj4+IGlzc3VlLg0KPj4NCj4+ IElmIHdlIHN3aXRjaCB0byBBQ0sgRnJhbWUgTGVuZ3RoLCB3ZSBuZWVkIHRvIG9ubHkgY2hlY2sg dGhlIHJlbWFpbmluZw0KPj4gc3BhY2UgaW4gdGhlIGZyYW1lLg0KPj4NCj4+IEkgdGhpbmsgdGhh dCB0aGlzIGlzIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgcmVwbGFjaW5nIEFDSyBCbG9jayBDb3Vu dA0KPj4gd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9IIHRoZSBkb3duc2lkZSBpcyB0aGF0IHlv dSBuZWVkIGV4dHJhIG9uZSB0bw0KPj4gdHdvIGJpdHMgKG9uZSBpZiB0aGUgc2l6ZSBvZiBibG9j ayAvIGdhcCBpcyBleHBlY3RlZCB0byBiZSBiZWxvdyA2NSwNCj4+IHR3byBpZiB0aGV5IGFyZSBl eHBlY3RlZCB0byBiZSBhYm92ZSB0aGF0KSBmb3IgZW5jb2RpbmcgQUNLIEZyYW1lDQo+PiBMZW5n dGggY29tcGFyZWQgdG8gQUNLIEJsb2NrIENvdW50Lg0KPj4NCj4+DQo+Pg0KPj4gSGF2aW5nIHNh aWQgdGhhdCwgSSBob25lc3RseSB3b25kZXIgaWYgYWxsIHRoZSBmcmFtZXMgY291bGQgaGF2ZSBp dCdzDQo+PiBsZW5ndGggYmVpbmcgZW5jb2RlZCAoZWl0aGVyIGV4cGxpY2l0bHkgb3IgZWl0aGVy IGFzIGEgc2lnbmFsIHRoYXQNCj4+IHNheXMgInRvIHRoZSBlbmQgb2YgdGhlIHBhY2tldCIpLiBD b25zaWRlciBzb21ldGhpbmcgbGlrZSBiZWxvdzoNCj4+DQo+PiB8MHwgZnJhbWUtdHlwZSAoNykg fCBmcmFtZS1wYXlsb2FkLWxlbmd0aCAoaSkgfCBmcmFtZS1wYXlsb2FkICgqKSB8DQo+PiAgb3IN Cj4+IHwxfCBmcmFtZS10eXBlICg3KSB8IGZyYW1lLXBheWxvYWQgKCopIHwNCj4+DQo+PiBXaGVu IE1TQiBvZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHplcm8sIHRoZSBsZW5ndGggb2YgdGhlIGZy YW1lDQo+PiBwYXlsb2FkIGlzIGRlc2lnbmF0ZWQgYnkgdGhlIHZhcmludCB0aGF0IGltbWVkaWF0 ZWx5IGZvbGxvd3MgdGhlIGZyYW1lDQo+PiB0eXBlLg0KPj4gV2hlbiBNU0Igb2YgdGhlIGZpcnN0 IG9jdGV0IHNldCB0byBvbmUsIHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lDQo+PiBwYXlsb2FkIHNw YW5zIHRvIHRoZSBlbmQgb2YgdGhlIHBhY2tldC4NCj4+DQo+PiBJbiB0aGlzIGVuY29kaW5nLCB3 ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0aCBmaWVsZCBvZiBhIFNUUkVBTQ0KPj4gZnJhbWUu IFNvIHRoZSBvdmVyaGVhZCBmb3IgY2Fycnlpbmcgc3RyZWFtIGRhdGEgd2lsbCBiZSBpbmRpZmZl cmVudCBpbg0KPj4gcHJhY3RpY2UuDQo+Pg0KPj4gRm9yIHRoZSBBQ0sgZnJhbWUsIHdlIGNhbiBv bWl0IHRoZSBBQ0sgQmxvY2sgQ291bnQgZmllbGQuIEFuZCB0aGUNCj4+IG92ZXJoZWFkIHdpbGwg YmUgb25lIHRvIHR3byBiaXRzIGlmIHRoZSBBQ0sgZnJhbWUgaXMgc2VudCBpbiB0aGUNCj4+IG1p ZGRsZSBvZiB0aGUgcGFja2V0ICh0aGVyZWJ5IHVzaW5nIHRoZSBlbmNvZGluZyB3aXRoIGV4cGxp Y2l0IGZyYW1lDQo+PiBwYXlsb2FkIGxlbmd0aCksIG9yIG9uZSBvY3RldCBvciBtb3JlIHNob3J0 ZXIgaWYgQUNLIGlzIHRoZSBsYXN0IGZyYW1lDQo+PiBvZiB0aGUgcGFja2V0Lg0KPj4NCj4+IFdl IGFyZSBsaWtlbHkgdG8gc2VlIGluY3JlYXNlIG9mIG92ZXJoZWFkIGZvciBtb3N0IG9mIHRoZSBv dGhlciB0eXBlcw0KPj4gb2YgZnJhbWVzLCBidXQgSSBkbyBub3QgdGhpbmsgdGhhdCB3b3VsZCBi ZSBhbiBpc3N1ZSBjb25zaWRlcmluZyB0aGF0DQo+PiB0aGV5IHdpbGwgYmUgZmFyIHNlbGRvbSBz ZWVuIGNvbXBhcmVkIHRvIFNUUkVBTXMgYW5kIEFDS3MuDQo+Pg0KPj4gVG8gc3VtbWFyaXplLCBt eSBhbnRpY2lwYXRpb24gaXMgdGhhdCB3ZSBjYW4gbWFrZSBhbGwgdGhlIGZyYW1lcw0KPj4gc2Vs Zi1jb250YWluZWQgKGkuZS4gdGhlIGxlbmd0aCBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHRo ZQ0KPj4ga25vd2xlZGdlIG9mIGhvdyBlYWNoIGZyYW1lIGlzIGVuY29kZWQpIHdpdGhvdXQgYW55 IG92ZXJoZWFkLCBpZiB3ZQ0KPj4gYWdyZWUgb24gbWFraW5nIHRoZSBmcmFtZSB0eXBlIHNwYWNl IDEgYml0IHNtYWxsZXIuDQo+Pg0KPj4gRmluYWxseSwgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiB1 c2luZyBhIHNlbGYtY29udGFpbmVkIGVuY29kaW5nIG9mDQo+PiBmcmFtZXMgaXMgdGhhdCB3ZSB3 b3VsZCBoYXZlIHRoZSBhYmlsaXR5IHRvIGludHJvZHVjZSBuZXcgb3B0aW9uYWwNCj4+IGZyYW1l cyB3aXRob3V0IG5lZ290aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRhaW5l ZCwgUVVJQw0KPj4gZW5kcG9pbnRzIHdpbGwgaGF2ZSB0aGUgZnJlZWRvbSBvZiBpZ25vcmluZyB0 aGUgZnJhbWVzIHRoYXQgdGhleSBkbw0KPj4gbm90IHVuZGVyc3RhbmQuDQo+Pg0KPj4gQmVpbmcg YWJsZSB0byBzZW5kIFFVSUMgZnJhbWVzIGRlZmluZWQgaW4gZXh0ZW5zaW9ucyB3aXRob3V0DQo+ PiBuZWdvdGlhdGluZyB1c2luZyBUcmFuc3BvcnQgUGFyYW1ldGVycyB3aWxsIGJlIGEgd2luIGlu IGJvdGggdGVybXMgb2YNCj4+IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMnIFRQIGlzIHNlbnQg aW4gY2xlYXIpIGFuZCBmbGV4aWJpbGl0eQ0KPj4gKGJlY2F1c2Ugd2Ugd2lsbCBiZSBwb3NzaWJs ZSB0byBzZW5kIHRoZSBleHRlbnNpb25zIGJlZm9yZSB3ZSBmaWd1cmUNCj4+IG91dCB3aGV0aGVy IHRoZSBwZWVyIHN1cHBvcnRzIHRoYXQgZXh0ZW5zaW9uKS4NCj4+DQo+PiA+IElmIHdlIGRvbid0 IHJlbW92ZSB0aGUgbnVtYmVyIG9mIGFjayBibG9ja3MsIHRoZW4gdGhlIGFjayBmcmFtZSBpcw0K Pj4gPiBsYXJnZXIsDQo+PiA+IGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzaXplIGZpZWxk IGlzIHVzZWZ1bCBmb3IgbW9zdA0KPj4gPiBpbXBsZW1lbnRhdGlvbnMuDQo+PiA+IEFsc28sIGl0 IG1lYW5zIHRoZSBsZW5ndGggY2FuIGRpc2FncmVlIHdpdGggdGhlIGFjdHVhbCBsZW5ndGgsIHdo aWNoIGFkZA0KPj4gPiBjb21wbGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3JpdGluZyBl cnJvci1wcm9uZSBjb2RlLiAgVGhlIGlkZWEgb2YNCj4+ID4gc29tZW9uZSBvZmZsb2FkaW5nIGFj ayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcgdG8gdHJ1c3QgdGhlDQo+PiA+IGxlbmd0 aA0KPj4gPiBzZWVtcyBsaWtlIHNvbWVvbmUgY291bGQgZ2V0IHdyb25nIGFuZCBjYXVzZSBzb21l IGNvbmNlcm5pbmcgaXNzdWVzLg0KPj4gPg0KPj4gPiBNeSBleHBlcmllbmNlIGlzIG11bHRpdGhy ZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgaXMgbW9yZSBjb3N0IGFuZCB3b3JrDQo+PiA+IHRoYW4N Cj4+ID4gaXQncyB3b3J0aC4gIFN1cmUgeW91IGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9u ZSBjb25uZWN0aW9uLCBidXQNCj4+ID4gdGhhdA0KPj4gPiBzZWVtcyBsaWtlIGFuIGFjYWRlbWlj IHByb2JsZW0sIG5vdCBvbmUgZm9yIHdvcmtsb2FkcyBJJ3ZlIHNlZW4uDQo+PiA+IFR5cGljYWxs eQ0KPj4gPiB0aGUgZXh0cmEgY29zdCBvZiBtdWx0aXRocmVhZGluZyBvdXR3ZWlnaHMgaXRzIHZh bHVlLg0KPj4gPg0KPj4gPiBUbyBiZSBjbGVhciwgSSBkb24ndCB0aGluayB0aGlzIGlzIGFuIGF3 ZnVsIGlkZWEsIGJ1dCBJIGFsc28gZG9uJ3Qgc2VlDQo+PiA+IHRoZQ0KPj4gPiB2YWx1ZSBhbmQg aXQgYWRkcyBjb21wbGV4aXR5LiAgSSByZWFkIE1hbmFzaSdzIGVtYWlsLCBidXQgSSBkb24ndCB0 aGluaw0KPj4gPiBJDQo+PiA+IHVuZGVyc3RhbmQgd2h5IGFueSBvZiB0aG9zZSBtYXR0ZXIgaW4g cHJhY3RpY2UuDQo+PiA+DQo+PiA+IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDQ6MTMgUE0gRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCj4+ ID4+DQo+PiA+PiBPbiBGcmksIEp1biAxNSwgMjAxOCBhdCA2OjQ2IFBNLCBNYXJ0ZW4gU2VlbWFu bg0KPj4gPj4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5zZWVtYW5uQGdt YWlsLmNvbT4+DQo+PiA+PiB3cm90ZToNCj4+ID4+Pg0KPj4gPj4+IFRoaXMgcHJvcG9zYWwgaW5j cmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUgYnkgMSBieXRlIGluIHRoZQ0KPj4gPj4+ IGNvbW1vbg0KPj4gPj4+IGNhc2UgKGxlc3MgdGhhbiA2MyBBQ0sgcmFuZ2VzKSwgc2luY2UgdGhl IEFDSyBsZW5ndGggZmllbGQgaGVyZSBhbHdheXMNCj4+ID4+PiBjb25zdW1lcyAyIGJ5dGVzLCB3 aGVyZWFzIHRoZSBBQ0sgQmxvY2sgQ291bnQgaXMgYSB2YXJpYWJsZS1sZW5ndGgNCj4+ID4+PiBp bnRlZ2VyLg0KPj4gPj4+IENvbnNpZGVyaW5nIGhvdyBtdWNoIHdvcmsgd2UgcHV0IGludG8gbWlu aW1pc2luZyB0aGUgc2l6ZSBvZiB0aGUNCj4+ID4+PiBmcmFtZXMsDQo+PiA+Pj4gdGhpcyBmZWVs cyBsaWtlIGEgc3RlcCBpbiB0aGUgd3JvbmcgZGlyZWN0aW9uLi4NCj4+ID4+Pg0KPj4gPj4+IFJl Z2FyZGluZyB0aGUgcHJvY2Vzc2luZyBjb3N0LCBJIGFncmVlIHdpdGggRG1pdHJpLiBIYW5kbGlu ZyBhbiBBQ0sNCj4+ID4+PiBmcmFtZQ0KPj4gPj4+IHJlcXVpcmVzIGxvb3Bpbmcgb3ZlciBhbmQg bWFraW5nIGNoYW5nZXMgdG8gYSBkYXRhIHN0cnVjdHVyZSB0aGF0DQo+PiA+Pj4ga2VlcHMNCj4+ ID4+PiB0cmFjayBvZiBzZW50IHBhY2tldHMuIFRoaXMgaXMgbXVjaCBtb3JlIGV4cGVuc2l2ZSB0 aGFuIHNpbXBseSBwYXJzaW5nDQo+PiA+Pj4gYQ0KPj4gPj4+IGJ1bmNoIG9mIHZhcmludHMgaW4g dGhlIEFDSyBmcmFtZS4gSXQgc2VlbXMgdW5saWtlbHkgdGhhdCBhDQo+PiA+Pj4gbXVsdGktdGhy ZWFkZWQNCj4+ID4+PiBwYWNrZXQgcGFyc2VyIHdvdWxkIG9mZmVyIGFueSByZWFsLXdvcmxkIHBl cmZvcm1hbmNlIGJlbmVmaXRzLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBJIGRvbid0IHdhbnQgdG8g b3ZlcnN0YXRlIHRoZSBiZW5lZml0IGhlcmUsIGJ1dCBteSBwb2ludCBpc24ndCB0aGF0DQo+PiA+ PiBwYXJzaW5nIGlzIGV4cGVuc2l2ZSBidXQgdGhhdCBpZiB5b3Ugd2FudCB0byBoYXZlIGEgbXVs dGl0aHJlYWRlZA0KPj4gPj4gcGFja2V0DQo+PiA+PiBwcm9jZXNzaW5nIHN5c3RlbSwgdGhlbiBp dCdzIG5pY2UgdG8gaGF2ZSBhIHNpbXBsZXIgZGF0YSBzdHJ1Y3R1cmUgKHRoZQ0KPj4gPj4gdW5w YXJzZWQgQUNLIGJsb2NrKSB0byBoYW5kIHRvIHRoZSBBQ0sgcHJvY2Vzc2luZyB0aHJlYWQuDQo+ PiA+Pg0KPj4gPj4gLUVrcg0KPj4gPj4NCj4+ID4+DQo+PiA+Pj4NCj4+ID4+PiBPbiBTYXQsIEp1 biAxNiwgMjAxOCBhdCA2OjE5IEFNIE1hcnRpbiBUaG9tc29uDQo+PiA+Pj4gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4NCj4+ID4+PiB3 cm90ZToNCj4+ID4+Pj4NCj4+ID4+Pj4gV2hlbiB3ZSBkaXNjdXNzZWQgdGhpcyBiZWZvcmUsIHNv bWUgcGVvcGxlIG9ic2VydmVkIHRoYXQgdGhpcyBjcmVhdGVzDQo+PiA+Pj4+IGEgbmVlZCB0byBl bmNvZGUgaW4gdHdvIHBhc3Nlcy4gIFRoYXQncyB0aGUgdHJhZGUtb2ZmIGhlcmUuICAoTm90DQo+ PiA+Pj4+IGV4cHJlc3NpbmcgYW4gb3Bpbmlvbi4pDQo+PiA+Pj4+IE9uIEZyaSwgSnVuIDE1LCAy MDE4IGF0IDM6NTEgUE0gSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpy aS5pZXRmQGdtYWlsLmNvbT4+DQo+PiA+Pj4+IHdyb3RlOg0KPj4gPj4+PiA+DQo+PiA+Pj4+ID4g SSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gb24gdGhpcy4gSSdtIGNlcnRhaW5seSBub3Qg b3Bwb3NlZCB0bw0KPj4gPj4+PiA+IGl0Lg0KPj4gPj4+PiA+IERvZXMgYW55b25lIGhhdmUgYSBz dHJvbmcgb3Bwb3NpdGlvbj8NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+IE9uIEZyaSwgSnVuIDE1LCAy MDE4IGF0IDM6MTAgUE0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCj4+ID4+Pj4gPiA8cHJhdmJA bWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4gPj4+ PiA+Pg0KPj4gPj4+PiA+PiBJIGFncmVlIGFzIHdlbGwgc2luY2UgdGhpcyBjYW4gaGVscCByZWR1 Y2UgcGVyIHBhY2tldCBwcm9jZXNzaW5nDQo+PiA+Pj4+ID4+IG92ZXJoZWFkLiBBQ0tzIGFyZSBn b2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9uIGZyYW1lIHR5cGUNCj4+ID4+Pj4gPj4g c28gbm8NCj4+ID4+Pj4gPj4gb2JqZWN0aW9ucyB0byBzcGVjaWFsIGNhc2luZy4NCj4+ID4+Pj4g Pj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gRnJvbTogUVVJQyBbbWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmIE9mIEVyaWMNCj4+ID4+Pj4gPj4gUmVzY29ybGENCj4+ID4+Pj4gPj4gU2VudDogRnJp ZGF5LCBKdW5lIDE1LCAyMDE4IDk6MTEgQU0NCj4+ID4+Pj4gPj4gVG86IERldmFsLCBNYW5hc2kg PG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+Pg0K Pj4gPj4+PiA+PiBDYzogSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpy aS5pZXRmQGdtYWlsLmNvbT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll dGYub3JnPj4NCj4+ID4+Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNL IGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4g Pj4+PiA+Pg0KPj4gPj4+PiA+PiBJIGFncmVlIHdpdGggTWFuYXNpIGhlcmUuIFRoaXMgY2hhbmdl IHdvdWxkIGFsbG93IGFjayBmcmFtZQ0KPj4gPj4+PiA+PiBwYXJzaW5nDQo+PiA+Pj4+ID4+IHRv IGJlIG1vcmUgc2VsZi1jb250YWluZWQsIHdoaWNoIGlzIGFuIGFkdmFudGFnZSBmb3IgdGhlIHBh cnNlcg0KPj4gPj4+PiA+PiBhbmQgYWxzbw0KPj4gPj4+PiA+PiBwb3RlbnRpYWxseSBmb3IgcGFy YWxsZWxpc20gKGJlY2F1c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhlDQo+PiA+Pj4+ID4+IGZy YW1lIGFuZCB0aGVuDQo+PiA+Pj4+ID4+IHByb2Nlc3MgaXQgaW4gcGFyYWxsZWwpLg0KPj4gPj4+ PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiAtRWtyDQo+PiA+Pj4+ID4+ DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ ID4+IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDU6MjIgUE0sIERldmFsLCBNYW5hc2kNCj4+ID4+ Pj4gPj4gPG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5j b20+PiB3cm90ZToNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gSW4gZ2VuZXJhbCwgdmFyaW50cyBy ZXF1aXJlIHNvbWUgc3BlY2lmaWMgbG9naWMgZm9yIHBhcnNpbmcuIFRvDQo+PiA+Pj4+ID4+IHNr aXANCj4+ID4+Pj4gPj4gb3ZlciBhbnkgaGVhZGVyLCBJIGhhdmUgdG8gcmVhZCBldmVyeSBzaW5n bGUgdmFyaW50LiBBcyB0aGUgY29kZQ0KPj4gPj4+PiA+PiBzZWVzIFN0cmVhbQ0KPj4gPj4+PiA+ PiBhbmQgQUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiAgVGhl IFN0cmVhbQ0KPj4gPj4+PiA+PiBmcmFtZSBoYXMgYQ0KPj4gPj4+PiA+PiBsZW5ndGggaW4gaXRz IHRoaXJkIGZpZWxkLg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+PiBBQ0sgcGFyc2luZywgaG93ZXZlciwgbmVlZHMgNiArIDIqbnVtX2Jsb2NrcyByZWFkcyB0 byBpZGVudGlmeQ0KPj4gPj4+PiA+PiBsZW5ndGguIFRoZXJlIGFyZSB0d28gcmVhZHMgZWFjaCBm b3Ig4oCYbGFyZ2VzdCBhY2tub3dsZWRnZWTigJksIOKAmEFDSw0KPj4gPj4+PiA+PiBkZWxheeKA mSBhbmQNCj4+ID4+Pj4gPj4g4oCYQUNLIGJsb2NrIGNvdW504oCZLiBUaGUgcGFpbiBwb2ludCBp cyB0aGUgdG90YWwgbnVtYmVyIG9mIGN5Y2xlcw0KPj4gPj4+PiA+PiBwYXJzZSBhbg0KPj4gPj4+ PiA+PiBBQ0suIElmIEkgYW0gcHJvY2Vzc2luZyAxME0gcHBzLCB3aGVyZSAxMCUgLSAzMCUgb2Yg dGhlIHBhY2tldHMNCj4+ID4+Pj4gPj4gaGF2ZSBhDQo+PiA+Pj4+ID4+IHBpZ2d5YmFja2VkIEFD SywgdGhlc2UgY3ljbGVzIGJlY29tZXMgYSBzaWduaWZpY2FudCBib3R0bGVuZWNrLg0KPj4gPj4+ PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBUaGFua3MsDQo+PiA+Pj4+ ID4+DQo+PiA+Pj4+ID4+IE1hbmFzaQ0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+ Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+PiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmFuYQ0KPj4gPj4+PiA+PiBJeWVuZ2Fy DQo+PiA+Pj4+ID4+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMSwgMjAxOCAzOjExIFBNDQo+PiA+Pj4+ ID4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5h c2kuZGV2YWxAaW50ZWwuY29tPj47IFFVSUMgV0cNCj4+ID4+Pj4gPj4gPHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KPj4gPj4+PiA+PiBTdWJqZWN0OiBSZTogUHJvcG9zYWwg dG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoDQo+PiA+Pj4+ID4+DQo+ PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IFlvdSdyZSByaWdodCB0aGF0IHdlIG5v IGxvbmdlciBoYXZlIHRoZSBhYmlsaXR5IHRvIHNraXAgYW4gQUNLDQo+PiA+Pj4+ID4+IGZyYW1l LA0KPj4gPj4+PiA+PiBhbmQgdGhpcyBjcmVwdCBpbiB3aGVuIHdlIG1vdmVkIHRvIHZhcmludHMu DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IEkgYmVsaWV2ZSB5b3VyIHByb2JsZW0gdGhvdWdoIGlz IGdlbmVyYWxseSB0cnVlIG9mIG1vc3QgZnJhbWVzIG5vdA0KPj4gPj4+PiA+PiBqdXN0IEFDS3Ms IHNpbmNlIGlkcywgcGFja2V0IG51bWJlcnMsIGFuZCBudW1iZXJzIGluIGFsbCBmcmFtZXMNCj4+ ID4+Pj4gPj4gYXJlIG5vdyBhbGwNCj4+ID4+Pj4gPj4gdmFyaW50cy4gVG8gc2tpcCBhbnkgZnJh bWUsIHlvdSdsbCBuZWVkIHRvIHBhcnNlIHRoZSB2YXJpbnQgZmllbGRzDQo+PiA+Pj4+ID4+IGlu IHRob3NlDQo+PiA+Pj4+ID4+IGZyYW1lcy4gSWYgeW91IGhhdmUgbG9naWMgdG8gcHJvY2VzcyBh bmQgc2tpcCB2YXJpbnRzLCB0aGVuDQo+PiA+Pj4+ID4+IHNraXBwaW5nIHRoZSBhY2sNCj4+ID4+ Pj4gPj4gYmxvY2sgc2VjdGlvbiBpcyBtZXJlbHkgcmVwZWF0aW5nIHRoaXMgb3BlcmF0aW9uICgy Km51bV9ibG9jaysxKQ0KPj4gPj4+PiA+PiB0aW1lcy4gRG8NCj4+ID4+Pj4gPj4geW91IHNlZSBz cGVjaWZpYyB2YWx1ZSBpbiBza2lwcGluZyBBQ0sgZnJhbWVzIG92ZXIgdGhlIG90aGVyDQo+PiA+ Pj4+ID4+IGNvbnRyb2wgZnJhbWVzPw0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+ Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAx OCBhdCA4OjQzIEFNIERtaXRyaSBUaWtob25vdg0KPj4gPj4+PiA+PiA8ZHRpa2hvbm92QGxpdGVz cGVlZHRlY2guLmNvbTxtYWlsdG86ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guLmNvbT4+IHdyb3Rl Og0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCAwMzozMzoz NVBNICswMDAwLCBEZXZhbCwgTWFuYXNpIHdyb3RlOg0KPj4gPj4+PiA+PiA+IC0gICAgICAgIE1v dmluZyB0aGUgQUNLIGxlbmd0aCB0byB0aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3MNCj4+ID4+ Pj4gPj4gPiB0aGUNCj4+ID4+Pj4gPj4gPiAgICAgICAgICBmbGV4aWJpbGl0eSBvZiBlaXRoZXIg cmVhZGluZyB0aGUgZW50aXJlIEFDSyBvciByZWFkaW5nDQo+PiA+Pj4+ID4+ID4gdGhlDQo+PiA+ Pj4+ID4+ID4gICAgICAgICAgZmlyc3QgMTYgYml0cyBhbmQgc2tpcHBpbmcgb3ZlciB0aGUgbGVu Z3RoLiBUaGlzIGlzIGENCj4+ID4+Pj4gPj4gPiB1c2VmdWwNCj4+ID4+Pj4gPj4gPiAgICAgICAg ICBmZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sgcHJvY2Vzc2luZyBpcyBzcGxpdCBpbnRv DQo+PiA+Pj4+ID4+ID4gICAgICAgICAgbXVsdGlwbGUgbGF5ZXJzLiBEZXBlbmRpbmcgb24gdGhl IHByb2Nlc3NvciB0aGlzIGlzIHJ1bg0KPj4gPj4+PiA+PiA+IG9uLA0KPj4gPj4+PiA+PiA+ICAg ICAgICAgIHRoZXJlIGFyZSBkaWZmZXJlbnQgYWR2YW50YWdlcyAtDQo+PiA+Pj4+ID4+DQo+PiA+ Pj4+ID4+IEp1c3QgYSBub3RlLiAgSW4gbXkgZXhwZXJpZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2lu ZyBhbiBBQ0sgZnJhbWUNCj4+ID4+Pj4gPj4gaXMNCj4+ID4+Pj4gPj4gbmVnbGlnaWJsZSBjb21w YXJlZCB0byB0aGUgY29zdCBvZiBwcm9jZXNzaW5nIGFuIEFDSyBmcmFtZTogdGhhdA0KPj4gPj4+ PiA+PiBpcywNCj4+ID4+Pj4gPj4gcG9raW5nIGF0IHZhcmlvdXMgbWVtb3J5IGxvY2F0aW9ucyB0 byBkaXNjYXJkIG5ld2x5IEFDS2VkIHBhY2tldHMuDQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+ICAg LSBEbWl0cmkuDQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+DQo+PiA+Pg0KPj4gPg0K Pj4NCj4+DQo+Pg0KPj4gLS0NCj4+IEthenVobyBPa3UNCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQo= --_000_1F436ED13A22A246A59CA374CBC543998B83EF15ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm00MTUyNjk4NjA2MTU4MTc4 MzUzbXNvbGlzdHBhcmFncmFwaCwgbGkubTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0cGFyYWdy YXBoLCBkaXYubTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHls ZS1uYW1lOm1fNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm00MTUyNjk4NjA2MTU4MTc4MzUzbXNv cGxhaW50ZXh0LCBsaS5tNDE1MjY5ODYwNjE1ODE3ODM1M21zb3BsYWludGV4dCwgZGl2Lm00MTUy Njk4NjA2MTU4MTc4MzUzbXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1lOm1fNDE1MjY5ODYw NjE1ODE3ODM1M21zb3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBD MCI+SGkgSWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+SGVy ZSBpcyBhbm90aGVyIGF0dGVtcHQgdG8gc29sdmUgdGhlIG9iamVjdGlvbnMgeW91IHJhaXNlZDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPiZndDtJJ20gbm90IGEg ZmFuIG9mIHRoaXMgcHJvcG9zYWwsIGJlY2F1c2UgSSB0aGluayBpdCBpcyBpbXByYWN0aWNhbCB0 byBkcm9wIHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04gcHJv cG9zYWwgaXQgYmVjb21lcyBpbXByYWN0aWNhbGx5IGNvbXBsZXgNCiB0byBwYXJzZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwNzBDMCI+SXMgdGhlcmUgYSByZWFzb24gdGhlIHByb3Bvc2FsIGZyb20gQ2hyaXN0aWFu IGRvZXMgbm90IHNvbHZlIHRoaXMgcHJvYmxlbT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzcwQUQ0NyI+Jmd0O0lmIHdlIGRvbid0IHJlbW92ZSB0aGUgbnVtYmVyIG9mIGFj ayBibG9ja3MsIHRoZW4gdGhlIGFjayBmcmFtZSBpcyBsYXJnZXIsIGJ1dCBJIGRvbid0IHRoaW5r IHRoZSBleHRyYSBzaXplIGZpZWxkIGlzIHVzZWZ1bCBmb3IgbW9zdCBpbXBsZW1lbnRhdGlvbnMu Jm5ic3A7IEFsc28sDQogaXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUg YWN0dWFsIGxlbmd0aCwgd2hpY2ggYWRkIGNvbXBsZXhpdHkgYW5kIHRoZSBwb3NzaWJpbGl0eSBv ZiB3cml0aW5nIGVycm9yLXByb25lIGNvZGUuJm5ic3A7IFRoZSBpZGVhIG9mIHNvbWVvbmUgb2Zm bG9hZGluZyBhY2sgcHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZSBs ZW5ndGggc2VlbXMgbGlrZSBzb21lb25lIGNvdWxkIGdldCB3cm9uZyBhbmQgY2F1c2UNCiBzb21l IGNvbmNlcm5pbmcgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5UaGUgcmlzayBvZiBkaXNhZ3Jl ZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgYmxvY2sgY291bnQgaXMgc2FtZSBhcyB0 aGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgbGVuZ3Ro LiBFaXRoZXIgd2F5IHRoaXMgbmVlZHMgdG8NCiBiZSBjb3VudGVkIHVwIHdoaWxlIGNyZWF0aW5n IHRoZSBBQ0sgYW5kIGNvdW50ZWQgZG93biB3aGlsZSBwYXJzaW5nIGl0LiBUaGUgcG9zc2liaWxp dHkgb2YgZXJyb3IgaXMgdGhlIHNhbWUuIEdldHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9u ZyBpcyBhcyBwcm9ibGVtYXRpYyBhcyBnZXR0aW5nIHRoZSBhY2sgbGVuZ3RoIHdyb25nLiBEbyB5 b3UgYWdyZWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij4mZ3Q7 TXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUg Y29zdCBhbmQgd29yayB0aGFuIGl0J3Mgd29ydGguJm5ic3A7IFN1cmUgeW91IGNhbid0IGZpbGwg YSAxMDBHIE5JQyB3aXRoIG9uZSBjb25uZWN0aW9uLCBidXQgdGhhdCBzZWVtcyBsaWtlDQogYW4g YWNhZGVtaWMgcHJvYmxlbSwgbm90IG9uZSBmb3Igd29ya2xvYWRzIEkndmUgc2Vlbi4mbmJzcDsg VHlwaWNhbGx5IHRoZSBleHRyYSBjb3N0IG9mIG11bHRpdGhyZWFkaW5nIG91dHdlaWdocyBpdHMg dmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRoZSB2YWx1ZSBpcyB0d28gZm9sZCDigJMgcHJlLXBy b2Nlc3NpbmcgYW5kIG11bHRpLXRocmVhZGluZy4gSWYgd2UgcHJlLXByb2Nlc3MgdGhlIHJlY2Vp dmVkIHBhY2tldHMgc3VjaCB0aGF0IEFDS3MgYW5kIHN0cmVhbXMgY2FuIGJlIGNvYWxlc2NlZCwg dGhlIHJlY2VpdmUgc2lkZQ0KIGNhbiBpbmRpY2F0ZSBhIGxhcmdlIGNodW5rIG9mIGluZm9ybWF0 aW9uIHRob3VnaCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRTc1QjY7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtY29sb3I6IzJFNzVCNjttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBo YToxMDAuMCUiPnRoZSBrZXJuZWwsIHJlZHVjaW5nIHRoZSBjb3N0IG9mIHN5c3RlbSBjYWxsIGFu ZA0KIHByb3RvY29sIG92ZXJoZWFkLiBUaGlzIGlzIHRoZSBzYW1lIGNvbmNlcHQgYXMgVURQIHNl Z21lbnRhdGlvbiB0YWtlbiBhIHN0ZXAgZnVydGhlciBvbiByZWNlaXZlIHNpZGUuIEFmdGVyIHRo aXMgY2h1bmsgaXMgaW5kaWNhdGVkIGludG8gdGhlIFFVSUMgcHJvdG9jb2wsIHRoZSBwcm90b2Nv bCBtYXkgcHJvY2VzcyBzdHJlYW0gYW5kIEFDSyBpbiBwYXJhbGxlbC4gV2hpbGUgZm9sa3MgbWF5 IG9yIG1heSBub3QgdXRpbGl6ZSB0aGlzLCB0aGVyZQ0KIGlzIGFuIGFkdmFudGFnZSBoZXJlLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzJFNzVCNjttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkU3 NUI2O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyRTc1QjY7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJFNzVCNjttc28tc3R5bGUt dGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJFNzVCNjttc28t c3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkU3NUI2O21zby1zdHlsZS10ZXh0ZmlsbC1maWxs LWFscGhhOjEwMC4wJSI+TWFuYXNpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19fX3JlcGx5c2VwYXJh dG9yIj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDExOjI2IEFNPGJyPg0KPGI+VG86PC9iPiBE ZXZhbCwgTWFuYXNpICZsdDttYW5hc2kuZGV2YWxAaW50ZWwuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gTWFydGVuIFNlZW1hbm4gJmx0O21hcnRlbnNlZW1hbm5AZ21haWwuY29tJmd0OzsgS2F6dWhv IE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZndDs7IEVyaWMgUmVzY29ybGEgJmx0O2VrckBy dGZtLmNvbSZndDs7IEphbmEgSXllbmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OzsgUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFV SUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUHJvcG9zYWwgdG8g cmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHN0aWxsIG5vdCBpbnRlcmVzdGVkIGluIHRoaXMgY2hh bmdlLCBmb3IgdGhlIHJlYXNvbnMgSSBzdGF0ZWQgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1biAxOSwgMjAxOCBhdCAyOjIxIFBN IERldmFsLCBNYW5hc2kgJmx0OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29t Ij5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRv IGNyZWF0ZSBhIG5ldyBQUj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzQxNTI2OTg2MDYxNTgx NzgzNTNfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fNDE1MjY5ODYwNjE1ODE3 ODM1M19fX19fX3JlcGx5c2VwYXJhdG8iPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIERldmFsLCBNYW5hc2kgPGJyPg0KPGI+U2VudDo8 L2I+IFN1bmRheSwgSnVuZSAxNywgMjAxOCAyOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0ZW4g U2VlbWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bWFydGVuc2VlbWFubkBnbWFpbC5jb208L2E+Jmd0OzsgS2F6dWhvIE9rdSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5r YXp1aG9va3VAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7 aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OyBFcmljIFJl c2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZWtyQHJ0Zm0uY29tPC9hPiZndDs7IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaS5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7Ow0KIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0 OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhy ZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUHJv cG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDA3MEMwIj5IaSBBbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+SSBoYXZlIG1hZGUgYSBsaXN0IG9mIG9iamVjdGlvbnMgdG8gdGhlIHBy b3Bvc2FsIGFuZCB0aGUgc29sdXRpb25zIHRvIHRob3NlIG9iamVjdGlvbnMgZGlzY3Vzc2VkIG9u DQogdGhpcyB0aHJlYWQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5hLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5Dby1leGlzdGVuY2Ugb2Yg bGVuZ3RoIGZpZWxkIHdpdGggRUNOIGZpZWxkIGFuZCBBQ0sgYmxvY2tzLg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFw aCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5DaHJpc3RpYW4gc3VnZ2VzdGVkIHRvIG1vdmUg dGhlIEVDTiBmaWVsZHMgdG8gcHJlY2VkZSB0aGUgQUNLIGJsb2Nrcy4gVGhpcyBpcyBhbiBlbGVn YW50IHNvbHV0aW9uLiBQYXJzaW5nIGVudGlyZSBsaXN0IG9mIEFDSyBibG9ja3MNCiB0byByZXZp ZXcgRUNOIGJpdHMgd291bGQgaGF2ZSBiZWVuIGFubm95aW5nLCBldmVuIHRob3VnaCBpdCBjYW4g d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2OTg2MDYxNTgxNzgz NTNtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNv bGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPmIuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRo ZXJlIGFyZSB0d28gY2FzZXMgdG8gYmUgcGFyc2VkIOKAkyBlbnRpcmUgQUNLIGFuZCBwYXJzZSBB Q0sgdG8gaWRlbnRpZnkgbGVuZ3RoLiBUaGVyZSBhcmUgc29tZSByZXNlcnZhdGlvbnMgd2hlbiBB Q0sgcGFyc2luZyBnZXRzIGhhcmRlciBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGVudGlyZSBoZWFk ZXINCiBuZWVkcyB0byBiZSBwYXJzZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNDE1 MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDA3MEMwIj5BZ3JlZW1lbnQgZnJvbSBzZXZlcmFsIGZvbGtzIGhlcmUuIEluIHRoZSBvcmlnaW5h bCBBQ0sgZGVmaW5lZCBpbiBkcmFmdCAxMiBvZiB0aGUgc2xpZGUsIG9uZSB3b3VsZCBjb3VudCBk b3duIG51bWJlciBvZiBBQ0sgYmxvY2tzDQogdG8gZ2V0IHRvIHRoZSBlbmQgb2YgdGhlIHBhY2tl dC4gSW4gdGhlIHByb3Bvc2FsIEkgbWFkZSwgb25lIHdvdWxkIGNvdW50IGRvd24gdGhlIGxlbmd0 aCB0byBpZGVudGlmeSB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuIFRoZSBsb2dpYyBpcyB2ZXJ5IHNp bWlsYXIgaW4gY3ljbGUgY291bnQgYW5kIGNvbXBsZXhpdHkuIFNldmVyYWwgZm9sa3MgYWxzbyBj b21tZW50ZWQgdG8gdGhpcyBlZmZlY3QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00 MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPmMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAw NzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDcwQzAiPk11bHRpLXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0 cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFn cmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkkgd291bGQgZXhwZWN0IHRoYXQg dGhlcmUgYXJlIDEwcyBvZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1c2UgYXQgYW55IHRpbWUg Zm9yIGEgc2VydmVyIHdpdGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRpLXRocmVhZGluZyB0bw0K IGhhbmRsZSBlYWNoIG9mIHRoZXNlIGZsb3dzIC8gY29ubmVjdGlvbnMgaW4gcGFyYWxsZWwgaXMg bmVjZXNzaXR5IHRvIGJlIGFibGUgdG8gc3VwcG9ydCBsYXJnZSBudW1iZXIgb2YgY29ubmVjdGlv bnMgb24gYSBoaWdoIHNwZWVkIGxpbmsuIFR4IHNlZ21lbnRhdGlvbiwgUnggY29hbGVzY2luZyBh cmUgd2VsbCBrbm93biBzdHJhdGVnaWVzIHRvIHJlZHVjZSB0aGUgcHJvY2Vzc2luZyBjb3N0LiBJ biBpbml0aWFsIHN0YWdlcywgY29kZSBpcyBvZnRlbg0KIHdyaXR0ZW4gYXMgYSBzaW5nbGUtdGhy ZWFkZWQgYW5kIHRoZW4gcmUtZmFjdG9yZWQgdG8gcGFyYWxsZWxpemUgY3ljbGUgaW50ZW5zaXZl IG9wZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93IHRoaXMgcHJvdG9jb2wgdG8gc2NhbGUgaW4g ZnV0dXJlLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgZG8gbm90IHByZWNsdWRlIHRoaXMgY2FzZS4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0cGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+ZC48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+SW5jcmVhc2Ug aW4gQUNLIHNpemUgYnkgMSBieXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt NDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2 OTg2MDYxNTgxNzgzNTNtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw NzBDMCI+SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzZXJpb3VzIGlzc3VlIGJ1dCBpZiBmb2xrcyBi dXQgd2UgY2FuIGNvbnNpZGVyIG1ha2luZyB0aGlzIGEgdmFyaW50LCBpZiBvdGhlcnMgaGF2ZSBz dHJvbmcgZmVlbGluZ3MgYWJvdXQgaXQuDQogSXTigJlzIGEgdHJhZGUtb2ZmIDogMiByZWFkcyB0 byBzYXZlIDEgYnl0ZS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4 NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNDE1MjY5ODYwNjE1 ODE3ODM1M21zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDA3MEMwIj5lLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMDA3MEMwIj5FdmVyeSBlbmNvZGFibGUgdmFsdWUgc2hvdWxkIGJlIHZh bGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUz bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPk5vdCBldmVyeSBsZW5ndGggd2lsbCBiZSB2YWxpZC4gVGhpcyBpcyBpbmhlcmVu dCB0byBsZW5ndGhzLiBUaGlzIHNhbWUgaXNzdWUgYWlscyB0aGUg4oCYcGF5bG9hZCBsZW5ndGji gJkgaW4gUVVJQyBoZWFkZXIuIE5vdCBvbmx5IGRvZXMgdGhlIGlzc3VlIGV4aXN0IGZvciBzbWFs bCB2YWx1ZXMsDQogaXQgYWxzbyBhcHBsaWVzIHRvIGxhcmdlIHZhbHVlcyBzaW5jZSBkYXRhIHN0 cmVhbSB3aWxsIGJlIHNlbnQgYWZ0ZXIgY3J5cHRvIG5lZ290aWF0aW9uLiZuYnNwOyBFLmcuICZu YnNwOy0gaG93IGRvZXMgb25lIGNyYWZ0IGEgcGF5bG9hZCB3aXRoIDYyIGJpdCBwYXlsb2FkIGxl bmd0aCBpbiBhIGxhcmdlIGhlYWRlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bTQxNTI2OTg2MDYxNTgxNzgzNTNtc29wbGFpbnRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2OTg2MDYx NTgxNzgzNTNtc29wbGFpbnRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTQxNTI2OTg2MDYxNTgxNzgzNTNtc29w bGFpbnRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNvcGxhaW50ZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im00MTUyNjk4NjA2MTU4MTc4MzUzbXNvcGxhaW50ZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0ZW4gU2VlbWFubiBbPGEgaHJl Zj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv Om1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXks IEp1bmUgMTcsIDIwMTggNjo1OSBBTTxicj4NCjxiPlRvOjwvYj4gS2F6dWhvIE9rdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9v a3VAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OyBFcmlj IFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs7IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaS5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7Ow0KIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJh dmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+ Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0Ozxh IGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsNCiBEZXZhbCwgTWFuYXNpICZsdDs8YSBo cmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFz aS5kZXZhbEBpbnRlbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUHJvcG9z YWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1heWJlIGl0J3Mgc3BlY2lmaWMgdG8gR28s IGJ1dCBJJ20gdXNpbmcgYSBzaW5nbGUgaW8uUmVhZGVyIGZvciB0aGUgd2hvbGUgcGFja2V0LCBz byBhcyBsb25nIGFzIHRoZSBwYWNrZXQgcGF5bG9hZCBpcyBsb25nIGVub3VnaCwgdGhlIHZhcmlu dCBwYXJzaW5nIHdpbGwgbm90IGZhaWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIGRvbid0IHRoaW5rIHRoYXQgc3BlY2lmaWNzIG9mIHByb2dyYW1taW5n IGxhbmd1YWdlcyBtYXR0ZXIgaGVyZSB0aG91Z2gsIGFuZCBJJ20gc3VyZSBib3RoIGZyYW1lIGZv cm1hdHMgY2FuIGJlIHJlYXNvbmFibHkgaW1wbGVtZW50ZWQgaW4gQyBhcyB3ZWxsIGFzIGluIEdv LiBUaGUgcmVhc29ucyBJJ20gb3Bwb3NlZA0KIHRvIE1hbmFzaSdzIHByb3Bvc2FsIGFyZSB0aGF0 IGl0IG1vdmVzIHVzIGF3YXkgZnJvbSB0aGUgcHJpbmNpcGxlIHRoYXQgb25seSByZWFzb25hYmxl IHZhbHVlcyBzaG91bGQgYmUgZW5jb2RhYmxlLCBhbmQgdGhhdCBpdCBpbmNyZWFzZXMgdGhlIHNp emUgb2YgdGhlIEFDSyBmcmFtZSwgZm9yIHRoZSBxdWVzdGlvbmFibGUgYmVuZWZpdCBvZiBiZWlu ZyBhYmxlIHRvIHBhcmFsbGVsaXNlIHRoZSBmcmFtZSBwYXJzZXIuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEp1biAxNywg MjAxOCBhdCA4OjQ4IFBNIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxOC0wNi0xNyAy MjozNiBHTVQmIzQzOzA5OjAwIE1hcnRlbiBTZWVtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86bWFy dGVuc2VlbWFubkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0ZW5zZWVtYW5uQGdtYWls LmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsgQXQgbGVhc3QgZm9yIG15IGltcGxlbWVudGF0aW9uLCBw YXJzaW5nIGRvZXNuJ3QgYmVjb21lIGVhc2llciwgaXQgYmVjb21lczxicj4NCiZndDsgbW9yZSBj b21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50LXBhcnNlciBhbHdheXMgY29uc3Vt ZXMgYXMgbWFueTxicj4NCiZndDsgYnl0ZXMgYXMgdGhlIHZhcmludCByZXF1aXJlcywgc28gYWZ0 ZXIgcGFyc2luZyBhIHZhcmludCwgSSdkIGhhdmUgdG88YnI+DQomZ3Q7IGludHJvZHVjZSBhbiBh ZGRpdGlvbmFsIGNoZWNrIHRoYXQgdGhpcyBkaWRuJ3Qgb3ZlcmZsb3cgdGhlIEFDSyBsZW5ndGgg KGUuZy48YnI+DQomZ3Q7IGNvbnNpZGVyIHRoYXQgSSBwYXJzZWQgdGhlIEFDSyBmcmFtZSBzbyBm YXIgdGhhdCBvbmx5IDIgYnl0ZXMgYXJlIHJlbWFpbmluZzxicj4NCiZndDsgYWNjb3JkaW5nIHRv IEFDSyBsZW5ndGggZmllbGQsIGJ1dCB0aGUgbmV4dCB2YXJpbnQgaXMgNCBieXRlcyBsb25nKS48 YnI+DQo8YnI+DQpJc24ndCB5b3VyIHZhcmludCBwYXJzZXIgY2hlY2tpbmcgdGhhdCBpdCBoYXMg bm90IChvciB3aWxsIG5vdCkgcnVuPGJyPg0KYWNyb3NzIHRoZSBlbmQgb2YgdGhlIHBhY2tldCBw YXlsb2FkIGZvciBldmVyeSBBQ0sgYmxvY2sgaXQgcGFyc2VzPzxicj4NCkknZCBhc3N1bWUgdGhh dCB5b3Ugd291bGQgYmUgZG9pbmcgdGhhdCwgYmVjYXVzZSBJIHRoaW5rIHRoYXQgaXM8YnI+DQpu ZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4uPGJyPg0KPGJyPg0KV2hhdCBJIGFtIHNh eWluZyB0aGF0IHRoYXQgY2hlY2sgY291bGQgYmUgY29udmVydGVkIHRvIGEgb3ZlcnJ1biBjaGVj azxicj4NCmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgJnF1b3Q7ZnJhbWUgcGF5bG9hZCZxdW90Oywg YW5kIHRoYXQgY2hlY2tpbmcgdGhlPGJyPg0KcmVtYWluaW5nIGJsb2NrIGNvdW50IGJlY29tZXMg dW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0s8YnI+DQpCbG9jayBDb3VudCB3aXRo IEFDSyBGcmFtZSBMZW5ndGguPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gZ2VuZXJhbCwg d2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdpcmUgaW1hZ2UgdG93YXJkcyBtYWtpbmcgZXZlcnkgZW5j b2RhYmxlPGJyPg0KJmd0OyB2YWx1ZSB2YWxpZC4gVGhpcyBwcm9wb3NhbCBtb3ZlcyB1cyBhd2F5 IGZyb20gdGhhdCBwcmluY2lwbGU6PGJyPg0KJmd0OyAqIHNvbWUgc21hbGwgdmFsdWVzIGFyZSBh bHdheXMgaW52YWxpZCAodGhlIGxlbmd0aCBjYW4gbmV2ZXIgYmUgYmV0d2VlbiAwPGJyPg0KJmd0 OyBhbmQgMyk8YnI+DQomZ3Q7ICogYSBsb3Qgb2YgaW50ZXJtZWRpYXRlIHZhbHVlcyBhcmUgaW52 YWxpZCAoaWYgdGhlIGJvdW5kYXJ5IGZhbGxzIGluc2lkZSBhPGJyPg0KJmd0OyB2YXJpbnQsIGFz IGRlc2NyaWJlZCBhYm92ZSk8YnI+DQomZ3Q7IEJvdGggdGhlc2UgY2FzZXMgY2FuJ3Qgb2NjdXIg d2l0aCB0aGUgY3VycmVudCBBQ0sgZnJhbWUgZm9ybWF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IE9u IFN1biwgSnVuIDE3LCAyMDE4IGF0IDc6NTQgUE0gS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAyMDE4LTA2LTE3 IDg6MzQgR01UJiM0MzswOTowMCBJYW4gU3dldHQ8YnI+DQomZ3Q7Jmd0OyAmbHQ7aWFuc3dldHQ9 PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7ICZn dDsgSSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBiZWNhdXNlIEkgdGhpbmsgaXQgaXMg aW1wcmFjdGljYWwgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGRyb3A8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04gcHJvcG9zYWwg aXQgYmVjb21lczxicj4NCiZndDsmZ3Q7ICZndDsgaW1wcmFjdGljYWxseSBjb21wbGV4IHRvIHBh cnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRm9yIHRoZSBFQ04gcHJvcG9zYWwsIGFz IENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkLCB3ZSBjYW4gbW92ZSB0aGUgRUNOPGJyPg0KJmd0OyZn dDsgY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sgYmxvY2tzLiBUaGVuLCBpdCB3b3VsZCBub3QgYmUg Y29tcGxleCB0bzxicj4NCiZndDsmZ3Q7IHBhcnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgQW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMgZWFzaWVyIGlmIHdlIHJlcGxh Y2UgQUNLIEJsb2NrPGJyPg0KJmd0OyZndDsgQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTm93LCB3aXRoIEFDSyBCbG9jayBDb3VudCwgd2Ug bmVlZCB0byBjaGVjayB0aGUgcmVtYWluaW5nIG51bWJlciBvZjxicj4NCiZndDsmZ3Q7IGJsb2Nr cyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5 IGJsb2NrPGJyPg0KJmd0OyZndDsgdGhhdCB3ZSBwYXJzZS4gRmFpbGluZyB0byBjaGVjayBlaXRo ZXIgbGVhZHMgdG8gYSBidWcgb3IgYSBzZWN1cml0eTxicj4NCiZndDsmZ3Q7IGlzc3VlLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYgd2Ugc3dpdGNoIHRvIEFDSyBGcmFtZSBMZW5ndGgs IHdlIG5lZWQgdG8gb25seSBjaGVjayB0aGUgcmVtYWluaW5nPGJyPg0KJmd0OyZndDsgc3BhY2Ug aW4gdGhlIGZyYW1lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayB0aGF0IHRo aXMgaXMgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiByZXBsYWNpbmcgQUNLIEJsb2NrIENvdW50PGJy Pg0KJmd0OyZndDsgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9IIHRoZSBkb3duc2lkZSBpcyB0 aGF0IHlvdSBuZWVkIGV4dHJhIG9uZSB0bzxicj4NCiZndDsmZ3Q7IHR3byBiaXRzIChvbmUgaWYg dGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVsb3cgNjUsPGJyPg0K Jmd0OyZndDsgdHdvIGlmIHRoZXkgYXJlIGV4cGVjdGVkIHRvIGJlIGFib3ZlIHRoYXQpIGZvciBl bmNvZGluZyBBQ0sgRnJhbWU8YnI+DQomZ3Q7Jmd0OyBMZW5ndGggY29tcGFyZWQgdG8gQUNLIEJs b2NrIENvdW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUg ZnJhbWVzIGNvdWxkIGhhdmUgaXQnczxicj4NCiZndDsmZ3Q7IGxlbmd0aCBiZWluZyBlbmNvZGVk IChlaXRoZXIgZXhwbGljaXRseSBvciBlaXRoZXIgYXMgYSBzaWduYWwgdGhhdDxicj4NCiZndDsm Z3Q7IHNheXMgJnF1b3Q7dG8gdGhlIGVuZCBvZiB0aGUgcGFja2V0JnF1b3Q7KS4gQ29uc2lkZXIg c29tZXRoaW5nIGxpa2UgYmVsb3c6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyB8MHwgZnJh bWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkLWxlbmd0aCAoaSkgfCBmcmFtZS1wYXlsb2FkICgq KSB8PGJyPg0KJmd0OyZndDsmbmJzcDsgb3I8YnI+DQomZ3Q7Jmd0OyB8MXwgZnJhbWUtdHlwZSAo NykgfCBmcmFtZS1wYXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXaGVu IE1TQiBvZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHplcm8sIHRoZSBsZW5ndGggb2YgdGhlIGZy YW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBpcyBkZXNpZ25hdGVkIGJ5IHRoZSB2YXJpbnQgdGhh dCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZTxicj4NCiZndDsmZ3Q7IHR5cGUuPGJyPg0K Jmd0OyZndDsgV2hlbiBNU0Igb2YgdGhlIGZpcnN0IG9jdGV0IHNldCB0byBvbmUsIHRoZSBsZW5n dGggb2YgdGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBzcGFucyB0byB0aGUgZW5kIG9m IHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbiB0aGlzIGVuY29kaW5n LCB3ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0aCBmaWVsZCBvZiBhIFNUUkVBTTxicj4NCiZn dDsmZ3Q7IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVhbSBkYXRhIHdp bGwgYmUgaW5kaWZmZXJlbnQgaW48YnI+DQomZ3Q7Jmd0OyBwcmFjdGljZS48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNLIEJs b2NrIENvdW50IGZpZWxkLiBBbmQgdGhlPGJyPg0KJmd0OyZndDsgb3ZlcmhlYWQgd2lsbCBiZSBv bmUgdG8gdHdvIGJpdHMgaWYgdGhlIEFDSyBmcmFtZSBpcyBzZW50IGluIHRoZTxicj4NCiZndDsm Z3Q7IG1pZGRsZSBvZiB0aGUgcGFja2V0ICh0aGVyZWJ5IHVzaW5nIHRoZSBlbmNvZGluZyB3aXRo IGV4cGxpY2l0IGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBsZW5ndGgpLCBvciBvbmUgb2N0 ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFzdCBmcmFtZTxicj4NCiZndDsmZ3Q7 IG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBhcmUgbGlrZWx5 IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3RoZXIgdHlwZXM8 YnI+DQomZ3Q7Jmd0OyBvZiBmcmFtZXMsIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IHdvdWxkIGJl IGFuIGlzc3VlIGNvbnNpZGVyaW5nIHRoYXQ8YnI+DQomZ3Q7Jmd0OyB0aGV5IHdpbGwgYmUgZmFy IHNlbGRvbSBzZWVuIGNvbXBhcmVkIHRvIFNUUkVBTXMgYW5kIEFDS3MuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBUbyBzdW1tYXJpemUsIG15IGFudGljaXBhdGlvbiBpcyB0aGF0IHdlIGNh biBtYWtlIGFsbCB0aGUgZnJhbWVzPGJyPg0KJmd0OyZndDsgc2VsZi1jb250YWluZWQgKGkuZS4g dGhlIGxlbmd0aCBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHRoZTxicj4NCiZndDsmZ3Q7IGtu b3dsZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVh ZCwgaWYgd2U8YnI+DQomZ3Q7Jmd0OyBhZ3JlZSBvbiBtYWtpbmcgdGhlIGZyYW1lIHR5cGUgc3Bh Y2UgMSBiaXQgc21hbGxlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZpbmFsbHksIHRo ZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRhaW5lZCBlbmNvZGluZyBvZjxi cj4NCiZndDsmZ3Q7IGZyYW1lcyBpcyB0aGF0IHdlIHdvdWxkIGhhdmUgdGhlIGFiaWxpdHkgdG8g aW50cm9kdWNlIG5ldyBvcHRpb25hbDxicj4NCiZndDsmZ3Q7IGZyYW1lcyB3aXRob3V0IG5lZ290 aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRhaW5lZCwgUVVJQzxicj4NCiZn dDsmZ3Q7IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZy YW1lcyB0aGF0IHRoZXkgZG88YnI+DQomZ3Q7Jmd0OyBub3QgdW5kZXJzdGFuZC48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlaW5nIGFibGUgdG8gc2VuZCBRVUlDIGZyYW1lcyBkZWZpbmVk IGluIGV4dGVuc2lvbnMgd2l0aG91dDxicj4NCiZndDsmZ3Q7IG5lZ290aWF0aW5nIHVzaW5nIFRy YW5zcG9ydCBQYXJhbWV0ZXJzIHdpbGwgYmUgYSB3aW4gaW4gYm90aCB0ZXJtcyBvZjxicj4NCiZn dDsmZ3Q7IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMnIFRQIGlzIHNlbnQgaW4gY2xlYXIpIGFu ZCBmbGV4aWJpbGl0eTxicj4NCiZndDsmZ3Q7IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2libGUg dG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJlPGJyPg0KJmd0OyZndDsgb3V0 IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydHMgdGhhdCBleHRlbnNpb24pLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sg YmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGxhcmdlciw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzaXplIGZpZWxk IGlzIHVzZWZ1bCBmb3IgbW9zdDxicj4NCiZndDsmZ3Q7ICZndDsgaW1wbGVtZW50YXRpb25zLjxi cj4NCiZndDsmZ3Q7ICZndDsgQWxzbywgaXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4gZGlzYWdyZWUg d2l0aCB0aGUgYWN0dWFsIGxlbmd0aCwgd2hpY2ggYWRkPGJyPg0KJmd0OyZndDsgJmd0OyBjb21w bGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3JpdGluZyBlcnJvci1wcm9uZSBjb2RlLiZu YnNwOyBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7ICZndDsgc29tZW9uZSBvZmZsb2FkaW5nIGFj ayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcgdG8gdHJ1c3QgdGhlPGJyPg0KJmd0OyZn dDsgJmd0OyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHNlZW1zIGxpa2Ugc29tZW9uZSBjb3Vs ZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuPGJyPg0KJmd0OyZn dDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVk IHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yazxicj4NCiZndDsmZ3Q7ICZn dDsgdGhhbjxicj4NCiZndDsmZ3Q7ICZndDsgaXQncyB3b3J0aC4mbmJzcDsgU3VyZSB5b3UgY2Fu J3QgZmlsbCBhIDEwMEcgTklDIHdpdGggb25lIGNvbm5lY3Rpb24sIGJ1dDxicj4NCiZndDsmZ3Q7 ICZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsgc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9i bGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLjxicj4NCiZndDsmZ3Q7ICZndDsg VHlwaWNhbGx5PGJyPg0KJmd0OyZndDsgJmd0OyB0aGUgZXh0cmEgY29zdCBvZiBtdWx0aXRocmVh ZGluZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IFRvIGJlIGNsZWFyLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYW4gYXdmdWwgaWRlYSwg YnV0IEkgYWxzbyBkb24ndCBzZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7 ICZndDsgdmFsdWUgYW5kIGl0IGFkZHMgY29tcGxleGl0eS4mbmJzcDsgSSByZWFkIE1hbmFzaSdz IGVtYWlsLCBidXQgSSBkb24ndCB0aGluazxicj4NCiZndDsmZ3Q7ICZndDsgSTxicj4NCiZndDsm Z3Q7ICZndDsgdW5kZXJzdGFuZCB3aHkgYW55IG9mIHRob3NlIG1hdHRlciBpbiBwcmFjdGljZS48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBPbiBTYXQsIEp1biAxNiwgMjAx OCBhdCA0OjEzIFBNIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5j b20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE9uIEZyaSwgSnVuIDE1LCAyMDE4 IGF0IDY6NDYgUE0sIE1hcnRlbiBTZWVtYW5uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h cnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg VGhpcyBwcm9wb3NhbCBpbmNyZWFzZXMgdGhlIHNpemUgb2YgdGhlIEFDSyBmcmFtZSBieSAxIGJ5 dGUgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNvbW1vbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJhbmdlcyksIHNpbmNlIHRoZSBB Q0sgbGVuZ3RoIGZpZWxkIGhlcmUgYWx3YXlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNv bnN1bWVzIDIgYnl0ZXMsIHdoZXJlYXMgdGhlIEFDSyBCbG9jayBDb3VudCBpcyBhIHZhcmlhYmxl LWxlbmd0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbnRlZ2VyLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBDb25zaWRlcmluZyBob3cgbXVjaCB3b3JrIHdlIHB1dCBpbnRvIG1pbmlt aXNpbmcgdGhlIHNpemUgb2YgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGZyYW1lcyw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhpcyBmZWVscyBsaWtlIGEgc3RlcCBpbiB0aGUg d3JvbmcgZGlyZWN0aW9uLi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgUmVnYXJkaW5nIHRoZSBwcm9jZXNzaW5nIGNvc3QsIEkgYWdyZWUgd2l0 aCBEbWl0cmkuIEhhbmRsaW5nIGFuIEFDSzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBmcmFt ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlcyBsb29waW5nIG92ZXIgYW5kIG1h a2luZyBjaGFuZ2VzIHRvIGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBrZWVwczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB0cmFjayBvZiBzZW50IHBh Y2tldHMuIFRoaXMgaXMgbXVjaCBtb3JlIGV4cGVuc2l2ZSB0aGFuIHNpbXBseSBwYXJzaW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYnVu Y2ggb2YgdmFyaW50cyBpbiB0aGUgQUNLIGZyYW1lLiBJdCBzZWVtcyB1bmxpa2VseSB0aGF0IGE8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbXVsdGktdGhyZWFkZWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgcGFja2V0IHBhcnNlciB3b3VsZCBvZmZlciBhbnkgcmVhbC13b3JsZCBwZXJm b3JtYW5jZSBiZW5lZml0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSSBkb24ndCB3YW50IHRvIG92ZXJzdGF0ZSB0 aGUgYmVuZWZpdCBoZXJlLCBidXQgbXkgcG9pbnQgaXNuJ3QgdGhhdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IHBhcnNpbmcgaXMgZXhwZW5zaXZlIGJ1dCB0aGF0IGlmIHlvdSB3YW50IHRvIGhhdmUg YSBtdWx0aXRocmVhZGVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcGFja2V0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQncyBuaWNlIHRvIGhhdmUgYSBz aW1wbGVyIGRhdGEgc3RydWN0dXJlICh0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB1bnBhcnNl ZCBBQ0sgYmxvY2spIHRvIGhhbmQgdG8gdGhlIEFDSyBwcm9jZXNzaW5nIHRocmVhZC48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDY6 MTkgQU0gTWFydGluIFRob21zb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBXaGVuIHdlIGRpc2N1c3NlZCB0aGlzIGJlZm9yZSwgc29tZSBwZW9wbGUgb2Jz ZXJ2ZWQgdGhhdCB0aGlzIGNyZWF0ZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGEg bmVlZCB0byBlbmNvZGUgaW4gdHdvIHBhc3Nlcy4mbmJzcDsgVGhhdCdzIHRoZSB0cmFkZS1vZmYg aGVyZS4mbmJzcDsgKE5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZXhwcmVzc2lu ZyBhbiBvcGluaW9uLik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEZyaSwgSnVu IDE1LCAyMDE4IGF0IDM6NTEgUE0gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJp LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwuY29tPC9hPiZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBJ IGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLiBJJ20gY2VydGFpbmx5IG5vdCBv cHBvc2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IGl0Ljxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBEb2VzIGFueW9uZSBoYXZlIGEgc3Ryb25nIG9w cG9zaXRpb24/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDM6MTAgUE0g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IEkgYWdyZWUgYXMgd2VsbCBzaW5jZSB0aGlzIGNhbiBoZWxwIHJlZHVjZSBwZXIgcGFja2V0 IHByb2Nlc3Npbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG92ZXJo ZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9uIGZyYW1lIHR5 cGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNvIG5vPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvYmplY3Rpb25zIHRvIHNwZWNpYWwgY2Fz aW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTog UVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRXJpYzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgUmVzY29ybGE8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVuZSAxNSwgMjAx OCA5OjExIEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogRGV2 YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20iIHRh cmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IENjOiBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmkuaWV0ZkBnbWFp bC5jb208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFD SyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IEkgYWdyZWUgd2l0aCBNYW5hc2kgaGVyZS4gVGhpcyBjaGFuZ2Ug d291bGQgYWxsb3cgYWNrIGZyYW1lPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBwYXJzaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0byBi ZSBtb3JlIHNlbGYtY29udGFpbmVkLCB3aGljaCBpcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBwYXJz ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCBhbHNvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwb3RlbnRpYWxseSBmb3IgcGFyYWxs ZWxpc20gKGJlY2F1c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSBhbmQgdGhlbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgcHJvY2VzcyBpdCBpbiBwYXJhbGxlbCkuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtRWtyPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIE1v biwgSnVuIDExLCAyMDE4IGF0IDU6MjIgUE0sIERldmFsLCBNYW5hc2k8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFs QGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJbiBnZW5lcmFsLCB2YXJpbnRzIHJlcXVp cmUgc29tZSBzcGVjaWZpYyBsb2dpYyBmb3IgcGFyc2luZy4gVG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNraXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkgc2luZ2xlIHZh cmludC4gQXMgdGhlIGNvZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IHNlZXMgU3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhbmQg QUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiZuYnNwOyBUaGUg U3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSBoYXMg YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGVuZ3RoIGluIGl0cyB0 aGlyZCBmaWVsZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IEFDSyBwYXJzaW5nLCBob3dldmVyLCBuZWVkcyA2ICYjNDM7IDIqbnVtX2Jsb2NrcyByZWFkcyB0 byBpZGVudGlmeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGVuZ3Ro LiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKAmGxhcmdlc3QgYWNrbm93bGVkZ2Vk4oCZ LCDigJhBQ0s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGRlbGF54oCZ IGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg4oCYQUNLIGJsb2Nr IGNvdW504oCZLiBUaGUgcGFpbiBwb2ludCBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIGN5Y2xlczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcGFyc2UgYW48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEFDSy4gSWYgSSBhbSBwcm9jZXNzaW5nIDEw TSBwcHMsIHdoZXJlIDEwJSAtIDMwJSBvZiB0aGUgcGFja2V0czxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgaGF2ZSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2lnbmlm aWNhbnQgYm90dGxlbmVjay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNYW5hc2k8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKYW5hPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBJeWVuZ2FyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgVG86IERldmFsLCBNYW5hc2kgJmx0OzxhIGhyZWY9Im1haWx0 bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXNpLmRldmFsQGlu dGVsLmNvbTwvYT4mZ3Q7OyBRVUlDIFdHPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3 aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IFlvdSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBoYXZlIHRoZSBhYmlsaXR5IHRvIHNr aXAgYW4gQUNLPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCB0aGlzIGNyZXB0IGlu IHdoZW4gd2UgbW92ZWQgdG8gdmFyaW50cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGJlbGll dmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1lcyBu b3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGp1c3QgQUNLcywgc2lu Y2UgaWRzLCBwYWNrZXQgbnVtYmVycywgYW5kIG51bWJlcnMgaW4gYWxsIGZyYW1lczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgYXJlIG5vdyBhbGw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHZhcmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5 b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgaW4gdGhvc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IGZyYW1lcy4gSWYgeW91IGhhdmUgbG9naWMgdG8gcHJvY2VzcyBhbmQgc2tp cCB2YXJpbnRzLCB0aGVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBz a2lwcGluZyB0aGUgYWNrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBi bG9jayBzZWN0aW9uIGlzIG1lcmVseSByZXBlYXRpbmcgdGhpcyBvcGVyYXRpb24gKDIqbnVtX2Js b2NrJiM0MzsxKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdGltZXMu IERvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB5b3Ugc2VlIHNwZWNp ZmljIHZhbHVlIGluIHNraXBwaW5nIEFDSyBmcmFtZXMgb3ZlciB0aGUgb3RoZXI8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wgZnJhbWVzPzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRyaSBUaWtob25vdjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkdGlr aG9ub3ZAbGl0ZXNwZWVkdGVjaC4uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHRpa2hvbm92QGxpdGVz cGVlZHRlY2guLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIE1v biwgSnVuIDExLCAyMDE4IGF0IDAzOjMzOjM1UE0gJiM0MzswMDAwLCBEZXZhbCwgTWFuYXNpIHdy b3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyAtJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1vdmluZyB0aGUgQUNLIGxlbmd0aCB0byB0aGUgZnJvbnQg b2YgdGhlIEFDSyBhbGxvd3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmbGV4aWJpbGl0eSBvZiBlaXRoZXIgcmVh ZGluZyB0aGUgZW50aXJlIEFDSyBvciByZWFkaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZmlyc3QgMTYgYml0 cyBhbmQgc2tpcHBpbmcgb3ZlciB0aGUgbGVuZ3RoLiBUaGlzIGlzIGE8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgdXNlZnVsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBmZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sgcHJvY2Vzc2luZyBpcyBzcGxpdCBpbnRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtdWx0aXBsZSBsYXllcnMuIERlcGVuZGluZyBvbiB0aGUg cHJvY2Vzc29yIHRoaXMgaXMgcnVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7IG9uLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgYXJlIGRpZmZlcmVudCBh ZHZhbnRhZ2VzIC08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdXN0IGEgbm90ZS4mbmJzcDsgSW4g bXkgZXhwZXJpZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWdsaWdpYmxlIGNvbXBhcmVkIHRvIHRoZSBjb3N0IG9mIHByb2Nl c3NpbmcgYW4gQUNLIGZyYW1lOiB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBpcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHBva2lu ZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBuZXdseSBBQ0tlZCBwYWNr ZXRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOy0gRG1pdHJpLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsgS2F6dWhvIE9r dTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3U8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1F436ED13A22A246A59CA374CBC543998B83EF15ORSMSX111amrcor_-- From nobody Tue Jun 19 14:22:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB8130E51 for ; Tue, 19 Jun 2018 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 TiDG34UB2PIV for ; Tue, 19 Jun 2018 14:22:41 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700111.outbound.protection.outlook.com [40.107.70.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A884130E2F for ; Tue, 19 Jun 2018 14:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BOJzVfHwsZHFFW6WKoOWlM3iFlSzW+uhZy0JQ9Q0dNc=; b=KCMgbz5Xn809qdO4P5oi7qYhxVT7fh5YPB2VsbnyICjD1YiCu7SjSEKbtkWWOmOvsByuhvBI6hoiLZ+8XcWghwFN3dkboieCvsgneZqWp8rrFLEuBa7cUNIhz550y02ZFIugqvNQ46FejfMMuD4Sj3mPABs3TgP32P7M9L4g43M= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB3942.namprd08.prod.outlook.com (52.135.194.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 21:22:38 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 21:22:38 +0000 From: Mike Bishop To: QUIC WG Subject: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeGw== Date: Tue, 19 Jun 2018 21:22:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB3942; 7:+u0es09Bxq158XdLECOrnFGkB9JfWaO6CKa1MC5JnIqDDmC6BgTt8lKwQ6idnxrG4u2RJ2ps929ZAsYdDIycRJhTzphCNExhenVWT8YakMRRD77zcQJJoSq+8j/4eHxQSC+XaVUSiLdFPSyoKYb9nwfj/M6auxKhTxjSrcmeNcNZvEmUo/4LMH/e3aljYUVxJFwNUvp7c6c+Qcd3kQGBBBXa9qYLdCbNLd2guffX0gLYkNLfSbTUrclnfcXJoC08 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bfd59951-90f0-46e8-a98b-08d5d62ac86f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB3942; x-ms-traffictypediagnostic: BYAPR08MB3942: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(2016111802025)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB3942; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB3942; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39830400003)(189003)(199004)(6916009)(26005)(14454004)(99286004)(186003)(5660300001)(97736004)(81156014)(59450400001)(6506007)(81166006)(74482002)(74316002)(66066001)(102836004)(3280700002)(478600001)(3660700001)(25786009)(7696005)(68736007)(86362001)(9686003)(561944003)(6436002)(55016002)(316002)(8936002)(7736002)(33656002)(5250100002)(486006)(8676002)(2900100001)(105586002)(6116002)(6306002)(2906002)(106356001)(3846002)(476003)(790700001)(53936002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB3942; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: x3Md++dwErv/Ol3RQC2qr6ZUpOXGBviVvib4WI4UimEtu9Idh1L8B5oqpPAJPpn8/9Oef71V0ZU5RqItmMwZKeJwDJQz1vtAWFX3C6nqoK3uqXBaadBwA+NXIkYjfbyMRcgsvYdZoDsShE466UQB2pDOm6E9UZD1hOX24OMzyVpU5oWzHpoTBXzBLPS4ou1PLDYQ4sBpo4bRGW/mIsq4+1tlrHYWHJlqM+Fggp7F49piS985lrf3k64TzQXvNV0yMHZhqTV0ttYArNka7eId1JDRCXz3figwN1bddcl+BB/374B33XDmnApXIVybf4S7+Tsj9kfGXc2qAr0JrNDLcA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB39446BABB72F7EAC6E87CF99DA700BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: bfd59951-90f0-46e8-a98b-08d5d62ac86f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 21:22:38.0083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3942 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 21:22:44 -0000 --_000_BYAPR08MB39446BABB72F7EAC6E87CF99DA700BYAPR08MB3944namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the Kista interim, we discussed the Unidirectional Stream Headers pr= oposal (PR #1359). In the current spec, the first three unidirectional str= eams have a designated purpose identified by the stream ID; all remaining s= erver-initiated unidirectional streams are used for push, and no other clie= nt-initiated unidirectional streams are used. The proposal is, at the most basic level, to use the first byte of a unidir= ectional stream to indicate its purpose. Pros: * Reduces need for application layer to reach into transport and get a = particular stream ID; this simplifies initialization and insulates the appl= ication from how the transport chooses to manage stream allocation. * Enables extensibility - without this, it is problematic to add a unid= irectional stream for any purpose in the future without a protocol rev. As= with QPACK, there are cases where a long-lived stream might be preferable = to a series of control-stream frames that need to be correlated together. Cons: * Streams aren't required to be presented "in order;" in the event of r= eordering, this makes the remainder of the stream unusable until the first = byte has arrived. * Assuming that different stream types get dispatched to different hand= lers, the stream might exist but not be assignable to a handler until the f= irst byte arrives (different view of previous issue). This creates a strea= m object that no one "owns." Some implementations that have looked at this think the first con is irrele= vant (since HTTP/QUIC doesn't make affordances for out-of-order consumption= anyway) and the second can be addressed by the use of a "dispatch" handler= whose job is to read the first byte and invoke the correct next handler. = This handler would own the stream until the first byte was available. Following the discussion in Kista, the hum was largely split between "Do th= is" and "Need more time/info," with only a few "Don't do this" hums. Howev= er, there hasn't been any substantive discussion of the proposal since then= . What does the WG need to move folks from the middle bucket into one of the = other two? --_000_BYAPR08MB39446BABB72F7EAC6E87CF99DA700BYAPR08MB3944namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the Kista interim, we discussed the Unidirect= ional Stream Headers proposal (PR #1359).  In the current spec, the fi= rst three unidirectional streams have a designated purpose identified by th= e stream ID; all remaining server-initiated unidirectional streams are used for push, and no other client-initiated un= idirectional streams are used.

 

The proposal is, at the most basic level, to use the= first byte of a unidirectional stream to indicate its purpose.<= /p>

 

Pros:

  • Reduces need for application layer to reach into transport and get a = particular stream ID; this simplifies initialization and insulates the appl= ication from how the transport chooses to manage stream allocation.
  • Enables extensibility &#= 8211; without this, it is problematic to add a unidirectional stream for an= y purpose in the future without a protocol rev.  As with QPACK, there = are cases where a long-lived stream might be preferable to a series of control-stream frames= that need to be correlated together.

 

Cons:

  • Streams aren’t required to be presented “in order;”= in the event of reordering, this makes the remainder of the stream unusabl= e until the first byte has arrived.
  • Assuming that diff= erent stream types get dispatched to different handlers, the stream might e= xist but not be assignable to a handler until the first byte arrives (diffe= rent view of previous issue).  This creates a stream object that no one “own= s.”

 

Some implementations that have looked at this think = the first con is irrelevant (since HTTP/QUIC doesn’t make affordances= for out-of-order consumption anyway) and the second can be addressed by th= e use of a “dispatch” handler whose job is to read the first byte and invoke the correct next handler.  This = handler would own the stream until the first byte was available.=

 

Following the discussion in Kista, the hum was large= ly split between “Do this” and “Need more time/info,̶= 1; with only a few “Don’t do this” hums.  However, t= here hasn’t been any substantive discussion of the proposal since the= n.

 

What does the WG need to move folks from the middle = bucket into one of the other two?

--_000_BYAPR08MB39446BABB72F7EAC6E87CF99DA700BYAPR08MB3944namp_-- From nobody Tue Jun 19 15:08:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5A130F6C for ; Tue, 19 Jun 2018 15:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=WgcAUAI4; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=FLgU3nvU 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 GY7IQZgMvZlf for ; Tue, 19 Jun 2018 15:08:41 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 6505E130F63 for ; Tue, 19 Jun 2018 15:08:41 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w5JM4BTo030847; Tue, 19 Jun 2018 15:08:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=oSVaYSzCzja9G1tJG51SXllzVd091aDaFRvCFG1GyWM=; b=WgcAUAI4VaKqYmPhrfsYUmZL5iJyiOEAka8a4Klbaa4IA1NsVRDVmRt6jpfukRnZoKqZ kfxeaJcpw1flS+Ier9+4UF2l3We1xi6giKuybEKwdutdxSLqT5rK8pYwQYmll2qaaUtu cACJQGiyDky2MWGZYkZdr8l1C0HCR/kGjZE= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2jq7yfre0d-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2018 15:08:38 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.28) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Jun 2018 18:08:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oSVaYSzCzja9G1tJG51SXllzVd091aDaFRvCFG1GyWM=; b=FLgU3nvU22HE9W79m8T7Jm2rv20H7ql9b9gDUTUT85GQfGc44fNe6+xXF9hPKHxck85lAEf76108/QqI0GVIC+2DPdP5SXt43a1yeUat2ntgdg9Mcj8E5hKItmcOd0I9McelTHMb4TOjAO5thqVJso9mLQS8PmlhI4vN3/Fazeg= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2373.namprd15.prod.outlook.com (52.135.198.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 22:08:35 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 22:08:35 +0000 From: Roberto Peon To: Mike Bishop , QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA Date: Tue, 19 Jun 2018 22:08:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:180::1:c652] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2373; 7:hpL+wQssGRGS8sDBWyDWxJEPp/BhbKGki7FGhi7MLW6t+Ec9ranSSpZQZLL83C+Y0lPNo7q29wCIjWYVcmjiI6MATwn5CTymJvUkYKfb7w66C5ZVsLIrXiQfC38lSPsLi81gTb2kR/GwSn8kC0lvQ6HTa82dkPqnns8O7YeGWoj5dZLIN275NklVMYgxuXuYS+FIR3kNAY+8UZ77rsh6Qf3nVYzfemSnuK0QxKSy3MT3dHMMTRkmY8BLxswiP+gL; 20:9tM5jBW/NiR1eBTDHPjBLSG+d1xIIJ0/hl/3wvrXRTVXvXHbbpbnT/0N+gEFKfHXv8WT/PnTYasvVP0B+9NzhCEz8DSMQEa0AhIinejZOmBPpdEQ/GNdLVgomY84/pxWKe46jPo3hKaEUXO7oL3fYYw6Me5MPlfPyU3za/B1Sgo= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 156bc910-5ea3-4e48-7dff-08d5d6313411 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2373; x-ms-traffictypediagnostic: BYAPR15MB2373: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2373; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2373; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(39380400002)(346002)(396003)(199004)(189003)(53546011)(8676002)(36756003)(6246003)(81156014)(81166006)(102836004)(6116002)(76176011)(99286004)(110136005)(54896002)(6506007)(59450400001)(6306002)(6512007)(58126008)(7736002)(5660300001)(316002)(105586002)(478600001)(53936002)(8936002)(14454004)(106356001)(186003)(486006)(6436002)(6486002)(83716003)(33656002)(561944003)(82746002)(229853002)(446003)(476003)(11346002)(46003)(2906002)(25786009)(86362001)(3280700002)(97736004)(3660700001)(2616005)(2900100001)(5250100002)(68736007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2373; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Odl8OsbsNYqpzIwCpfJX/KRVtzLBdcItz4zf1mG6rfQHaygFyaHM1sJE+oxAHl+H8X8L+D098iMM9wa30OvjE2DT1FQwWMMflnkFCienFiSnWnmbsg7hs7vKuSW2LKsn6WOrLkotaU0Zv3uNyLghPx/NWyq520AdR7+BTL8k30Joe2PLem3SKY1/nuCsUePwj3CDp1mE9koVifSNZDyoDzmehA69YQTJwTQHZQCTkGjtniS6Z16cENLlQjw0P7D0F5H1CwuGJAvbsojUHIQ9ZM6eLmyM6Nancp2OHAkpSP/C9ghqVbB+HmFM5QukNSJTlffLkkmYRVAnkgDtd9/v2A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B1FC187DA5364C51A68A65F72EA52DDCfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 156bc910-5ea3-4e48-7dff-08d5d6313411 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 22:08:35.6690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2373 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:08:45 -0000 --_000_B1FC187DA5364C51A68A65F72EA52DDCfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB5b3UganVzdCBraWNrZWQgdGhlIGRpc2N1c3Npb24gb2ZmIE1pa2UhDQoNCkFub3Ro ZXIgdGhpbmcgdGhhdCB3YXMgbWVudGlvbmVkIHdhcyB0byBoYXZlIHRoZXNlIGFzIHR3byBkaWZm ZXJlbnQgc3RyZWFtIGZyYW1lcy4NCk9uZSBjb3VsZCBoYXZlIGJvdGggc2VsZi1kZXNjcmliaW5n IGFuZCDigJh0aGlzLWlzLW5vdC1zcGVjaWFs4oCZIHN0cmVhbXMgYnkgdGFraW5nIHVwIGEgc2lu Z2xlIGFkZGl0aW9uYWwgY29kZXBvaW50Lg0KDQoNCi09Ug0KDQpGcm9tOiBRVUlDIDxxdWljLWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVm b3UuYmU+DQpEYXRlOiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IGF0IDI6MjMgUE0NClRvOiBRVUlD IFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhl YWRlcnMNCg0KRHVyaW5nIHRoZSBLaXN0YSBpbnRlcmltLCB3ZSBkaXNjdXNzZWQgdGhlIFVuaWRp cmVjdGlvbmFsIFN0cmVhbSBIZWFkZXJzIHByb3Bvc2FsIChQUiAjMTM1OSkuICBJbiB0aGUgY3Vy cmVudCBzcGVjLCB0aGUgZmlyc3QgdGhyZWUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBoYXZlIGEg ZGVzaWduYXRlZCBwdXJwb3NlIGlkZW50aWZpZWQgYnkgdGhlIHN0cmVhbSBJRDsgYWxsIHJlbWFp bmluZyBzZXJ2ZXItaW5pdGlhdGVkIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlIHVzZWQgZm9y IHB1c2gsIGFuZCBubyBvdGhlciBjbGllbnQtaW5pdGlhdGVkIHVuaWRpcmVjdGlvbmFsIHN0cmVh bXMgYXJlIHVzZWQuDQoNClRoZSBwcm9wb3NhbCBpcywgYXQgdGhlIG1vc3QgYmFzaWMgbGV2ZWws IHRvIHVzZSB0aGUgZmlyc3QgYnl0ZSBvZiBhIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSB0byBpbmRp Y2F0ZSBpdHMgcHVycG9zZS4NCg0KUHJvczoNCg0KICAqICAgUmVkdWNlcyBuZWVkIGZvciBhcHBs aWNhdGlvbiBsYXllciB0byByZWFjaCBpbnRvIHRyYW5zcG9ydCBhbmQgZ2V0IGEgcGFydGljdWxh ciBzdHJlYW0gSUQ7IHRoaXMgc2ltcGxpZmllcyBpbml0aWFsaXphdGlvbiBhbmQgaW5zdWxhdGVz IHRoZSBhcHBsaWNhdGlvbiBmcm9tIGhvdyB0aGUgdHJhbnNwb3J0IGNob29zZXMgdG8gbWFuYWdl IHN0cmVhbSBhbGxvY2F0aW9uLg0KICAqICAgRW5hYmxlcyBleHRlbnNpYmlsaXR5IOKAkyB3aXRo b3V0IHRoaXMsIGl0IGlzIHByb2JsZW1hdGljIHRvIGFkZCBhIHVuaWRpcmVjdGlvbmFsIHN0cmVh bSBmb3IgYW55IHB1cnBvc2UgaW4gdGhlIGZ1dHVyZSB3aXRob3V0IGEgcHJvdG9jb2wgcmV2LiAg QXMgd2l0aCBRUEFDSywgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIGEgbG9uZy1saXZlZCBzdHJlYW0g bWlnaHQgYmUgcHJlZmVyYWJsZSB0byBhIHNlcmllcyBvZiBjb250cm9sLXN0cmVhbSBmcmFtZXMg dGhhdCBuZWVkIHRvIGJlIGNvcnJlbGF0ZWQgdG9nZXRoZXIuDQoNCkNvbnM6DQoNCiAgKiAgIFN0 cmVhbXMgYXJlbuKAmXQgcmVxdWlyZWQgdG8gYmUgcHJlc2VudGVkIOKAnGluIG9yZGVyO+KAnSBp biB0aGUgZXZlbnQgb2YgcmVvcmRlcmluZywgdGhpcyBtYWtlcyB0aGUgcmVtYWluZGVyIG9mIHRo ZSBzdHJlYW0gdW51c2FibGUgdW50aWwgdGhlIGZpcnN0IGJ5dGUgaGFzIGFycml2ZWQuDQogICog ICBBc3N1bWluZyB0aGF0IGRpZmZlcmVudCBzdHJlYW0gdHlwZXMgZ2V0IGRpc3BhdGNoZWQgdG8g ZGlmZmVyZW50IGhhbmRsZXJzLCB0aGUgc3RyZWFtIG1pZ2h0IGV4aXN0IGJ1dCBub3QgYmUgYXNz aWduYWJsZSB0byBhIGhhbmRsZXIgdW50aWwgdGhlIGZpcnN0IGJ5dGUgYXJyaXZlcyAoZGlmZmVy ZW50IHZpZXcgb2YgcHJldmlvdXMgaXNzdWUpLiAgVGhpcyBjcmVhdGVzIGEgc3RyZWFtIG9iamVj dCB0aGF0IG5vIG9uZSDigJxvd25zLuKAnQ0KDQpTb21lIGltcGxlbWVudGF0aW9ucyB0aGF0IGhh dmUgbG9va2VkIGF0IHRoaXMgdGhpbmsgdGhlIGZpcnN0IGNvbiBpcyBpcnJlbGV2YW50IChzaW5j ZSBIVFRQL1FVSUMgZG9lc27igJl0IG1ha2UgYWZmb3JkYW5jZXMgZm9yIG91dC1vZi1vcmRlciBj b25zdW1wdGlvbiBhbnl3YXkpIGFuZCB0aGUgc2Vjb25kIGNhbiBiZSBhZGRyZXNzZWQgYnkgdGhl IHVzZSBvZiBhIOKAnGRpc3BhdGNo4oCdIGhhbmRsZXIgd2hvc2Ugam9iIGlzIHRvIHJlYWQgdGhl IGZpcnN0IGJ5dGUgYW5kIGludm9rZSB0aGUgY29ycmVjdCBuZXh0IGhhbmRsZXIuICBUaGlzIGhh bmRsZXIgd291bGQgb3duIHRoZSBzdHJlYW0gdW50aWwgdGhlIGZpcnN0IGJ5dGUgd2FzIGF2YWls YWJsZS4NCg0KRm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGluIEtpc3RhLCB0aGUgaHVtIHdhcyBs YXJnZWx5IHNwbGl0IGJldHdlZW4g4oCcRG8gdGhpc+KAnSBhbmQg4oCcTmVlZCBtb3JlIHRpbWUv aW5mbyzigJ0gd2l0aCBvbmx5IGEgZmV3IOKAnERvbuKAmXQgZG8gdGhpc+KAnSBodW1zLiAgSG93 ZXZlciwgdGhlcmUgaGFzbuKAmXQgYmVlbiBhbnkgc3Vic3RhbnRpdmUgZGlzY3Vzc2lvbiBvZiB0 aGUgcHJvcG9zYWwgc2luY2UgdGhlbi4NCg0KV2hhdCBkb2VzIHRoZSBXRyBuZWVkIHRvIG1vdmUg Zm9sa3MgZnJvbSB0aGUgbWlkZGxlIGJ1Y2tldCBpbnRvIG9uZSBvZiB0aGUgb3RoZXIgdHdvPw0K --_000_B1FC187DA5364C51A68A65F72EA52DDCfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNjM0MTA2MjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MzU3ODE0MTQgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDY0NTkyNDY4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTY2NjIxODM0IDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyDQoJe21zby1saXN0LWlkOjg5OTYzNTAzNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTk0MDk1MjkyMDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE5NzE1ODY5ODY7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1Mzk3MTYwMDg7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIHlvdSBqdXN0IGtpY2tlZCB0aGUgZGlzY3Vzc2lvbiBvZmYgTWlrZSE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QW5vdGhlciB0aGluZyB0aGF0IHdhcyBtZW50aW9uZWQgd2FzIHRvIGhhdmUg dGhlc2UgYXMgdHdvIGRpZmZlcmVudCBzdHJlYW0gZnJhbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T25lIGNvdWxkIGhhdmUgYm90aCBzZWxmLWRlc2NyaWJpbmcgYW5k IOKAmHRoaXMtaXMtbm90LXNwZWNpYWzigJkgc3RyZWFtcyBieSB0YWtpbmcgdXAgYSBzaW5nbGUg YWRkaXRpb25hbCBjb2RlcG9pbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi09Ujxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7cXVpYy1i b3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWlrZSBCaXNob3AgJmx0O21iaXNob3BA ZXZlcXVlZm91LmJlJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKdW5lIDE5LCAyMDE4 IGF0IDI6MjMgUE08YnI+DQo8Yj5UbzogPC9iPlFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1cmlu ZyB0aGUgS2lzdGEgaW50ZXJpbSwgd2UgZGlzY3Vzc2VkIHRoZSBVbmlkaXJlY3Rpb25hbCBTdHJl YW0gSGVhZGVycyBwcm9wb3NhbCAoUFIgIzEzNTkpLiZuYnNwOyBJbiB0aGUgY3VycmVudCBzcGVj LCB0aGUgZmlyc3QgdGhyZWUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBoYXZlIGEgZGVzaWduYXRl ZCBwdXJwb3NlIGlkZW50aWZpZWQgYnkgdGhlIHN0cmVhbSBJRDsgYWxsIHJlbWFpbmluZyBzZXJ2 ZXItaW5pdGlhdGVkDQogdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgdXNlZCBmb3IgcHVzaCwg YW5kIG5vIG90aGVyIGNsaWVudC1pbml0aWF0ZWQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUg dXNlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb3Bvc2FsIGlzLCBhdCB0aGUgbW9z dCBiYXNpYyBsZXZlbCwgdG8gdXNlIHRoZSBmaXJzdCBieXRlIG9mIGEgdW5pZGlyZWN0aW9uYWwg c3RyZWFtIHRvIGluZGljYXRlIGl0cyBwdXJwb3NlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q cm9zOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPlJlZHVjZXMgbmVlZCBmb3IgYXBwbGljYXRpb24gbGF5 ZXIgdG8gcmVhY2ggaW50byB0cmFuc3BvcnQgYW5kIGdldCBhIHBhcnRpY3VsYXIgc3RyZWFtIElE OyB0aGlzIHNpbXBsaWZpZXMgaW5pdGlhbGl6YXRpb24gYW5kIGluc3VsYXRlcyB0aGUgYXBwbGlj YXRpb24gZnJvbSBob3cgdGhlIHRyYW5zcG9ydCBjaG9vc2VzDQogdG8gbWFuYWdlIHN0cmVhbSBh bGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPkVuYWJsZXMgZXh0 ZW5zaWJpbGl0eSDigJMgd2l0aG91dCB0aGlzLCBpdCBpcyBwcm9ibGVtYXRpYyB0byBhZGQgYSB1 bmlkaXJlY3Rpb25hbCBzdHJlYW0gZm9yIGFueSBwdXJwb3NlIGluIHRoZSBmdXR1cmUgd2l0aG91 dCBhIHByb3RvY29sIHJldi4mbmJzcDsgQXMgd2l0aCBRUEFDSywgdGhlcmUgYXJlIGNhc2VzIHdo ZXJlIGENCiBsb25nLWxpdmVkIHN0cmVhbSBtaWdodCBiZSBwcmVmZXJhYmxlIHRvIGEgc2VyaWVz IG9mIGNvbnRyb2wtc3RyZWFtIGZyYW1lcyB0aGF0IG5lZWQgdG8gYmUgY29ycmVsYXRlZCB0b2dl dGhlci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uczo8bzpwPjwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm82Ij5TdHJlYW1zIGFyZW7igJl0IHJlcXVpcmVkIHRvIGJlIHByZXNlbnRlZCDigJxpbiBvcmRl cjvigJ0gaW4gdGhlIGV2ZW50IG9mIHJlb3JkZXJpbmcsIHRoaXMgbWFrZXMgdGhlIHJlbWFpbmRl ciBvZiB0aGUgc3RyZWFtIHVudXNhYmxlIHVudGlsIHRoZSBmaXJzdCBieXRlIGhhcyBhcnJpdmVk LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPkFzc3VtaW5nIHRoYXQgZGlmZmVy ZW50IHN0cmVhbSB0eXBlcyBnZXQgZGlzcGF0Y2hlZCB0byBkaWZmZXJlbnQgaGFuZGxlcnMsIHRo ZSBzdHJlYW0gbWlnaHQgZXhpc3QgYnV0IG5vdCBiZSBhc3NpZ25hYmxlIHRvIGEgaGFuZGxlciB1 bnRpbCB0aGUgZmlyc3QgYnl0ZSBhcnJpdmVzIChkaWZmZXJlbnQgdmlldyBvZg0KIHByZXZpb3Vz IGlzc3VlKS4mbmJzcDsgVGhpcyBjcmVhdGVzIGEgc3RyZWFtIG9iamVjdCB0aGF0IG5vIG9uZSDi gJxvd25zLuKAnTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIGltcGxlbWVudGF0 aW9ucyB0aGF0IGhhdmUgbG9va2VkIGF0IHRoaXMgdGhpbmsgdGhlIGZpcnN0IGNvbiBpcyBpcnJl bGV2YW50IChzaW5jZSBIVFRQL1FVSUMgZG9lc27igJl0IG1ha2UgYWZmb3JkYW5jZXMgZm9yIG91 dC1vZi1vcmRlciBjb25zdW1wdGlvbiBhbnl3YXkpIGFuZCB0aGUgc2Vjb25kIGNhbiBiZSBhZGRy ZXNzZWQgYnkgdGhlIHVzZSBvZiBhIOKAnGRpc3BhdGNo4oCdIGhhbmRsZXIgd2hvc2Ugam9iDQog aXMgdG8gcmVhZCB0aGUgZmlyc3QgYnl0ZSBhbmQgaW52b2tlIHRoZSBjb3JyZWN0IG5leHQgaGFu ZGxlci4mbmJzcDsgVGhpcyBoYW5kbGVyIHdvdWxkIG93biB0aGUgc3RyZWFtIHVudGlsIHRoZSBm aXJzdCBieXRlIHdhcyBhdmFpbGFibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvbGxvd2lu ZyB0aGUgZGlzY3Vzc2lvbiBpbiBLaXN0YSwgdGhlIGh1bSB3YXMgbGFyZ2VseSBzcGxpdCBiZXR3 ZWVuIOKAnERvIHRoaXPigJ0gYW5kIOKAnE5lZWQgbW9yZSB0aW1lL2luZm8s4oCdIHdpdGggb25s eSBhIGZldyDigJxEb27igJl0IGRvIHRoaXPigJ0gaHVtcy4mbmJzcDsgSG93ZXZlciwgdGhlcmUg aGFzbuKAmXQgYmVlbiBhbnkgc3Vic3RhbnRpdmUgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvcG9zYWwg c2luY2UgdGhlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkb2VzIHRoZSBXRyBuZWVk IHRvIG1vdmUgZm9sa3MgZnJvbSB0aGUgbWlkZGxlIGJ1Y2tldCBpbnRvIG9uZSBvZiB0aGUgb3Ro ZXIgdHdvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B1FC187DA5364C51A68A65F72EA52DDCfbcom_-- From nobody Tue Jun 19 16:22:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF962130E46 for ; Tue, 19 Jun 2018 16:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvqViZyX8QrJ for ; Tue, 19 Jun 2018 16:22:37 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCB6129385 for ; Tue, 19 Jun 2018 16:22:36 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5JNMUTr003985; Wed, 20 Jun 2018 00:22:30 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0389.001; Wed, 20 Jun 2018 00:22:30 +0100 From: Lucas Pardue To: Roberto Peon , Mike Bishop , QUIC WG Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCAgACH9M0= Date: Tue, 19 Jun 2018 23:22:29 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB57DD1@bgb01xud1012> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23918.003 x-tm-as-result: No-9.141900-8.000000-10 x-tmase-matchedrid: VfovoVrt/oa7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p2lyfbzMrA/wvdr Uz92KvFQox3eLPiNwxUI/uAZhBR3ZbcP6OCfbw/mlGudLLtRO1uX/suzL1NqnBFT6ltzclWNMHd gBLLUyr7d9RcyCqw9YO47aD4Eo6Bid/V8JZegTXxKzOvae5Q0rJpHQFN7rLyrXCmcAC8DBrO75X NDwQTEhCb44l85OBVPwxqBbMVi5UFEI3p+/xYxHXyX60mMab9IxBgaBynd2vm7+NPPxj+R6pmEa 0nYf62kp0BXvhEpm9NW3VcAc19KwQzyMxeMEX6wgxsfzkNRlfLdB/CxWTRRu25FeHtsUoHuEtiK Q29leQ2/lt8EyG3Xt5v3X6cdyd81mVz0A8vVs1FLhb8xGEnVfg== x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--9.141900-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23918.003 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:22:39 -0000 Considering con 1, in the present design push streams assign special meanin= g to the push ID variant that appears at the start of the stream. So implem= entations will be stuck until the first bits are delivered anyway, with or = without a type byte. ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Roberto Peon [fenix@fb.com] Sent: 19 June 2018 23:08 To: Mike Bishop; QUIC WG Subject: Re: Path forward with stream headers I think you just kicked the discussion off Mike! Another thing that was mentioned was to have these as two different stream = frames. One could have both self-describing and =91this-is-not-special=92 streams b= y taking up a single additional codepoint. -=3DR From: QUIC on behalf of Mike Bishop Date: Tuesday, June 19, 2018 at 2:23 PM To: QUIC WG Subject: Path forward with stream headers During the Kista interim, we discussed the Unidirectional Stream Headers pr= oposal (PR #1359). In the current spec, the first three unidirectional str= eams have a designated purpose identified by the stream ID; all remaining s= erver-initiated unidirectional streams are used for push, and no other clie= nt-initiated unidirectional streams are used. The proposal is, at the most basic level, to use the first byte of a unidir= ectional stream to indicate its purpose. Pros: * Reduces need for application layer to reach into transport and get a = particular stream ID; this simplifies initialization and insulates the appl= ication from how the transport chooses to manage stream allocation. * Enables extensibility =96 without this, it is problematic to add a un= idirectional stream for any purpose in the future without a protocol rev. = As with QPACK, there are cases where a long-lived stream might be preferabl= e to a series of control-stream frames that need to be correlated together. Cons: * Streams aren=92t required to be presented =93in order;=94 in the even= t of reordering, this makes the remainder of the stream unusable until the = first byte has arrived. * Assuming that different stream types get dispatched to different hand= lers, the stream might exist but not be assignable to a handler until the f= irst byte arrives (different view of previous issue). This creates a strea= m object that no one =93owns.=94 Some implementations that have looked at this think the first con is irrele= vant (since HTTP/QUIC doesn=92t make affordances for out-of-order consumpti= on anyway) and the second can be addressed by the use of a =93dispatch=94 h= andler whose job is to read the first byte and invoke the correct next hand= ler. This handler would own the stream until the first byte was available. Following the discussion in Kista, the hum was largely split between =93Do = this=94 and =93Need more time/info,=94 with only a few =93Don=92t do this= =94 hums. However, there hasn=92t been any substantive discussion of the p= roposal since then. What does the WG need to move folks from the middle bucket into one of the = other two? From nobody Tue Jun 19 16:38:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CEB13101E for ; Tue, 19 Jun 2018 16:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 L4IUt0TWivZN for ; Tue, 19 Jun 2018 16:37:58 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0095.outbound.protection.outlook.com [104.47.38.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40475131012 for ; Tue, 19 Jun 2018 16:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jE/10eTBYFnQBy/DskHvVTGwj1DyDS1CwkFiHyjymVo=; b=uezy9Xdv2iMJt80Jf/hEbY7T3dh1vJB8buSYaGSt6zLIGkCEEbbz4yCtnyPMAVE4v23bIb0ayMEzCwJNNnxpGgw61XQ1CJRT1Ea5zDAxxc5fZdMDr+fH/4w0IQ7y4B6O7nrn2crJBVhaRcDGkMLyGCcF17gpHIyWwZEy1mUUxOU= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4438.namprd08.prod.outlook.com (20.176.251.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Tue, 19 Jun 2018 23:37:55 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 23:37:55 +0000 From: Mike Bishop To: Lucas Pardue , Roberto Peon , QUIC WG Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCAgACH9M3///oK4A== Date: Tue, 19 Jun 2018 23:37:54 +0000 Message-ID: References: , <7CF7F94CB496BF4FAB1676F375F9666A3BB57DD1@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB57DD1@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4438; 7:Ae3u16Hz7J2hD+5AaNfhAXtgu6Pqm0R3/xUSwStthPldkrsh0GwrN0OYVsqkAI2Kbgd15WBjrnzm4O9P01V/eEn0kjh+WN34j+csH6KpvoJuKlM150kH83bArIRnSd706mq1+cTx6MVHSzi03aI0ZXLh8GYNJpzEGT9rLUz4WcPNSaRMahvA6XnNYSlhIqPSPRJ9+to4JLI0aXq7Ijcx8u6w3O5435s+T9YGuggLGTZWCu1HW8FxzXqv7YQfSOmG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2ccda5d8-d530-4d4a-ff18-08d5d63dae75 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4438; x-ms-traffictypediagnostic: BYAPR08MB4438: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484)(127952516941037); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(2016111802025)(20161123560045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4438; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4438; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39830400003)(396003)(39380400002)(346002)(376002)(189003)(199004)(13464003)(52314003)(25786009)(6116002)(476003)(316002)(86362001)(106356001)(74482002)(105586002)(66066001)(3846002)(5660300001)(305945005)(7736002)(6246003)(99286004)(74316002)(11346002)(9686003)(186003)(446003)(5250100002)(486006)(53936002)(81166006)(55016002)(478600001)(6436002)(97736004)(8676002)(26005)(561944003)(81156014)(33656002)(53546011)(2906002)(102836004)(59450400001)(3280700002)(110136005)(2900100001)(14454004)(229853002)(7696005)(76176011)(8936002)(3660700001)(6506007)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4438; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: uI5Zd+FjdwiV0XPAk1V+7EKjRj+6hmLn+QXdCqjlhfF82FaLmyfZdutP1q0/tqfYF5BlZh3LcMYB4nO/0KOcaCeKNdO+EOroDBOTtw0gO4GVowFq92ibfnt+P0oF4+20wZWcuvl5vBhJMs6Yzu05DzhvUs0BMc600++GUoe7nsD2PSPVzClt1RqFcsYttPo8JgXQHLYZugMKNfft/s99piN5MziQCMFCipXXifrnzVmbhWWCPaBpOqeXkclwl+QmYzAl9G4L7kwtfsKVBWPjaLGTs6lfV22KFIty8p5N4fBrwCGTORLNKCu62jdf4Yk+1Bu1iODMLHl5z01yNRtipQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 2ccda5d8-d530-4d4a-ff18-08d5d63dae75 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 23:37:54.9209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4438 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:38:02 -0000 I largely agree with you, Lucas, but will point out that in the current des= ign you at least know that it's a push stream. So a hypothetical implement= ation can at least get the stream assigned to its "push handler" even if it= can't begin to route the pushed content. Essentially this adds a second l= ayer of indirection before the stream gets assigned to the final consumer. -----Original Message----- From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20 Sent: Tuesday, June 19, 2018 4:22 PM To: Roberto Peon ; Mike Bishop ; QUIC W= G Subject: RE: Path forward with stream headers Considering con 1, in the present design push streams assign special meanin= g to the push ID variant that appears at the start of the stream. So implem= entations will be stuck until the first bits are delivered anyway, with or = without a type byte. ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Roberto Peon [fenix@fb.com] Sent: 19 June 2018 23:08 To: Mike Bishop; QUIC WG Subject: Re: Path forward with stream headers I think you just kicked the discussion off Mike! Another thing that was mentioned was to have these as two different stream = frames. One could have both self-describing and 'this-is-not-special' streams by ta= king up a single additional codepoint. -=3DR From: QUIC on behalf of Mike Bishop Date: Tuesday, June 19, 2018 at 2:23 PM To: QUIC WG Subject: Path forward with stream headers During the Kista interim, we discussed the Unidirectional Stream Headers pr= oposal (PR #1359). In the current spec, the first three unidirectional str= eams have a designated purpose identified by the stream ID; all remaining s= erver-initiated unidirectional streams are used for push, and no other clie= nt-initiated unidirectional streams are used. The proposal is, at the most basic level, to use the first byte of a unidir= ectional stream to indicate its purpose. Pros: * Reduces need for application layer to reach into transport and get a = particular stream ID; this simplifies initialization and insulates the appl= ication from how the transport chooses to manage stream allocation. * Enables extensibility - without this, it is problematic to add a unid= irectional stream for any purpose in the future without a protocol rev. As= with QPACK, there are cases where a long-lived stream might be preferable = to a series of control-stream frames that need to be correlated together. Cons: * Streams aren't required to be presented "in order;" in the event of r= eordering, this makes the remainder of the stream unusable until the first = byte has arrived. * Assuming that different stream types get dispatched to different hand= lers, the stream might exist but not be assignable to a handler until the f= irst byte arrives (different view of previous issue). This creates a strea= m object that no one "owns." Some implementations that have looked at this think the first con is irrele= vant (since HTTP/QUIC doesn't make affordances for out-of-order consumption= anyway) and the second can be addressed by the use of a "dispatch" handler= whose job is to read the first byte and invoke the correct next handler. = This handler would own the stream until the first byte was available. Following the discussion in Kista, the hum was largely split between "Do th= is" and "Need more time/info," with only a few "Don't do this" hums. Howev= er, there hasn't been any substantive discussion of the proposal since then= . What does the WG need to move folks from the middle bucket into one of the = other two? From nobody Tue Jun 19 16:41:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F821311D8 for ; Tue, 19 Jun 2018 16:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 gLbGjyU-L27j for ; Tue, 19 Jun 2018 16:40:18 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680112.outbound.protection.outlook.com [40.107.68.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1371311EE for ; Tue, 19 Jun 2018 16:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+4lzDRqDUHs1GrxrCFeEea+/4cIA8dNUc1RllEP6xI0=; b=HiLpk81yJWYynSYlIsIPe9Xquz6k6VQVsYokkBtWI1VtqfOOmVe/OyIDwkhQPpG34gCqizejqkOP1jZ/I7gbydl6SjU6FvQl85P1GpK/Vkd+mCnwsn2pXnOsLzY9jjz6gN6QmwDWF5XhXT/uap7SL9xOHthDCFRknptIIP0w8Q8= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB3960.namprd08.prod.outlook.com (52.135.194.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 23:40:13 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 23:40:13 +0000 From: Mike Bishop To: Roberto Peon , QUIC WG Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobA= Date: Tue, 19 Jun 2018 23:40:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB3960; 7:tiOrTBsF0Zw8Wvz5eBa1J75inK/Q4RZ9IB1APlcstwyxRYDjMPerVCOtDWhxZvBMIqcuLLFiaP8/jmfTXS7/0O/FJiZ+JrRVhqKnGw+ksev+yE91gv1OFbhWxEcz3O5P/fPICQ1zJoagguwjXMNAjoA2Jdbx3wcvY6aPWtGuFAntSaHFiXOgfDduQMUqTYX4HzmMAGiOZ0lUd1/tpUdKH+MTsYKZI9UNxg6dbfXsuvsfZrPOglvIvOhTif8tcgYo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0744b187-9e1f-4c7f-10a8-08d5d63e0131 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB3960; x-ms-traffictypediagnostic: BYAPR08MB3960: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(2016111802025)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB3960; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB3960; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(366004)(346002)(39380400002)(376002)(189003)(199004)(26005)(6436002)(8936002)(74316002)(7736002)(8676002)(229853002)(74482002)(81156014)(81166006)(5250100002)(478600001)(6246003)(186003)(7696005)(99286004)(14454004)(6506007)(76176011)(86362001)(59450400001)(25786009)(53546011)(55016002)(102836004)(66066001)(106356001)(105586002)(53936002)(316002)(33656002)(561944003)(110136005)(236005)(2900100001)(5660300001)(3660700001)(3846002)(790700001)(97736004)(68736007)(6116002)(3280700002)(2906002)(6306002)(476003)(486006)(54896002)(446003)(11346002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB3960; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: C+00xQNb3i9nam5zo2o610Jfy47ZWHNbSS//3mycu6DAr4k4gjMfN10+E0azpikDJTkOUMzqOIPtqKHmgO1AYjRgpY5NcEcmiO0qUplO5XX6FK71Hp8ql5rR/KUxSDNP4/JZ95soSMdBAZUC/BEE5ER4hzoN7OnPoYF0k1j2Kxdl+JQvMBxNtMdxftZJcvC9994t43FSSoUogYgqVZJYASe2akRVZeSO0N8RTSjZ/9GZ8ZzFtfFwGejYPBmj+9xG5I4fSTeWNOGMcIxpSacBPpxreIN8easttUw7HCaq0T/M4qno92yVaPFV3CTAaRNnn9eYessVGHz4eyrOsmw2dg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944608B5D376690AEF6C583DA700BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 0744b187-9e1f-4c7f-10a8-08d5d63e0131 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 23:40:13.7090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3960 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:40:33 -0000 --_000_BYAPR08MB3944608B5D376690AEF6C583DA700BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IG1lYW4gUVVJQyBTVFJFQU0gZnJhbWVzLCBJ4oCZbSBnb2luZyB0byByZWdpc3RlciBt eSBzdHJvbmcgb2JqZWN0aW9ucyB0byB0aGF0LiAgVGhhdOKAmXMgbm90IGEgZGlzdGluY3Rpb24g dGhlIFFVSUMgdHJhbnNwb3J0IG5lZWRzLCBhbmQgSeKAmW0gaGVzaXRhbnQgdG8gYXNrIHRoZW0g dG8gYWRkIGl0IG9uIEhUVFDigJlzIGJlaGFsZi4NCg0KVGhlIG90aGVyIHN1Z2dlc3Rpb24gSSBo ZWFyZCB3YXMgaGF2aW5nIGRpZmZlcmVudCByZWdpb25zIG9mIHN0cmVhbXMsIHN1Y2ggYXMgY29u dGludWluZyB0byBjb25zdW1lIHRoZSBmaXJzdCB0aHJlZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1z ICh3aXRob3V0IHR5cGUgYnl0ZSkgZm9yIHRoZSBjb250cm9sIHN0cmVhbXMgd2Uga25vdyB3aWxs IGV4aXN0LCB0aGVuIGhhdmUgYSB0eXBlIGJ5dGUgcGFzdCB0aGF0IHBvaW50IGZvciBkaXNhbWJp Z3VhdGluZyBhbGwgc3Vic2VxdWVudCBzdHJlYW1zLg0KDQpGcm9tOiBSb2JlcnRvIFBlb24gW21h aWx0bzpmZW5peEBmYi5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDM6MDkgUE0N ClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBRVUlDIFdHIDxxdWljQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzDQoN CkkgdGhpbmsgeW91IGp1c3Qga2lja2VkIHRoZSBkaXNjdXNzaW9uIG9mZiBNaWtlIQ0KDQpBbm90 aGVyIHRoaW5nIHRoYXQgd2FzIG1lbnRpb25lZCB3YXMgdG8gaGF2ZSB0aGVzZSBhcyB0d28gZGlm ZmVyZW50IHN0cmVhbSBmcmFtZXMuDQpPbmUgY291bGQgaGF2ZSBib3RoIHNlbGYtZGVzY3JpYmlu ZyBhbmQg4oCYdGhpcy1pcy1ub3Qtc3BlY2lhbOKAmSBzdHJlYW1zIGJ5IHRha2luZyB1cCBhIHNp bmdsZSBhZGRpdGlvbmFsIGNvZGVwb2ludC4NCg0KLT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVm b3UuYmU+Pg0KRGF0ZTogVHVlc2RheSwgSnVuZSAxOSwgMjAxOCBhdCAyOjIzIFBNDQpUbzogUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBQYXRo IGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQpEdXJpbmcgdGhlIEtpc3RhIGludGVyaW0s IHdlIGRpc2N1c3NlZCB0aGUgVW5pZGlyZWN0aW9uYWwgU3RyZWFtIEhlYWRlcnMgcHJvcG9zYWwg KFBSICMxMzU5KS4gIEluIHRoZSBjdXJyZW50IHNwZWMsIHRoZSBmaXJzdCB0aHJlZSB1bmlkaXJl Y3Rpb25hbCBzdHJlYW1zIGhhdmUgYSBkZXNpZ25hdGVkIHB1cnBvc2UgaWRlbnRpZmllZCBieSB0 aGUgc3RyZWFtIElEOyBhbGwgcmVtYWluaW5nIHNlcnZlci1pbml0aWF0ZWQgdW5pZGlyZWN0aW9u YWwgc3RyZWFtcyBhcmUgdXNlZCBmb3IgcHVzaCwgYW5kIG5vIG90aGVyIGNsaWVudC1pbml0aWF0 ZWQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgdXNlZC4NCg0KVGhlIHByb3Bvc2FsIGlzLCBh dCB0aGUgbW9zdCBiYXNpYyBsZXZlbCwgdG8gdXNlIHRoZSBmaXJzdCBieXRlIG9mIGEgdW5pZGly ZWN0aW9uYWwgc3RyZWFtIHRvIGluZGljYXRlIGl0cyBwdXJwb3NlLg0KDQpQcm9zOg0KDQogICog ICBSZWR1Y2VzIG5lZWQgZm9yIGFwcGxpY2F0aW9uIGxheWVyIHRvIHJlYWNoIGludG8gdHJhbnNw b3J0IGFuZCBnZXQgYSBwYXJ0aWN1bGFyIHN0cmVhbSBJRDsgdGhpcyBzaW1wbGlmaWVzIGluaXRp YWxpemF0aW9uIGFuZCBpbnN1bGF0ZXMgdGhlIGFwcGxpY2F0aW9uIGZyb20gaG93IHRoZSB0cmFu c3BvcnQgY2hvb3NlcyB0byBtYW5hZ2Ugc3RyZWFtIGFsbG9jYXRpb24uDQogICogICBFbmFibGVz IGV4dGVuc2liaWxpdHkg4oCTIHdpdGhvdXQgdGhpcywgaXQgaXMgcHJvYmxlbWF0aWMgdG8gYWRk IGEgdW5pZGlyZWN0aW9uYWwgc3RyZWFtIGZvciBhbnkgcHVycG9zZSBpbiB0aGUgZnV0dXJlIHdp dGhvdXQgYSBwcm90b2NvbCByZXYuICBBcyB3aXRoIFFQQUNLLCB0aGVyZSBhcmUgY2FzZXMgd2hl cmUgYSBsb25nLWxpdmVkIHN0cmVhbSBtaWdodCBiZSBwcmVmZXJhYmxlIHRvIGEgc2VyaWVzIG9m IGNvbnRyb2wtc3RyZWFtIGZyYW1lcyB0aGF0IG5lZWQgdG8gYmUgY29ycmVsYXRlZCB0b2dldGhl ci4NCg0KQ29uczoNCg0KICAqICAgU3RyZWFtcyBhcmVu4oCZdCByZXF1aXJlZCB0byBiZSBwcmVz ZW50ZWQg4oCcaW4gb3JkZXI74oCdIGluIHRoZSBldmVudCBvZiByZW9yZGVyaW5nLCB0aGlzIG1h a2VzIHRoZSByZW1haW5kZXIgb2YgdGhlIHN0cmVhbSB1bnVzYWJsZSB1bnRpbCB0aGUgZmlyc3Qg Ynl0ZSBoYXMgYXJyaXZlZC4NCiAgKiAgIEFzc3VtaW5nIHRoYXQgZGlmZmVyZW50IHN0cmVhbSB0 eXBlcyBnZXQgZGlzcGF0Y2hlZCB0byBkaWZmZXJlbnQgaGFuZGxlcnMsIHRoZSBzdHJlYW0gbWln aHQgZXhpc3QgYnV0IG5vdCBiZSBhc3NpZ25hYmxlIHRvIGEgaGFuZGxlciB1bnRpbCB0aGUgZmly c3QgYnl0ZSBhcnJpdmVzIChkaWZmZXJlbnQgdmlldyBvZiBwcmV2aW91cyBpc3N1ZSkuICBUaGlz IGNyZWF0ZXMgYSBzdHJlYW0gb2JqZWN0IHRoYXQgbm8gb25lIOKAnG93bnMu4oCdDQoNClNvbWUg aW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSBsb29rZWQgYXQgdGhpcyB0aGluayB0aGUgZmlyc3Qg Y29uIGlzIGlycmVsZXZhbnQgKHNpbmNlIEhUVFAvUVVJQyBkb2VzbuKAmXQgbWFrZSBhZmZvcmRh bmNlcyBmb3Igb3V0LW9mLW9yZGVyIGNvbnN1bXB0aW9uIGFueXdheSkgYW5kIHRoZSBzZWNvbmQg Y2FuIGJlIGFkZHJlc3NlZCBieSB0aGUgdXNlIG9mIGEg4oCcZGlzcGF0Y2jigJ0gaGFuZGxlciB3 aG9zZSBqb2IgaXMgdG8gcmVhZCB0aGUgZmlyc3QgYnl0ZSBhbmQgaW52b2tlIHRoZSBjb3JyZWN0 IG5leHQgaGFuZGxlci4gIFRoaXMgaGFuZGxlciB3b3VsZCBvd24gdGhlIHN0cmVhbSB1bnRpbCB0 aGUgZmlyc3QgYnl0ZSB3YXMgYXZhaWxhYmxlLg0KDQpGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24g aW4gS2lzdGEsIHRoZSBodW0gd2FzIGxhcmdlbHkgc3BsaXQgYmV0d2VlbiDigJxEbyB0aGlz4oCd IGFuZCDigJxOZWVkIG1vcmUgdGltZS9pbmZvLOKAnSB3aXRoIG9ubHkgYSBmZXcg4oCcRG9u4oCZ dCBkbyB0aGlz4oCdIGh1bXMuICBIb3dldmVyLCB0aGVyZSBoYXNu4oCZdCBiZWVuIGFueSBzdWJz dGFudGl2ZSBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NhbCBzaW5jZSB0aGVuLg0KDQpXaGF0IGRv ZXMgdGhlIFdHIG5lZWQgdG8gbW92ZSBmb2xrcyBmcm9tIHRoZSBtaWRkbGUgYnVja2V0IGludG8g b25lIG9mIHRoZSBvdGhlciB0d28/DQo= --_000_BYAPR08MB3944608B5D376690AEF6C583DA700BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox MDIyNjUyMDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjI5ODQ0ODUyO30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MzYzNDEwNjI2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjM1NzgxNDE0IDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyDQoJe21zby1saXN0LWlkOjQwMzk4ODczMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE0Mzg3MzU5OTQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo0NjQ1OTI0Njg7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1NjY2MjE4 MzQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgbWVhbiBRVUlDIFNUUkVBTSBmcmFtZXMsIEnigJltIGdv aW5nIHRvIHJlZ2lzdGVyIG15IHN0cm9uZyBvYmplY3Rpb25zIHRvIHRoYXQuJm5ic3A7IFRoYXTi gJlzIG5vdCBhIGRpc3RpbmN0aW9uIHRoZSBRVUlDIHRyYW5zcG9ydCBuZWVkcywgYW5kIEnigJlt IGhlc2l0YW50IHRvIGFzayB0aGVtIHRvIGFkZCBpdCBvbiBIVFRQ4oCZcyBiZWhhbGYuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciBzdWdnZXN0aW9uIEkgaGVhcmQgd2FzIGhhdmlu ZyBkaWZmZXJlbnQgcmVnaW9ucyBvZiBzdHJlYW1zLCBzdWNoIGFzIGNvbnRpbnVpbmcgdG8gY29u c3VtZSB0aGUgZmlyc3QgdGhyZWUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyAod2l0aG91dCB0eXBl IGJ5dGUpIGZvciB0aGUgY29udHJvbCBzdHJlYW1zIHdlIGtub3cgd2lsbCBleGlzdCwgdGhlbiBo YXZlIGEgdHlwZSBieXRlIHBhc3QgdGhhdCBwb2ludA0KIGZvciBkaXNhbWJpZ3VhdGluZyBhbGwg c3Vic2VxdWVudCBzdHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJvYmVydG8gUGVvbiBbbWFpbHRvOmZl bml4QGZiLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggMzow OSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJl Jmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBqdXN0IGtpY2tlZCB0aGUgZGlzY3Vzc2lv biBvZmYgTWlrZSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciB0aGluZyB0aGF0IHdh cyBtZW50aW9uZWQgd2FzIHRvIGhhdmUgdGhlc2UgYXMgdHdvIGRpZmZlcmVudCBzdHJlYW0gZnJh bWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGNvdWxkIGhhdmUg Ym90aCBzZWxmLWRlc2NyaWJpbmcgYW5kIOKAmHRoaXMtaXMtbm90LXNwZWNpYWzigJkgc3RyZWFt cyBieSB0YWtpbmcgdXAgYSBzaW5nbGUgYWRkaXRpb25hbCBjb2RlcG9pbnQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LT1SPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZsdDs8YSBocmVmPSJtYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZv dS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVz ZGF5LCBKdW5lIDE5LCAyMDE4IGF0IDI6MjMgUE08YnI+DQo8Yj5UbzogPC9iPlFVSUMgV0cgJmx0 OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVyaW5nIHRo ZSBLaXN0YSBpbnRlcmltLCB3ZSBkaXNjdXNzZWQgdGhlIFVuaWRpcmVjdGlvbmFsIFN0cmVhbSBI ZWFkZXJzIHByb3Bvc2FsIChQUiAjMTM1OSkuJm5ic3A7IEluIHRoZSBjdXJyZW50IHNwZWMsIHRo ZSBmaXJzdCB0aHJlZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGhhdmUgYSBkZXNpZ25hdGVkIHB1 cnBvc2UgaWRlbnRpZmllZCBieSB0aGUgc3RyZWFtIElEOyBhbGwgcmVtYWluaW5nIHNlcnZlci1p bml0aWF0ZWQNCiB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSB1c2VkIGZvciBwdXNoLCBhbmQg bm8gb3RoZXIgY2xpZW50LWluaXRpYXRlZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSB1c2Vk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvcG9zYWwgaXMsIGF0IHRoZSBtb3N0IGJh c2ljIGxldmVsLCB0byB1c2UgdGhlIGZpcnN0IGJ5dGUgb2YgYSB1bmlkaXJlY3Rpb25hbCBzdHJl YW0gdG8gaW5kaWNhdGUgaXRzIHB1cnBvc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb3M6 PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPlJl ZHVjZXMgbmVlZCBmb3IgYXBwbGljYXRpb24gbGF5ZXIgdG8gcmVhY2ggaW50byB0cmFuc3BvcnQg YW5kIGdldCBhIHBhcnRpY3VsYXIgc3RyZWFtIElEOyB0aGlzIHNpbXBsaWZpZXMgaW5pdGlhbGl6 YXRpb24gYW5kIGluc3VsYXRlcyB0aGUgYXBwbGljYXRpb24gZnJvbSBob3cgdGhlIHRyYW5zcG9y dCBjaG9vc2VzIHRvIG1hbmFnZSBzdHJlYW0gYWxsb2NhdGlvbi48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+RW5hYmxl cyBleHRlbnNpYmlsaXR5IOKAkyB3aXRob3V0IHRoaXMsIGl0IGlzIHByb2JsZW1hdGljIHRvIGFk ZCBhIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSBmb3IgYW55IHB1cnBvc2UgaW4gdGhlIGZ1dHVyZSB3 aXRob3V0IGEgcHJvdG9jb2wgcmV2LiZuYnNwOyBBcyB3aXRoIFFQQUNLLCB0aGVyZSBhcmUgY2Fz ZXMgd2hlcmUgYSBsb25nLWxpdmVkIHN0cmVhbSBtaWdodA0KIGJlIHByZWZlcmFibGUgdG8gYSBz ZXJpZXMgb2YgY29udHJvbC1zdHJlYW0gZnJhbWVzIHRoYXQgbmVlZCB0byBiZSBjb3JyZWxhdGVk IHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zOjxvOnA+PC9vOnA+ PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm82Ij5TdHJlYW1zIGFyZW7i gJl0IHJlcXVpcmVkIHRvIGJlIHByZXNlbnRlZCDigJxpbiBvcmRlcjvigJ0gaW4gdGhlIGV2ZW50 IG9mIHJlb3JkZXJpbmcsIHRoaXMgbWFrZXMgdGhlIHJlbWFpbmRlciBvZiB0aGUgc3RyZWFtIHVu dXNhYmxlIHVudGlsIHRoZSBmaXJzdCBieXRlIGhhcyBhcnJpdmVkLjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm82Ij5Bc3N1 bWluZyB0aGF0IGRpZmZlcmVudCBzdHJlYW0gdHlwZXMgZ2V0IGRpc3BhdGNoZWQgdG8gZGlmZmVy ZW50IGhhbmRsZXJzLCB0aGUgc3RyZWFtIG1pZ2h0IGV4aXN0IGJ1dCBub3QgYmUgYXNzaWduYWJs ZSB0byBhIGhhbmRsZXIgdW50aWwgdGhlIGZpcnN0IGJ5dGUgYXJyaXZlcyAoZGlmZmVyZW50IHZp ZXcgb2YgcHJldmlvdXMgaXNzdWUpLiZuYnNwOyBUaGlzDQogY3JlYXRlcyBhIHN0cmVhbSBvYmpl Y3QgdGhhdCBubyBvbmUg4oCcb3ducy7igJ08bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U29tZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXZlIGxvb2tlZCBhdCB0aGlzIHRoaW5rIHRoZSBm aXJzdCBjb24gaXMgaXJyZWxldmFudCAoc2luY2UgSFRUUC9RVUlDIGRvZXNu4oCZdCBtYWtlIGFm Zm9yZGFuY2VzIGZvciBvdXQtb2Ytb3JkZXIgY29uc3VtcHRpb24gYW55d2F5KSBhbmQgdGhlIHNl Y29uZCBjYW4gYmUgYWRkcmVzc2VkIGJ5IHRoZSB1c2Ugb2YgYSDigJxkaXNwYXRjaOKAnSBoYW5k bGVyIHdob3NlIGpvYg0KIGlzIHRvIHJlYWQgdGhlIGZpcnN0IGJ5dGUgYW5kIGludm9rZSB0aGUg Y29ycmVjdCBuZXh0IGhhbmRsZXIuJm5ic3A7IFRoaXMgaGFuZGxlciB3b3VsZCBvd24gdGhlIHN0 cmVhbSB1bnRpbCB0aGUgZmlyc3QgYnl0ZSB3YXMgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Gb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW4gS2lzdGEsIHRoZSBodW0gd2FzIGxh cmdlbHkgc3BsaXQgYmV0d2VlbiDigJxEbyB0aGlz4oCdIGFuZCDigJxOZWVkIG1vcmUgdGltZS9p bmZvLOKAnSB3aXRoIG9ubHkgYSBmZXcg4oCcRG9u4oCZdCBkbyB0aGlz4oCdIGh1bXMuJm5ic3A7 IEhvd2V2ZXIsIHRoZXJlIGhhc27igJl0IGJlZW4gYW55IHN1YnN0YW50aXZlIGRpc2N1c3Npb24g b2YgdGhlIHByb3Bvc2FsIHNpbmNlIHRoZW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQg ZG9lcyB0aGUgV0cgbmVlZCB0byBtb3ZlIGZvbGtzIGZyb20gdGhlIG1pZGRsZSBidWNrZXQgaW50 byBvbmUgb2YgdGhlIG90aGVyIHR3bz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BYAPR08MB3944608B5D376690AEF6C583DA700BYAPR08MB3944namp_-- From nobody Tue Jun 19 16:47:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87913101E for ; Tue, 19 Jun 2018 16:47:38 -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 qnZeICl23QQK for ; Tue, 19 Jun 2018 16:47:36 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E445131012 for ; Tue, 19 Jun 2018 16:47:36 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id p95-v6so1704473ota.5 for ; Tue, 19 Jun 2018 16:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3MwCKvLlpySURekwtjGWcrnnsImSGCOqlBGqKf0uS9s=; b=o6B4+W6siD+r6GlD35pZqVekIA8zD6VXUKcwlmXq2+f4MlrRm9uepQd8oL6idBOYMs o9Y1Hv4gGxjoCH13cMp1hhXkSjYqYoMrggLKfuoPnV4q6Z7mR3FkAb+oxquS1Aihtmlk SoQa1swNoDegpiyXTs/c7jfvg7sR76Ka32jMU2q3aFIxnKlFE+ifOZOS8QraEAujGvUI q5xUh979b59bm1qsoQefWEPkzQhSNByrxqeXaMhcobFqjwrgfn2lM3U1jL2H7go1T25i ykPoqvcsDcRhpXMeYcCGofS/IOwpxCVryBZdAE8QOwJ0d0H9PIvIvvCnCikSqYWs7OOT IqAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3MwCKvLlpySURekwtjGWcrnnsImSGCOqlBGqKf0uS9s=; b=nGgL50Uf0f467aF2on+IqBpOhxdLhxhep4cNaxEOv+FNv8c4MIYSfmqIvvvkHKSY+i /Igzt5w98fdTMwEjbDMR6STSRf+S0MCvK9emTLvXSRUz9P8d2YhsoytCiCzRuB1vn/Dz vPoPZn76eFgCqwHvhurM6EaRre5gGiLZ/INt0nTJc0TirXL5fxYIGpwXTH5oyqWgICCh FwjfZKU1dhu4tEnuH63cGJUc+yJw1UfczsmSkL4cqGFhu/lJ4QIrBmlc4w5o13xzusKm pFUG4V7iUlqzg9C38BYWm2QiLIukhfzinpTaQBTiEUF5WV/QM1Jp1RceXs5AN0ly1BTZ 3PLQ== X-Gm-Message-State: APt69E0NKoVXtg/RRUw3kV3W9+iIaiuCrKpr18h4VwzES86E0jGVFSHr 0Z+CbMWCYo1Ljqpwnp00JjrznSHOrujNRiXKcrnR/Q== X-Google-Smtp-Source: ADUXVKITi99poH40+Oj+rnnIsg8xarmRPhWInS6l06vWgQr2fOZ9iM3Fav3m7kT1E4aR4LUoRSLuRdc3ZfQWHZyHwfg= X-Received: by 2002:a9d:3578:: with SMTP id l53-v6mr12344838ote.15.1529452055505; Tue, 19 Jun 2018 16:47:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Wed, 20 Jun 2018 09:47:25 +1000 Message-ID: Subject: Re: Path forward with stream headers To: Mike Bishop Cc: Roberto Peon , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:47:39 -0000 I don't see any reason to add that for HTTP/QUIC either. Even if you get past the type and push ID, there is still the (highly ordered) HEADERS frame there. A different protocol might not have this restriction, but we're talking about a mechanism in the HTTP mapping, not the generic protocol. Also, if you are concerned that frames might arrive before the purpose of a stream is known, send the first octet with every other STREAM frame until it is acknowledged. It's a little wasteful, and doesn't really help much, but it's entirely possible. I'm pretty strongly in favour of a change here. On Wed, Jun 20, 2018 at 9:41 AM Mike Bishop wrote: > > If you mean QUIC STREAM frames, I=E2=80=99m going to register my strong o= bjections to that. That=E2=80=99s not a distinction the QUIC transport nee= ds, and I=E2=80=99m hesitant to ask them to add it on HTTP=E2=80=99s behalf= . > > > > The other suggestion I heard was having different regions of streams, suc= h as continuing to consume the first three unidirectional streams (without = type byte) for the control streams we know will exist, then have a type byt= e past that point for disambiguating all subsequent streams. > > > > From: Roberto Peon [mailto:fenix@fb.com] > Sent: Tuesday, June 19, 2018 3:09 PM > To: Mike Bishop ; QUIC WG > Subject: Re: Path forward with stream headers > > > > I think you just kicked the discussion off Mike! > > > > Another thing that was mentioned was to have these as two different strea= m frames. > > One could have both self-describing and =E2=80=98this-is-not-special=E2= =80=99 streams by taking up a single additional codepoint. > > > > -=3DR > > > > From: QUIC on behalf of Mike Bishop > Date: Tuesday, June 19, 2018 at 2:23 PM > To: QUIC WG > Subject: Path forward with stream headers > > > > During the Kista interim, we discussed the Unidirectional Stream Headers = proposal (PR #1359). In the current spec, the first three unidirectional s= treams have a designated purpose identified by the stream ID; all remaining= server-initiated unidirectional streams are used for push, and no other cl= ient-initiated unidirectional streams are used. > > > > The proposal is, at the most basic level, to use the first byte of a unid= irectional stream to indicate its purpose. > > > > Pros: > > Reduces need for application layer to reach into transport and get a part= icular stream ID; this simplifies initialization and insulates the applicat= ion from how the transport chooses to manage stream allocation. > Enables extensibility =E2=80=93 without this, it is problematic to add a = unidirectional stream for any purpose in the future without a protocol rev.= As with QPACK, there are cases where a long-lived stream might be prefera= ble to a series of control-stream frames that need to be correlated togethe= r. > > > > Cons: > > Streams aren=E2=80=99t required to be presented =E2=80=9Cin order;=E2=80= =9D in the event of reordering, this makes the remainder of the stream unus= able until the first byte has arrived. > Assuming that different stream types get dispatched to different handlers= , the stream might exist but not be assignable to a handler until the first= byte arrives (different view of previous issue). This creates a stream ob= ject that no one =E2=80=9Cowns.=E2=80=9D > > > > Some implementations that have looked at this think the first con is irre= levant (since HTTP/QUIC doesn=E2=80=99t make affordances for out-of-order c= onsumption anyway) and the second can be addressed by the use of a =E2=80= =9Cdispatch=E2=80=9D handler whose job is to read the first byte and invoke= the correct next handler. This handler would own the stream until the fir= st byte was available. > > > > Following the discussion in Kista, the hum was largely split between =E2= =80=9CDo this=E2=80=9D and =E2=80=9CNeed more time/info,=E2=80=9D with only= a few =E2=80=9CDon=E2=80=99t do this=E2=80=9D hums. However, there hasn= =E2=80=99t been any substantive discussion of the proposal since then. > > > > What does the WG need to move folks from the middle bucket into one of th= e other two? From nobody Tue Jun 19 17:02:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FD3131041 for ; Tue, 19 Jun 2018 17:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Jm55ukzM; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ScBeeUdH 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 ZbR3HbetORd1 for ; Tue, 19 Jun 2018 17:02:05 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 E4BF713101E for ; Tue, 19 Jun 2018 17:02:04 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5JNwPx9026602; Tue, 19 Jun 2018 17:02:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=M70bbjSic+YEPxBqGyYwOuTNn0yA/Lpu6yqCVgpZcRI=; b=Jm55ukzMSR3XT2Q8pNmTolfMWJcYSOPI+A4pIzZaS/E7g2mum+PVd/vOeMoD0+Ok8dSs o6ooZ6jlcZTs0r1a0e5H/Zdq+Sko8F7nazh6zBv5qIC4eh7+kqfGejS5Xq42S/+A/XN5 Vy7pu8XQCFMq+ohlKmY9mcnbkLZEuUQ2Bww= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jq9bm8e93-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2018 17:02:01 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.28) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Jun 2018 20:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M70bbjSic+YEPxBqGyYwOuTNn0yA/Lpu6yqCVgpZcRI=; b=ScBeeUdHqfFPvIlBfXG3SMIKiLLcVtjEmA4dgKm43mK15S39oZZCST7+Fww+wZwEwdoE4OaQTmkqbkNs0nmLI1Su9M8frexecjsf2gMqOPaBywuf3gbmaafMP6yvYBV81j3AIW2rTZsae0KufSl6VQkRKFxalXppNvt5MEAmXtc= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2325.namprd15.prod.outlook.com (52.135.197.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 00:01:58 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 00:01:58 +0000 From: Roberto Peon To: Mike Bishop , QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAK4LgA== Date: Wed, 20 Jun 2018 00:01:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:180::1:c652] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2325; 7:hhKC4u5THsDDIUNDZpZ4rpkEgEFj3XJMjb7ANa2tYUP90rRn0AEkcwmYFe41uRVVV3GSVZM30UBjzBT0QuQ9LI4uL3AP5dgDVf9zmCvVuKI69KQERAnQf1hlHWQoG4aTbQ+/Qp2Z/dgHWSFYe9rYpoa7w2lhbrXxJQ7bPowvb9bx05xs2Q7fg8No/dXTJVgBe3ESNdYmAbwmJT5S2DaGBQfYTv2kn1NyunxOk7STh8RN4l33tqR+lj+voo4v9A/D; 20:0BYuiKxlvINFKoOsdITW6o6rkqH+i+UiEJFm8+gFunfGpu7GsZgsHP7FChPI7+Kne61HOzMSCJhMwA7sZZUMPZUr0uYw9lQaSgxkYhBFH1R1NUqXfHoL8hjK7PzoNNkvzrBYWyixw/8iRAwjMttMTTvZdxQg06sMMZRgaaiFJQM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bd8e7a5e-f5f8-4208-7d08-08d5d6410ac7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2325; x-ms-traffictypediagnostic: BYAPR15MB2325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2325; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2325; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(376002)(39860400002)(39380400002)(189003)(199004)(25786009)(6306002)(6246003)(86362001)(6512007)(97736004)(53936002)(68736007)(82746002)(236005)(106356001)(2900100001)(478600001)(33656002)(561944003)(14454004)(54896002)(105586002)(5660300001)(5250100002)(3280700002)(59450400001)(83716003)(6506007)(53546011)(102836004)(2616005)(46003)(186003)(8936002)(99286004)(229853002)(3660700001)(81156014)(8676002)(81166006)(6486002)(6436002)(7736002)(6116002)(76176011)(58126008)(110136005)(486006)(476003)(316002)(446003)(36756003)(2906002)(11346002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2325; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: wM3quBt90/FFIrsKa41RBwQGQj50rp3UDpE0CyeMg1j/NpoHywjU8jK6y4BP8dyZiZwN4QdCFTNfUjCk2XrwKaQZiD7ccp5kKkz6Rnn/wv8OjBGNMGdSLyWoGLjt8R2V3SsrV/b+fTO1dZhpwPnm+JNVp9M6pKkcqtkHgpGU32l9DqLRpiIEfaJBgXwXm4GX3/68or2ZBkAXKAlGPZ8+femLc6D9RXGbbGmIezuU5ggEC7SnaqXL/xrc92R039lVTZO0Yz893NuZLnwNmyAHs/NWTH5qNG+tJkdxMd90von9AMTr5VKmbWvNr8ZYcx4k/t/HhqmmtLVVgGqs7em/Fg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C4F5AE695F264048975C4CBF3B3D1F85fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bd8e7a5e-f5f8-4208-7d08-08d5d6410ac7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 00:01:58.3138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2325 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 00:02:10 -0000 --_000_C4F5AE695F264048975C4CBF3B3D1F85fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUsIGJvcm4gb2YgbXkgYmVsaWVmIHRoYXQg dGhlIGZyYW1lLXR5cGVzIChkaXNhc3NvY2lhdGVkIGZyb20gSFRUUCBzZW1hbnRpY3MpIHdlIGhh dmUgZm9yIEhUVFAgc2hvdWxkIHN1ZmZpY2UgZm9yIGJhc2ljYWxseSBldmVyeSBwcm90b2NvbCAo YXNzdW1pbmcgd2Ugc29sdmUgdGhlIEw3IG1hcHBpbmcgaXNzdWUgd2l0aCBzdHJlYW0gZ3JvdXBz IG9yIHNvbWUgc2ltaWxhcikuDQoNCknigJlsbCBub3RlIHRoYXQgZXZlbiBmb3IgSFRUUCwgaXQg aXMgcG9zc2libGUgdG8gc2VuZCBvbmx5IFFQQUNLIGxpdGVyYWxzIGluIGEgc3RyZWFtLCBtZWFu aW5nIHRoYXQgd2Ugd2lsbCBiZSBpbmR1Y2luZyBwb3RlbnRpYWwgYWRkaXRpb25hbCBIb0wgYmxv Y2tpbmcgaW4gdGhhdCBjYXNlLiBUaGlzIHdpbGwgbm90IGJlIGludGVyZXN0aW5nIGZvciBtb3N0 IGN1cnJlbnQgSFRUUCBpbXBsZW1lbnRhdGlvbnMsIHdoaWNoIG9ubHkgZGVsaXZlciBieXRlcyBp bi1vcmRlciwgYnV0IGl0IHNlZW1zIHRvIG1lIHRvIGJlIGEg4oCcVENQLWlzLW5vdC1qdXN0LXNv Y2tldHPigJ0gc3R5bGUgaXNzdWUgd2hlcmUgQVBJIGFuZCBwcm90b2NvbCBoYXZlIGJlY29tZSBj b25mbGF0ZWQuDQoNCi09Ug0KDQoNCkZyb206IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZv dS5iZT4NCkRhdGU6IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggYXQgNDo0MCBQTQ0KVG86IFJvYmVy dG8gUGVvbiA8ZmVuaXhAZmIuY29tPiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQpJZiB5b3UgbWVhbiBRVUlD IFNUUkVBTSBmcmFtZXMsIEnigJltIGdvaW5nIHRvIHJlZ2lzdGVyIG15IHN0cm9uZyBvYmplY3Rp b25zIHRvIHRoYXQuICBUaGF04oCZcyBub3QgYSBkaXN0aW5jdGlvbiB0aGUgUVVJQyB0cmFuc3Bv cnQgbmVlZHMsIGFuZCBJ4oCZbSBoZXNpdGFudCB0byBhc2sgdGhlbSB0byBhZGQgaXQgb24gSFRU UOKAmXMgYmVoYWxmLg0KDQpUaGUgb3RoZXIgc3VnZ2VzdGlvbiBJIGhlYXJkIHdhcyBoYXZpbmcg ZGlmZmVyZW50IHJlZ2lvbnMgb2Ygc3RyZWFtcywgc3VjaCBhcyBjb250aW51aW5nIHRvIGNvbnN1 bWUgdGhlIGZpcnN0IHRocmVlIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgKHdpdGhvdXQgdHlwZSBi eXRlKSBmb3IgdGhlIGNvbnRyb2wgc3RyZWFtcyB3ZSBrbm93IHdpbGwgZXhpc3QsIHRoZW4gaGF2 ZSBhIHR5cGUgYnl0ZSBwYXN0IHRoYXQgcG9pbnQgZm9yIGRpc2FtYmlndWF0aW5nIGFsbCBzdWJz ZXF1ZW50IHN0cmVhbXMuDQoNCg0KRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhAZmIu Y29tXQ0KU2VudDogVHVlc2RheSwgSnVuZSAxOSwgMjAxOCAzOjA5IFBNDQpUbzogTWlrZSBCaXNo b3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQpJIHRoaW5rIHlvdSBq dXN0IGtpY2tlZCB0aGUgZGlzY3Vzc2lvbiBvZmYgTWlrZSENCg0KQW5vdGhlciB0aGluZyB0aGF0 IHdhcyBtZW50aW9uZWQgd2FzIHRvIGhhdmUgdGhlc2UgYXMgdHdvIGRpZmZlcmVudCBzdHJlYW0g ZnJhbWVzLg0KT25lIGNvdWxkIGhhdmUgYm90aCBzZWxmLWRlc2NyaWJpbmcgYW5kIOKAmHRoaXMt aXMtbm90LXNwZWNpYWzigJkgc3RyZWFtcyBieSB0YWtpbmcgdXAgYSBzaW5nbGUgYWRkaXRpb25h bCBjb2RlcG9pbnQuDQoNCi09Ug0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNaWtlIEJpc2hvcCA8 bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4NCkRhdGU6 IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggYXQgMjoyMyBQTQ0KVG86IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUGF0aCBmb3J3YXJkIHdpdGgg c3RyZWFtIGhlYWRlcnMNCg0KRHVyaW5nIHRoZSBLaXN0YSBpbnRlcmltLCB3ZSBkaXNjdXNzZWQg dGhlIFVuaWRpcmVjdGlvbmFsIFN0cmVhbSBIZWFkZXJzIHByb3Bvc2FsIChQUiAjMTM1OSkuICBJ biB0aGUgY3VycmVudCBzcGVjLCB0aGUgZmlyc3QgdGhyZWUgdW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBoYXZlIGEgZGVzaWduYXRlZCBwdXJwb3NlIGlkZW50aWZpZWQgYnkgdGhlIHN0cmVhbSBJRDsg YWxsIHJlbWFpbmluZyBzZXJ2ZXItaW5pdGlhdGVkIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJl IHVzZWQgZm9yIHB1c2gsIGFuZCBubyBvdGhlciBjbGllbnQtaW5pdGlhdGVkIHVuaWRpcmVjdGlv bmFsIHN0cmVhbXMgYXJlIHVzZWQuDQoNClRoZSBwcm9wb3NhbCBpcywgYXQgdGhlIG1vc3QgYmFz aWMgbGV2ZWwsIHRvIHVzZSB0aGUgZmlyc3QgYnl0ZSBvZiBhIHVuaWRpcmVjdGlvbmFsIHN0cmVh bSB0byBpbmRpY2F0ZSBpdHMgcHVycG9zZS4NCg0KUHJvczoNCg0KICAqICAgUmVkdWNlcyBuZWVk IGZvciBhcHBsaWNhdGlvbiBsYXllciB0byByZWFjaCBpbnRvIHRyYW5zcG9ydCBhbmQgZ2V0IGEg cGFydGljdWxhciBzdHJlYW0gSUQ7IHRoaXMgc2ltcGxpZmllcyBpbml0aWFsaXphdGlvbiBhbmQg aW5zdWxhdGVzIHRoZSBhcHBsaWNhdGlvbiBmcm9tIGhvdyB0aGUgdHJhbnNwb3J0IGNob29zZXMg dG8gbWFuYWdlIHN0cmVhbSBhbGxvY2F0aW9uLg0KICAqICAgRW5hYmxlcyBleHRlbnNpYmlsaXR5 IOKAkyB3aXRob3V0IHRoaXMsIGl0IGlzIHByb2JsZW1hdGljIHRvIGFkZCBhIHVuaWRpcmVjdGlv bmFsIHN0cmVhbSBmb3IgYW55IHB1cnBvc2UgaW4gdGhlIGZ1dHVyZSB3aXRob3V0IGEgcHJvdG9j b2wgcmV2LiAgQXMgd2l0aCBRUEFDSywgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIGEgbG9uZy1saXZl ZCBzdHJlYW0gbWlnaHQgYmUgcHJlZmVyYWJsZSB0byBhIHNlcmllcyBvZiBjb250cm9sLXN0cmVh bSBmcmFtZXMgdGhhdCBuZWVkIHRvIGJlIGNvcnJlbGF0ZWQgdG9nZXRoZXIuDQoNCkNvbnM6DQoN CiAgKiAgIFN0cmVhbXMgYXJlbuKAmXQgcmVxdWlyZWQgdG8gYmUgcHJlc2VudGVkIOKAnGluIG9y ZGVyO+KAnSBpbiB0aGUgZXZlbnQgb2YgcmVvcmRlcmluZywgdGhpcyBtYWtlcyB0aGUgcmVtYWlu ZGVyIG9mIHRoZSBzdHJlYW0gdW51c2FibGUgdW50aWwgdGhlIGZpcnN0IGJ5dGUgaGFzIGFycml2 ZWQuDQogICogICBBc3N1bWluZyB0aGF0IGRpZmZlcmVudCBzdHJlYW0gdHlwZXMgZ2V0IGRpc3Bh dGNoZWQgdG8gZGlmZmVyZW50IGhhbmRsZXJzLCB0aGUgc3RyZWFtIG1pZ2h0IGV4aXN0IGJ1dCBu b3QgYmUgYXNzaWduYWJsZSB0byBhIGhhbmRsZXIgdW50aWwgdGhlIGZpcnN0IGJ5dGUgYXJyaXZl cyAoZGlmZmVyZW50IHZpZXcgb2YgcHJldmlvdXMgaXNzdWUpLiAgVGhpcyBjcmVhdGVzIGEgc3Ry ZWFtIG9iamVjdCB0aGF0IG5vIG9uZSDigJxvd25zLuKAnQ0KDQpTb21lIGltcGxlbWVudGF0aW9u cyB0aGF0IGhhdmUgbG9va2VkIGF0IHRoaXMgdGhpbmsgdGhlIGZpcnN0IGNvbiBpcyBpcnJlbGV2 YW50IChzaW5jZSBIVFRQL1FVSUMgZG9lc27igJl0IG1ha2UgYWZmb3JkYW5jZXMgZm9yIG91dC1v Zi1vcmRlciBjb25zdW1wdGlvbiBhbnl3YXkpIGFuZCB0aGUgc2Vjb25kIGNhbiBiZSBhZGRyZXNz ZWQgYnkgdGhlIHVzZSBvZiBhIOKAnGRpc3BhdGNo4oCdIGhhbmRsZXIgd2hvc2Ugam9iIGlzIHRv IHJlYWQgdGhlIGZpcnN0IGJ5dGUgYW5kIGludm9rZSB0aGUgY29ycmVjdCBuZXh0IGhhbmRsZXIu ICBUaGlzIGhhbmRsZXIgd291bGQgb3duIHRoZSBzdHJlYW0gdW50aWwgdGhlIGZpcnN0IGJ5dGUg d2FzIGF2YWlsYWJsZS4NCg0KRm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGluIEtpc3RhLCB0aGUg aHVtIHdhcyBsYXJnZWx5IHNwbGl0IGJldHdlZW4g4oCcRG8gdGhpc+KAnSBhbmQg4oCcTmVlZCBt b3JlIHRpbWUvaW5mbyzigJ0gd2l0aCBvbmx5IGEgZmV3IOKAnERvbuKAmXQgZG8gdGhpc+KAnSBo dW1zLiAgSG93ZXZlciwgdGhlcmUgaGFzbuKAmXQgYmVlbiBhbnkgc3Vic3RhbnRpdmUgZGlzY3Vz c2lvbiBvZiB0aGUgcHJvcG9zYWwgc2luY2UgdGhlbi4NCg0KV2hhdCBkb2VzIHRoZSBXRyBuZWVk IHRvIG1vdmUgZm9sa3MgZnJvbSB0aGUgbWlkZGxlIGJ1Y2tldCBpbnRvIG9uZSBvZiB0aGUgb3Ro ZXIgdHdvPw0K --_000_C4F5AE695F264048975C4CBF3B3D1F85fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9746A1FFF3CCFE4AAA849F4BD88B113D@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM2MzQxMDYyNjsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTYzNTc4MTQxNCA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NjQ1OTI0Njg7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1NjY2MjE4MzQgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQ1NDY2NzQ4NjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE2NjQ1ODM4Mjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlk OjE1NjMzMjc3NTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MzQ3NzE4NDg7fQ0KQGxpc3Qg bDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaGVyZSBpcyBhIG1pc3VuZGVyc3RhbmRpbmcgaGVyZSwgYm9ybiBvZiBteSBi ZWxpZWYgdGhhdCB0aGUgZnJhbWUtdHlwZXMgKGRpc2Fzc29jaWF0ZWQgZnJvbSBIVFRQIHNlbWFu dGljcykgd2UgaGF2ZSBmb3IgSFRUUCBzaG91bGQgc3VmZmljZSBmb3IgYmFzaWNhbGx5IGV2ZXJ5 IHByb3RvY29sIChhc3N1bWluZyB3ZSBzb2x2ZSB0aGUgTDcgbWFwcGluZyBpc3N1ZSB3aXRoIHN0 cmVhbSBncm91cHMgb3Igc29tZQ0KIHNpbWlsYXIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PGJyPg0KSeKAmWxsIG5vdGUgdGhhdCBldmVuIGZvciBIVFRQLCBpdCBp cyBwb3NzaWJsZSB0byBzZW5kIG9ubHkgUVBBQ0sgbGl0ZXJhbHMgaW4gYSBzdHJlYW0sIG1lYW5p bmcgdGhhdCB3ZSB3aWxsIGJlIGluZHVjaW5nIHBvdGVudGlhbCBhZGRpdGlvbmFsIEhvTCBibG9j a2luZyBpbiB0aGF0IGNhc2UuIFRoaXMgd2lsbCBub3QgYmUgaW50ZXJlc3RpbmcgZm9yIG1vc3Qg Y3VycmVudCBIVFRQIGltcGxlbWVudGF0aW9ucywgd2hpY2ggb25seSBkZWxpdmVyIGJ5dGVzDQog aW4tb3JkZXIsIGJ1dCBpdCBzZWVtcyB0byBtZSB0byBiZSBhIOKAnFRDUC1pcy1ub3QtanVzdC1z b2NrZXRz4oCdIHN0eWxlIGlzc3VlIHdoZXJlIEFQSSBhbmQgcHJvdG9jb2wgaGF2ZSBiZWNvbWUg Y29uZmxhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGJyPg0K LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1pa2UgQmlzaG9wICZsdDttYmlzaG9w QGV2ZXF1ZWZvdS5iZSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVuZSAxOSwgMjAx OCBhdCA0OjQwIFBNPGJyPg0KPGI+VG86IDwvYj5Sb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNv bSZndDssIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJFOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVyczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgbWVhbiBRVUlDIFNUUkVB TSBmcmFtZXMsIEnigJltIGdvaW5nIHRvIHJlZ2lzdGVyIG15IHN0cm9uZyBvYmplY3Rpb25zIHRv IHRoYXQuJm5ic3A7IFRoYXTigJlzIG5vdCBhIGRpc3RpbmN0aW9uIHRoZSBRVUlDIHRyYW5zcG9y dCBuZWVkcywgYW5kIEnigJltIGhlc2l0YW50IHRvIGFzayB0aGVtIHRvIGFkZCBpdCBvbiBIVFRQ 4oCZcyBiZWhhbGYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciBzdWdnZXN0aW9u IEkgaGVhcmQgd2FzIGhhdmluZyBkaWZmZXJlbnQgcmVnaW9ucyBvZiBzdHJlYW1zLCBzdWNoIGFz IGNvbnRpbnVpbmcgdG8gY29uc3VtZSB0aGUgZmlyc3QgdGhyZWUgdW5pZGlyZWN0aW9uYWwgc3Ry ZWFtcyAod2l0aG91dCB0eXBlIGJ5dGUpIGZvciB0aGUgY29udHJvbCBzdHJlYW1zIHdlIGtub3cg d2lsbCBleGlzdCwgdGhlbiBoYXZlIGEgdHlwZSBieXRlIHBhc3QgdGhhdCBwb2ludA0KIGZvciBk aXNhbWJpZ3VhdGluZyBhbGwgc3Vic2VxdWVudCBzdHJlYW1zLjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFJvYmVydG8gUGVvbiBbbWFpbHRvOmZlbml4QGZiLmNvbV0gPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggMzowOSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBC aXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVh bSBoZWFkZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IHlvdSBqdXN0IGtpY2tlZCB0aGUgZGlzY3Vzc2lvbiBvZmYgTWlrZSE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QW5vdGhlciB0aGluZyB0aGF0IHdhcyBtZW50aW9uZWQgd2FzIHRvIGhhdmUgdGhl c2UgYXMgdHdvIGRpZmZlcmVudCBzdHJlYW0gZnJhbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T25lIGNvdWxkIGhhdmUgYm90aCBzZWxmLWRlc2NyaWJpbmcgYW5kIOKA mHRoaXMtaXMtbm90LXNwZWNpYWzigJkgc3RyZWFtcyBieSB0YWtpbmcgdXAgYSBzaW5nbGUgYWRk aXRpb25hbCBjb2RlcG9pbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5RVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWlj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWlrZSBCaXNob3AgJmx0Ozxh IGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKdW5lIDE5LCAyMDE4IGF0IDI6MjMg UE08YnI+DQo8Yj5UbzogPC9iPlFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu b3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UGF0aCBmb3J3 YXJkIHdpdGggc3RyZWFtIGhlYWRlcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVyaW5nIHRoZSBLaXN0YSBpbnRlcmltLCB3ZSBkaXNjdXNz ZWQgdGhlIFVuaWRpcmVjdGlvbmFsIFN0cmVhbSBIZWFkZXJzIHByb3Bvc2FsIChQUiAjMTM1OSku Jm5ic3A7IEluIHRoZSBjdXJyZW50IHNwZWMsIHRoZSBmaXJzdCB0aHJlZSB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zIGhhdmUgYSBkZXNpZ25hdGVkIHB1cnBvc2UgaWRlbnRpZmllZCBieSB0aGUgc3Ry ZWFtIElEOyBhbGwgcmVtYWluaW5nIHNlcnZlci1pbml0aWF0ZWQNCiB1bmlkaXJlY3Rpb25hbCBz dHJlYW1zIGFyZSB1c2VkIGZvciBwdXNoLCBhbmQgbm8gb3RoZXIgY2xpZW50LWluaXRpYXRlZCB1 bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgcHJvcG9zYWwgaXMsIGF0IHRoZSBtb3N0IGJhc2ljIGxldmVsLCB0byB1c2UgdGhlIGZpcnN0 IGJ5dGUgb2YgYSB1bmlkaXJlY3Rpb25hbCBzdHJlYW0gdG8gaW5kaWNhdGUgaXRzIHB1cnBvc2Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb3M6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPlJlZHVjZXMgbmVlZCBmb3IgYXBwbGljYXRpb24g bGF5ZXIgdG8gcmVhY2ggaW50byB0cmFuc3BvcnQgYW5kIGdldCBhIHBhcnRpY3VsYXIgc3RyZWFt IElEOyB0aGlzIHNpbXBsaWZpZXMgaW5pdGlhbGl6YXRpb24gYW5kIGluc3VsYXRlcyB0aGUgYXBw bGljYXRpb24gZnJvbSBob3cgdGhlIHRyYW5zcG9ydCBjaG9vc2VzIHRvIG1hbmFnZSBzdHJlYW0g YWxsb2NhdGlvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+RW5hYmxlcyBleHRlbnNpYmlsaXR5IOKAkyB3aXRob3V0 IHRoaXMsIGl0IGlzIHByb2JsZW1hdGljIHRvIGFkZCBhIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSBm b3IgYW55IHB1cnBvc2UgaW4gdGhlIGZ1dHVyZSB3aXRob3V0IGEgcHJvdG9jb2wgcmV2LiZuYnNw OyBBcyB3aXRoIFFQQUNLLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgYSBsb25nLWxpdmVkIHN0cmVh bSBtaWdodA0KIGJlIHByZWZlcmFibGUgdG8gYSBzZXJpZXMgb2YgY29udHJvbC1zdHJlYW0gZnJh bWVzIHRoYXQgbmVlZCB0byBiZSBjb3JyZWxhdGVkIHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db25zOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0 OmwwIGxldmVsMSBsZm82Ij5TdHJlYW1zIGFyZW7igJl0IHJlcXVpcmVkIHRvIGJlIHByZXNlbnRl ZCDigJxpbiBvcmRlcjvigJ0gaW4gdGhlIGV2ZW50IG9mIHJlb3JkZXJpbmcsIHRoaXMgbWFrZXMg dGhlIHJlbWFpbmRlciBvZiB0aGUgc3RyZWFtIHVudXNhYmxlIHVudGlsIHRoZSBmaXJzdCBieXRl IGhhcyBhcnJpdmVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1saXN0OmwwIGxldmVsMSBsZm82Ij5Bc3N1bWluZyB0aGF0IGRpZmZlcmVudCBzdHJlYW0g dHlwZXMgZ2V0IGRpc3BhdGNoZWQgdG8gZGlmZmVyZW50IGhhbmRsZXJzLCB0aGUgc3RyZWFtIG1p Z2h0IGV4aXN0IGJ1dCBub3QgYmUgYXNzaWduYWJsZSB0byBhIGhhbmRsZXIgdW50aWwgdGhlIGZp cnN0IGJ5dGUgYXJyaXZlcyAoZGlmZmVyZW50IHZpZXcgb2YgcHJldmlvdXMgaXNzdWUpLiZuYnNw OyBUaGlzDQogY3JlYXRlcyBhIHN0cmVhbSBvYmplY3QgdGhhdCBubyBvbmUg4oCcb3ducy7igJ08 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBo YXZlIGxvb2tlZCBhdCB0aGlzIHRoaW5rIHRoZSBmaXJzdCBjb24gaXMgaXJyZWxldmFudCAoc2lu Y2UgSFRUUC9RVUlDIGRvZXNu4oCZdCBtYWtlIGFmZm9yZGFuY2VzIGZvciBvdXQtb2Ytb3JkZXIg Y29uc3VtcHRpb24gYW55d2F5KSBhbmQgdGhlIHNlY29uZCBjYW4gYmUgYWRkcmVzc2VkIGJ5IHRo ZSB1c2Ugb2YgYSDigJxkaXNwYXRjaOKAnSBoYW5kbGVyIHdob3NlIGpvYg0KIGlzIHRvIHJlYWQg dGhlIGZpcnN0IGJ5dGUgYW5kIGludm9rZSB0aGUgY29ycmVjdCBuZXh0IGhhbmRsZXIuJm5ic3A7 IFRoaXMgaGFuZGxlciB3b3VsZCBvd24gdGhlIHN0cmVhbSB1bnRpbCB0aGUgZmlyc3QgYnl0ZSB3 YXMgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xsb3dpbmcgdGhlIGRpc2N1 c3Npb24gaW4gS2lzdGEsIHRoZSBodW0gd2FzIGxhcmdlbHkgc3BsaXQgYmV0d2VlbiDigJxEbyB0 aGlz4oCdIGFuZCDigJxOZWVkIG1vcmUgdGltZS9pbmZvLOKAnSB3aXRoIG9ubHkgYSBmZXcg4oCc RG9u4oCZdCBkbyB0aGlz4oCdIGh1bXMuJm5ic3A7IEhvd2V2ZXIsIHRoZXJlIGhhc27igJl0IGJl ZW4gYW55IHN1YnN0YW50aXZlIGRpc2N1c3Npb24gb2YgdGhlIHByb3Bvc2FsIHNpbmNlIHRoZW4u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG9lcyB0aGUgV0cgbmVlZCB0byBtb3ZlIGZv bGtzIGZyb20gdGhlIG1pZGRsZSBidWNrZXQgaW50byBvbmUgb2YgdGhlIG90aGVyIHR3bz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C4F5AE695F264048975C4CBF3B3D1F85fbcom_-- From nobody Tue Jun 19 17:21:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485A5130ECE for ; Tue, 19 Jun 2018 17:21:13 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=VgXleHtY; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=VNtqn3py 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 YXXFvZPtFAgj for ; Tue, 19 Jun 2018 17:21:09 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 C35EB130E65 for ; Tue, 19 Jun 2018 17:21:09 -0700 (PDT) Received: from pps.filterd (m0148460.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5K0Iwo1027256; Tue, 19 Jun 2018 17:21:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=A9o0Cm0YWMgjrissA/HtWL65Yw3mKpfTw2z2PaxFmtA=; b=VgXleHtY2IXT+qzOsTXEneTJMR7bZ6h2yqcu8spJVWtHJk4/PIh9HY9H2MOzeM852zuz UQjqNb5zZIdlTyj6pMNIK6LjLAt5f5e8QswsOE65Zm+Aj2EemTi0HGZjPUlnN/2k37K4 SMijRB2RMINFgGRbwEUr08QgSVQhI9dGKiM= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jqafnr90c-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2018 17:21:05 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Jun 2018 20:21:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A9o0Cm0YWMgjrissA/HtWL65Yw3mKpfTw2z2PaxFmtA=; b=VNtqn3py/jX3oCE1Xc0E+A43zxlwt2xpD/1zrTOI8Mn9Cx2RkowV+kn7g5VC2SvMefWvczo5odN9R3wyoeZDLB0/AgBF+zMjO+/SV7uTGsDNdp6Ox0k144Et4AyxwWauTzVrDv91mPN/FbLyqCc4rGQ6z9I5YJHyj8IDOORb0uw= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2375.namprd15.prod.outlook.com (52.135.198.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Wed, 20 Jun 2018 00:21:02 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 00:21:02 +0000 From: Roberto Peon To: Martin Thomson , Mike Bishop CC: QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsA Date: Wed, 20 Jun 2018 00:21:02 +0000 Message-ID: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:180::1:c652] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2375; 7:/v7RQbBsmujTGMIvrVN9qJ7fnei6iuPeWW8Eo8+5LUenuqot1z/4eoZaHxJOuSjsQo9zqXiZu46XhUrb7IrKOLEKKcOGoKwOoOP6PUTRSFLGidifpUtOJflsBBK2xPALIDfY3adoqNDVSSyAugIFRgIL8cdWdak4rzGFatuU6lHJDlHNLnLJtNTcYG4vP1/av0mljnT5mtpWLJbq1CKXZJ/XMuUTdYuPC5ba4hPRyipx7mNTDaP0Rd0S7SalUc3z; 20:faXrht4ylFgJLevxRI1NED1m6Qfx+f0pJgtxB9UXyjK1631K9uhbZfEKWwTh8ETNjyq8GgjUb+8uaWh/EFwgQ93um0YzlJIEwrKnJQkFktB6SwP8GSv+MA0Uc2YCmre9Isdi0/U/TOhZdVcxz3k33sciiUUKSXo8XxvfKeDPoOw= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d5dfb1ca-3204-40e7-6913-08d5d643b4ee x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2375; x-ms-traffictypediagnostic: BYAPR15MB2375: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2375; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2375; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(396003)(366004)(39380400002)(189003)(199004)(39060400002)(106356001)(7736002)(561944003)(478600001)(68736007)(305945005)(86362001)(8676002)(81156014)(6512007)(6246003)(81166006)(8936002)(476003)(486006)(33656002)(14454004)(4326008)(53936002)(6436002)(25786009)(229853002)(6486002)(97736004)(186003)(76176011)(36756003)(6506007)(2900100001)(102836004)(53546011)(5250100002)(59450400001)(82746002)(46003)(6116002)(83716003)(110136005)(316002)(93886005)(58126008)(99286004)(2616005)(2906002)(11346002)(105586002)(446003)(3660700001)(3280700002)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2375; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QspKfbOxB8Wq0qjo5GGOAZclzPkHJo7jiMAce30K5K96OxZb9UiKvqf7RB5E0Ea9rIaaMuaSBgKyXQMDkrxzaZmu6YnB2K6yhKm8YD2oK6jmFrPTWr49TdFti2xGSZBCGKUVCxO9RIqmyArFgCv1ZZOflrnMJX2oIc/L9+1wMATUX2F04kPwCxje67LDbK0T3o/4RZCpuOY9J+jcsEX51ovxpewKlG/GRPz9e3wBUNFtYzBzks0V9ieraTjmXFXaiuNPKjS/0+qy4qR17Yh3UGbVBf0dUGpH0mPF1oTqz0txIWrJtkO811d9JCBuXc4cfQHeeqXT3tiRvmCI+nZK7A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d5dfb1ca-3204-40e7-6913-08d5d643b4ee X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 00:21:02.8219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2375 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 00:21:14 -0000 QW5vdGhlciB3YXkgdG8gYXR0ZW1wdCB0byBleHByZXNzIHRoaXM6DQoNCkltYWdpbmUgYW4gSFRU UCBpbXBsZW1lbnRhdGlvbiB3aGljaCBoYXMgYW4gQVBJIHdoaWNoIGVuYWJsZXMgZGF0YSB0byBi ZSBpbnRlcnByZXRlZCBhcyBpdCBpcyByZWNlaXZlZC4NCkluIG90aGVyIHdvcmRzLCBpbnN0ZWFk IG9mIGEgc29ja2V0LWxpa2UgQVBJIHdoaWNoIHJldHVybnMgZGF0YSBvbmx5IHdoZW4geW91J3Zl IHJlY2VpdmVkIEFMTCBvZiB0aGUgcHJpb3IgTiBieXRlcywgeW91IGdldCBhIHNjYXR0ZXItZ2F0 aGVyIEFQSSB3aGljaCBjYW4gcHJlc2VudCBkYXRhIGFzIGlmIHlvdSB3ZXJlIHJlY2VpdmluZyB0 aGUgcmVzdWx0cyBvZiBtYW55IHJhbmdlIHJlcXVlc3RzLiANCg0KVGhpcyBpcyBwdXJlbHkgYW4g QVBJIGNoYW5nZS0tIHlvdSBzdGlsbCBlaXRoZXIgc2VuZCBhIHJlcXVlc3QgYW5kIGdvdCBkYXRh LCBvciB3ZXJlIHNlcnZlciBwdXNoJ2QgZGF0YS4gDQoNCkluIHRoZSBjYXNlIG9mIG1hcHBpbmcg dmlkZW8gdG8gSFRUUCwgb25lIGNvdWxkIHNlcGFyYXRlIHRoZSAiY29udGFpbmVyIGJpdHMiIChh LmsuYS4gZnJhbWluZyBzdHJlYW0pIGFuZCBlbGVtZW50YWwgYml0c3RyZWFtIGludG8gc2VwYXJh dGUgSFRUUCBvYmplY3RzLiBUaHVzLCBpZiBJJ3ZlIHJlY2VpdmVkIGFsbCBvZiB0aGUgYnl0ZXMg b24gdGhlIGZyYW1pbmcgc3RyZWFtIHRoYXQgZGVzY3JpYmUgYSBwb3J0aW9uIG9mIHRoZSBlbGVt ZW50YWwgYml0c3RyZWFtLCBhbmQgSSBoYXZlIHRoYXQgcG9ydGlvbiBvZiB0aGUgZWxlbWVudGFs IGJpdHN0cmVhbSwgSSBjYW4gcHJlc2VudCB2aWRlby4gDQpBcyBJIGtub3cgeW91IGtub3csIGl0 IGlzIG9mdGVuIGFkdmFudGFnZW91cyB0byBnaXZlIGRhdGEgdG8gdGhlIGRlY29kZXIgdG8gcHJl c2VudCB2aWRlbyBpbiBhIHRpbWVseSBtYW5uZXIgdG8gdGhlIHVzZXIsIGV2ZW4gd2hlbiBkb2lu ZyBzbyBpbnRyb2R1Y2VzIG5vaXNlLg0KVGhlcmUgYXJlIG90aGVyIGxheW91dHMgdGhhdCB3b3Vs ZCBtYWtlIHNlbnNlOiBQdXR0aW5nIGFsbCBJLWZyYW1lcyBpbnRvIGEgc2VwYXJhdGUgSFRUUCBv YmplY3QgZnJvbSB0aGUgb25lIHdoaWNoIGhhcyBhbGwgb2YgdGhlIFAtZnJhbWVzLCBldGMuDQoN ClRoaXMgKHByZXNlbnRhdGlvbiBvZiBhIHBvcnRpb24gb2YgdGhlIHZpZGVvKSBjb3VsZCBiZSBw b3NzaWJsZSB3aXRob3V0IHJlY2VpdmluZyBhbnkgb2YgdGhlIGJ5dGVzIG9mIHRoZSBlbGVtZW50 YWwgYml0c3RyZWFtIGZvci9mcm9tIHRoZSBwcmV2aW91cyBHT1AsIHdoaWNoIGNvdWxkIGhhdmUg YmVlbiBzZW50IGluIHRoZSBwcmlvciBwYWNrZXQocykuDQoNClRoaXMgY291bGQgYmUgZG9uZSB3 aXRoIHNlcnZlciBwdXNoIGFzIHdyaXR0ZW4gZm9yIEhUVFAgdG9kYXksIGFzc3VtaW5nIHRoZSBj bGllbnQgaGFzIEFQSXMgZXhwb3NlZCB0byBhbGxvdyBpdCBhY2Nlc3MgdG8gdGhlIGRhdGEgKGFz IGlzIHRoZSBzdGFydGluZyBwcmVtaXNlKS4NCg0KSG93ZXZlciwgaWYgb25lIG11c3QgcmVjZWl2 ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3RyZWFtLCBhZGRpdGlvbmFsIEhvTCBibG9ja2lu ZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2svaW50ZXJwcmV0YXRpb24pIGlzIGluZHVjZWQuDQoN Ci09UiANCg0K77u/T24gNi8xOS8xOCwgNDo0OCBQTSwgIk1hcnRpbiBUaG9tc29uIiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24g dG8gYWRkIHRoYXQgZm9yIEhUVFAvUVVJQyBlaXRoZXIuICBFdmVuIGlmIHlvdQ0KICAgIGdldCBw YXN0IHRoZSB0eXBlIGFuZCBwdXNoIElELCB0aGVyZSBpcyBzdGlsbCB0aGUgKGhpZ2hseSBvcmRl cmVkKQ0KICAgIEhFQURFUlMgZnJhbWUgdGhlcmUuICBBIGRpZmZlcmVudCBwcm90b2NvbCBtaWdo dCBub3QgaGF2ZSB0aGlzDQogICAgcmVzdHJpY3Rpb24sIGJ1dCB3ZSdyZSB0YWxraW5nIGFib3V0 IGEgbWVjaGFuaXNtIGluIHRoZSBIVFRQIG1hcHBpbmcsDQogICAgbm90IHRoZSBnZW5lcmljIHBy b3RvY29sLg0KICAgIA0KICAgIEFsc28sIGlmIHlvdSBhcmUgY29uY2VybmVkIHRoYXQgZnJhbWVz IG1pZ2h0IGFycml2ZSBiZWZvcmUgdGhlIHB1cnBvc2UNCiAgICBvZiBhIHN0cmVhbSBpcyBrbm93 biwgc2VuZCB0aGUgZmlyc3Qgb2N0ZXQgd2l0aCBldmVyeSBvdGhlciBTVFJFQU0NCiAgICBmcmFt ZSB1bnRpbCBpdCBpcyBhY2tub3dsZWRnZWQuICBJdCdzIGEgbGl0dGxlIHdhc3RlZnVsLCBhbmQg ZG9lc24ndA0KICAgIHJlYWxseSBoZWxwIG11Y2gsIGJ1dCBpdCdzIGVudGlyZWx5IHBvc3NpYmxl Lg0KICAgIA0KICAgIEknbSBwcmV0dHkgc3Ryb25nbHkgaW4gZmF2b3VyIG9mIGEgY2hhbmdlIGhl cmUuDQogICAgT24gV2VkLCBKdW4gMjAsIDIwMTggYXQgOTo0MSBBTSBNaWtlIEJpc2hvcCA8bWJp c2hvcEBldmVxdWVmb3UuYmU+IHdyb3RlOg0KICAgID4NCiAgICA+IElmIHlvdSBtZWFuIFFVSUMg U1RSRUFNIGZyYW1lcywgSeKAmW0gZ29pbmcgdG8gcmVnaXN0ZXIgbXkgc3Ryb25nIG9iamVjdGlv bnMgdG8gdGhhdC4gIFRoYXTigJlzIG5vdCBhIGRpc3RpbmN0aW9uIHRoZSBRVUlDIHRyYW5zcG9y dCBuZWVkcywgYW5kIEnigJltIGhlc2l0YW50IHRvIGFzayB0aGVtIHRvIGFkZCBpdCBvbiBIVFRQ 4oCZcyBiZWhhbGYuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBUaGUgb3RoZXIgc3VnZ2Vz dGlvbiBJIGhlYXJkIHdhcyBoYXZpbmcgZGlmZmVyZW50IHJlZ2lvbnMgb2Ygc3RyZWFtcywgc3Vj aCBhcyBjb250aW51aW5nIHRvIGNvbnN1bWUgdGhlIGZpcnN0IHRocmVlIHVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgKHdpdGhvdXQgdHlwZSBieXRlKSBmb3IgdGhlIGNvbnRyb2wgc3RyZWFtcyB3ZSBr bm93IHdpbGwgZXhpc3QsIHRoZW4gaGF2ZSBhIHR5cGUgYnl0ZSBwYXN0IHRoYXQgcG9pbnQgZm9y IGRpc2FtYmlndWF0aW5nIGFsbCBzdWJzZXF1ZW50IHN0cmVhbXMuDQogICAgPg0KICAgID4NCiAg ICA+DQogICAgPiBGcm9tOiBSb2JlcnRvIFBlb24gW21haWx0bzpmZW5peEBmYi5jb21dDQogICAg PiBTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDM6MDkgUE0NCiAgICA+IFRvOiBNaWtlIEJp c2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KICAg ID4gU3ViamVjdDogUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzDQogICAgPg0K ICAgID4NCiAgICA+DQogICAgPiBJIHRoaW5rIHlvdSBqdXN0IGtpY2tlZCB0aGUgZGlzY3Vzc2lv biBvZmYgTWlrZSENCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IEFub3RoZXIgdGhpbmcgdGhh dCB3YXMgbWVudGlvbmVkIHdhcyB0byBoYXZlIHRoZXNlIGFzIHR3byBkaWZmZXJlbnQgc3RyZWFt IGZyYW1lcy4NCiAgICA+DQogICAgPiBPbmUgY291bGQgaGF2ZSBib3RoIHNlbGYtZGVzY3JpYmlu ZyBhbmQg4oCYdGhpcy1pcy1ub3Qtc3BlY2lhbOKAmSBzdHJlYW1zIGJ5IHRha2luZyB1cCBhIHNp bmdsZSBhZGRpdGlvbmFsIGNvZGVwb2ludC4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IC09 Ug0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0K ICAgID4gRGF0ZTogVHVlc2RheSwgSnVuZSAxOSwgMjAxOCBhdCAyOjIzIFBNDQogICAgPiBUbzog UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NCiAgICA+IFN1YmplY3Q6IFBhdGggZm9yd2FyZCB3aXRo IHN0cmVhbSBoZWFkZXJzDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBEdXJpbmcgdGhlIEtp c3RhIGludGVyaW0sIHdlIGRpc2N1c3NlZCB0aGUgVW5pZGlyZWN0aW9uYWwgU3RyZWFtIEhlYWRl cnMgcHJvcG9zYWwgKFBSICMxMzU5KS4gIEluIHRoZSBjdXJyZW50IHNwZWMsIHRoZSBmaXJzdCB0 aHJlZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGhhdmUgYSBkZXNpZ25hdGVkIHB1cnBvc2UgaWRl bnRpZmllZCBieSB0aGUgc3RyZWFtIElEOyBhbGwgcmVtYWluaW5nIHNlcnZlci1pbml0aWF0ZWQg dW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgdXNlZCBmb3IgcHVzaCwgYW5kIG5vIG90aGVyIGNs aWVudC1pbml0aWF0ZWQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgdXNlZC4NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+IFRoZSBwcm9wb3NhbCBpcywgYXQgdGhlIG1vc3QgYmFzaWMgbGV2 ZWwsIHRvIHVzZSB0aGUgZmlyc3QgYnl0ZSBvZiBhIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSB0byBp bmRpY2F0ZSBpdHMgcHVycG9zZS4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IFByb3M6DQog ICAgPg0KICAgID4gUmVkdWNlcyBuZWVkIGZvciBhcHBsaWNhdGlvbiBsYXllciB0byByZWFjaCBp bnRvIHRyYW5zcG9ydCBhbmQgZ2V0IGEgcGFydGljdWxhciBzdHJlYW0gSUQ7IHRoaXMgc2ltcGxp ZmllcyBpbml0aWFsaXphdGlvbiBhbmQgaW5zdWxhdGVzIHRoZSBhcHBsaWNhdGlvbiBmcm9tIGhv dyB0aGUgdHJhbnNwb3J0IGNob29zZXMgdG8gbWFuYWdlIHN0cmVhbSBhbGxvY2F0aW9uLg0KICAg ID4gRW5hYmxlcyBleHRlbnNpYmlsaXR5IOKAkyB3aXRob3V0IHRoaXMsIGl0IGlzIHByb2JsZW1h dGljIHRvIGFkZCBhIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSBmb3IgYW55IHB1cnBvc2UgaW4gdGhl IGZ1dHVyZSB3aXRob3V0IGEgcHJvdG9jb2wgcmV2LiAgQXMgd2l0aCBRUEFDSywgdGhlcmUgYXJl IGNhc2VzIHdoZXJlIGEgbG9uZy1saXZlZCBzdHJlYW0gbWlnaHQgYmUgcHJlZmVyYWJsZSB0byBh IHNlcmllcyBvZiBjb250cm9sLXN0cmVhbSBmcmFtZXMgdGhhdCBuZWVkIHRvIGJlIGNvcnJlbGF0 ZWQgdG9nZXRoZXIuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBDb25zOg0KICAgID4NCiAg ICA+IFN0cmVhbXMgYXJlbuKAmXQgcmVxdWlyZWQgdG8gYmUgcHJlc2VudGVkIOKAnGluIG9yZGVy O+KAnSBpbiB0aGUgZXZlbnQgb2YgcmVvcmRlcmluZywgdGhpcyBtYWtlcyB0aGUgcmVtYWluZGVy IG9mIHRoZSBzdHJlYW0gdW51c2FibGUgdW50aWwgdGhlIGZpcnN0IGJ5dGUgaGFzIGFycml2ZWQu DQogICAgPiBBc3N1bWluZyB0aGF0IGRpZmZlcmVudCBzdHJlYW0gdHlwZXMgZ2V0IGRpc3BhdGNo ZWQgdG8gZGlmZmVyZW50IGhhbmRsZXJzLCB0aGUgc3RyZWFtIG1pZ2h0IGV4aXN0IGJ1dCBub3Qg YmUgYXNzaWduYWJsZSB0byBhIGhhbmRsZXIgdW50aWwgdGhlIGZpcnN0IGJ5dGUgYXJyaXZlcyAo ZGlmZmVyZW50IHZpZXcgb2YgcHJldmlvdXMgaXNzdWUpLiAgVGhpcyBjcmVhdGVzIGEgc3RyZWFt IG9iamVjdCB0aGF0IG5vIG9uZSDigJxvd25zLuKAnQ0KICAgID4NCiAgICA+DQogICAgPg0KICAg ID4gU29tZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXZlIGxvb2tlZCBhdCB0aGlzIHRoaW5rIHRo ZSBmaXJzdCBjb24gaXMgaXJyZWxldmFudCAoc2luY2UgSFRUUC9RVUlDIGRvZXNu4oCZdCBtYWtl IGFmZm9yZGFuY2VzIGZvciBvdXQtb2Ytb3JkZXIgY29uc3VtcHRpb24gYW55d2F5KSBhbmQgdGhl IHNlY29uZCBjYW4gYmUgYWRkcmVzc2VkIGJ5IHRoZSB1c2Ugb2YgYSDigJxkaXNwYXRjaOKAnSBo YW5kbGVyIHdob3NlIGpvYiBpcyB0byByZWFkIHRoZSBmaXJzdCBieXRlIGFuZCBpbnZva2UgdGhl IGNvcnJlY3QgbmV4dCBoYW5kbGVyLiAgVGhpcyBoYW5kbGVyIHdvdWxkIG93biB0aGUgc3RyZWFt IHVudGlsIHRoZSBmaXJzdCBieXRlIHdhcyBhdmFpbGFibGUuDQogICAgPg0KICAgID4NCiAgICA+ DQogICAgPiBGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW4gS2lzdGEsIHRoZSBodW0gd2FzIGxh cmdlbHkgc3BsaXQgYmV0d2VlbiDigJxEbyB0aGlz4oCdIGFuZCDigJxOZWVkIG1vcmUgdGltZS9p bmZvLOKAnSB3aXRoIG9ubHkgYSBmZXcg4oCcRG9u4oCZdCBkbyB0aGlz4oCdIGh1bXMuICBIb3dl dmVyLCB0aGVyZSBoYXNu4oCZdCBiZWVuIGFueSBzdWJzdGFudGl2ZSBkaXNjdXNzaW9uIG9mIHRo ZSBwcm9wb3NhbCBzaW5jZSB0aGVuLg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gV2hhdCBk b2VzIHRoZSBXRyBuZWVkIHRvIG1vdmUgZm9sa3MgZnJvbSB0aGUgbWlkZGxlIGJ1Y2tldCBpbnRv IG9uZSBvZiB0aGUgb3RoZXIgdHdvPw0KICAgIA0KDQo= From nobody Tue Jun 19 17:29:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC5130EDA for ; Tue, 19 Jun 2018 17:29:18 -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 r2DfUIMd8wvH for ; Tue, 19 Jun 2018 17:29:16 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164A9130E65 for ; Tue, 19 Jun 2018 17:29:16 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id d19-v6so1769449oti.8 for ; Tue, 19 Jun 2018 17:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=udC7E2mdhaDzbGJAhLhKZXb+65Nihv5m57wL/wbMtls=; b=IPmG4FyP1GdqL6bdtsxq0dpuCRSV2VSQ+aFAUazJ2h7jmkNw212oTavW4h/c5HaA2m LJFYS+LLfI8JomqFxG8O34z4DuYKk03W2SJsgP4v6TcjEYCOauEnEGRGX1+GFJ9idlO0 MnGj6IlW0x2WWUlf3+crdCscpWjo3MdqNM2g0c7H3TrIoo5CDfiAVhOcv3OGLj22eoFD +SkeSfd5cLJtoLvw2Fu5XfUsqUC3upOD/uAI12Ijq70ppKlSWhLWQCgrZjS/vr6FM20I Gtx7yjS8VWJb1QcFV7hwOdTDh1DRjQGqFIk5BBuGOD+hI4wa4JzOC7agk5/MaxdKjjRU nSbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=udC7E2mdhaDzbGJAhLhKZXb+65Nihv5m57wL/wbMtls=; b=PAT/VLa/7wODSu2WCm2l3B6iKhOP0A8VavaffCmW1qQ6D/gLTwhOEzaRToy4jAR1ZD na36mZwPANS+cK86BUupvW0ncoEBZZ81dfnh2ZbQnEb3/lRCm9T0wEhJsg25qyBlFb3Q 35SmrLBoyKNvFJPy1WB+k7XvmP8YzF38Wok1Vvg3qYxELZU2lcnqexqwj/5mZ2hzhkf0 H951sgWmPm14t2325CVxQSlvm/C9yfunPTz9+oIWRkHG/tCe9b3qVZEszN6HOXmYV7AI FkcJ/WfRTiJrOVZl7DxkeZrpY/B2X0JDk+jB/3jtrs/nDvJSTFzZhRveWqRQmEueAP4B 4XaQ== X-Gm-Message-State: APt69E34LIe8bfw2zNiuqsmjii7pc5uW0v3kUofTZM8baRKSONDsSNdG r547QddD3Ta9zSR3Il9dC07QNUFvF8g27O4//nM= X-Google-Smtp-Source: ADUXVKKEaPabrO6UZIrvFZIreF6TbHd/Oj0Bb58C0OmvOJk5Dy4jeZ29w+kbyRi0nMm+OcdQAn955M6ZJSw/rd0D13c= X-Received: by 2002:a9d:e2a:: with SMTP id c39-v6mr12306943otc.241.1529454555492; Tue, 19 Jun 2018 17:29:15 -0700 (PDT) MIME-Version: 1.0 References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> In-Reply-To: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> From: Martin Thomson Date: Wed, 20 Jun 2018 10:29:06 +1000 Message-ID: Subject: Re: Path forward with stream headers To: Roberto Peon Cc: Mike Bishop , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 00:29:18 -0000 On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon wrote: > However, if one must receive the first packet of each stream, additional HoL blocking (which prevents playback/interpretation) is induced. This is the bit I'm pushing back on. The first byte isn't privileged. There's a push ID, a HEADERS frame, and the start of the first DATA frame before you can start into random access. Without that, you can't know what you are reading. I fail to see how one additional octet is a problem here. From nobody Tue Jun 19 18:44:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D46130E27 for ; Tue, 19 Jun 2018 18:44:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ifrlNT3I5eIE for ; Tue, 19 Jun 2018 18:44:03 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C8D130E5E for ; Tue, 19 Jun 2018 18:44:02 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l25-v6so2007788ioh.12 for ; Tue, 19 Jun 2018 18:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRwEg7OBcIv8FEowca9tThYn2GsL8RMagC1WlOtkoq8=; b=QHPKA/iRam+kjmBEjSxp/DmwHNhX8eKCFcQ5E9l5kGoCbDkx8HuOBrmnDGngfoGiLS I7TOiY+h3LlfokDNj2AtsXxuuzoHPWrGEdikLh6iipEIUmzj0aCiNCis4tPZBYP3Nq0U Sj4s4CrU+38pE0j1tkzJVJgtvylKjfbErTkTlPgX/PhNL/GZyhXJFxcRkLE/iABVQ7IL 2pLedoNd1F9GxS/75ZQAAnnO+IUNA4KxKWky0pi+c+nr5GeCFxooCQAJwYfsD6dokwP6 ootZ/0Rlm/Z10Udk3ouBjULvnAzbdMUajQP4BaZkiEqash17kY79RzZ2vKC5qnL18XfE S7CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jRwEg7OBcIv8FEowca9tThYn2GsL8RMagC1WlOtkoq8=; b=lIPV4LB6dgBwHxgCGEhfOZe67g6HRVGIgKEvISb8uExKd+wWwft7txZdGJST0WLHJW QrXIrkMMZ4iShJv30hJZfpfxERNIDokMcu0dxv8dnTA2w2UZYx1YRpMy/+dQnVO/4ELT 5IRR6REsA31wPJP/v7oAGeLYhrwQ4gP6W8OGbYTBpZiksf/ymK+FKrtTWMe/q/Bp/yw2 DchlPlntwt2s0bQ7Gern7MNfZG2SfOmp/ervCr2gBt5wU4zmShPQCZzGwi47kE1zivit JQwojOPAcUA8Nlatzsjo5tNrMDGTq+Lcv/2NaYATQqBaEiMroRDeRJsaz+kO9jhylk3B fdHw== X-Gm-Message-State: APt69E3B59xgxqKCGUsy1e4GZLXCm9pvSAAwZ9sqUgPXxikH3Uk0CCrq X1kKYUz5xw7p+h4Ep5RrqT5Ai6QJAzSjEz+vybo= X-Google-Smtp-Source: ADUXVKLsi7CmZFH1TcpiQzYMxCavhXq+lYh+909wHruScgiI6d4t250bAtCiNVfYQ03yOsOdj1CehAbH0mI6PQ0VkkQ= X-Received: by 2002:a6b:ba45:: with SMTP id k66-v6mr15477103iof.129.1529459041871; Tue, 19 Jun 2018 18:44:01 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> From: Marten Seemann Date: Wed, 20 Jun 2018 08:43:49 +0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" Cc: Ian Swett , Kazuho Oku , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000e3afb8056f08ee92" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 01:44:08 -0000 --000000000000e3afb8056f08ee92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Manasi, > The risk of disagreement between ack blocks and ack block count is same as the risk of disagreement between ack blocks and ack length. Either way this needs to be counted up while creating the ACK and counted down while parsing it. The possibility of error is the same. Getting the ack block count wrong is as problematic as getting the ack length wrong. Do you agree= ? I disagree. Let's take an example of an ACK frame with one ACK range, that needs a 2 byte varint to represent the First ACK Block and another 2 byte varint to represent the Gap. With your proposal: 1. The values 0 and 1 are invalid, since the length fields itself is included in the length. 2. The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 are invalid, since the length needs to include the Largest Acknowled= ged and the Ack Delay. 3. The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first valid value, and correspond to an ACK frame with no blocks. 4. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, since it would cut the varint for the First ACK Block 5. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, since it would cut the frame after the First ACK Block (but eve= ry block must be followed by a gap length) 6. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, since it would cut the varint for the Gap 7. Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is valid There are *a lot* of invalid values that you can encode into the ACK length field. More importantly, *none* of these error cases exists with the current frame format. The *only* error case that can occur with our current format is that the packet is too short for the number of ACK blocks that are supposed to contained in the frame. This can occur with your proposal as well (in addition to the error cases listed above). My concern is not that it's impossible or even particularly hard to catch these errors, but I dislike the property that some (in fact, most) encodable values are invalid. Best, Marten On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi wrote: > Hi Ian, > > > > Here is another attempt to solve the objections you raised: > > > > >I'm not a fan of this proposal, because I think it is impractical to dro= p > the number of ack blocks, because with the ECN proposal it becomes > impractically complex to parse. > > Is there a reason the proposal from Christian does not solve this problem= ? > > > > >If we don't remove the number of ack blocks, then the ack frame is > larger, but I don't think the extra size field is useful for most > implementations. Also, it means the length can disagree with the actual > length, which add complexity and the possibility of writing error-prone > code. The idea of someone offloading ack processing and then proceeding = to > trust the length seems like someone could get wrong and cause some > concerning issues. > > The risk of disagreement between ack blocks and ack block count is same a= s > the risk of disagreement between ack blocks and ack length. Either way th= is > needs to be counted up while creating the ACK and counted down while > parsing it. The possibility of error is the same. Getting the ack block > count wrong is as problematic as getting the ack length wrong. Do you agr= ee? > > > > >My experience is multithreaded packet processing is more cost and work > than it's worth. Sure you can't fill a 100G NIC with one connection, but > that seems like an academic problem, not one for workloads I've seen. > Typically the extra cost of multithreading outweighs its value. > > The value is two fold =E2=80=93 pre-processing and multi-threading. If we > pre-process the received packets such that ACKs and streams can be > coalesced, the receive side can indicate a large chunk of information > though the kernel, reducing the cost of system call and protocol > overhead. This is the same concept as UDP segmentation taken a step furth= er > on receive side. After this chunk is indicated into the QUIC protocol, th= e > protocol may process stream and ACK in parallel. While folks may or may n= ot > utilize this, there is an advantage here. > > > > Thanks, > > Manasi > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, June 19, 2018 11:26 AM > *To:* Deval, Manasi > *Cc:* Marten Seemann ; Kazuho Oku < > kazuhooku@gmail.com>; Eric Rescorla ; Jana Iyengar < > jri.ietf@gmail.com>; Praveen Balasubramanian ; IETF > QUIC WG ; Martin Thomson > > > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > I'm still not interested in this change, for the reasons I stated above. > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > wrote: > > Hi All, > > > > Do we have agreement here to create a new PR? > > > > Thanks, > > Manasi > > > > *From:* Deval, Manasi > *Sent:* Sunday, June 17, 2018 2:25 PM > *To:* Marten Seemann ; Kazuho Oku < > kazuhooku@gmail.com> > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* RE: Proposal to replace ACK block count with ACK length > > > > Hi All, > > > > I have made a list of objections to the proposal and the solutions to > those objections discussed on this thread. > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > Christian suggested to move the ECN fields to precede the ACK blocks. Thi= s > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits would have been annoying, even though it can work. > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse A= CK to > identify length. There are some reservations when ACK parsing gets harder > for the case where the entire header needs to be parsed. > > > > Agreement from several folks here. In the original ACK defined in draft 1= 2 > of the slide, one would count down number of ACK blocks to get to the end > of the packet. In the proposal I made, one would count down the length to > identify the end of the packet. The logic is very similar in cycle count > and complexity. Several folks also commented to this effect. > > > > c. Multi-threaded packet processing > > > > I would expect that there are 10s of 1000s of connections in use at any > time for a server with a high speed link. Multi-threading to handle each = of > these flows / connections in parallel is necessity to be able to support > large number of connections on a high speed link. Tx segmentation, Rx > coalescing are well known strategies to reduce the processing cost. In > initial stages, code is often written as a single-threaded and then > re-factored to parallelize cycle intensive operations. In order to allow > this protocol to scale in future, I would suggest we do not preclude this > case. > > > > d. Increase in ACK size by 1 byte. > > > > I do not see this as a serious issue but if folks but we can consider > making this a varint, if others have strong feelings about it. It=E2=80= =99s a > trade-off : 2 reads to save 1 byte. > > > > e. Every encodable value should be valid > > Not every length will be valid. This is inherent to lengths. This same > issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue > exist for small values, it also applies to large values since data stream > will be sent after crypto negotiation. E.g. - how does one craft a > payload with 62 bit payload length in a large header? > > > > > > Thanks, > > Manasi > > > > > > *From:* Marten Seemann [mailto:martenseemann@gmail.com > ] > *Sent:* Sunday, June 17, 2018 6:59 AM > *To:* Kazuho Oku > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com>; Deval, Manasi > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the whole > packet, so as long as the packet payload is long enough, the varint parsi= ng > will not fail. > > I don't think that specifics of programming languages matter here though, > and I'm sure both frame formats can be reasonably implemented in C as wel= l > as in Go. The reasons I'm opposed to Manasi's proposal are that it moves = us > away from the principle that only reasonable values should be encodable, > and that it increases the size of the ACK frame, for the questionable > benefit of being able to parallelise the frame parser. > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > > At least for my implementation, parsing doesn't become easier, it becom= es > > more complex with this proposal. My varint-parser always consumes as ma= ny > > bytes as the varint requires, so after parsing a varint, I'd have to > > introduce an additional check that this didn't overflow the ACK length > (e.g. > > consider that I parsed the ACK frame so far that only 2 bytes are > remaining > > according to ACK length field, but the next varint is 4 bytes long). > > Isn't your varint parser checking that it has not (or will not) run > across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun. > > What I am saying that that check could be converted to a overrun check > against the end of the "frame payload", and that checking the > remaining block count becomes unnecessary, in case we replace ACK > Block Count with ACK Frame Length. > > > > > In general, we've been moving the wire image towards making every > encodable > > value valid. This proposal moves us away from that principle: > > * some small values are always invalid (the length can never be between= 0 > > and 3) > > * a lot of intermediate values are invalid (if the boundary falls insid= e > a > > varint, as described above) > > Both these cases can't occur with the current ACK frame format. > > > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: > >> > >> 2018-06-17 8:34 GMT+09:00 Ian Swett > >> : > >> > I'm not a fan of this proposal, because I think it is impractical to > >> > drop > >> > the number of ack blocks, because with the ECN proposal it becomes > >> > impractically complex to parse. > >> > >> For the ECN proposal, as Christian has suggested, we can move the ECN > >> counters before the ACK blocks. Then, it would not be complex to > >> parse. > >> > >> And my view is that parsing becomes easier if we replace ACK Block > >> Count with ACK Frame Length. > >> > >> Now, with ACK Block Count, we need to check the remaining number of > >> blocks and the remaining space in the packet payload for every block > >> that we parse. Failing to check either leads to a bug or a security > >> issue. > >> > >> If we switch to ACK Frame Length, we need to only check the remaining > >> space in the frame. > >> > >> I think that this is the biggest benefit of replacing ACK Block Count > >> with ACK Frame Length. OTOH the downside is that you need extra one to > >> two bits (one if the size of block / gap is expected to be below 65, > >> two if they are expected to be above that) for encoding ACK Frame > >> Length compared to ACK Block Count. > >> > >> > >> > >> Having said that, I honestly wonder if all the frames could have it's > >> length being encoded (either explicitly or either as a signal that > >> says "to the end of the packet"). Consider something like below: > >> > >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >> or > >> |1| frame-type (7) | frame-payload (*) | > >> > >> When MSB of the first octet set to zero, the length of the frame > >> payload is designated by the varint that immediately follows the frame > >> type. > >> When MSB of the first octet set to one, the length of the frame > >> payload spans to the end of the packet. > >> > >> In this encoding, we can always omit the Length field of a STREAM > >> frame. So the overhead for carrying stream data will be indifferent in > >> practice. > >> > >> For the ACK frame, we can omit the ACK Block Count field. And the > >> overhead will be one to two bits if the ACK frame is sent in the > >> middle of the packet (thereby using the encoding with explicit frame > >> payload length), or one octet or more shorter if ACK is the last frame > >> of the packet. > >> > >> We are likely to see increase of overhead for most of the other types > >> of frames, but I do not think that would be an issue considering that > >> they will be far seldom seen compared to STREAMs and ACKs. > >> > >> To summarize, my anticipation is that we can make all the frames > >> self-contained (i.e. the length can be determined without the > >> knowledge of how each frame is encoded) without any overhead, if we > >> agree on making the frame type space 1 bit smaller. > >> > >> Finally, the biggest benefit of using a self-contained encoding of > >> frames is that we would have the ability to introduce new optional > >> frames without negotiation. By making the frames self-contained, QUIC > >> endpoints will have the freedom of ignoring the frames that they do > >> not understand. > >> > >> Being able to send QUIC frames defined in extensions without > >> negotiating using Transport Parameters will be a win in both terms of > >> security (because clients' TP is sent in clear) and flexibility > >> (because we will be possible to send the extensions before we figure > >> out whether the peer supports that extension). > >> > >> > If we don't remove the number of ack blocks, then the ack frame is > >> > larger, > >> > but I don't think the extra size field is useful for most > >> > implementations. > >> > Also, it means the length can disagree with the actual length, which > add > >> > complexity and the possibility of writing error-prone code. The ide= a > of > >> > someone offloading ack processing and then proceeding to trust the > >> > length > >> > seems like someone could get wrong and cause some concerning issues. > >> > > >> > My experience is multithreaded packet processing is more cost and wo= rk > >> > than > >> > it's worth. Sure you can't fill a 100G NIC with one connection, but > >> > that > >> > seems like an academic problem, not one for workloads I've seen. > >> > Typically > >> > the extra cost of multithreading outweighs its value. > >> > > >> > To be clear, I don't think this is an awful idea, but I also don't s= ee > >> > the > >> > value and it adds complexity. I read Manasi's email, but I don't > think > >> > I > >> > understand why any of those matter in practice. > >> > > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >> >> > >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >> >> > >> >> wrote: > >> >>> > >> >>> This proposal increases the size of the ACK frame by 1 byte in the > >> >>> common > >> >>> case (less than 63 ACK ranges), since the ACK length field here > always > >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length > >> >>> integer. > >> >>> Considering how much work we put into minimising the size of the > >> >>> frames, > >> >>> this feels like a step in the wrong direction.. > >> >>> > >> >>> Regarding the processing cost, I agree with Dmitri. Handling an AC= K > >> >>> frame > >> >>> requires looping over and making changes to a data structure that > >> >>> keeps > >> >>> track of sent packets. This is much more expensive than simply > parsing > >> >>> a > >> >>> bunch of varints in the ACK frame. It seems unlikely that a > >> >>> multi-threaded > >> >>> packet parser would offer any real-world performance benefits. > >> >> > >> >> > >> >> I don't want to overstate the benefit here, but my point isn't that > >> >> parsing is expensive but that if you want to have a multithreaded > >> >> packet > >> >> processing system, then it's nice to have a simpler data structure > (the > >> >> unparsed ACK block) to hand to the ACK processing thread. > >> >> > >> >> -Ekr > >> >> > >> >> > >> >>> > >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> When we discussed this before, some people observed that this > creates > >> >>>> a need to encode in two passes. That's the trade-off here. (Not > >> >>>> expressing an opinion.) > >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >> >>>> wrote: > >> >>>> > > >> >>>> > I don't have a strong opinion on this. I'm certainly not oppose= d > to > >> >>>> > it. > >> >>>> > Does anyone have a strong opposition? > >> >>>> > > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> I agree as well since this can help reduce per packet processi= ng > >> >>>> >> overhead. ACKs are going to be the second most common frame ty= pe > >> >>>> >> so no > >> >>>> >> objections to special casing. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >> >>>> >> Rescorla > >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >> >>>> >> To: Deval, Manasi > >> >>>> >> Cc: Jana Iyengar ; QUIC WG > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> I agree with Manasi here. This change would allow ack frame > >> >>>> >> parsing > >> >>>> >> to be more self-contained, which is an advantage for the parse= r > >> >>>> >> and also > >> >>>> >> potentially for parallelism (because you can quickly find the > >> >>>> >> frame and then > >> >>>> >> process it in parallel). > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> -Ekr > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> In general, varints require some specific logic for parsing. T= o > >> >>>> >> skip > >> >>>> >> over any header, I have to read every single varint. As the co= de > >> >>>> >> sees Stream > >> >>>> >> and ACK headers most frequently, that is my focus. The Stream > >> >>>> >> frame has a > >> >>>> >> length in its third field. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify > >> >>>> >> length. There are two reads each for =E2=80=98largest acknowle= dged=E2=80=99, > =E2=80=98ACK > >> >>>> >> delay=E2=80=99 and > >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total= number of cycles > >> >>>> >> parse an > >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packet= s > >> >>>> >> have a > >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck= . > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> > >> >>>> >> Manasi > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >> >>>> >> Iyengar > >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >> >>>> >> To: Deval, Manasi ; QUIC WG > >> >>>> >> > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> You're right that we no longer have the ability to skip an ACK > >> >>>> >> frame, > >> >>>> >> and this crept in when we moved to varints. > >> >>>> >> > >> >>>> >> I believe your problem though is generally true of most frames > not > >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frame= s > >> >>>> >> are now all > >> >>>> >> varints. To skip any frame, you'll need to parse the varint > fields > >> >>>> >> in those > >> >>>> >> frames. If you have logic to process and skip varints, then > >> >>>> >> skipping the ack > >> >>>> >> block section is merely repeating this operation (2*num_block+= 1) > >> >>>> >> times. Do > >> >>>> >> you see specific value in skipping ACK frames over the other > >> >>>> >> control frames? > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >> >>>> >> > - Moving the ACK length to the front of the ACK allow= s > >> >>>> >> > the > >> >>>> >> > flexibility of either reading the entire ACK or > reading > >> >>>> >> > the > >> >>>> >> > first 16 bits and skipping over the length. This is= a > >> >>>> >> > useful > >> >>>> >> > feature for the case where ACK processing is split > into > >> >>>> >> > multiple layers. Depending on the processor this is > run > >> >>>> >> > on, > >> >>>> >> > there are different advantages - > >> >>>> >> > >> >>>> >> Just a note. In my experience, the cost of parsing an ACK fra= me > >> >>>> >> is > >> >>>> >> negligible compared to the cost of processing an ACK frame: th= at > >> >>>> >> is, > >> >>>> >> poking at various memory locations to discard newly ACKed > packets. > >> >>>> >> > >> >>>> >> - Dmitri. > >> >>>> >> > >> >>>> >> > >> >>>> > >> >> > >> > > >> > >> > >> > >> -- > >> Kazuho Oku > > > > -- > Kazuho Oku > > --000000000000e3afb8056f08ee92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Manasi,

>=C2=A0T= he risk of disagreement between ack blocks and ack block count is same as t= he risk of disagreement between ack blocks and ack length. Either way this = needs to be counted up while creating the ACK and counted down while parsin= g it. The possibility of error is the same. Getting the ack block count wro= ng is as problematic as getting the ack length wrong. Do you agree?

I disagree. Let's take an exam= ple of an ACK frame with one ACK range, that needs a 2 byte varint to repre= sent the First ACK Block and another 2 byte varint to represent the Gap.
With your proposal:
  1. The values 0= and 1 are invalid, since the length fields itself is included in the lengt= h.
  2. The values 2, 3, ..., (2 + len(LargestAc= knowledged) +=C2=A0len(AckDelay)) - 1 are invalid, since the length needs t= o include the Largest Acknowledged and the Ack Delay.
  3. The value=C2=A02 + len(LargestAcknowledged) +=C2=A0len(AckDelay) would be the first valid value, an= d correspond to an ACK frame with no blocks.
  4. The value 2 + l= en(LargestAcknowledged) +=C2=A0len(AckDelay= )=C2=A0+ 1 is invalid, since it would cut the varint for the First A= CK Block
  5. The value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 2 is invalid, since it would cut t= he frame after the First ACK Block (but every block must be followed by a g= ap length)
  6. The value 2 + len= (LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 3 is invalid, since it wo= uld cut the varint for the Gap
  7. Finally, the value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)= =C2=A0+ 4=C2=A0is valid
There are= *a lot* of invalid values that you can encode into the ACK length field. M= ore importantly, *none* of these error cases exists with the current frame = format.=C2=A0
The *only* error case that = can occur with our current format is that the packet is too short for the n= umber of ACK blocks that are supposed to contained in the frame. This can o= ccur with your proposal as well (in addition to the error cases listed abov= e).

My concern is not that it's impossible or even particularly har= d to catch these errors, but I dislike the property that some (in fact, mos= t) encodable values are invalid.

Best,
Mart= en


On Wed, Jun 20, 2018 at 3:21 AM Deval, Ma= nasi <manasi= .deval@intel.com> wrote:

Hi Ian,

=C2=A0

Here is another attempt to solve the = objections you raised:

=C2=A0

>I'm not a fan of this proposa= l, because I think it is impractical to drop the number of ack blocks, beca= use with the ECN proposal it becomes impractically complex to parse.

Is there a reason the proposal from Christian does= not solve this problem?

=C2=A0

>If we don't remove the number= of ack blocks, then the ack frame is larger, but I don't think the ext= ra size field is useful for most implementations.=C2=A0 Also, it means the length can disagree with the actual length, which add complex= ity and the possibility of writing error-prone code.=C2=A0 The idea of some= one offloading ack processing and then proceeding to trust the length seems= like someone could get wrong and cause some concerning issues.

The risk of disagreement between ack blocks and ac= k block count is same as the risk of disagreement between ack blocks and ac= k length. Either way this needs to be counted up while creating the ACK and counted down while parsing it. Th= e possibility of error is the same. Getting the ack block count wrong is as= problematic as getting the ack length wrong. Do you agree?

=C2=A0

>My experience is multithreaded pa= cket processing is more cost and work than it's worth.=C2=A0 Sure you c= an't fill a 100G NIC with one connection, but that seems like an academic problem, not one for workloads I've seen.=C2=A0 Typically = the extra cost of multithreading outweighs its value.<= /p>

The value is two fold =E2=80=93 pre-processing and= multi-threading. If we pre-process the received packets such that ACKs and= streams can be coalesced, the receive side can indicate a large chunk of information though the= kernel, reducing the cost of system call and protocol overhead. This is the same concept as UDP segmentation taken a st= ep further on receive side. After this chunk is indicated into the QUIC pro= tocol, the protocol may process stream and ACK in parallel. While folks may= or may not utilize this, there is an advantage here. =C2=A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com= ]
Sent: Tuesday, June 19, 2018 11:26 AM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <kazuhooku@gmail.com>; = Eric Rescorla <ekr@rtf= m.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com&= gt;; IETF QUIC WG <qu= ic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>


Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

I'm still not interested in this change, for the= reasons I stated above.

=C2=A0

On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi All,

=C2=A0

Do we have agreement here to create a= new PR?

=C2=A0

Thanks,

Manasi

=C2=A0

From: Deval, Manasi
Sent: Sunday, June 17, 2018 2:25 PM
To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <kazuhooku@gmail.com> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorl= a <ekr@rtfm.com>= ;; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= ;martin.thoms= on@gmail.com>
Subject: RE: Proposal to replace ACK block count with ACK length

=C2=A0

Hi All,

=C2=A0

I have made a list of objections to t= he proposal and the solutions to those objections discussed on this thread.

=C2=A0

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Co-existence of length field with ECN field and ACK b= locks.

=C2=A0

Christian suggested to move the ECN field= s to precede the ACK blocks. This is an elegant solution. Parsing entire li= st of ACK blocks to review ECN bits would have been annoying, even though it can work.

=C2=A0

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two cases to be parsed =E2=80=93 entire ACK= and parse ACK to identify length. There are some reservations when ACK par= sing gets harder for the case where the entire header needs to be parsed.

=C2=A0

Agreement from several folks here. In the= original ACK defined in draft 12 of the slide, one would count down number= of ACK blocks to get to the end of the packet. In the proposal I made, one would count d= own the length to identify the end of the packet. The logic is very similar= in cycle count and complexity. Several folks also commented to this effect= .

=C2=A0

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multi-threaded packet processing

=C2=A0

I would expect that there are 10s of 1000= s of connections in use at any time for a server with a high speed link. Mu= lti-threading to handle each of these flows / connections in parallel is necessity to be ab= le to support large number of connections on a high speed link. Tx segmenta= tion, Rx coalescing are well known strategies to reduce the processing cost= . In initial stages, code is often written as a single-threaded and then re-factored to parallelize cycle int= ensive operations. In order to allow this protocol to scale in future, I wo= uld suggest we do not preclude this case.

=C2=A0

d.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Increase in ACK size by 1 byte.<= /p>

=C2=A0

I do not see this as a serious issue but = if folks but we can consider making this a varint, if others have strong fe= elings about it. It=E2=80=99s a trade-off : 2 reads to save 1 byte.

=C2=A0

e.<= /span>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Every encodable value should be valid<= /span>

Not= every length will be valid. This is inherent to lengths. This same issue a= ils the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does the = issue exist for small values, it also applies to large values since data stream will be sent after crypt= o negotiation.=C2=A0 E.g. =C2=A0- how does one craft a payload with 62 bit = payload length in a large header?

=C2=A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: Marten Seemann [mailto:martenseemann@gmail.c= om]
Sent: Sunday, June 17, 2018 6:59 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; E= ric Rescorla <ekr@rtfm= .com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= ;martin.thoms= on@gmail.com>; Deval, Manasi <manasi.deval@intel.com>
Subject: Re: Proposal to replace ACK block count with ACK length

=C2=A0

Maybe it's specific to Go, but I'm using a s= ingle io.Reader for the whole packet, so as long as the packet payload is l= ong enough, the varint parsing will not fail.

I don't think that specifics of programming lang= uages matter here though, and I'm sure both frame formats can be reason= ably implemented in C as well as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us away from the principle that= only reasonable values should be encodable, and that it increases the size= of the ACK frame, for the questionable benefit of being able to parallelis= e the frame parser.

=C2=A0

On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com= > wrote:

2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.= com>:
> At least for my implementation, parsing doesn't become easier, it = becomes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have = to
> introduce an additional check that this didn't overflow the ACK le= ngth (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every = encodable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format. >
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is imp= ractical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>=C2=A0 or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibilit= y
>> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack= frame is
>> > larger,
>> > but I don't think the extra size field is useful for most=
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.= =C2=A0 The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with= one connection, but
>> > that
>> > seems like an academic problem, not one for workloads I'v= e seen.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I a= lso don't see
>> > the
>> > value and it adds complexity.=C2=A0 I read Manasi's email= , but I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my po= int isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler d= ata structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.=C2=A0 That's = the trade-off here.=C2=A0 (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I= 'm certainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.=C2=A0 The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*num_bl= ocks reads to identify
>> >>>> >> length. There are two reads each for =E2= =80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>> >>>> >> delay=E2=80=99 and
>> >>>> >> =E2=80=98ACK block count=E2=80=99. The p= ain point is the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have = the ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll n= eed to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wrote: >> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000= , Deval, Manasi wrote:
>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= eature for the case where ACK processing is split into
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.=C2=A0 In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku

--000000000000e3afb8056f08ee92-- From nobody Tue Jun 19 23:24:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6509C130E39 for ; Tue, 19 Jun 2018 23:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 DY2KbEKVMtYa for ; Tue, 19 Jun 2018 23:24:13 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 F22F61292F1 for ; Tue, 19 Jun 2018 23:24:12 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id j135-v6so3967348itj.1 for ; Tue, 19 Jun 2018 23:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=BpRBmmiBkTdS5B1+bP7wI+JjGJGHUxYl+u8SSF8O7qk=; b=ZVNP01Jo8cbqz+vvmsJDlnVRb0GCP0+Pv3gjH+mcfXVg2skEIow8UAs6SPSoSGO9p2 W2IlEiOTfzcFvYTvRHNqHT5CKuS/ANm3iTAes3bvJK3usJXTNl9MTQzPp61GX+jeu+sU PbeJLoNkr3/OeQ0/UDreoKYfLQ5SdnbvmkGxO8FNANXkSOvIcCyrAlhqminO39pDe5kJ V07mfuklSrmYLAPdoZlKJ6poObPzBcVwuv5lszfAaYpKh2RU0826t56YrXlFg43nywWF 9N2MWh4LWtT4qhdNAQU30TjCfWn97q1dVz6xV2/i+vCuGK9NxMERw+8cZbr4akZObwU/ RnQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=BpRBmmiBkTdS5B1+bP7wI+JjGJGHUxYl+u8SSF8O7qk=; b=qXJ8s9NNtwv66ziQTgvSf/gJsVhr6XXrmzmhizVpwTBLwDKSTIU8Da7ih1giO56Ftx K+JHqlXCDVsZ9AbptG9lRWAFIYrrfd2OFK/oWPBN2Jg/xH7o1+CPI3FwCw2hWCTpQ/+j W4edh1DJ+wAyMVSN5UvgmAUx8R0+lyQQ1Uqeg6j4g/wqLFO4Nn2AKITI/oXMCTQ+O6Wl Z6RKYZ5ro075Ur8vEH1RnsaN3If8DHEL4d+euCTra9Um6lJEmpwraY2Fh9nPFtpxeaoU /5kyNWuv2YVV5lnyGeCD/JpjqrK/n7woS+Pzh5LxVgXcuH0oPF6CQI78TEhMzMhyPntW DuEw== X-Gm-Message-State: APt69E1ts1t0Hj167eQ79HivVoic3C9iWk9BtjI6lUyLJ6XNZaTKNIQD lbVMeDl8k/aFzBJcyEg5f7wnTU+G3AIAxwxDKlo= X-Google-Smtp-Source: AAOMgpecDEMVkTz50QhNQQIPgZEfdBJywvG/gLrN7+CvF4AWRQANze8b8oViS9uUvx1TG+O7eUa/xlaUTCeQ94qDW7Q= X-Received: by 2002:a24:5e82:: with SMTP id h124-v6mr546386itb.80.1529475852388; Tue, 19 Jun 2018 23:24:12 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 20 Jun 2018 06:24:11 +0000 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 20 Jun 2018 06:24:11 +0000 Message-ID: Subject: Re: Path forward with stream headers To: Martin Thomson , Roberto Peon Cc: Mike Bishop , QUIC WG Content-Type: multipart/alternative; boundary="000000000000dfd5fa056f0cd88a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 06:24:15 -0000 --000000000000dfd5fa056f0cd88a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Martin says the first byte isn=E2=80=99t that special. However, the fram= e might be delivered with an empty. More generally in QUIC, it could be useful to have an API guarantee that the first N bytes delivered to a frame are not fragmented, where N is a reasonable limit, like 8 bytes and that retransmission does not fragment that section. This would not prevent out of order delivery of later frames but it greatly simplifies adding custom headers to a stream. A recent change permitted sending empty frame headers without FIN bit, which I think is fine, but if the application asks for 0..8 bytes to be atomic, I think that would be useful too. If nothing else as a substitute for atomic message frames. On 20 June 2018 at 02.29.32, Martin Thomson (martin.thomson@gmail.com) wrote: On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon wrote: > However, if one must receive the first packet of each stream, additional HoL blocking (which prevents playback/interpretation) is induced. This is the bit I'm pushing back on. The first byte isn't privileged. There's a push ID, a HEADERS frame, and the start of the first DATA frame before you can start into random access. Without that, you can't know what you are reading. I fail to see how one additional octet is a problem here. --000000000000dfd5fa056f0cd88a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = As Martin says the f= irst byte isn=E2=80=99t that special. However, the frame might be delivered= with an empty.

More = generally in QUIC, it could be useful to have an API guarantee that the fir= st N bytes delivered to a frame are not fragmented, where N is a reasonable= limit, like 8 bytes and that retransmission does not fragment that section= .

<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">This would not prev= ent out of order delivery of later frames but it greatly simplifies adding = custom headers to a stream.

A recent change permitted sending empty frame headers without FIN bi= t, which I think is fine, but if the application asks for 0..8 bytes to be = atomic, I think that would be useful too. If nothing else as a substitute f= or atomic message frames.

On 20 June 2018= at 02.29.32, Martin Thomson (m= artin.thomson@gmail.com) wrote:

On Wed, Jun 20, 2018 at 10:21 AM Rober= to Peon <fenix@fb.com> wrote:
> However, if one must receive the first packet of each stream, addi= tional HoL blocking (which prevents playback/interpretation) is induced.

This is the bit I'm pushing back on. The first byte isn't priv= ileged.
There's a push ID, a HEADERS frame, and the start of the first DATA
frame before you can start into random access. Without that, you
can't know what you are reading. I fail to see how one additional
octet is a problem here.

--000000000000dfd5fa056f0cd88a-- From nobody Wed Jun 20 02:26:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AED131063 for ; Wed, 20 Jun 2018 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sID4yrt46ev6 for ; Wed, 20 Jun 2018 02:26:30 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2E7124BE5 for ; Wed, 20 Jun 2018 02:26:29 -0700 (PDT) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5K9QKTW016527; Wed, 20 Jun 2018 10:26:20 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) with mapi id 14.03.0389.001; Wed, 20 Jun 2018 10:26:19 +0100 From: Lucas Pardue To: Martin Thomson , Roberto Peon CC: QUIC WG , Mike Bishop Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAQ6RgIAACWUAgAACQQD//12OIA== Date: Wed, 20 Jun 2018 09:26:19 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB57E48@bgb01xud1012> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23918.005 x-tm-as-result: No-14.349700-8.000000-10 x-tmase-matchedrid: xcONGPdDH5q7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p2HwGEm+CpYGf8L rlgUVepk23e6ga05TafUw09eu4b0WK0ZS7JYIH8qTVa+L3Zgqc7IGHrVFGApflSOymiJfTYXEDX nfhaIDBbCwCFdlZnIFr8hoaHdEEfqDRnS4uw63fD7IK6Q1+r9nu6vBRO2P4iNW+jwVKpqvlIAKi VXSMAOPU1i8No7236cNYYFTQ0sf/fsrfmvTLX/no1nuRzhSr7jll6sbwG1OHJrKNt7ipQiY5g1+ tpX7uJKI8+3Tr0jNDSM9QcQn/pjfgi0xaFtKyGqpFf2dGv7wxuK6IJmwLQESFJxdAzF6l77bLmh E9P+CcUNUGFvbBSGNZ3Qs5sK78d4ZLv1EPvn0C+TEgTE0DYkgJC6w7+sMxqP6NfipxutJCfAHyD M1D54TozIgBPIhs6ZSPgkq1IMgi0YB2fOueQzjxRFJJyf5BJeov6oNokdHvRMgzLPB1Mutg== x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--14.349700-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23918.005 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 09:26:32 -0000 SSBhZ3JlZSB3aXRoIE1hcnRpbi4gSG93ZXZlciwgdG8gdGhpbmsgYXJvdW5kIHRoZSB0b3BpYyBh IGxpdHRsZSwgdGhlIHRlbGxpbmcgcHJvYmxlbSBpcyB0aGF0IHdlIHdhbnQgdHdvIHRoaW5nczog YSBzdHJlYW0gd2l0aCBtZWFuaW5nIG90aGVyIHRoYW4gYmlkaXJlY3Rpb25hbCByZXF1ZXN0L3Jl c3BvbnNlLCBhbmQgdG8gcmV1c2UgdGhlIGZyYW1lcyAoSEVBREVSUyBhbmQgREFUQSkgYXNzb2Np YXRlZCB3aXRoIHJlcXVlc3QvcmVzcG9uc2UuIFRoaXMgbGVhZHMgdG8gaGF2aW5nIHRvIGFkZCB0 aGUgcHVzaCBJRCB0byB0aGUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtIGhlYWRlci4NCg0KU28gaGVy ZSdzIGEgY2FuZGlkYXRlIHByb3Bvc2FsOg0KDQpSZW1vdmUgdGhlIHB1c2ggSUQgZnJvbSB0aGUg c3RyZWFtIGhlYWRlciBhbmQgcHV0IGl0IGEgbmV3IFBVU0hfSEVBREVSUyBmcmFtZSAobm90aWNl IHRoZSBzaW1pbGFyaXR5IHRvIFBVU0hfUFJPTUlTRSk6DQoNCiAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgUHVzaCBJRCAoaSkg ICAgICAgICAgICAgICAgICAgICAgICAuLi4NCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAg ICAgICAgICAgICBIZWFkZXIgQmxvY2sgKCopICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4OiBQVVNIX0hFQURFUlMgZnJh bWUgcGF5bG9hZA0KDQogICBUaGUgcGF5bG9hZCBjb25zaXN0cyBvZjoNCg0KICAgUHVzaCBJRDog IEEgdmFyaWFibGUtbGVuZ3RoIGludGVnZXIgdGhhdCBpZGVudGlmaWVzIHRoZSBzZXJ2ZXIgcHVz aA0KICAgICAgdGhhdCB0aGlzIGlzIGEgcmVzcG9uc2UgdG8uDQoNCiAgIEhlYWRlciBCbG9jazog IFFQQUNLLWNvbXByZXNzZWQgcmVzcG9uc2UgaGVhZGVycy4NCiAgICAgU2VlIFtRUEFDS10gZm9y IG1vcmUgZGV0YWlscy4NCg0KVGhpcyBzaGlmdHMgdGhlIHByb2JsZW0gb2YgcmVvcmRlcmluZyBm cm9tIHN0cmVhbSBieXRlIHBvc2l0aW9uIG1vcmUgdG93YXJkcyB0aGUgSFRUUCBNZXNzYWdlIEV4 Y2hhbmdlIHNlcXVlbmNlIGRlZmluZWQgaW4gMy4yLg0KDQpMdWNhcw0KDQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj5TZW50OiAyMCBKdW5lIDIwMTggMDE6MjkN Cj5UbzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQo+Q2M6IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+DQo+U3ViamVjdDogUmU6 IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzDQo+DQo+T24gV2VkLCBKdW4gMjAsIDIw MTggYXQgMTA6MjEgQU0gUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+IHdyb3RlOg0KPj4gSG93 ZXZlciwgaWYgb25lIG11c3QgcmVjZWl2ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3RyZWFt LCBhZGRpdGlvbmFsIEhvTA0KPmJsb2NraW5nICh3aGljaCBwcmV2ZW50cyBwbGF5YmFjay9pbnRl cnByZXRhdGlvbikgaXMgaW5kdWNlZC4NCj4NCj5UaGlzIGlzIHRoZSBiaXQgSSdtIHB1c2hpbmcg YmFjayBvbi4gIFRoZSBmaXJzdCBieXRlIGlzbid0IHByaXZpbGVnZWQuDQo+VGhlcmUncyBhIHB1 c2ggSUQsIGEgSEVBREVSUyBmcmFtZSwgYW5kIHRoZSBzdGFydCBvZiB0aGUgZmlyc3QgREFUQSBm cmFtZQ0KPmJlZm9yZSB5b3UgY2FuIHN0YXJ0IGludG8gcmFuZG9tIGFjY2Vzcy4gIFdpdGhvdXQg dGhhdCwgeW91IGNhbid0IGtub3cgd2hhdA0KPnlvdSBhcmUgcmVhZGluZy4gIEkgZmFpbCB0byBz ZWUgaG93IG9uZSBhZGRpdGlvbmFsIG9jdGV0IGlzIGEgcHJvYmxlbSBoZXJlLg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUt bWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZA0KbWF5IGNvbnRh aW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJCQyB1bmxl c3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluDQplcnJv ciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBv ciBkaXNjbG9zZSB0aGUNCmluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5j ZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5Lg0KUGxlYXNlIG5vdGUg dGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFpbHMNCnNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVy IGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0bw0KdGhpcy4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Wed Jun 20 05:49:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322D127332 for ; Wed, 20 Jun 2018 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 wnU7oWxgmx3D for ; Wed, 20 Jun 2018 05:49:08 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 83B19130E6C for ; Wed, 20 Jun 2018 05:49:08 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 579E53A042 for ; Wed, 20 Jun 2018 08:49:07 -0400 (EDT) Received: by mail-oi0-f43.google.com with SMTP id e8-v6so2901606oii.2 for ; Wed, 20 Jun 2018 05:49:07 -0700 (PDT) X-Gm-Message-State: APt69E2pfRj9KgTPlOCND8FLnxIfgditoFIpXfjASFAgbImnTbsIZics CsHM4GzwvKjLcv7+RpZ/IdDyT+e0BQmVXvJAYrI= X-Google-Smtp-Source: ADUXVKKJURqAU9oPiE64YBvrfYQgI23T6huwiGmvMrwVo42hEU77K+TGYh/GrF8ySBjwe4G7WnVub66HjXFEMtzf5SE= X-Received: by 2002:aca:d7d6:: with SMTP id o205-v6mr10981594oig.347.1529498947034; Wed, 20 Jun 2018 05:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 05:49:06 -0700 (PDT) In-Reply-To: References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> From: Patrick McManus Date: Wed, 20 Jun 2018 08:49:06 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Path forward with stream headers To: Martin Thomson Cc: Roberto Peon , QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="0000000000006c25ee056f12398b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 12:49:11 -0000 --0000000000006c25ee056f12398b Content-Type: text/plain; charset="UTF-8" I'm sensitive to Roberto's point about in-order being an API property and not a protocol property. I think hq has a future there. otoh, the winning argument here seems to be that this only impacts the first frame of the stream and there is a tendency to put other stateful/routeful things in there anyhow - so the impact is small for any reasonably sized stream.. and one message per stream models are probably getting their out-of-orderness between streams instead of intra-message anyhow. so I'm in the pro camp. On Tue, Jun 19, 2018 at 8:29 PM, Martin Thomson wrote: > On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon wrote: > > However, if one must receive the first packet of each stream, additional > HoL blocking (which prevents playback/interpretation) is induced. > > This is the bit I'm pushing back on. The first byte isn't privileged. > There's a push ID, a HEADERS frame, and the start of the first DATA > frame before you can start into random access. Without that, you > can't know what you are reading. I fail to see how one additional > octet is a problem here. > > --0000000000006c25ee056f12398b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sensitive to Roberto's point about in-ord= er being an API property and not a protocol property. I think hq has a futu= re there.

otoh, the winning argument here seems to= be that this only impacts the first frame of the stream and there is a ten= dency to put other stateful/routeful things in there anyhow - so the impact= is small for any reasonably sized stream.. and one message per stream mode= ls are probably getting their out-of-orderness between streams instead of i= ntra-message anyhow.

so I'm in the pro camp.



<= div class=3D"gmail_quote">On Tue, Jun 19, 2018 at 8:29 PM, Martin Thomson <= span dir=3D"ltr"><martin.thomson@gmail.com> wrote:
On Wed, Jun 20, 2018 at 10:21 AM Roberto Peo= n <fenix@fb.com> wrote:
> However, if one must receive the first packet of each stream, addition= al HoL blocking (which prevents playback/interpretation) is induced.

This is the bit I'm pushing back on.=C2=A0 The first byte isn= 9;t privileged.
There's a push ID, a HEADERS frame, and the start of the first DATA
frame before you can start into random access.=C2=A0 Without that, you
can't know what you are reading.=C2=A0 I fail to see how one additional=
octet is a problem here.


--0000000000006c25ee056f12398b-- From nobody Wed Jun 20 09:32:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C272130E8C for ; Wed, 20 Jun 2018 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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=evequefou.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 dlDxl-415M0f for ; Wed, 20 Jun 2018 09:31:57 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680110.outbound.protection.outlook.com [40.107.68.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768B5126F72 for ; Wed, 20 Jun 2018 09:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hvDo89dXvV8sMCWrD57Ixb/iz7rruIv1WA6pc7BPRjA=; b=RptPM7b25D+UFFEFeKLkCawgqcRU87+5hH8EZTxuriNq2BrNH+F3tFi6iEu3HAp9SXfCcJsvQjO4gjmFBsJV4rOLGmnqjYHjyKsMfdRyoG0E0T/nYhAb+uMja84HLogMFQi4PEpVl3eT5ds6RzuUY3728ttxFBqbTNJi4wEePYM= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4184.namprd08.prod.outlook.com (20.176.250.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 16:31:55 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 16:31:55 +0000 From: Mike Bishop To: Martin Thomson , Roberto Peon CC: QUIC WG Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsAgAB3mgD//vSUkA== Date: Wed, 20 Jun 2018 16:31:55 +0000 Message-ID: References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4184; 7:C8uBFWnNaXcsp2mcOjVaKfa7r3hHGNeU8ekWymuFWYPndMKT93okvs3tageF975efQmWsExcZxUPNNusNmDAjK9b7Kcr7J5fQ8S5FXafa92g1vD3ATzpegY6/uUOHZUIlharrnAQjCizGdiIo9W1i39VQAbChnRbY4qhuSgphohMzYb4Ajg20ZF67Jm6kY6jYzEvGUeGBDD0w7UerjXMZo8d6UXYbQRQV9c7lZRiuziSGTUfZbHBDrDDqhbuf+8I x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 71e643a3-9d0c-4cbf-bc4f-08d5d6cb562d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4184; x-ms-traffictypediagnostic: BYAPR08MB4184: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123560045)(2016111802025)(20161123558120)(20161123564045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4184; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4184; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39830400003)(396003)(346002)(376002)(366004)(199004)(189003)(13464003)(81166006)(81156014)(53546011)(97736004)(59450400001)(6506007)(3846002)(74482002)(26005)(102836004)(99286004)(229853002)(7696005)(486006)(76176011)(68736007)(6116002)(4326008)(74316002)(7736002)(5660300001)(25786009)(790700001)(8936002)(5250100002)(6246003)(53936002)(8676002)(39060400002)(316002)(478600001)(33656002)(110136005)(2900100001)(86362001)(3660700001)(446003)(55016002)(186003)(3280700002)(6306002)(236005)(6436002)(54896002)(9686003)(14454004)(476003)(11346002)(106356001)(93886005)(105586002)(66066001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4184; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: j9LNgkE2ZhAsPJ2YCOrLy+SnEyxm02Mpk3aai/L7fFv7OKDoj5loFMdZYydRHuc8Q2dZhjSFoHhi9DHbo+rV6Y4wB4F+BuFoaom730gAWEEWWwTRyj7towEwe0CtbEAJdT/Naw9o6uPJ4B68NETIYYMsU32jnZd1WJ4ayyricjZ+D3JSGcO5LXAYZHOSz9SRPniBDdIkZia9HUSzxuZIcChIuq83WQ+lkzWXogPbvNd/OtPh+Etvma6VsYunGUBkqjSj3j4Y5fPl/BWPukTUdHjAcZmD1m2GjT0fewulz4xcL1r8IrK5s5sMtJNHkoxyLemNWDz5UdIDunbjXVsyiA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944A7F25A5940057CCFF6F0DA770BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 71e643a3-9d0c-4cbf-bc4f-08d5d6cb562d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 16:31:55.3735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4184 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:32:02 -0000 --_000_BYAPR08MB3944A7F25A5940057CCFF6F0DA770BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gIFRoaXMgaXMgYWxyZWFkeSBhIHByb3BlcnR5IG9mIHVzaW5nIGZyYW1lcy4gIEp1 c3QgbGlrZSB0aGUgdmlkZW8gaXRzZWxmIGNvbnNpc3Rpbmcgb2YgYm90aCBzdHJ1Y3R1cmUgYW5k IGNvbnRlbnQsIHlvdSBoYXZlIHRvIGZpbmQgdGhlIGZyYW1lIGhlYWRlciAoYW5kIHRoZXJlZm9y ZSBpdHMgbGVuZ3RoKSBmaXJzdC4gIE9uY2UgeW91IGhhdmUgdGhhdCwgeW91IGNhbiBkbyB0d28g dGhpbmdzOg0KDQogICogICBSYW5kb20gYWNjZXNzIGFueXdoZXJlIHdpdGhpbiB0aGF0IGZyYW1l DQogICogICBMb2NhdGUgdGhlIGhlYWRlciBvZiB0aGUgbmV4dCBmcmFtZSBhbmQgYmVnaW4gaW50 ZXJwcmV0aW5nIGl0LCBpZiB0aGF04oCZcyByZWNlaXZlZCBmaXJzdA0KDQoNCg0KSG93ZXZlciwg cmVtb3ZpbmcgYmxvY2tpbmcgb24gdGhlIGZyYW1lIGhlYWRlciBlbnRpcmVseSBpcyBhIHByZXR0 eSBzdWJzdGFudGlhbCBjaGFuZ2UgKGFuZCBwcm9iYWJseSBsb29rcyBhIGxvdCBsaWtlIEhUVFAv UVVJQyAtMDEgb3Igc28sIHdpdGggYSBkZWRpY2F0ZWQgc3RyZWFtIGZvciBkYXRhKS4gIEkgZG9u 4oCZdCBmZWVsIGxpa2UgYmxvY2tpbmcgb24gdGhlIGZpcnN0IGJ5dGUgaXMgbmVjZXNzYXJpbHkg YW55IGRpZmZlcmVudCBmcm9tIGJsb2NraW5nIG9uIHRoZSBmaXJzdCBmcmFtZSBoZWFkZXIgd2hp Y2ggaW1tZWRpYXRlbHkgZm9sbG93cyBpdC4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bV0NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggNToyOSBQTQ0KVG86IFJvYmVydG8gUGVv biA8ZmVuaXhAZmIuY29tPg0KQ2M6IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGF0aCBmb3J3YXJkIHdpdGgg c3RyZWFtIGhlYWRlcnMNCg0KDQoNCk9uIFdlZCwgSnVuIDIwLCAyMDE4IGF0IDEwOjIxIEFNIFJv YmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+PiB3cm90ZToNCg0K PiBIb3dldmVyLCBpZiBvbmUgbXVzdCByZWNlaXZlIHRoZSBmaXJzdCBwYWNrZXQgb2YgZWFjaCBz dHJlYW0sIGFkZGl0aW9uYWwgSG9MIGJsb2NraW5nICh3aGljaCBwcmV2ZW50cyBwbGF5YmFjay9p bnRlcnByZXRhdGlvbikgaXMgaW5kdWNlZC4NCg0KDQoNClRoaXMgaXMgdGhlIGJpdCBJJ20gcHVz aGluZyBiYWNrIG9uLiAgVGhlIGZpcnN0IGJ5dGUgaXNuJ3QgcHJpdmlsZWdlZC4NCg0KVGhlcmUn cyBhIHB1c2ggSUQsIGEgSEVBREVSUyBmcmFtZSwgYW5kIHRoZSBzdGFydCBvZiB0aGUgZmlyc3Qg REFUQSBmcmFtZSBiZWZvcmUgeW91IGNhbiBzdGFydCBpbnRvIHJhbmRvbSBhY2Nlc3MuICBXaXRo b3V0IHRoYXQsIHlvdSBjYW4ndCBrbm93IHdoYXQgeW91IGFyZSByZWFkaW5nLiAgSSBmYWlsIHRv IHNlZSBob3cgb25lIGFkZGl0aW9uYWwgb2N0ZXQgaXMgYSBwcm9ibGVtIGhlcmUuDQo= --_000_BYAPR08MB3944A7F25A5940057CCFF6F0DA770BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjAxMTY2NzAzOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY5ODkxNDQwMCA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkkgYWdyZWUuJm5ic3A7IFRoaXMgaXMgYWxyZWFkeSBhIHByb3BlcnR5IG9mIHVz aW5nIGZyYW1lcy4mbmJzcDsgSnVzdCBsaWtlIHRoZSB2aWRlbyBpdHNlbGYgY29uc2lzdGluZyBv ZiBib3RoIHN0cnVjdHVyZSBhbmQgY29udGVudCwgeW91IGhhdmUgdG8gZmluZCB0aGUgZnJhbWUg aGVhZGVyIChhbmQgdGhlcmVmb3JlIGl0cyBsZW5ndGgpIGZpcnN0LiZuYnNwOyBPbmNlIHlvdSBo YXZlIHRoYXQsIHlvdSBjYW4gZG8gdHdvIHRoaW5nczo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UmFuZG9tIGFjY2VzcyBhbnl3aGVyZSB3 aXRoaW4gdGhhdCBmcmFtZTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj5Mb2NhdGUgdGhlIGhlYWRlciBvZiB0aGUg bmV4dCBmcmFtZSBhbmQgYmVnaW4gaW50ZXJwcmV0aW5nIGl0LCBpZiB0aGF04oCZcyByZWNlaXZl ZCBmaXJzdDxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCByZW1v dmluZyBibG9ja2luZyBvbiB0aGUgZnJhbWUgaGVhZGVyIGVudGlyZWx5IGlzIGEgcHJldHR5IHN1 YnN0YW50aWFsIGNoYW5nZSAoYW5kIHByb2JhYmx5IGxvb2tzIGEgbG90IGxpa2UgSFRUUC9RVUlD IC0wMSBvciBzbywgd2l0aCBhIGRlZGljYXRlZCBzdHJlYW0gZm9yIGRhdGEpLiZuYnNwOyBJIGRv buKAmXQgZmVlbCBsaWtlIGJsb2NraW5nIG9uIHRoZSBmaXJzdCBieXRlIGlzIG5lY2Vzc2FyaWx5 DQogYW55IGRpZmZlcmVudCBmcm9tIGJsb2NraW5nIG9uIHRoZSBmaXJzdCBmcmFtZSBoZWFkZXIg d2hpY2ggaW1tZWRpYXRlbHkgZm9sbG93cyBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gPGJyPg0KU2VudDogVHVlc2RheSwgSnVu ZSAxOSwgMjAxOCA1OjI5IFBNPGJyPg0KVG86IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29t Jmd0Ozxicj4NCkNjOiBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NClN1YmplY3Q6IFJlOiBQYXRoIGZvcndh cmQgd2l0aCBzdHJlYW0gaGVhZGVyczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gV2VkLCBKdW4gMjAs IDIwMTggYXQgMTA6MjEgQU0gUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhA ZmIuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+ZmVuaXhAZmIuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIb3dldmVyLCBpZiBvbmUgbXVzdCByZWNlaXZlIHRo ZSBmaXJzdCBwYWNrZXQgb2YgZWFjaCBzdHJlYW0sIGFkZGl0aW9uYWwgSG9MIGJsb2NraW5nICh3 aGljaCBwcmV2ZW50cyBwbGF5YmFjay9pbnRlcnByZXRhdGlvbikgaXMgaW5kdWNlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBpcyB0aGUgYml0IEknbSBwdXNoaW5nIGJhY2sg b24uJm5ic3A7IFRoZSBmaXJzdCBieXRlIGlzbid0IHByaXZpbGVnZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGVyZSdzIGEgcHVzaCBJRCwgYSBIRUFERVJTIGZy YW1lLCBhbmQgdGhlIHN0YXJ0IG9mIHRoZSBmaXJzdCBEQVRBIGZyYW1lIGJlZm9yZSB5b3UgY2Fu IHN0YXJ0IGludG8gcmFuZG9tIGFjY2Vzcy4mbmJzcDsgV2l0aG91dCB0aGF0LCB5b3UgY2FuJ3Qg a25vdyB3aGF0IHlvdSBhcmUgcmVhZGluZy4mbmJzcDsgSSBmYWlsIHRvIHNlZSBob3cgb25lIGFk ZGl0aW9uYWwgb2N0ZXQgaXMgYSBwcm9ibGVtIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR08MB3944A7F25A5940057CCFF6F0DA770BYAPR08MB3944namp_-- From nobody Wed Jun 20 09:37:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9159131059 for ; Wed, 20 Jun 2018 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 d8OBL005Trkf for ; Wed, 20 Jun 2018 09:37:37 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6980A1310EC for ; Wed, 20 Jun 2018 09:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WJnSagMwz3wnS+lGfIMcUyGMKx/IXhjynBQooJFhtEI=; b=LUfQD+gRP8D9tXbCuy/hm0mwjvZWYL8VkHIy0gN9RjiVob/NfUuD9ezMtgOh8rpL9u2qEPlkxINq+A6TMHNhxIdtcyk05wdqi+rxM67gjLmZZL2yhU+v4ZoAnQGLFkDyYqV/QIMJoSl26t45ziBkuYed4AP4vNZUSga8jSOMdq4= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4965.namprd08.prod.outlook.com (20.176.255.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Wed, 20 Jun 2018 16:37:33 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 16:37:33 +0000 From: Mike Bishop To: Lucas Pardue , Martin Thomson , Roberto Peon CC: QUIC WG Subject: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwA== Date: Wed, 20 Jun 2018 16:37:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4965; 7:bIADoi6kur6GpbH/YDLvhwEpRBN4MBnVUCvnUW4po8Mxc/7msRJunr08y6IzJXCa8rCYW3ynsE6BzUss9rIXDZwn+y36GdJdjl7tBuZoLejYUwMoWSDY1IcOyMvTYK/0Kjl9G6pLQmSE7bVEZuIqF9G8z653BNTyvPrx5AAQkRbQUHn4ucHVs1steLQTUqpf3xLwCwnsNT7Fq97OgL07/Yk4uJNwtp8KCJk6YOY8XEWhWqmxNspoAAcN1X8IZb9o x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0a74fd56-4d67-4118-ba2e-08d5d6cc1f74 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4965; x-ms-traffictypediagnostic: BYAPR08MB4965: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(204407124797145)(85827821059158)(67672495146484)(127952516941037); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(2016111802025)(20161123562045)(20161123558120)(20161123564045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4965; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4965; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(39380400002)(396003)(346002)(366004)(376002)(13464003)(199004)(189003)(53546011)(55016002)(6306002)(53936002)(9686003)(74482002)(486006)(25786009)(6116002)(3846002)(39060400002)(2906002)(53386004)(4326008)(14454004)(26005)(99286004)(33656002)(6436002)(316002)(186003)(478600001)(476003)(7696005)(6506007)(110136005)(966005)(102836004)(59450400001)(74316002)(97736004)(5660300001)(7116003)(66066001)(305945005)(106356001)(561944003)(5250100002)(5890100001)(68736007)(3660700001)(3280700002)(81156014)(7736002)(105586002)(2900100001)(8676002)(81166006)(8936002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4965; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: +ojzey+l4rqG48ou9TX4kl2NEO4W7tx3U9SG3jUshPWr91V4RN7tNua10SzFdDsZJAJyFcvJWNZGpZwFP/AxOSRGOi3J1Lre2l3au4+lYr1MQ4NbPKwHJj+5jketIjL17yHuRGNxT5d5raUwd9H+pWDJRk/z1mRZgg9v1f18b8oipA3rev0n4g2ypW5xWZO4lqUQ969nfWkMUAvYdIkyuwtGqiF6sQ0wibG6aFpwfRzfmoXSfG2oUYvZ54vzOCsC+b4nOyEXAyp5VrWqZhoWTB5MCMynRAeOjawkoqc1loHnUiBz0Oji3PGauGM1vc1CGKAQZIUAtomxVPkcRG8Zng== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 0a74fd56-4d67-4118-ba2e-08d5d6cc1f74 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 16:37:32.9957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4965 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:37:51 -0000 U2VwYXJhdGluZyB0aHJlYWRzLCBiZWNhdXNlIEkgdGhpbmsgdGhpcyBpcyByZWFsbHkgYSBzZXBh cmF0ZSB0b3BpYy4NCg0KUGVyaGFwcyBJJ20gbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBJIGRvbid0 IHNlZSBob3cgdGhhdCBjaGFuZ2Ugc3Vic3RhbnRpdmVseSBjaGFuZ2VzIGFueXRoaW5nIGZvciB0 aGUgYmV0dGVyLiAgVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmVuJ3QgcmVxdWlyZWQgdG8gdXNl IEhUVFAvUVVJQyBmcmFtZXM7IHRoZSBRUEFDSyBzdHJlYW0gY2VydGFpbmx5IGRvbid0LiAgKEl0 IGFjdHVhbGx5IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBzZXBhcmF0ZSBmcmFtZSB0eXBlIHNw YWNlcyBiZXR3ZWVuIHJlcXVlc3Qgc3RyZWFtcyBhbmQgY29udHJvbCBzdHJlYW1zLCBidXQgdGhh dCdzIGEgc2VwYXJhdGUgY29udmVyc2F0aW9uLikgIFRoZSBwdXNoIHN0cmVhbSB1c2VzIHRoZSBz YW1lIGZyYW1lcyBiZWNhdXNlIGl0J3MgZnVuZGFtZW50YWxseSB0aGUgc2FtZSB0aGluZyBhcyBh IHJlc3BvbnNlIHRvIGEgcmVxdWVzdCwgc28gaXQncyBlbmNvZGVkIHRoZSBzYW1lIHdheS4gIEl0 J3MgYSBjb252ZW5pZW5jZSAtLSBkZWZpbmluZyBhIG5ldyBmcmFtZSB0eXBlIHRvIHN1cHBvcnQg aXQgc2VlbXMgbGlrZSB0aGUgd3JvbmcgZGlyZWN0aW9uLg0KDQpZb3VyIHByb3Bvc2FsIHdvdWxk IG1vdmUgdGhlIFB1c2ggSUQgc2xpZ2h0bHkgbGF0ZXIgaW4gdGhlIHN0cmVhbSwgYnV0IG5vdCBv dGhlcndpc2UgY2hhbmdlIGFueXRoaW5nLiAgV2hpbGUgdGhlIG9kZHMgb2YgaGF2aW5nIGludGVy bWVkaWF0ZSByZXNwb25zZXMgb24gYSBwdXNoIGFyZSB2YW5pc2hpbmdseSBsb3csIGl0J3Mgbm90 IGlsbGVnYWwgYW5kIG5laXRoZXIgYXJlIHRyYWlsZXJzLiAgU28gbm93IHRoZSBQdXNoIElEIGlz IGEgcHJvcGVydHkgb2YgZWFjaCBoZWFkZXIgYmxvY2sgcmF0aGVyIHRoYW4gb2YgdGhlIHN0cmVh bSwgYW5kIEkgZG9uJ3Qga25vdyBob3cgdG8gbWFrZSBzZW5zZSBvZiBhIHN0cmVhbSB3aGVyZSB0 aGV5IGRpZmZlciBiZXR3ZWVuIGZyYW1lcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEx1Y2FzIFBhcmR1ZSBbbWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWtdIA0KU2Vu dDogV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDE4IDI6MjYgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpD YzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZv dS5iZT4NClN1YmplY3Q6IFJFOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQpJ IGFncmVlIHdpdGggTWFydGluLiBIb3dldmVyLCB0byB0aGluayBhcm91bmQgdGhlIHRvcGljIGEg bGl0dGxlLCB0aGUgdGVsbGluZyBwcm9ibGVtIGlzIHRoYXQgd2Ugd2FudCB0d28gdGhpbmdzOiBh IHN0cmVhbSB3aXRoIG1lYW5pbmcgb3RoZXIgdGhhbiBiaWRpcmVjdGlvbmFsIHJlcXVlc3QvcmVz cG9uc2UsIGFuZCB0byByZXVzZSB0aGUgZnJhbWVzIChIRUFERVJTIGFuZCBEQVRBKSBhc3NvY2lh dGVkIHdpdGggcmVxdWVzdC9yZXNwb25zZS4gVGhpcyBsZWFkcyB0byBoYXZpbmcgdG8gYWRkIHRo ZSBwdXNoIElEIHRvIHRoZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW0gaGVhZGVyLg0KDQpTbyBoZXJl J3MgYSBjYW5kaWRhdGUgcHJvcG9zYWw6DQoNClJlbW92ZSB0aGUgcHVzaCBJRCBmcm9tIHRoZSBz dHJlYW0gaGVhZGVyIGFuZCBwdXQgaXQgYSBuZXcgUFVTSF9IRUFERVJTIGZyYW1lIChub3RpY2Ug dGhlIHNpbWlsYXJpdHkgdG8gUFVTSF9QUk9NSVNFKToNCg0KICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBQdXNoIElEIChpKSAg ICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgIEhlYWRlciBCbG9jayAoKikgICAgICAgICAgICAgICAgICAgICAgLi4uDQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KDQogICAgICAgICAgICAgICAgICAgRmlndXJlIDg6IFBVU0hfSEVBREVSUyBmcmFt ZSBwYXlsb2FkDQoNCiAgIFRoZSBwYXlsb2FkIGNvbnNpc3RzIG9mOg0KDQogICBQdXNoIElEOiAg QSB2YXJpYWJsZS1sZW5ndGggaW50ZWdlciB0aGF0IGlkZW50aWZpZXMgdGhlIHNlcnZlciBwdXNo DQogICAgICB0aGF0IHRoaXMgaXMgYSByZXNwb25zZSB0by4NCg0KICAgSGVhZGVyIEJsb2NrOiAg UVBBQ0stY29tcHJlc3NlZCByZXNwb25zZSBoZWFkZXJzLg0KICAgICBTZWUgW1FQQUNLXSBmb3Ig bW9yZSBkZXRhaWxzLg0KDQpUaGlzIHNoaWZ0cyB0aGUgcHJvYmxlbSBvZiByZW9yZGVyaW5nIGZy b20gc3RyZWFtIGJ5dGUgcG9zaXRpb24gbW9yZSB0b3dhcmRzIHRoZSBIVFRQIE1lc3NhZ2UgRXhj aGFuZ2Ugc2VxdWVuY2UgZGVmaW5lZCBpbiAzLjIuDQoNCkx1Y2FzDQoNCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPlNlbnQ6IDIwIEp1bmUgMjAxOCAwMToyOQ0K PlRvOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NCj5DYzogUVVJQyBXRyA8cXVpY0BpZXRm Lm9yZz47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT4NCj5TdWJqZWN0OiBSZTog UGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnMNCj4NCj5PbiBXZWQsIEp1biAyMCwgMjAx OCBhdCAxMDoyMSBBTSBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4gd3JvdGU6DQo+PiBIb3dl dmVyLCBpZiBvbmUgbXVzdCByZWNlaXZlIHRoZSBmaXJzdCBwYWNrZXQgb2YgZWFjaCBzdHJlYW0s IA0KPj4gYWRkaXRpb25hbCBIb0wNCj5ibG9ja2luZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2sv aW50ZXJwcmV0YXRpb24pIGlzIGluZHVjZWQuDQo+DQo+VGhpcyBpcyB0aGUgYml0IEknbSBwdXNo aW5nIGJhY2sgb24uICBUaGUgZmlyc3QgYnl0ZSBpc24ndCBwcml2aWxlZ2VkLg0KPlRoZXJlJ3Mg YSBwdXNoIElELCBhIEhFQURFUlMgZnJhbWUsIGFuZCB0aGUgc3RhcnQgb2YgdGhlIGZpcnN0IERB VEEgDQo+ZnJhbWUgYmVmb3JlIHlvdSBjYW4gc3RhcnQgaW50byByYW5kb20gYWNjZXNzLiAgV2l0 aG91dCB0aGF0LCB5b3UgY2FuJ3QgDQo+a25vdyB3aGF0IHlvdSBhcmUgcmVhZGluZy4gIEkgZmFp bCB0byBzZWUgaG93IG9uZSBhZGRpdGlvbmFsIG9jdGV0IGlzIGEgcHJvYmxlbSBoZXJlLg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpU aGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJD IHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4N CmVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQpEbyBub3QgdXNlLCBj b3B5IG9yIGRpc2Nsb3NlIHRoZQ0KaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJl bGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4NClBsZWFzZSBu b3RlIHRoYXQgdGhlIEJCQyBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0 aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Wed Jun 20 11:28:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06B130E02 for ; Wed, 20 Jun 2018 11:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-JQMqSWK3Ha for ; Wed, 20 Jun 2018 11:28:00 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28086130DFA for ; Wed, 20 Jun 2018 11:27:59 -0700 (PDT) Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5KIRbJR012404; Wed, 20 Jun 2018 19:27:37 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1007.national.core.bbc.co.uk ([10.161.14.21]) with mapi id 14.03.0389.001; Wed, 20 Jun 2018 19:27:37 +0100 From: Lucas Pardue To: Mike Bishop , Martin Thomson , Roberto Peon CC: QUIC WG Subject: RE: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwAACdGVF Date: Wed, 20 Jun 2018 18:27:36 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23920.001 x-tm-as-result: No-7.569200-8.000000-10 x-tmase-matchedrid: QW5G6BKkLTq7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p0z7Q5F3647KI4+ prdZfxRmOc2zxuS7VoTi6aYiETc/RHKgzS9kU8wE6/xAZojbl7dQCOsAlaxN70+0uGVOF08Q/ue nWPEZxJyf/ayjPGtsEV6jD9X3nXNS6IXGykEpO3em/Bn0aZ3AM0rh/hn4JkBnyL0CMroLynUr1p Erez50TP8lqKDjhCPxoOydO6sfhDXESC2hdca5cs+ayFtEW0uYLAnNohUyMa0Ul9bvAS7WQLogb MqBj3ntg3KrVoJXYdNftuJwrFEhTVUqh/e/yPQx3QfwsVk0UbtuRXh7bFKB7iTFYUPSkR1hmqhp DzR9MwjvnKjgiJiIPq2l90rUNkkZsBTJSD2iAW0= x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--7.569200-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23920.001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:28:02 -0000 Thanks for the feedback. To be clear, I'm in favor of typed streams but to = play devils advocate. =0A= =0A= > Unidirectional streams aren't required to use HTTP/QUIC frames;=0A= =0A= QPACK aside, the only examples we have use frames. So the question is: do w= e think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC ex= tension point?=0A= =0A= Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Header = Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. The = main difference with push is that the stream ID cannot be used to correlate= request and response. So we use a push ID that is framed everywhere *excep= t* the push delivery stream. PUSH_HEADERS is a more honest approach to this= quirk (at some small framing inconvenience), everything relevant to the He= ader Block is bundled together. It acts as a stream reservation mechanism t= hat ties push response data, with request and response headers. =0A= =0A= It doesn't change much: =0A= =0A= Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS)=0A= Typed streams: stream type byte + push ID + HEADERS + DATA (+ HEADERS)=0A= Untyped and framed streams: PUSH_HEADERS (including push ID) + DATA (+HEAD= ERS)=0A= =0A= I could try to make a weak argument that framing helps because you could at= least skip over frames if you get their length but not the rest. The curre= nt design requires the full push ID to be received before HEADERS and DATA = processing.=0A= =0A= Lucas=0A= From nobody Wed Jun 20 11:58:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED965130EB7 for ; Wed, 20 Jun 2018 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 4lcitxH0xxm8 for ; Wed, 20 Jun 2018 11:58:03 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.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 1CBA812777C for ; Wed, 20 Jun 2018 11:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kIu9W3Sj+PZ6cFR/KpVZO2RTgn8ircKEeX/xtDEm9kY=; b=rSKm008qbIHCJtlGLbYFjckuDs6ZxOuAa6spMYR7Upcmg1G2gEPMyxLcr7XWPV2QrHhGejoUJ+G6xwgmaBLa5ehE8Dg52SsCE0eZFXqPkJ/DNPJZxQkkrcMl3Xujo5WFYCkFDRULHXd/rcrQCrdgDcl1NwvT6MgDMxijNAOdAlM= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB3847.namprd08.prod.outlook.com (52.135.193.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Wed, 20 Jun 2018 18:57:59 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 18:57:59 +0000 From: Mike Bishop To: Lucas Pardue , Martin Thomson , Roberto Peon CC: QUIC WG Subject: RE: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwAACdGVFAAJIJNA= Date: Wed, 20 Jun 2018 18:57:58 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB3847; 7:vQ5qmfSLS7Epn5CatxqE+a77Xb4zRGOERxbwudj8VWwDm/D4gaCXED/qoB0aPY4nqi4XcBFZooGHkbBs90SPsKCI8uZoSh2Qvys3hBsoxW+A1khiPdo8+sQ7UauwRTtJ6F67wgMOyaqldt3cUvfQzoxDcaPQ5drugbDGoObsmKjDmNFI6I4wSDYDxXyOv13aaKvzwU+qKXhkDsspV/9Q5pVNsxt78rHsh8P7OkEElK79dTNuQ+V4ho29eGhb+3wG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 60c3f450-7c70-4e7b-4b6a-08d5d6dfbdab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB3847; x-ms-traffictypediagnostic: BYAPR08MB3847: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(67672495146484)(127952516941037); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(2016111802025)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB3847; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB3847; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(376002)(346002)(39380400002)(396003)(51914003)(199004)(189003)(13464003)(486006)(74316002)(4326008)(11346002)(25786009)(2906002)(446003)(106356001)(5250100002)(5660300001)(7116003)(102836004)(26005)(305945005)(39060400002)(6116002)(3846002)(68736007)(229853002)(74482002)(186003)(6506007)(66066001)(478600001)(86362001)(9686003)(14454004)(76176011)(476003)(7696005)(99286004)(53936002)(316002)(3280700002)(105586002)(33656002)(7736002)(6246003)(59450400001)(8936002)(55016002)(53546011)(110136005)(97736004)(6436002)(3660700001)(81156014)(8676002)(81166006)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB3847; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: m896ban/nPTa6MQlHpykdmRNkgA0pYoe2374FSkFsa46tzr4lDVRlJiUAtL3h0uI9NLQF3T1F+bxf57rznR/62dBN2aUqPKpnmIAn5Ou6b3UCtUBadxtezQBM7cSxLfAcxFMW+E8t5fChOCxhl8GhLNBgTrIUQqj0ceaZCPUC76Fe1xlcPldd1AQrGphoCDI8i4dTJsBTDbEgMOSiGF8TsutmZsmgWt7QsMOcyi+yzCEIz8CHGwEkLOseY/Mr/HhpBx7PfxxR7cY79HqByUOyOZ+wOdwGDvjLkyGVIhc+2BbNw3fBmqyvQxYRLkYjIu04/UCeRwlOs5bMyII6j+P8A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 60c3f450-7c70-4e7b-4b6a-08d5d6dfbdab X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 18:57:58.9983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3847 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:58:07 -0000 Philosophically, I'd go a step further and say that, as in the PR, the sema= ntics of the stream are entirely determined by the type byte. Any internal= divisions of regions within the bytestream are as needed by that type and = defined by it. Some, like the QPACK stream, won't actually need divided re= gions. The fact that push streams and control streams subdivide their regions usin= g frames from the same type space as request streams is somewhere between a= convenience due to push's similarity to things we already have (responses)= and a historical legacy of H2. There's no reason they would need to do so= ; there's just also no real reason to change. -----Original Message----- From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20 Sent: Wednesday, June 20, 2018 11:28 AM To: Mike Bishop ; Martin Thomson ; Roberto Peon Cc: QUIC WG Subject: RE: PUSH_HEADERS frame Thanks for the feedback. To be clear, I'm in favor of typed streams but to = play devils advocate.=20 > Unidirectional streams aren't required to use HTTP/QUIC frames; QPACK aside, the only examples we have use frames. So the question is: do w= e think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC ex= tension point? Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Header = Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. The = main difference with push is that the stream ID cannot be used to correlate= request and response. So we use a push ID that is framed everywhere *excep= t* the push delivery stream. PUSH_HEADERS is a more honest approach to this= quirk (at some small framing inconvenience), everything relevant to the He= ader Block is bundled together. It acts as a stream reservation mechanism t= hat ties push response data, with request and response headers. =20 It doesn't change much:=20 Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS) Typed streams= : stream type byte + push ID + HEADERS + DATA (+ HEADERS) Untyped and frame= d streams: PUSH_HEADERS (including push ID) + DATA (+HEADERS) I could try to make a weak argument that framing helps because you could at= least skip over frames if you get their length but not the rest. The curre= nt design requires the full push ID to be received before HEADERS and DATA = processing. Lucas From nobody Wed Jun 20 14:03:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146451311AA for ; Wed, 20 Jun 2018 14:03:18 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=k+3C/mC5; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Ytssdt/P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9o3PybCJ4ld for ; Wed, 20 Jun 2018 14:03:16 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 8647F130EC7 for ; Wed, 20 Jun 2018 14:03:16 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5KKq4AN007500; Wed, 20 Jun 2018 14:03:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=RA90wjNgj7ILCPkj1WooxGckfycolkKc765wYvqVHN0=; b=k+3C/mC5TMav8qvzx5rskp4MDUA8mpBpTzESsvgJd2QV/Ew5ZI0nOqqonsAmgX3huZYs MRymSbEsSAETM1YxNbwAG0gE8Z8pIG5jA7Z9BtAQjqTrLlSKvYLYrOqf9f0eenyOSj+X xBNFy7bmwxO4oW2+xIkxp0ijD26J9bQ5rjY= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2jqt1d0xuv-4 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 14:03:12 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 20 Jun 2018 14:03:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RA90wjNgj7ILCPkj1WooxGckfycolkKc765wYvqVHN0=; b=Ytssdt/PEBNRYC7pENmDAG18rhNyalo4n55krnqoyvYVbOEcjw/L2k2/atlp61S+SXim6Xz73EpFKmrnai1A4eozzSrQTA4vBvBExSgJ6/7YmZDg5cTqMzyz5nYZO6VIHMjexqiM/n4eSzTyU7eEuGsn4Auq3IECxnUMXMZiETk= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2439.namprd15.prod.outlook.com (52.135.198.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Wed, 20 Jun 2018 21:03:07 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 21:03:07 +0000 From: Roberto Peon To: Martin Thomson CC: Mike Bishop , QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsAgAB3mgCAAKkoAA== Date: Wed, 20 Jun 2018 21:03:07 +0000 Message-ID: <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:200::7:c553] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2439; 7:ZwZ5h5S59dvVnsTRKYbsPUnTse5NC1XXTAzsUbXV7FunIeLy9T9fxEBrIvg72ZIdYbefc0gsZF+gtmR1kyZo2lpb/4nE+/8JknjrGdwqcI4RslKvxqWik6pfylYrp+Avk8o/khA6cT/H6r4DO9LH8hSlI6EVLYrQzzOzuHDNkCxzRyRDWZrxP7P3ZJUNfPmd54wyLrIMAIht1y4ryiUd70sPs5E4StJowki9uIKAzApAlbjXa6DFVIkiOfsdl2fR; 20:v7Ku4ifJBwxZzNSgmlrhNl96DfvrGuaSgnelSjCCXNKC3QuV9OYVFN3h5TGe61ETZxl8vs9JAkUA+2oex2eKLetNpZfQQDIgtvpffhZgO8atA8+fKfqEZngiNCTDsTcM/BtbheLGR5UC+//HjTJd2i/5b9vjA9F/k3c7haKvcO8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: edf993f1-3d64-486e-463c-08d5d6f1392c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2439; x-ms-traffictypediagnostic: BYAPR15MB2439: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2439; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2439; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(396003)(346002)(366004)(39860400002)(189003)(199004)(33656002)(93886005)(316002)(11346002)(446003)(229853002)(54906003)(2616005)(6916009)(59450400001)(68736007)(76176011)(99286004)(5660300001)(476003)(102836004)(186003)(53546011)(6506007)(486006)(36756003)(58126008)(105586002)(14454004)(46003)(106356001)(4326008)(97736004)(6246003)(7736002)(83716003)(5250100002)(6512007)(25786009)(39060400002)(3280700002)(3660700001)(6116002)(8936002)(2906002)(82746002)(305945005)(6436002)(478600001)(8676002)(6486002)(86362001)(81156014)(53936002)(81166006)(2900100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2439; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /TouRDFdKUaZbJzuQqhHTSjDrCfadVhsrNrw+zhiFePIJxzgr30bsCr5pDeucJkvhBgCA+xXRqO+w3xxhrqyUF9gFUhREHOIoWHGDyMr6BMdSH7iFIKpZbvNwOWmXc922mzOfJNJJQ+r906Y6q3x6r6fvCY3KTlfIKYL2Pibiy9sv0FqwCg9F/1N0na5KhoczSX1oNgxuV+WY5O01drAEen768QPu9QRaSgCsDZ6PTGqkq01HAnP0SiGppo9poblM7ITnn0GRnv+0QbwPR3xTy6VnXXcMZ8rgMG/VoyVIvRemRKUdnuA1iDQqud2rUAGtEvMlYxsejrqIOBmVhg/hg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <22167B0E95CD7E49A9A2B18CAF189B60@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: edf993f1-3d64-486e-463c-08d5d6f1392c X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 21:03:07.4958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2439 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-20_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 21:03:30 -0000 WW91J3JlIGFzc3VtaW5nIHRoZSBkYXRhIGlzbid0IHNlbGYtZGVzY3JpcHRpdmUgaW4gdGhlIGJv ZHkuDQotPVINCg0K77u/T24gNi8xOS8xOCwgNToyOSBQTSwgIk1hcnRpbiBUaG9tc29uIiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCg0KICAgIE9uIFdlZCwgSnVuIDIwLCAyMDE4 IGF0IDEwOjIxIEFNIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPiB3cm90ZToNCiAgICA+IEhv d2V2ZXIsIGlmIG9uZSBtdXN0IHJlY2VpdmUgdGhlIGZpcnN0IHBhY2tldCBvZiBlYWNoIHN0cmVh bSwgYWRkaXRpb25hbCBIb0wgYmxvY2tpbmcgKHdoaWNoIHByZXZlbnRzIHBsYXliYWNrL2ludGVy cHJldGF0aW9uKSBpcyBpbmR1Y2VkLg0KICAgIA0KICAgIFRoaXMgaXMgdGhlIGJpdCBJJ20gcHVz aGluZyBiYWNrIG9uLiAgVGhlIGZpcnN0IGJ5dGUgaXNuJ3QgcHJpdmlsZWdlZC4NCiAgICBUaGVy ZSdzIGEgcHVzaCBJRCwgYSBIRUFERVJTIGZyYW1lLCBhbmQgdGhlIHN0YXJ0IG9mIHRoZSBmaXJz dCBEQVRBDQogICAgZnJhbWUgYmVmb3JlIHlvdSBjYW4gc3RhcnQgaW50byByYW5kb20gYWNjZXNz LiAgV2l0aG91dCB0aGF0LCB5b3UNCiAgICBjYW4ndCBrbm93IHdoYXQgeW91IGFyZSByZWFkaW5n LiAgSSBmYWlsIHRvIHNlZSBob3cgb25lIGFkZGl0aW9uYWwNCiAgICBvY3RldCBpcyBhIHByb2Js ZW0gaGVyZS4NCiAgICANCg0K From nobody Wed Jun 20 14:48:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76A130F35 for ; Wed, 20 Jun 2018 14:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 TDowOjdm0CCy for ; Wed, 20 Jun 2018 14:48:01 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C9E130F27 for ; Wed, 20 Jun 2018 14:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/LFVQlupDUxAyXvGVyMmRj97qmTkkTDHRoN6i5TpGoI=; b=IFN2jStaCjyaOCOtGlhTx2NTLPO6Y4Zy3yYSl1PlPff7mjO4f2iU4Lwava1JoAcQsv5Fu6T26SQHAcXCxhw19T3iuOAirM96S2NnHOFHoy2yonkIWc0J3S7lbFXjTlkCMxhVg/8YP869DS6cfEQzzuI/N8fLEUGxRTvE//9JMJ0= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4184.namprd08.prod.outlook.com (20.176.250.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 21:48:00 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::6093:5ef9:46a3:ca1f%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 21:48:00 +0000 From: Mike Bishop To: Roberto Peon , Martin Thomson CC: QUIC WG Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsAgAB3mgCAAKkoAP//RDTQ Date: Wed, 20 Jun 2018 21:48:00 +0000 Message-ID: References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> In-Reply-To: <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4184; 7:+lqg8b+HYJVNVJlVHI34gzINuOpqz6hzQzwO7nu9UF2uEJ3qH+mp5O0UjedE1nbS9SQYBghRY1ueRmwy+/UE0+RAF6dcpdow6QM//vnjjXYweyNBUpqfpkj7m+OvuFLj/vsXaP3XBCvgqwJ8QDbmkadtpZb2gA7LcTKB6OTACik/P+ShXsrGJcymFjCpEW90MgQW3H5LGO1QRkMGMj78ThX4ZI6bDsNoJWT6i+GgTnlDh8mb/x2kvEAjzRX09f6P x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cf37f8d3-2295-44f3-fe10-08d5d6f77e23 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4184; x-ms-traffictypediagnostic: BYAPR08MB4184: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123560045)(2016111802025)(20161123558120)(20161123564045)(6043046)(6072148)(201708071742011)(7699016); SRVR:BYAPR08MB4184; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4184; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(39830400003)(366004)(13464003)(189003)(199004)(86362001)(110136005)(3660700001)(2900100001)(478600001)(446003)(33656002)(106356001)(105586002)(93886005)(66066001)(2906002)(316002)(6436002)(9686003)(14454004)(186003)(3280700002)(55016002)(11346002)(476003)(4326008)(229853002)(76176011)(7696005)(486006)(68736007)(99286004)(53546011)(26005)(8676002)(81156014)(81166006)(74482002)(102836004)(59450400001)(3846002)(6506007)(6116002)(97736004)(53936002)(6246003)(39060400002)(5660300001)(305945005)(7736002)(74316002)(25786009)(8936002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4184; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: Z8Wy7Pk0LjbcvL4DLjama20bo9aHxuVKLp4L+pSGlyZWUu02nONHKNqtuUH8mi9zZTT5ch8kWdts8xVaAHMxSnLKvEnr6gBIycQ84VTnmL4rDSvRQ7OmkEhdUS9Yl1SFDP+1kwIetLfExV2P8XD26k+0AVck2JosMEah5zfo8ier+lwaQBP0HrqRhambYLUnjpX7LWtphSfU+QKvjwlnqTlSyIUoXr9qKRxcraw5zqsNxcNy1Z50QzsdCcQAbTxJZqPLJ7rBmBTwVVDTaIyPbkdpjQRjDtj/s21cLBSpjMOpA2TdsR2OU4GQVNFvGT9qI5VzaNTjnql2EnLzDQybwQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: cf37f8d3-2295-44f3-fe10-08d5d6f77e23 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 21:48:00.1785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4184 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 21:48:12 -0000 QnV0IHlvdSBkb24ndCBrbm93IHdoZXJlIHRoZSBib2R5IGlzIHVudGlsIHlvdSd2ZSBzZWVuIHRo ZSBoZWFkZXIuICBPdGhlcndpc2UsIHlvdSdyZSBub3QgY2VydGFpbiB0aGF0IHdoYXQgeW91J3Jl IHNlZWluZyAqaXMqIGJvZHksIHJhdGhlciB0aGFuIHNvbWV0aGluZyBpbiBhIGRpZmZlcmVudCBm cmFtZSB0aGF0IGhhcHBlbnMgdG8gbG9vayBsaWtlIHlvdXIgc2VsZi1kZXNjcmlwdGlvbi4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvYmVydG8gUGVvbiBbbWFpbHRvOmZl bml4QGZiLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTggMjowMyBQTQ0KVG86 IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogTWlrZSBCaXNo b3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQpZb3UncmUgYXNzdW1p bmcgdGhlIGRhdGEgaXNuJ3Qgc2VsZi1kZXNjcmlwdGl2ZSBpbiB0aGUgYm9keS4NCi09Ug0KDQrv u79PbiA2LzE5LzE4LCA1OjI5IFBNLCAiTWFydGluIFRob21zb24iIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20+IHdyb3RlOg0KDQogICAgT24gV2VkLCBKdW4gMjAsIDIwMTggYXQgMTA6MjEgQU0g Um9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+IHdyb3RlOg0KICAgID4gSG93ZXZlciwgaWYgb25l IG11c3QgcmVjZWl2ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3RyZWFtLCBhZGRpdGlvbmFs IEhvTCBibG9ja2luZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2svaW50ZXJwcmV0YXRpb24pIGlz IGluZHVjZWQuDQogICAgDQogICAgVGhpcyBpcyB0aGUgYml0IEknbSBwdXNoaW5nIGJhY2sgb24u ICBUaGUgZmlyc3QgYnl0ZSBpc24ndCBwcml2aWxlZ2VkLg0KICAgIFRoZXJlJ3MgYSBwdXNoIElE LCBhIEhFQURFUlMgZnJhbWUsIGFuZCB0aGUgc3RhcnQgb2YgdGhlIGZpcnN0IERBVEENCiAgICBm cmFtZSBiZWZvcmUgeW91IGNhbiBzdGFydCBpbnRvIHJhbmRvbSBhY2Nlc3MuICBXaXRob3V0IHRo YXQsIHlvdQ0KICAgIGNhbid0IGtub3cgd2hhdCB5b3UgYXJlIHJlYWRpbmcuICBJIGZhaWwgdG8g c2VlIGhvdyBvbmUgYWRkaXRpb25hbA0KICAgIG9jdGV0IGlzIGEgcHJvYmxlbSBoZXJlLg0KICAg IA0KDQo= From nobody Wed Jun 20 14:56:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEC1130EBF for ; Wed, 20 Jun 2018 14:56:17 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, 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=fb.com header.b=haobiUc3; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CntFN9uW 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 Y9x521Vm3tuf for ; Wed, 20 Jun 2018 14:56:14 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 2FADE130E26 for ; Wed, 20 Jun 2018 14:56:14 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5KLs11m012774; Wed, 20 Jun 2018 14:56:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=IWNsqH5LVP2OoYitdxMT2WRNzKuknZk5ktvxaxsVpgM=; b=haobiUc3LUxqMYQPD19kQXA0iLhRVGX5Rs9/2Q5YcadXsI5l2AGGiaUdvSbP2Cuemo2e oNHqKSng/mOu1KmN5n4QrHrFIT622n4ivxoIhrFzXIM+88oxm09LAsaVV6qyt/LlC5SR TkobRWS+mdClL8uGCdifWV6kTlXUzC4aSO0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jqwprg9fs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 14:56:09 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 20 Jun 2018 14:56:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IWNsqH5LVP2OoYitdxMT2WRNzKuknZk5ktvxaxsVpgM=; b=CntFN9uWAPSPxzjtxEv0PGBJ3HAZquoYm3Pl3UrDnfUrsmJ5q5Tb3uTBc8Jzf+euA7DuRWoKwUTb2bQxsEzIu0vfSWycGqMKD0JtZr2JiZXzb/XfT5cEzACIy+x/PbKpK6YWi2v0MVjSN208GD55sZCSdX0xhiuJhO/WBH5e98I= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2423.namprd15.prod.outlook.com (52.135.198.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 21:56:06 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 21:56:06 +0000 From: Roberto Peon To: Mike Bishop , Martin Thomson CC: QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsAgAB3mgD//vSUkAA/tN0A Date: Wed, 20 Jun 2018 21:56:06 +0000 Message-ID: <75130101-9A7C-4B54-BEE7-202CD46DDFE4@fb.com> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:200::7:c553] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2423; 7:mw3RR3osZPPqUwMHWAcTdKVYSFd3AhbGfxrIhTtwwVG/mUxr23J686EWGuto62Krmf6PJe87JCJW3YjKk+TTw2JZX1htlZlQIDilc2ptFH1C5W0zVXHdK8qi3SAFFs/PvBLd6IXbnPTENPmPVOKBBA9rKql/eX9OeoM/M8yrij+uvLwZ0/nKp9isIK3DY/lpu8gfSsWS8+qezuw1yVD4ugQcw3k5bBJScxbEt900+H4YzZSk+hW20OCL1VYP9Pv5; 20:8f2nsjKedFtYqTKEmM5fXtYtgishfd48dsZz2c1vdqyHlpGdks2wZtUBtQPGaveA2l8fuMP8tebDQKnQaSYs6a4yXvRcoz8145wvSB0pJckbzvLjVUtCdKC9t+7KBq3RrMT3Me85GV3L4kabDOFVujtEsk6YO8sylstPVJ52KZU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d3ebde73-9eff-4dfc-74ef-08d5d6f8a011 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2423; x-ms-traffictypediagnostic: BYAPR15MB2423: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2423; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2423; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(39380400002)(346002)(13464003)(199004)(189003)(33656002)(6486002)(6436002)(14454004)(4326008)(36756003)(5660300001)(68736007)(25786009)(561944003)(106356001)(2906002)(105586002)(7736002)(2900100001)(81156014)(8936002)(5250100002)(8676002)(81166006)(3280700002)(39060400002)(6246003)(6116002)(229853002)(53936002)(3660700001)(6306002)(478600001)(6512007)(236005)(54896002)(186003)(97736004)(46003)(11346002)(82746002)(83716003)(93886005)(316002)(59450400001)(53546011)(6506007)(102836004)(86362001)(2616005)(486006)(446003)(58126008)(99286004)(110136005)(76176011)(476003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2423; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YMKqpvOcQz/RhGmTvzC5sDPkU3aLu66lshFZJE62wZYCyWi/ItWR251yv+mSVJNmHHsPHfwFpXOBPF85e+aaGhZRNl6J9Pov720rGGkEzQjNw+2qfaClE40Ujuviu49wqAeVAu3hrv0rGo8dJdUiNAz57DkgagnJ9xF6YQfEBEc4e6fWmi5pTq6gqa3H6uav8A/uB+hdv8alzKfPlws4+lGeetYxAGuZS09Hj3SGNdPcRYe9SjHpvKfI6k91fRb6n34dvuUWLiM+Wzlpwqgd2HlNXnl+JnggEugw/dM8x3H9yxXULOKTOIfUkzvWCF/52XBPCxyj7VPiyvd5OGIeWg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_751301019A7C4B54BEE7202CD46DDFE4fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d3ebde73-9eff-4dfc-74ef-08d5d6f8a011 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 21:56:06.6962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2423 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-20_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 21:56:18 -0000 --_000_751301019A7C4B54BEE7202CD46DDFE4fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVk4oCUb25lIG11c3QgYmUgYWJsZSB0byBsb2NhdGUgYW5kIGtub3cgd2hhdCBkYXRhIGlz IGJlZm9yZSBvbmUgY2FuIHNhZmVseSBpbnRlcnByZXQgaXQuDQoNClRoZXJlIGFyZSB0d28gYXJn dW1lbnRzIGhlcmUgZm9yIHdheXMgb25lIGNvdWxkIGRvIHRoYXQ6DQoNCiAgMS4gIFRoZXJlIGFy ZSBIVFRQICh0aGUgTDcgcHJvdG9jb2wpIHVzZWNhc2VzIHdoZXJlIG9uZSBjYW4gaW50ZXJwcmV0 IGRhdGEgd2l0aG91dCBoYXZpbmcgcmVjZWl2ZWQgdGhlIGZpcnN0IHBvcnRpb24gb2YgdGhlIHN0 cmVhbS4NCkluIGEgKHRoZW9yZXRpY2FsIFFVSUMgVjIpIHdvcmxkIHdpdGggc3RyZWFtIGdyb3Vw cywgb25lIHdvdWxkIGtub3cgYnkgdmlydHVlIG9mIHRoZSBmYWN0IHRoYXQgdGhlIHN0cmVhbSBp cyBpbiBhIHN0cmVhbSBncm91cCB0aGF0IHRoZSBlbmRwb2ludCBvZiB0aGUgZGF0YSBpcyB0aGUg c2FtZSwgYW5kIHRodXMgYmUgYWJsZSB0byBpbmZlciwgb3IgZGV0ZXJtaW5lIGJ5IGVuY29kaW5n IHRoZSBkYXRhIGluIG11bHRpcGxlIHBsYWNlcy9vZmZzZXRzL3dpdGggRkVDIHdoYXQgdGhvc2Ug Zmlyc3QgYnl0ZXMgbWF5IGhhdmUgYmVlbi4NCiAgMi4gIE5vbi1IVFRQIHVzZWNhc2VzIHdoaWNo IG1heSBrbm93IGFib3V0IHRoZSByZWxhdGlvbnNoaXAgb2Ygc3RyZWFtcy9zdHJlYW0gZ3JvdXBz IHN1Y2ggYXMgV2ViUlRDLg0KDQoNCldl4oCZcmUgbm90IGN1cnJlbnRseSBkZXNpZ25pbmcgZm9y ICMyLCBmb3IgYmV0dGVyIG9yIHdvcnNlLg0KDQpXaXRoIHRoZSBwcm9wb3NhbCByaWdodCBub3cs IHdlIGFyZSBmb3JjaW5nIEhvTCBibG9ja2luZyBmb3IgYm90aCBIVFRQIGFuZCBub24tSFRUUCBz dHJlYW1zIGJ5IG1ha2luZyB0aGUgYXNzdW1wdGlvbiB0aGF0IGRhdGEgY2Fubm90IGJlIGludGVy cHJldGVkIHdpdGhvdXQgdGhlIGZpcnN0IGZldyBieXRlcy4NCg0KDQpJIGd1ZXNzIGl0IGFsbCBj b21lcyBkb3duIHRvOg0KICAgV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiB0aGUgcHJvcG9zYWwgdGhh dCBvdXR3ZWlnaHMgdGhlIHBvdGVudGlhbCBsb3NzPw0KYW5kDQogIFdoYXQgaXMgdGhlIGNvc3Qg b2YgYnVybmluZyBhIGNvZGVwb2ludCAoYXMgYSBmcmFtZS10eXBlKSB0byBwcmV2ZW50IHRoZSBw b3RlbnRpYWwgbG9zcz8NCg0KSXQgc2VlbXMgbGlrZSB0aGUgYmVuZWZpdCBvZiB3aGF0IHdl4oCZ cmUgZG9pbmcgaXMgdG8gbm9ybWFsaXplIFFQQUNL4oCZcyBzdHJlYW1zIHdpdGggZXZlcnl0aGlu ZyBlbHNlL21ha2UgUVBBQ0sgc3RyZWFtcytzdHJlYW1JRHMgbm90IHNwZWNpYWwuDQpJIGxpa2Ug dGhlIGlkZWEgb2YgYSBzZWxmLWRlc2NyaXB0aXZlIHN0cmVhbS10eXBlLS0gaW4gcGFydGljdWxh ciwgSSBsaWtlIHRoZSBpZGVhIG9mIHRoZSBzZWxmLWRlc2NyaXB0aXZlIHN0cmVhbS10eXBlIGJl Y2F1c2UgaXQgYWxsb3dzIGEgZmFpcmx5IG9idmlvdXMgKHBvdGVudGlhbCBmdXR1cmUpIG1hcHBp bmcgb2YgbXVsdGlwbGUgUVBBQ0sgY29udGV4dHMgb250byBhIHNpbmdsZSBjb25uZWN0aW9uLg0K T1RPSCwgSSBoYXRlIHRoYXQgd2XigJlkIGZvcmNlIGFsbCBIVFRQIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgaW50byBpdCB3aGVuIHdlIGNhbiBkZWZpbmUgdXNlY2FzZXMgdGhhdCB3b3VsZCBiZSBp bXBhY3RlZCBieSB0aGF0IGRlY2lzaW9uLg0KLT1SDQoNCkZyb206IE1pa2UgQmlzaG9wIDxtYmlz aG9wQGV2ZXF1ZWZvdS5iZT4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAyMCwgMjAxOCBhdCA5OjMy IEFNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4sIFJvYmVy dG8gUGVvbiA8ZmVuaXhAZmIuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogUGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnMNCg0KDQpJIGFncmVlLiAg VGhpcyBpcyBhbHJlYWR5IGEgcHJvcGVydHkgb2YgdXNpbmcgZnJhbWVzLiAgSnVzdCBsaWtlIHRo ZSB2aWRlbyBpdHNlbGYgY29uc2lzdGluZyBvZiBib3RoIHN0cnVjdHVyZSBhbmQgY29udGVudCwg eW91IGhhdmUgdG8gZmluZCB0aGUgZnJhbWUgaGVhZGVyIChhbmQgdGhlcmVmb3JlIGl0cyBsZW5n dGgpIGZpcnN0LiAgT25jZSB5b3UgaGF2ZSB0aGF0LCB5b3UgY2FuIGRvIHR3byB0aGluZ3M6DQoN CiAgKiAgIFJhbmRvbSBhY2Nlc3MgYW55d2hlcmUgd2l0aGluIHRoYXQgZnJhbWUNCiAgKiAgIExv Y2F0ZSB0aGUgaGVhZGVyIG9mIHRoZSBuZXh0IGZyYW1lIGFuZCBiZWdpbiBpbnRlcnByZXRpbmcg aXQsIGlmIHRoYXTigJlzIHJlY2VpdmVkIGZpcnN0DQoNCg0KDQpIb3dldmVyLCByZW1vdmluZyBi bG9ja2luZyBvbiB0aGUgZnJhbWUgaGVhZGVyIGVudGlyZWx5IGlzIGEgcHJldHR5IHN1YnN0YW50 aWFsIGNoYW5nZSAoYW5kIHByb2JhYmx5IGxvb2tzIGEgbG90IGxpa2UgSFRUUC9RVUlDIC0wMSBv ciBzbywgd2l0aCBhIGRlZGljYXRlZCBzdHJlYW0gZm9yIGRhdGEpLiAgSSBkb27igJl0IGZlZWwg bGlrZSBibG9ja2luZyBvbiB0aGUgZmlyc3QgYnl0ZSBpcyBuZWNlc3NhcmlseSBhbnkgZGlmZmVy ZW50IGZyb20gYmxvY2tpbmcgb24gdGhlIGZpcnN0IGZyYW1lIGhlYWRlciB3aGljaCBpbW1lZGlh dGVseSBmb2xsb3dzIGl0Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KU2VudDog VHVlc2RheSwgSnVuZSAxOSwgMjAxOCA1OjI5IFBNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBm Yi5jb20+DQpDYzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQYXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVh ZGVycw0KDQoNCg0KT24gV2VkLCBKdW4gMjAsIDIwMTggYXQgMTA6MjEgQU0gUm9iZXJ0byBQZW9u IDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0KDQo+IEhvd2V2ZXIs IGlmIG9uZSBtdXN0IHJlY2VpdmUgdGhlIGZpcnN0IHBhY2tldCBvZiBlYWNoIHN0cmVhbSwgYWRk aXRpb25hbCBIb0wgYmxvY2tpbmcgKHdoaWNoIHByZXZlbnRzIHBsYXliYWNrL2ludGVycHJldGF0 aW9uKSBpcyBpbmR1Y2VkLg0KDQoNCg0KVGhpcyBpcyB0aGUgYml0IEknbSBwdXNoaW5nIGJhY2sg b24uICBUaGUgZmlyc3QgYnl0ZSBpc24ndCBwcml2aWxlZ2VkLg0KDQpUaGVyZSdzIGEgcHVzaCBJ RCwgYSBIRUFERVJTIGZyYW1lLCBhbmQgdGhlIHN0YXJ0IG9mIHRoZSBmaXJzdCBEQVRBIGZyYW1l IGJlZm9yZSB5b3UgY2FuIHN0YXJ0IGludG8gcmFuZG9tIGFjY2Vzcy4gIFdpdGhvdXQgdGhhdCwg eW91IGNhbid0IGtub3cgd2hhdCB5b3UgYXJlIHJlYWRpbmcuICBJIGZhaWwgdG8gc2VlIGhvdyBv bmUgYWRkaXRpb25hbCBvY3RldCBpcyBhIHByb2JsZW0gaGVyZS4NCg== --_000_751301019A7C4B54BEE7202CD46DDFE4fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <88EAA74395C6084383EF6949F2E41701@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFp blRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MTY1 MDc5Njk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x ODM4NjYzMzM4IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjAxMTY2NzAzOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY5ODkxNDQw MCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNTQwODkyNzUyOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDczMDc4NjQwO30NCkBsaXN0IGwyOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVk 4oCUb25lIG11c3QgYmUgYWJsZSB0byBsb2NhdGUgYW5kIGtub3cgd2hhdCBkYXRhIGlzIGJlZm9y ZSBvbmUgY2FuIHNhZmVseSBpbnRlcnByZXQgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQpUaGVyZSBhcmUgdHdvIGFyZ3VtZW50cyBoZXJlIGZvciB3YXlzIG9u ZSBjb3VsZCBkbyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij5UaGVyZSBhcmUgSFRU UCAodGhlIEw3IHByb3RvY29sKSB1c2VjYXNlcyB3aGVyZSBvbmUgY2FuIGludGVycHJldCBkYXRh IHdpdGhvdXQgaGF2aW5nIHJlY2VpdmVkIHRoZSBmaXJzdCBwb3J0aW9uIG9mIHRoZSBzdHJlYW0u DQo8YnI+DQpJbiBhICh0aGVvcmV0aWNhbCBRVUlDIFYyKSB3b3JsZCB3aXRoIHN0cmVhbSBncm91 cHMsIG9uZSB3b3VsZCBrbm93IGJ5IHZpcnR1ZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBzdHJlYW0g aXMgaW4gYSBzdHJlYW0gZ3JvdXAgdGhhdCB0aGUgZW5kcG9pbnQgb2YgdGhlIGRhdGEgaXMgdGhl IHNhbWUsIGFuZCB0aHVzIGJlIGFibGUgdG8gaW5mZXIsIG9yIGRldGVybWluZSBieSBlbmNvZGlu ZyB0aGUgZGF0YSBpbiBtdWx0aXBsZSBwbGFjZXMvb2Zmc2V0cy93aXRoDQogRkVDIHdoYXQgdGhv c2UgZmlyc3QgYnl0ZXMgbWF5IGhhdmUgYmVlbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm80Ij5Ob24tSFRUUCB1c2VjYXNlcyB3aGljaCBtYXkga25vdyBhYm91dCB0aGUgcmVsYXRp b25zaGlwIG9mIHN0cmVhbXMvc3RyZWFtIGdyb3VwcyBzdWNoIGFzIFdlYlJUQy48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2XigJlyZSBub3QgY3VycmVudGx5IGRl c2lnbmluZyBmb3IgIzIsIGZvciBiZXR0ZXIgb3Igd29yc2UuPGJyPg0KPGJyPg0KV2l0aCB0aGUg cHJvcG9zYWwgcmlnaHQgbm93LCB3ZSBhcmUgZm9yY2luZyBIb0wgYmxvY2tpbmcgZm9yIGJvdGgg SFRUUCBhbmQgbm9uLUhUVFAgc3RyZWFtcyBieSBtYWtpbmcgdGhlIGFzc3VtcHRpb24gdGhhdCBk YXRhIGNhbm5vdCBiZSBpbnRlcnByZXRlZCB3aXRob3V0IHRoZSBmaXJzdCBmZXcgYnl0ZXMuPGJy Pg0KPGJyPg0KPGJyPg0KSSBndWVzcyBpdCBhbGwgY29tZXMgZG93biB0bzo8YnI+DQombmJzcDsm bmJzcDsgV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiB0aGUgcHJvcG9zYWwgdGhhdCBvdXR3ZWlnaHMg dGhlIHBvdGVudGlhbCBsb3NzPzxicj4NCmFuZDxicj4NCiZuYnNwOyBXaGF0IGlzIHRoZSBjb3N0 IG9mIGJ1cm5pbmcgYSBjb2RlcG9pbnQgKGFzIGEgZnJhbWUtdHlwZSkgdG8gcHJldmVudCB0aGUg cG90ZW50aWFsIGxvc3M/PGJyPg0KPGJyPg0KSXQgc2VlbXMgbGlrZSB0aGUgYmVuZWZpdCBvZiB3 aGF0IHdl4oCZcmUgZG9pbmcgaXMgdG8gbm9ybWFsaXplIFFQQUNL4oCZcyBzdHJlYW1zIHdpdGgg ZXZlcnl0aGluZyBlbHNlL21ha2UgUVBBQ0sgc3RyZWFtcyYjNDM7c3RyZWFtSURzIG5vdCBzcGVj aWFsLjxicj4NCkkgbGlrZSB0aGUgaWRlYSBvZiBhIHNlbGYtZGVzY3JpcHRpdmUgc3RyZWFtLXR5 cGUtLSBpbiBwYXJ0aWN1bGFyLCBJIGxpa2UgdGhlIGlkZWEgb2YgdGhlIHNlbGYtZGVzY3JpcHRp dmUgc3RyZWFtLXR5cGUgYmVjYXVzZSBpdCBhbGxvd3MgYSBmYWlybHkgb2J2aW91cyAocG90ZW50 aWFsIGZ1dHVyZSkgbWFwcGluZyBvZiBtdWx0aXBsZSBRUEFDSyBjb250ZXh0cyBvbnRvIGEgc2lu Z2xlIGNvbm5lY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PVE9I LCBJIGhhdGUgdGhhdCB3ZeKAmWQgZm9yY2UgYWxsIEhUVFAgdW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBpbnRvIGl0IHdoZW4gd2UgY2FuIGRlZmluZSB1c2VjYXNlcyB0aGF0IHdvdWxkIGJlIGltcGFj dGVkIGJ5IHRoYXQgZGVjaXNpb24uPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5NaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAyMCwgMjAxOCBhdCA5OjMyIEFNPGJy Pg0KPGI+VG86IDwvYj5NYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29t Jmd0OywgUm9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5R VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogUGF0 aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBhZ3JlZS4mbmJzcDsgVGhpcyBpcyBhbHJl YWR5IGEgcHJvcGVydHkgb2YgdXNpbmcgZnJhbWVzLiZuYnNwOyBKdXN0IGxpa2UgdGhlIHZpZGVv IGl0c2VsZiBjb25zaXN0aW5nIG9mIGJvdGggc3RydWN0dXJlIGFuZCBjb250ZW50LCB5b3UgaGF2 ZSB0byBmaW5kIHRoZSBmcmFtZSBoZWFkZXIgKGFuZCB0aGVyZWZvcmUgaXRzIGxlbmd0aCkgZmly c3QuJm5ic3A7IE9uY2UgeW91IGhhdmUgdGhhdCwgeW91IGNhbiBkbyB0d28gdGhpbmdzOjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj5SYW5k b20gYWNjZXNzIGFueXdoZXJlIHdpdGhpbiB0aGF0IGZyYW1lPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPkxvY2F0 ZSB0aGUgaGVhZGVyIG9mIHRoZSBuZXh0IGZyYW1lIGFuZCBiZWdpbiBpbnRlcnByZXRpbmcgaXQs IGlmIHRoYXTigJlzIHJlY2VpdmVkIGZpcnN0PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkhvd2V2ZXIsIHJlbW92aW5nIGJsb2NraW5nIG9uIHRoZSBmcmFtZSBoZWFkZXIgZW50 aXJlbHkgaXMgYSBwcmV0dHkgc3Vic3RhbnRpYWwgY2hhbmdlIChhbmQgcHJvYmFibHkgbG9va3Mg YSBsb3QgbGlrZSBIVFRQL1FVSUMgLTAxIG9yIHNvLCB3aXRoIGEgZGVkaWNhdGVkIHN0cmVhbSBm b3IgZGF0YSkuJm5ic3A7IEkgZG9u4oCZdCBmZWVsIGxpa2UgYmxvY2tpbmcgb24gdGhlIGZpcnN0 IGJ5dGUgaXMgbmVjZXNzYXJpbHkNCiBhbnkgZGlmZmVyZW50IGZyb20gYmxvY2tpbmcgb24gdGhl IGZpcnN0IGZyYW1lIGhlYWRlciB3aGljaCBpbW1lZGlhdGVseSBmb2xsb3dzIGl0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSA8YnI+ DQpTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDU6MjkgUE08YnI+DQpUbzogUm9iZXJ0byBQ ZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7PGJyPg0KQ2M6IE1pa2UgQmlzaG9wICZsdDttYmlzaG9w QGV2ZXF1ZWZvdS5iZSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3Vi amVjdDogUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPk9uIFdlZCwgSnVuIDIwLCAyMDE4IGF0IDEwOjIxIEFNIFJvYmVydG8g UGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmZlbml4QGZiLmNvbTwvc3Bhbj48L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg SG93ZXZlciwgaWYgb25lIG11c3QgcmVjZWl2ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3Ry ZWFtLCBhZGRpdGlvbmFsIEhvTCBibG9ja2luZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2svaW50 ZXJwcmV0YXRpb24pIGlzIGluZHVjZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo aXMgaXMgdGhlIGJpdCBJJ20gcHVzaGluZyBiYWNrIG9uLiZuYnNwOyBUaGUgZmlyc3QgYnl0ZSBp c24ndCBwcml2aWxlZ2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhlcmUncyBhIHB1c2ggSUQsIGEgSEVBREVSUyBmcmFtZSwgYW5kIHRoZSBzdGFydCBvZiB0aGUg Zmlyc3QgREFUQSBmcmFtZSBiZWZvcmUgeW91IGNhbiBzdGFydCBpbnRvIHJhbmRvbSBhY2Nlc3Mu Jm5ic3A7IFdpdGhvdXQgdGhhdCwgeW91IGNhbid0IGtub3cgd2hhdCB5b3UgYXJlIHJlYWRpbmcu Jm5ic3A7IEkgZmFpbCB0byBzZWUgaG93IG9uZSBhZGRpdGlvbmFsIG9jdGV0IGlzIGEgcHJvYmxl bSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_751301019A7C4B54BEE7202CD46DDFE4fbcom_-- From nobody Wed Jun 20 15:05:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD68130EC7 for ; Wed, 20 Jun 2018 15:05:34 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=J7pF3yPH; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CNZ85xx0 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 8nfYZvtijUQr for ; Wed, 20 Jun 2018 15:05:32 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 47B71130EBF for ; Wed, 20 Jun 2018 15:05:32 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w5KLxrdw023120; Wed, 20 Jun 2018 15:05:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=AYhgZeQdUiYc5sQibej3LkpgdjSqgxey8lMIrAtCXjs=; b=J7pF3yPHpc0IIbRMAiCkGqvVdbY2MI+o9yfPLhZ35bHdPCu3tJd8ddMLDT7r8JwjdYL8 1pUF6e1WifGHQJr/WkHhW95Xx25eVmXaIecZOb6tCHU16IEcLzfv4yTyFVcnk5eApVgR Ss/3M5NoLpad0lwNo2dLvjYoxZPdHbCFVkk= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2jqstvs3rm-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 15:05:28 -0700 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 20 Jun 2018 15:05:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AYhgZeQdUiYc5sQibej3LkpgdjSqgxey8lMIrAtCXjs=; b=CNZ85xx0Tzyv5+sPuo099ph+Gol0zb5rcOF7y3QZu8SzCm7t4uo75rjzSnW8Sb0iZ8NLbR5pmEYfpSGE3XHsNcdSZijCo3uj2KXZiDdpeD2Go4UmUFtTH6j+gpwEOv7xGOMJtn6iV+bamt85J6cI81b+bHYfimAiO/fOqLYk06s= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2342.namprd15.prod.outlook.com (52.135.197.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Wed, 20 Jun 2018 22:05:26 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 22:05:26 +0000 From: Roberto Peon To: Mike Bishop , Martin Thomson CC: QUIC WG Subject: Re: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAR9VgP//lAsAgAB3mgCAAKkoAP//RDTQACDvdYA= Date: Wed, 20 Jun 2018 22:05:25 +0000 Message-ID: <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:200::7:c553] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2342; 7:bfQNgBJL9AddAPXOxbWPlUWsabFpOpkiSqOPcscTVcqX+cU9OSe+aY6+E/o85vklb05Fua0qItNyje/t3hFwjMTZQxANazg5wFI6C/mY6w/UnZCl7nPxQOlC6atbf2e3EW1/Ehh4Cj3Y/Ga255/d9cCJ3TaDp9sSr43YaJ3Fl+DysHI+XVk52kQWz4Ud+NweH2Q04PAz7pc/KV/6W1mwE5PDSJTcvarh/wyQrF2y8I9XM86lPVWn6/6LLz4D/BcM; 20:yAC5oyM8yGBYFxOwnCqM2HfgfKbcsR8Nc34JmMKSHXCMGYCCzJgJkR7Np4nPyhnRt6/OieQ57RvAmyJdso5IywxIkUdCoy65vrUe6jmS5OpGCCABQL3F7GE3araNtY0yJVfaWbBHs6jgxOwWI+9TXDr9PBAcRYR8SXPzbfoj+Jc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6f785749-8c07-4f0e-bb55-08d5d6f9ed66 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2342; x-ms-traffictypediagnostic: BYAPR15MB2342: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2342; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2342; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(39860400002)(396003)(346002)(366004)(13464003)(189003)(199004)(8936002)(2906002)(5660300001)(316002)(36756003)(6486002)(6512007)(6436002)(58126008)(68736007)(6116002)(99286004)(5250100002)(229853002)(110136005)(2900100001)(186003)(25786009)(86362001)(97736004)(83716003)(81166006)(39060400002)(81156014)(53936002)(6506007)(4326008)(53546011)(14454004)(3660700001)(105586002)(102836004)(6246003)(106356001)(478600001)(76176011)(59450400001)(93886005)(46003)(2616005)(11346002)(33656002)(476003)(82746002)(8676002)(446003)(305945005)(7736002)(3280700002)(486006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2342; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lstcbRrPWSt7k4iMqmsSel92YGKv3koFD1L/94+y+yAqKXKJTeNHRP4c9206Jx3XOQljuZSp59HitgwXau0K1+RjC+ngsQoH0WXSJUVsQOrekubT3GmhEdqemAHuZJDwBl+HazyDuxplls74GvbSlyCZmIX/PxzwjmEJtXL8swJNqmel0FTpEy9FHaWKmvDWtUwcDWnLbCtwZ3DIRNDosWZwHBi3NH5LBOXrktqMXpwrVJG5zpjoYF9cOTcnfavHZhbr6B04w9tYbE3k1lzYjsK15eDnvidZh6KCSiQPTpNogqNmVV5R25arRQ7PQ5yYqlZ4JcAKqWOhktmDOrqE8Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <72521DE4503B2E47BF16927170122781@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6f785749-8c07-4f0e-bb55-08d5d6f9ed66 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 22:05:25.9364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2342 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-20_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:05:34 -0000 WWVwLCB5b3UncmUgcmlnaHQsIGJlY2F1c2Ugd2UncmUgbm90IGhhdmluZyBIRUFERVJTIHZzIERB VEEgZnJhbWVzIGFzIGEgUVVJQy1sYXllciB0aGluZywgd2UncmUgc2NyZXdlZC4gDQoNCi09Ug0K DQrvu79PbiA2LzIwLzE4LCAyOjQ4IFBNLCAiTWlrZSBCaXNob3AiIDxtYmlzaG9wQGV2ZXF1ZWZv dS5iZT4gd3JvdGU6DQoNCiAgICBCdXQgeW91IGRvbid0IGtub3cgd2hlcmUgdGhlIGJvZHkgaXMg dW50aWwgeW91J3ZlIHNlZW4gdGhlIGhlYWRlci4gIE90aGVyd2lzZSwgeW91J3JlIG5vdCBjZXJ0 YWluIHRoYXQgd2hhdCB5b3UncmUgc2VlaW5nICppcyogYm9keSwgcmF0aGVyIHRoYW4gc29tZXRo aW5nIGluIGEgZGlmZmVyZW50IGZyYW1lIHRoYXQgaGFwcGVucyB0byBsb29rIGxpa2UgeW91ciBz ZWxmLWRlc2NyaXB0aW9uLg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog ICAgRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhAZmIuY29tXSANCiAgICBTZW50OiBX ZWRuZXNkYXksIEp1bmUgMjAsIDIwMTggMjowMyBQTQ0KICAgIFRvOiBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPg0KICAgIENjOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl dmVxdWVmb3UuYmU+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJlOiBQ YXRoIGZvcndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KICAgIA0KICAgIFlvdSdyZSBhc3N1bWlu ZyB0aGUgZGF0YSBpc24ndCBzZWxmLWRlc2NyaXB0aXZlIGluIHRoZSBib2R5Lg0KICAgIC09Ug0K ICAgIA0KICAgIE9uIDYvMTkvMTgsIDU6MjkgUE0sICJNYXJ0aW4gVGhvbXNvbiIgPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgDQogICAgICAgIE9uIFdlZCwgSnVuIDIwLCAy MDE4IGF0IDEwOjIxIEFNIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPiB3cm90ZToNCiAgICAg ICAgPiBIb3dldmVyLCBpZiBvbmUgbXVzdCByZWNlaXZlIHRoZSBmaXJzdCBwYWNrZXQgb2YgZWFj aCBzdHJlYW0sIGFkZGl0aW9uYWwgSG9MIGJsb2NraW5nICh3aGljaCBwcmV2ZW50cyBwbGF5YmFj ay9pbnRlcnByZXRhdGlvbikgaXMgaW5kdWNlZC4NCiAgICAgICAgDQogICAgICAgIFRoaXMgaXMg dGhlIGJpdCBJJ20gcHVzaGluZyBiYWNrIG9uLiAgVGhlIGZpcnN0IGJ5dGUgaXNuJ3QgcHJpdmls ZWdlZC4NCiAgICAgICAgVGhlcmUncyBhIHB1c2ggSUQsIGEgSEVBREVSUyBmcmFtZSwgYW5kIHRo ZSBzdGFydCBvZiB0aGUgZmlyc3QgREFUQQ0KICAgICAgICBmcmFtZSBiZWZvcmUgeW91IGNhbiBz dGFydCBpbnRvIHJhbmRvbSBhY2Nlc3MuICBXaXRob3V0IHRoYXQsIHlvdQ0KICAgICAgICBjYW4n dCBrbm93IHdoYXQgeW91IGFyZSByZWFkaW5nLiAgSSBmYWlsIHRvIHNlZSBob3cgb25lIGFkZGl0 aW9uYWwNCiAgICAgICAgb2N0ZXQgaXMgYSBwcm9ibGVtIGhlcmUuDQogICAgICAgIA0KICAgIA0K ICAgIA0KDQo= From nobody Wed Jun 20 16:51:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1E130E3D for ; Wed, 20 Jun 2018 16:51:54 -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 ed_bcKA9SnuW for ; Wed, 20 Jun 2018 16:51:49 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 7F368130E46 for ; Wed, 20 Jun 2018 16:51:47 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id a5-v6so1484632otf.12 for ; Wed, 20 Jun 2018 16:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FFIZzfVB5+kpBdePHSH3L2k5UgTRJMrbgnBFitEMvIM=; b=qc1al82UqqFOyUzsbNDP3EJx8Z0y8XIVlxwTE9gg80VdDe3PGYssrdMlUvYise0rgS J0kGmbCCULldFf5vTwS5fEVbYsU71WzWNg9Tw9oFOvPkEd5NF2Ayb7maTLl8a7/ai3rg Xz3rZPJaxabvww86iMOeZfh0sCZ4QzAsIpJvMzSLaf2+46E4U2UG9plaxDHO90l6gyVN 5cX6k1L2hFbHS9x/c19kgEHo4cFmWbtb/YBpFA2KjfvFZjTsCm7f9LpQTzTcTFZg5xG6 cru8AaA3xAKFIWa5WQFa2WTklDTSWAlp/8C4PU+HBtq3W+Ro92nSWJLEnQfxRqCXcX7a 7PwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FFIZzfVB5+kpBdePHSH3L2k5UgTRJMrbgnBFitEMvIM=; b=ki75QEePJ+lECQ0DI3UwmsOL92LLzrDXnxKXkJojiDW6FNXnLoVRXzS05QaBDETztR 5KT0a8Kd2RVe3sWiTJQgrZd1L0SjMWOyYrgIiF7TN1NVcJaXc6wfFjFS80wtT5xYPOKh yT1PaHsweAoaqPfVIhoMwD3S2gc//U3fs6AIU3FX7QXUrmX4AWFUCyNZUPiVmVuxsTzJ B2ADZieIihV3rCslaMFhuRD164InY0gD7kpYUQhnI8JyUcNresxsnOUO0Aj9h21N51aY bL4LAPizIEVAu/E3DnYpb0TQhXB8w6SkQyAVOaI6Qs2O+Ozo2VUUP5Q186777R79uFmL SYUg== X-Gm-Message-State: APt69E0h/7cJJlYEBM1Kbyds68FWuPjEnBqahS2uHouLfgc9cIDN1o4h pTW5nYbtkgiYSvQCYoMrCa67Wzp2TAtTLjLVSJc= X-Google-Smtp-Source: ADUXVKIn7pnhFh8I1WASalOmDy3Ltn9zYXRJFhNv4XrqLTKXnF5fCkqCnFjW026fZTNyVmFbyJ1ZxvjwRtTNQfxBgOo= X-Received: by 2002:a9d:36ca:: with SMTP id s10-v6mr5865015otd.352.1529538706832; Wed, 20 Jun 2018 16:51:46 -0700 (PDT) MIME-Version: 1.0 References: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> In-Reply-To: From: Martin Thomson Date: Thu, 21 Jun 2018 09:51:36 +1000 Message-ID: Subject: Re: PUSH_HEADERS frame To: Mike Bishop Cc: Lucas Pardue , Roberto Peon , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:51:55 -0000 I agree with Mike. FWIW, implementing push is trivial as a result of it using the same framing as requests and responses; I would be opposed to changing that. On Thu, Jun 21, 2018 at 4:58 AM Mike Bishop wrote: > > Philosophically, I'd go a step further and say that, as in the PR, the se= mantics of the stream are entirely determined by the type byte. Any intern= al divisions of regions within the bytestream are as needed by that type an= d defined by it. Some, like the QPACK stream, won't actually need divided = regions. > > The fact that push streams and control streams subdivide their regions us= ing frames from the same type space as request streams is somewhere between= a convenience due to push's similarity to things we already have (response= s) and a historical legacy of H2. There's no reason they would need to do = so; there's just also no real reason to change. > > -----Original Message----- > From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] > Sent: Wednesday, June 20, 2018 11:28 AM > To: Mike Bishop ; Martin Thomson ; Roberto Peon > Cc: QUIC WG > Subject: RE: PUSH_HEADERS frame > > Thanks for the feedback. To be clear, I'm in favor of typed streams but t= o play devils advocate. > > > Unidirectional streams aren't required to use HTTP/QUIC frames; > > QPACK aside, the only examples we have use frames. So the question is: do= we think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC = extension point? > > Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Heade= r Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. Th= e main difference with push is that the stream ID cannot be used to correla= te request and response. So we use a push ID that is framed everywhere *exc= ept* the push delivery stream. PUSH_HEADERS is a more honest approach to th= is quirk (at some small framing inconvenience), everything relevant to the = Header Block is bundled together. It acts as a stream reservation mechanism= that ties push response data, with request and response headers. > > It doesn't change much: > > Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS) Typed strea= ms: stream type byte + push ID + HEADERS + DATA (+ HEADERS) Untyped and fra= med streams: PUSH_HEADERS (including push ID) + DATA (+HEADERS) > > I could try to make a weak argument that framing helps because you could = at least skip over frames if you get their length but not the rest. The cur= rent design requires the full push ID to be received before HEADERS and DAT= A processing. > > Lucas From nobody Wed Jun 20 17:30:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A961130EE0 for ; Wed, 20 Jun 2018 17:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YUYOIJcB2VQ for ; Wed, 20 Jun 2018 17:30:42 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F48F130EDB for ; Wed, 20 Jun 2018 17:30:41 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5L0UYvZ005821; Thu, 21 Jun 2018 01:30:34 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0389.001; Thu, 21 Jun 2018 01:30:34 +0100 From: Lucas Pardue To: Martin Thomson , Mike Bishop CC: Roberto Peon , QUIC WG Subject: RE: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwAACdGVFAAJIJNAACF8SAAAC5KUl Date: Thu, 21 Jun 2018 00:30:33 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B115@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:30:44 -0000 Well, I only partially buy the simplicity from reusing HEADERS. The client = has juggling to do to parse push ID in order to correlate the response with= request - I'd argue whether it is done inside or outside the frame equally= trivial. Anecdotally, when explaning HTTP/QUIC server push to an audience not tracki= ng WG progress so closely, it has struck people as quite a departure from H= 2 and GQUIC (for the better I might add). FWIW I think typed streams would = make communication easier, as it makes the capability more conspicuous. Lucas ________________________________________ From: Martin Thomson [martin.thomson@gmail.com] Sent: 21 June 2018 00:51 To: Mike Bishop Cc: Lucas Pardue; Roberto Peon; QUIC WG Subject: Re: PUSH_HEADERS frame I agree with Mike. FWIW, implementing push is trivial as a result of it using the same framing as requests and responses; I would be opposed to changing that. On Thu, Jun 21, 2018 at 4:58 AM Mike Bishop wrote: > > Philosophically, I'd go a step further and say that, as in the PR, the se= mantics of the stream are entirely determined by the type byte. Any intern= al divisions of regions within the bytestream are as needed by that type an= d defined by it. Some, like the QPACK stream, won't actually need divided = regions. > > The fact that push streams and control streams subdivide their regions us= ing frames from the same type space as request streams is somewhere between= a convenience due to push's similarity to things we already have (response= s) and a historical legacy of H2. There's no reason they would need to do = so; there's just also no real reason to change. > > -----Original Message----- > From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] > Sent: Wednesday, June 20, 2018 11:28 AM > To: Mike Bishop ; Martin Thomson ; Roberto Peon > Cc: QUIC WG > Subject: RE: PUSH_HEADERS frame > > Thanks for the feedback. To be clear, I'm in favor of typed streams but t= o play devils advocate. > > > Unidirectional streams aren't required to use HTTP/QUIC frames; > > QPACK aside, the only examples we have use frames. So the question is: do= we think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC = extension point? > > Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Heade= r Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. Th= e main difference with push is that the stream ID cannot be used to correla= te request and response. So we use a push ID that is framed everywhere *exc= ept* the push delivery stream. PUSH_HEADERS is a more honest approach to th= is quirk (at some small framing inconvenience), everything relevant to the = Header Block is bundled together. It acts as a stream reservation mechanism= that ties push response data, with request and response headers. > > It doesn't change much: > > Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS) Typed strea= ms: stream type byte + push ID + HEADERS + DATA (+ HEADERS) Untyped and fra= med streams: PUSH_HEADERS (including push ID) + DATA (+HEADERS) > > I could try to make a weak argument that framing helps because you could = at least skip over frames if you get their length but not the rest. The cur= rent design requires the full push ID to be received before HEADERS and DAT= A processing. > > Lucas From nobody Thu Jun 21 10:30:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC05130EF4 for ; Thu, 21 Jun 2018 10:30:34 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=GkzGDLFl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UbudfgIF 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 sVFQVqbz0AGj for ; Thu, 21 Jun 2018 10:30:32 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 DD95C130E19 for ; Thu, 21 Jun 2018 10:30:32 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5LHOPYI016168; Thu, 21 Jun 2018 10:30:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=c2ilMuuIAZq3yz99QVTu5ahIlzMEdcT///RfeV7GSIc=; b=GkzGDLFlLAehVzyEjmcYUtyxI75/hqHmqqi4LbJQki49N8ikQ/fhkEcxtLJ5gsZ2VKoT g064wBHjwf0/LuFRG1JOGI2Ycb6+5JVskwa7T3lGFBdJmqQy5Egw/sPYj2WSwXSx44L7 Iv8RjypYDGSTXeNOXC33cr8VQxbIPIE0JX0= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jrg7381uy-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2018 10:30:26 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 21 Jun 2018 13:30:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c2ilMuuIAZq3yz99QVTu5ahIlzMEdcT///RfeV7GSIc=; b=UbudfgIFO6JiGFpdM3D0SKrjpH+khRsk6jG4P1Er4Gn244rbSLtLt3IunN/bgFpbNNBirn9E8NOZk7paDI2wXtt7aRtRB8w0asCSui3hgvm3PTYxEsNIhFlRzIxu+rWD8kUe6o9lBG+HmNFsyw3sbk35vSjyOSIyjjaE3TLAgnY= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2326.namprd15.prod.outlook.com (52.135.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Thu, 21 Jun 2018 17:30:22 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::6597:ce9d:39a9:6851%2]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 17:30:22 +0000 From: Roberto Peon To: Lucas Pardue , Martin Thomson , Mike Bishop CC: QUIC WG Subject: Re: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwAACdGVFAAJIJNAACneDAAABXD6AABTyoYA= Date: Thu, 21 Jun 2018 17:30:22 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B115@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B115@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [2620:10d:c090:200::7:c553] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2326; 7:69NUT21ynU+WlkBlfv9zk1vaPbp48/hkoKcE2CQOOosZPhtZs0bbPsAnq529qTLu1jwzRNUajatesYHe7SupcTmIocpmUI0Hsb9j2oui9OXm/lML6GhMAFdqw349kgX2Aq7Fn2a4eAMa303MwH4z/+irDupGeeLHUwovv/qapn7huWQUl+mcFseK4jFU46TyDpN9zm5OnULA1l6hNDZwWJ12wxjI/Jy1RwnibZxjQbPAX1kQKLYlgLF7GUmIxZ9r; 20:S6v9Xzx3Lfd7YrYHVykhTuPRPn5Sxe7cNG0njo62uH1FEBsziBR7Pz1pah0pwr6trl/L2Xw2u2ykw4yuFPQNK7bu/d211CreZgRSmJIAq8H9VqExSSNwGnr+EDnluZfTxifAZyvRJ8F/W7D3Cngm+cq0ebQAXKdI0V0Xmxiwr4A= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c61b6e17-1fcf-4c94-a372-08d5d79caafb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2326; x-ms-traffictypediagnostic: BYAPR15MB2326: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(67672495146484)(127952516941037)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR15MB2326; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2326; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(39380400002)(396003)(366004)(13464003)(189003)(199004)(51914003)(6506007)(11346002)(76176011)(53936002)(25786009)(3280700002)(46003)(5250100002)(81166006)(81156014)(186003)(58126008)(110136005)(316002)(93886005)(2906002)(486006)(39060400002)(476003)(53546011)(83716003)(36756003)(446003)(59450400001)(99286004)(4326008)(102836004)(2900100001)(2616005)(3660700001)(82746002)(6246003)(105586002)(478600001)(97736004)(6436002)(8936002)(86362001)(14454004)(6512007)(7736002)(305945005)(33656002)(7116003)(8676002)(68736007)(6116002)(106356001)(6486002)(5660300001)(229853002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2326; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MEGTHyMiI7pAducLooexXDN4+XAlNKUPBUZ8uKaCLG2xRfGs5dLYqNBeE+5MmR6n0QqIwdGlFfnO1a3e/oPjQ/ddsfgv/SNGOnFYKcnuvVy8Bt7lxoMaGPrcRSh/qVopjYZdlCR8KaiP+KblFh7nP7TKeSpLsHFv7G7jZ0k/39Ytv5At8gQHGcRsdDHwS5eO8pzqgVQyiOn5H0dIztvhCujqZXeB96vXDPVUEZIjXzJpHtrn4yNF/TF7jmOfEx+ZlXFxyMFh/mYIUZfRmD2yJEoZhTNAbQNOnjShJrsYzAeudbcDgYDlBNwcu8eA6+nvRGdmkEdkIyZYX+IBwtTOhA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <937642BB0F782A45A549F48C0F01B2B8@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c61b6e17-1fcf-4c94-a372-08d5d79caafb X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 17:30:22.4562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2326 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 17:30:35 -0000 QXMgTWlrZSBzaG93ZWQsIHR5cGVkIGZyYW1lcyBhbmQgdHlwZWQgc3RyZWFtcyBhcmUgdmVyeSBt dWNoIG5vdCB0aGUgc2FtZS4NCkx1Y2FzLCBhcmUgeW91IGFyZ3VpbmcgZm9yIHR5cGVkICpmcmFt ZXMqIG9yIHR5cGVkICpzdHJlYW1zKj8NCi09Ug0KDQrvu79PbiA2LzIwLzE4LCA1OjMxIFBNLCAi THVjYXMgUGFyZHVlIiA8THVjYXMuUGFyZHVlQGJiYy5jby51az4gd3JvdGU6DQoNCiAgICBXZWxs LCBJIG9ubHkgcGFydGlhbGx5IGJ1eSB0aGUgc2ltcGxpY2l0eSBmcm9tIHJldXNpbmcgSEVBREVS Uy4gVGhlIGNsaWVudCBoYXMganVnZ2xpbmcgdG8gZG8gdG8gcGFyc2UgcHVzaCBJRCBpbiBvcmRl ciB0byBjb3JyZWxhdGUgdGhlIHJlc3BvbnNlIHdpdGggcmVxdWVzdCAtIEknZCBhcmd1ZSB3aGV0 aGVyIGl0IGlzIGRvbmUgaW5zaWRlIG9yIG91dHNpZGUgdGhlIGZyYW1lIGVxdWFsbHkgdHJpdmlh bC4NCiAgICANCiAgICBBbmVjZG90YWxseSwgd2hlbiBleHBsYW5pbmcgSFRUUC9RVUlDIHNlcnZl ciBwdXNoIHRvIGFuIGF1ZGllbmNlIG5vdCB0cmFja2luZyBXRyBwcm9ncmVzcyBzbyBjbG9zZWx5 LCBpdCBoYXMgc3RydWNrIHBlb3BsZSBhcyBxdWl0ZSBhIGRlcGFydHVyZSBmcm9tIEgyIGFuZCBH UVVJQyAoZm9yIHRoZSBiZXR0ZXIgSSBtaWdodCBhZGQpLiBGV0lXIEkgdGhpbmsgdHlwZWQgc3Ry ZWFtcyB3b3VsZCBtYWtlIGNvbW11bmljYXRpb24gZWFzaWVyLCBhcyBpdCBtYWtlcyB0aGUgY2Fw YWJpbGl0eSBtb3JlIGNvbnNwaWN1b3VzLg0KICAgIA0KICAgIEx1Y2FzDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIEZyb206IE1hcnRpbiBUaG9tc29u IFttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQogICAgU2VudDogMjEgSnVuZSAyMDE4IDAwOjUx DQogICAgVG86IE1pa2UgQmlzaG9wDQogICAgQ2M6IEx1Y2FzIFBhcmR1ZTsgUm9iZXJ0byBQZW9u OyBRVUlDIFdHDQogICAgU3ViamVjdDogUmU6IFBVU0hfSEVBREVSUyBmcmFtZQ0KICAgIA0KICAg IEkgYWdyZWUgd2l0aCBNaWtlLiAgRldJVywgaW1wbGVtZW50aW5nIHB1c2ggaXMgdHJpdmlhbCBh cyBhIHJlc3VsdCBvZg0KICAgIGl0IHVzaW5nIHRoZSBzYW1lIGZyYW1pbmcgYXMgcmVxdWVzdHMg YW5kIHJlc3BvbnNlczsgSSB3b3VsZCBiZQ0KICAgIG9wcG9zZWQgdG8gY2hhbmdpbmcgdGhhdC4N CiAgICBPbiBUaHUsIEp1biAyMSwgMjAxOCBhdCA0OjU4IEFNIE1pa2UgQmlzaG9wIDxtYmlzaG9w QGV2ZXF1ZWZvdS5iZT4gd3JvdGU6DQogICAgPg0KICAgID4gUGhpbG9zb3BoaWNhbGx5LCBJJ2Qg Z28gYSBzdGVwIGZ1cnRoZXIgYW5kIHNheSB0aGF0LCBhcyBpbiB0aGUgUFIsIHRoZSBzZW1hbnRp Y3Mgb2YgdGhlIHN0cmVhbSBhcmUgZW50aXJlbHkgZGV0ZXJtaW5lZCBieSB0aGUgdHlwZSBieXRl LiAgQW55IGludGVybmFsIGRpdmlzaW9ucyBvZiByZWdpb25zIHdpdGhpbiB0aGUgYnl0ZXN0cmVh bSBhcmUgYXMgbmVlZGVkIGJ5IHRoYXQgdHlwZSBhbmQgZGVmaW5lZCBieSBpdC4gIFNvbWUsIGxp a2UgdGhlIFFQQUNLIHN0cmVhbSwgd29uJ3QgYWN0dWFsbHkgbmVlZCBkaXZpZGVkIHJlZ2lvbnMu DQogICAgPg0KICAgID4gVGhlIGZhY3QgdGhhdCBwdXNoIHN0cmVhbXMgYW5kIGNvbnRyb2wgc3Ry ZWFtcyBzdWJkaXZpZGUgdGhlaXIgcmVnaW9ucyB1c2luZyBmcmFtZXMgZnJvbSB0aGUgc2FtZSB0 eXBlIHNwYWNlIGFzIHJlcXVlc3Qgc3RyZWFtcyBpcyBzb21ld2hlcmUgYmV0d2VlbiBhIGNvbnZl bmllbmNlIGR1ZSB0byBwdXNoJ3Mgc2ltaWxhcml0eSB0byB0aGluZ3Mgd2UgYWxyZWFkeSBoYXZl IChyZXNwb25zZXMpIGFuZCBhIGhpc3RvcmljYWwgbGVnYWN5IG9mIEgyLiAgVGhlcmUncyBubyBy ZWFzb24gdGhleSB3b3VsZCBuZWVkIHRvIGRvIHNvOyB0aGVyZSdzIGp1c3QgYWxzbyBubyByZWFs IHJlYXNvbiB0byBjaGFuZ2UuDQogICAgPg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICA+IEZyb206IEx1Y2FzIFBhcmR1ZSBbbWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28u dWtdDQogICAgPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTggMTE6MjggQU0NCiAgICA+ IFRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQog ICAgPiBDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NCiAgICA+IFN1YmplY3Q6IFJFOiBQVVNI X0hFQURFUlMgZnJhbWUNCiAgICA+DQogICAgPiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gVG8g YmUgY2xlYXIsIEknbSBpbiBmYXZvciBvZiB0eXBlZCBzdHJlYW1zIGJ1dCB0byBwbGF5IGRldmls cyBhZHZvY2F0ZS4NCiAgICA+DQogICAgPiA+IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlbid0 IHJlcXVpcmVkIHRvIHVzZSBIVFRQL1FVSUMgZnJhbWVzOw0KICAgID4NCiAgICA+IFFQQUNLIGFz aWRlLCB0aGUgb25seSBleGFtcGxlcyB3ZSBoYXZlIHVzZSBmcmFtZXMuIFNvIHRoZSBxdWVzdGlv biBpczogZG8gd2UgdGhpbmsgaXQgaXMgaW4gc2NvcGUgdG8gc3VwcG9ydCB1bi1mcmFtZWQgU1RS RUFNIGJ5dGVzIGFzIGFuIEhUVFAvUVVJQyBleHRlbnNpb24gcG9pbnQ/DQogICAgPg0KICAgID4g QmFjayB0byBQVVNIX0hFQURFUlMsIHRoZSBjaGFuZ2UgaXMgYSBzdWJ0bGUgb25lLiBJJ2QgaGln aGxpZ2h0IHRoZSBIZWFkZXIgQmxvY2ssIHdoaWNoIHByZXNlbnRseSBoYXMgdHdvIGJlYXJlciBm cmFtZXMgSEVBREVSUyBhbmQgUFVTSF9QUk9NSVNFLiBUaGUgbWFpbiBkaWZmZXJlbmNlIHdpdGgg cHVzaCBpcyB0aGF0IHRoZSBzdHJlYW0gSUQgY2Fubm90IGJlIHVzZWQgdG8gY29ycmVsYXRlIHJl cXVlc3QgYW5kIHJlc3BvbnNlLiBTbyB3ZSB1c2UgYSBwdXNoIElEIHRoYXQgaXMgZnJhbWVkIGV2 ZXJ5d2hlcmUgKmV4Y2VwdCogdGhlIHB1c2ggZGVsaXZlcnkgc3RyZWFtLiBQVVNIX0hFQURFUlMg aXMgYSBtb3JlIGhvbmVzdCBhcHByb2FjaCB0byB0aGlzIHF1aXJrIChhdCBzb21lIHNtYWxsIGZy YW1pbmcgaW5jb252ZW5pZW5jZSksIGV2ZXJ5dGhpbmcgcmVsZXZhbnQgdG8gdGhlIEhlYWRlciBC bG9jayBpcyBidW5kbGVkIHRvZ2V0aGVyLiBJdCBhY3RzIGFzIGEgc3RyZWFtIHJlc2VydmF0aW9u IG1lY2hhbmlzbSB0aGF0IHRpZXMgcHVzaCByZXNwb25zZSBkYXRhLCB3aXRoIHJlcXVlc3QgYW5k IHJlc3BvbnNlIGhlYWRlcnMuDQogICAgPg0KICAgID4gSXQgZG9lc24ndCBjaGFuZ2UgbXVjaDoN CiAgICA+DQogICAgPiBVbnR5cGVkIHN0cmVhbXMgKHRvZGF5KTogcHVzaCBJRCArIEhFQURFUlMg KyBEQVRBICgrIEhFQURFUlMpIFR5cGVkIHN0cmVhbXM6IHN0cmVhbSB0eXBlIGJ5dGUgKyBwdXNo IElEICsgSEVBREVSUyArIERBVEEgKCsgSEVBREVSUykgVW50eXBlZCBhbmQgZnJhbWVkIHN0cmVh bXM6ICBQVVNIX0hFQURFUlMgKGluY2x1ZGluZyBwdXNoIElEKSArIERBVEEgKCtIRUFERVJTKQ0K ICAgID4NCiAgICA+IEkgY291bGQgdHJ5IHRvIG1ha2UgYSB3ZWFrIGFyZ3VtZW50IHRoYXQgZnJh bWluZyBoZWxwcyBiZWNhdXNlIHlvdSBjb3VsZCBhdCBsZWFzdCBza2lwIG92ZXIgZnJhbWVzIGlm IHlvdSBnZXQgdGhlaXIgbGVuZ3RoIGJ1dCBub3QgdGhlIHJlc3QuIFRoZSBjdXJyZW50IGRlc2ln biByZXF1aXJlcyB0aGUgZnVsbCBwdXNoIElEIHRvIGJlIHJlY2VpdmVkIGJlZm9yZSBIRUFERVJT IGFuZCBEQVRBIHByb2Nlc3NpbmcuDQogICAgPg0KICAgID4gTHVjYXMNCiAgICANCg0K From nobody Thu Jun 21 11:08:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86B412F1A6 for ; Thu, 21 Jun 2018 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bocz3KGvOgVk for ; Thu, 21 Jun 2018 11:08:43 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984E0124C04 for ; Thu, 21 Jun 2018 11:08:42 -0700 (PDT) Received: from BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5LI8X0Y019732; Thu, 21 Jun 2018 19:08:33 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.03.0389.001; Thu, 21 Jun 2018 19:08:33 +0100 From: Lucas Pardue To: Roberto Peon , Martin Thomson , Mike Bishop CC: QUIC WG Subject: RE: PUSH_HEADERS frame Thread-Topic: PUSH_HEADERS frame Thread-Index: AdQItM9/wr2FRkmcSU6cCT2bnOJHwAACdGVFAAJIJNAACF8SAAAC5KUlACIVeAAAAyZcvA== Date: Thu, 21 Jun 2018 18:08:33 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B23B@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BB58F3A@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B115@bgb01xud1012>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23922.000 x-tm-as-result: No-8.986800-8.000000-10 x-tmase-matchedrid: cgbqQT5W8he7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p1QKAQSutQYXMX+ rw9BJFvkwj/YNxEfqolzxvUqN7uOVOyt+a9Mtf+eoprTEHvewADjmgMQ17h562Ek/mdKoRi5D+A 3vN265hecs+AAiy/A+HohyeDbLUuCn/KiuQleQIW8coKUcaOOvVT5iq0BT4XZ2oLGTNKlb9dYpc rLTXioByu9v6J5hdMYgDLqnrRlXrboYnQQ+lY28ZRMZUCEHkRt x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--8.986800-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23922.000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:08:45 -0000 I'm arguing against the middle ground we currently have. So either typed st= reams, or extensions as untyped streams with HTTP framing to support disamb= iguation. The downside of mandatory framing is it prevents unexplored use cases. P.s. Another place to unframed data is the CONNECT method, exchange STREAM = frames rather than DATA. Lucas ________________________________________ From: Roberto Peon [fenix@fb.com] Sent: 21 June 2018 18:30 To: Lucas Pardue; Martin Thomson; Mike Bishop Cc: QUIC WG Subject: Re: PUSH_HEADERS frame As Mike showed, typed frames and typed streams are very much not the same. Lucas, are you arguing for typed *frames* or typed *streams*? -=3DR ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Thu Jun 21 12:37:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C78130EC5 for ; Thu, 21 Jun 2018 12:37:51 -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 yxtYAgL5cYB0 for ; Thu, 21 Jun 2018 12:37:49 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24722130DFA for ; Thu, 21 Jun 2018 12:37:49 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id l19-v6so4058394ioj.5 for ; Thu, 21 Jun 2018 12:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DcVXiwvG5r1mrREiNYqa9B5QecCoXXNOFNNkAH/hObY=; b=MZR38wsN0ARc53zUwbcOXj16VrMP76Xm8Dn+8QknnBMJb19nWQE3hhJd0IOEiIi8AV Y/jXzmCqEIXE3p05ZFJyxN52GCV6l4OBb5CbJfi0/L8MDK5erjZtbONfxOdw2KUGdi+V a57WoNKKOXX8djPmZsZD1x7/UxYYuKwMAMjgszm0Yqcxdav9M0z8mXgamWgaBXG7E1Qi +nlV1eKBVWIHRlJnNJG2S5LjUUZUDoWGTMmqrvMY+O0qMFZvngjsrBcIEvAkOPKgaM6i oiM5BuhXijognhiABSmpRyqQfBYIgTIO4XB/HCWQ8fQpC0/b+T9JLlRjh+/Q7Fk8TXbY Agww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DcVXiwvG5r1mrREiNYqa9B5QecCoXXNOFNNkAH/hObY=; b=p4hg0OHviMQejP+f79FoCPmzGTpmtpSGUfa/cVrwR+tdwdPBCCxBaBtPhw1ZBTFSgQ AfTJYFdJq3TXNvBRer4kC0LTB7Md9gWVjD7X7MJxe2gYKz3rX9C7qJZ8zr/RLX4RoogR kfbQhG/NC3MiRuvabGuNMhbeUuhizXJw5iq3ydi9xTUpdIe5BK/vP3sbl5n6a72r0S+h uKVbo25VzWl4YqPNPBDaferT2wGtdeOjG+k57NhUM9N5rUTK7vF8a/6vB2rliVeaKyg0 FN2Haq98I+yMW11QZc2cZsYZaYkaD8MnN6J4bK6/lg/Lg9q6HPjUzz5ixfQINJ4m7yFo 6QGQ== X-Gm-Message-State: APt69E2OQtDoBExTIprz0Y0gZgop6esYdCkuOU56q4zXNWPyhy1tIK/5 9JTYCP+4DaJ4kLgF3vltIjC6NLNTu3pg4rAYrcI= X-Google-Smtp-Source: ADUXVKJiNay9wxpEauou7nHNbo4IKCIjQxxuh39iHhTO1V1Vr2ANrhjh8u6NJc9QcnqrSg5ajfBLTrzyIkvsoQz44qc= X-Received: by 2002:a6b:1502:: with SMTP id 2-v6mr23254611iov.203.1529609868352; Thu, 21 Jun 2018 12:37:48 -0700 (PDT) MIME-Version: 1.0 References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com> In-Reply-To: <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com> From: Jana Iyengar Date: Thu, 21 Jun 2018 12:37:33 -0700 Message-ID: Subject: Re: Path forward with stream headers To: Roberto Peon Cc: Mike Bishop , Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000d9254c056f2c0c2e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:37:52 -0000 --000000000000d9254c056f2c0c2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike's point that the HTTP headers need to be read before reading data from a stream out of order makes it clear that the first bytes are already HoL blocking in this current mapping. Given the current mapping, while I'm sympathetic to Roberto's argument that there are use cases where an application might want to read data out of order from a stream, I don't see additional HoL blocking because of this byte. That said, I like the self-descriptiveness of the stream ID. Even for debugging purposes, it's a matter of training yourself to understand what stream IDs mean what type of stream, but once that's done, it's always true for QUICv1. Having looked at a large number of GQUIC traces, I can say that being able to tell at a glance what a particular stream ID across traces is very useful (In GQUIC, stream 1 is crypto, stream 3 is headers, and stream 5 is the first request stream from the client). With a type byte, debuggability is worse, since you now must see the first byte and remember what stream ID maps to what for the rest of the connection, and you need to do this for every connection you're looking at. Given my experience, I would prefer having stream IDs that are self descriptive. I understand the desire to keep this flexible for future tweaks of HTTP/QUIC without a version rev, but it is a degree of freedom that we can surely plan to exercise for things we cannot anticipate right now. I'm not yet convinced that adding this additional extensibility mechanism is necessary right now. On Wed, Jun 20, 2018 at 3:05 PM Roberto Peon wrote: > Yep, you're right, because we're not having HEADERS vs DATA frames as a > QUIC-layer thing, we're screwed. > > -=3DR > > =EF=BB=BFOn 6/20/18, 2:48 PM, "Mike Bishop" wrote: > > But you don't know where the body is until you've seen the header. > Otherwise, you're not certain that what you're seeing *is* body, rather > than something in a different frame that happens to look like your > self-description. > > -----Original Message----- > From: Roberto Peon [mailto:fenix@fb.com] > Sent: Wednesday, June 20, 2018 2:03 PM > To: Martin Thomson > Cc: Mike Bishop ; QUIC WG > Subject: Re: Path forward with stream headers > > You're assuming the data isn't self-descriptive in the body. > -=3DR > > On 6/19/18, 5:29 PM, "Martin Thomson" > wrote: > > On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon > wrote: > > However, if one must receive the first packet of each stream, > additional HoL blocking (which prevents playback/interpretation) is induc= ed. > > This is the bit I'm pushing back on. The first byte isn't > privileged. > There's a push ID, a HEADERS frame, and the start of the first DA= TA > frame before you can start into random access. Without that, you > can't know what you are reading. I fail to see how one additiona= l > octet is a problem here. > > > > > --000000000000d9254c056f2c0c2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike's point that the HTTP headers need to be read bef= ore reading data from a stream out of order makes it clear that the first b= ytes are already HoL blocking in this current mapping. Given the current ma= pping, while=C2=A0I'm sympathetic to Roberto= 's argument that there are use cases where an application might want to= read data out of order from a stream,=C2=A0I don't see addition= al HoL blocking because of this byte.

That said, I like = the self-descriptiveness of the stream ID. Even for debugging purposes, it&= #39;s a matter of training yourself to understand what stream IDs mean what= type of stream, but once that's done, it's always true for QUICv1.= Having looked at a large number of GQUIC traces, I can say that being able= to tell at a glance what a particular stream ID across traces is very usef= ul (In GQUIC, stream 1 is crypto, stream 3 is headers, and stream 5 is the first request = stream from the client).=C2=A0=C2=A0With a type byte, debuggability is worse, sinc= e you now must see the first byte and remember what stream ID maps to what = for the rest of the connection, and you need to do this for every connectio= n you're looking at.

Given my experience, I would prefer = having stream IDs that are self descriptive.

I understand the desir= e to keep this flexible for future tweaks of HTTP/QUIC without a version re= v, but it is a degree of freedom that we can surely plan to exercise for th= ings we cannot anticipate right now. I'm not yet convinced that adding = this additional extensibility mechanism is necessary right now.
<= br>

On Wed, Jun = 20, 2018 at 3:05 PM Roberto Peon <fenix@= fb.com> wrote:
Yep, you'= re right, because we're not having HEADERS vs DATA frames as a QUIC-lay= er thing, we're screwed.

-=3DR

=EF=BB=BFOn 6/20/18, 2:48 PM, "Mike Bishop" <mbishop@evequefou.be> wrote= :

=C2=A0 =C2=A0 But you don't know where the body is until you've see= n the header.=C2=A0 Otherwise, you're not certain that what you're = seeing *is* body, rather than something in a different frame that happens t= o look like your self-description.

=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: Roberto Peon [mailto:fenix@fb.com]
=C2=A0 =C2=A0 Sent: Wednesday, June 20, 2018 2:03 PM
=C2=A0 =C2=A0 To: Martin Thomson <martin.thomson@gmail.com>
=C2=A0 =C2=A0 Cc: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
=C2=A0 =C2=A0 Subject: Re: Path forward with stream headers

=C2=A0 =C2=A0 You're assuming the data isn't self-descriptive in th= e body.
=C2=A0 =C2=A0 -=3DR

=C2=A0 =C2=A0 On 6/19/18, 5:29 PM, "Martin Thomson" <martin.thomson@gmail= .com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon &= lt;fenix@fb.com> w= rote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > However, if one must receive the first pac= ket of each stream, additional HoL blocking (which prevents playback/interp= retation) is induced.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the bit I'm pushing back on.=C2=A0 = The first byte isn't privileged.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There's a push ID, a HEADERS frame, and the= start of the first DATA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 frame before you can start into random access.= =C2=A0 Without that, you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 can't know what you are reading.=C2=A0 I fa= il to see how one additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 octet is a problem here.




--000000000000d9254c056f2c0c2e-- From nobody Thu Jun 21 13:14:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3238D130DDA for ; Thu, 21 Jun 2018 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijzcLWqGpudG for ; Thu, 21 Jun 2018 13:14:25 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CF112777C for ; Thu, 21 Jun 2018 13:14:25 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5LKEFtl000227; Thu, 21 Jun 2018 21:14:15 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0389.001; Thu, 21 Jun 2018 21:14:14 +0100 From: Lucas Pardue To: Jana Iyengar , Roberto Peon CC: Martin Thomson , QUIC WG , "Mike Bishop" Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAQ6RgIAACWUAgAACQQCAAVjHgIAADIsAgAAE3YCAAWkFgIAAGsop Date: Thu, 21 Jun 2018 20:14:14 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B27A@bgb01xud1012> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23922.001 x-tm-as-result: No-22.437800-8.000000-10 x-tmase-matchedrid: pS5owHKhBO1xGyfbWjfsSxuurbgYp+HQ/AZW18vjv1rimKcLRvsB1f5D CQVs54vCdvgGbsWpCcs+cjURnQbybFN5kIZnYeEYDB+ErBr0bAMl3afZehJEWcDyFv55sQyoL7t ZVXGShKBHtoT1310A7Tq3VvpaabDWzlreSYLGlVVCnGIuUMP0VRSRa9qpSosfrGn3BSxZVNSWsb lXE0A4wcpx30wDMdnPuyr9EDhG9KTHgweLox1o/wCwcUB5CbVqUD62xKrM2xkT7lsB95pa6lVL0 wx3ivhjFghSmBzCmc6oAbdnwCiIK1pHpNJHp94gr04R126GsicZskwWqoib3JJYEw3N9rxJL/MF Hd27Ns2nTiCfefUQqGb3Z7icbZPc6LVOyhonqfRIRA38P/dwbiTbbsi+pqSF/uymSAhGxLKwQli WBbE2aTYP2PIfxdcyIIhkaWkr82y2jsN8aguKvAu8ZZ1LOcwGTEFC0zV7bKRCannV/b7f2RPcZp 2k3oC4Yo9I0FrCIXwRT9NxjBEqGBoI+ORjNh9IbQ9aoPSmWJFSssBkvOlYfi/h9VOvT6Ag1+h8V lGgU8R90nHcE0R/71BqAeJWJKSGsut7KF2H4sdmNCKOCsW/Ova/bRHEsPI352VTYrkmb1vS0MbW fFpgAMWipJ3o/FgqnV8gelGeWcJQZ9BJr++dN4Dqq/69HfgsLPZWqnMLGVIgUEQTkIWiYpggi1y Gvzqdr55WycvL5EJ2UbqcatE72nx8EDQqTtoDA9lly13c/gGLB4sTRpOnCcj0Eew4TN42MMpwBa b+8feW/AnXk7PkkGmXLkyc+kNe8ZTibkDR5X2JDLgwb/1K2VkMvWAuahr8WRYdoGMKeqJnswcbX 99OHBjXymPSXaehMJdUU7FFzNI2JhN21dkG4Li0QrW47DsaftwZ3X11IV0= x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--22.437800-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23922.001 Content-Type: multipart/mixed; boundary="_004_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:14:29 -0000 --_004_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_ Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_" --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFuYSwNCg0KSSBhcHByZWNpYXRlIHRoZSBkZWJ1Z2dhYmlsaXR5IGNvbmNlcm5zLCBjYW4g dGhpcyBqdXN0IGJlIHNvbHZlZCBieSB0b29saW5nPyBJcyB0aGUgaXNzdWUgd2l0aCB0cnlpbmcg dG8gbG9vayBhdCBhcHBsaWNhdGlvbiBkZWJ1ZyBsb2dzIGluIHJlYWx0aW1lIGFzIGFwcGxpY2F0 aW9ucyByZWNlaXZlIFFVSUMgcGFja2V0cz8NCg0KV2lyZXNoYXJrIGZvciBIVFRQLzIgYWxyZWFk eSBhY3RzIHN0YXRlZnVsbHkgd2hlbiBpdCBkZWNyeXB0cyBzZXNzaW9ucyBhbmQgZGlzc2VjdHMg SFBBQ0ssIHdvdWxkIGl0IGJlIHRlcnJpYmx5IGRpZmZpY3VsdCBmb3IgaXQgdG8gcmVhZCB0aGlz IGZpcnN0IGJ5dGUgYW5kIHJlcHJlc2VudCB0aGUgc3RyZWFtIHR5cGUgaW4gYSBjb252ZW5pZW50 IHdheT8NCg0KTm90ZSB0aGF0IHRoZSBwcm9wb3NhbCBpcyBqdXN0IGZvciB1bmlkaXJlY3Rpb25h bCBzdHJlYW1zIC0gY2xpZW50LWluaXRpYXRlZCBiaWRpIHN0cmVhbXMgYXJlIG5vcm1hbCByZXF1 ZXN0L3Jlc3BvbnNlIG9uIGluY3JlbWVudGluZyBzdHJlYW0gSURzLCB0aGF0J3MgYWxsIHRoYXQg bmVlZHMgdG8gYmUgbG9va2VkIGZvciBpbiBhIGxvdCBvZiB0cmFmZmljIHNjZW5hcmlvcy4NCg0K SSdtIHByb2JhYmx5IGZhciBsZXNzIGV4cGVyaWVuY2VkIHdpdGggZGVidWdnaW5nIEdRVUlDIHRy YWNlcyBidXQgaW4gbXkgZXhwZXJpZW5jZSBjcm9zcyByZWZlcmVuY2luZyBmcmFtZXMgZnJvbSBT dHJlYW0gMyB0byB0aGUgcmVzcG9uc2Ugc3RyZWFtIHdhcyBhbHdheXMgYSBiaXQgY2x1bmt5LCBl c3BlY2lhbGx5IGZvciBwdXNoIHByb21pc2UuIFNlZSB0aGUgYXR0YWNoZWQgc2NyZWVuc2hvdCBv ZiBhIHZlcnkgb2xkIHdpcmVzaGFyayBkaXNzZWN0IG9mIEdRVUlDIChOQiBBbGV4aXMgTGEgR291 dHRlIHF1aWNrbHkgZml4ZWQgdGhlIGJ1ZyB3aXRoIGRlY29kaW5nIHRoZSBIZWFkZXIgQmxvY2sg RnJhZ21lbnQgc2hvd24gaW4gdGhhdCBpbWFnZSwgdGhhbmtzISkuDQoNCkx1Y2FzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUVVJQyBbcXVpYy1ib3VuY2VzQGlldGYu b3JnXSBvbiBiZWhhbGYgb2YgSmFuYSBJeWVuZ2FyIFtqcmkuaWV0ZkBnbWFpbC5jb21dDQpTZW50 OiAyMSBKdW5lIDIwMTggMjA6MzcNClRvOiBSb2JlcnRvIFBlb24NCkNjOiBNYXJ0aW4gVGhvbXNv bjsgUVVJQyBXRzsgTWlrZSBCaXNob3ANClN1YmplY3Q6IFJlOiBQYXRoIGZvcndhcmQgd2l0aCBz dHJlYW0gaGVhZGVycw0KDQpNaWtlJ3MgcG9pbnQgdGhhdCB0aGUgSFRUUCBoZWFkZXJzIG5lZWQg dG8gYmUgcmVhZCBiZWZvcmUgcmVhZGluZyBkYXRhIGZyb20gYSBzdHJlYW0gb3V0IG9mIG9yZGVy IG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhlIGZpcnN0IGJ5dGVzIGFyZSBhbHJlYWR5IEhvTCBibG9j a2luZyBpbiB0aGlzIGN1cnJlbnQgbWFwcGluZy4gR2l2ZW4gdGhlIGN1cnJlbnQgbWFwcGluZywg d2hpbGUgSSdtIHN5bXBhdGhldGljIHRvIFJvYmVydG8ncyBhcmd1bWVudCB0aGF0IHRoZXJlIGFy ZSB1c2UgY2FzZXMgd2hlcmUgYW4gYXBwbGljYXRpb24gbWlnaHQgd2FudCB0byByZWFkIGRhdGEg b3V0IG9mIG9yZGVyIGZyb20gYSBzdHJlYW0sIEkgZG9uJ3Qgc2VlIGFkZGl0aW9uYWwgSG9MIGJs b2NraW5nIGJlY2F1c2Ugb2YgdGhpcyBieXRlLg0KDQpUaGF0IHNhaWQsIEkgbGlrZSB0aGUgc2Vs Zi1kZXNjcmlwdGl2ZW5lc3Mgb2YgdGhlIHN0cmVhbSBJRC4gRXZlbiBmb3IgZGVidWdnaW5nIHB1 cnBvc2VzLCBpdCdzIGEgbWF0dGVyIG9mIHRyYWluaW5nIHlvdXJzZWxmIHRvIHVuZGVyc3RhbmQg d2hhdCBzdHJlYW0gSURzIG1lYW4gd2hhdCB0eXBlIG9mIHN0cmVhbSwgYnV0IG9uY2UgdGhhdCdz IGRvbmUsIGl0J3MgYWx3YXlzIHRydWUgZm9yIFFVSUN2MS4gSGF2aW5nIGxvb2tlZCBhdCBhIGxh cmdlIG51bWJlciBvZiBHUVVJQyB0cmFjZXMsIEkgY2FuIHNheSB0aGF0IGJlaW5nIGFibGUgdG8g dGVsbCBhdCBhIGdsYW5jZSB3aGF0IGEgcGFydGljdWxhciBzdHJlYW0gSUQgYWNyb3NzIHRyYWNl cyBpcyB2ZXJ5IHVzZWZ1bCAoSW4gR1FVSUMsIHN0cmVhbSAxIGlzIGNyeXB0bywgc3RyZWFtIDMg aXMgaGVhZGVycywgYW5kIHN0cmVhbSA1IGlzIHRoZSBmaXJzdCByZXF1ZXN0IHN0cmVhbSBmcm9t IHRoZSBjbGllbnQpLiAgV2l0aCBhIHR5cGUgYnl0ZSwgZGVidWdnYWJpbGl0eSBpcyB3b3JzZSwg c2luY2UgeW91IG5vdyBtdXN0IHNlZSB0aGUgZmlyc3QgYnl0ZSBhbmQgcmVtZW1iZXIgd2hhdCBz dHJlYW0gSUQgbWFwcyB0byB3aGF0IGZvciB0aGUgcmVzdCBvZiB0aGUgY29ubmVjdGlvbiwgYW5k IHlvdSBuZWVkIHRvIGRvIHRoaXMgZm9yIGV2ZXJ5IGNvbm5lY3Rpb24geW91J3JlIGxvb2tpbmcg YXQuDQoNCkdpdmVuIG15IGV4cGVyaWVuY2UsIEkgd291bGQgcHJlZmVyIGhhdmluZyBzdHJlYW0g SURzIHRoYXQgYXJlIHNlbGYgZGVzY3JpcHRpdmUuDQoNCkkgdW5kZXJzdGFuZCB0aGUgZGVzaXJl IHRvIGtlZXAgdGhpcyBmbGV4aWJsZSBmb3IgZnV0dXJlIHR3ZWFrcyBvZiBIVFRQL1FVSUMgd2l0 aG91dCBhIHZlcnNpb24gcmV2LCBidXQgaXQgaXMgYSBkZWdyZWUgb2YgZnJlZWRvbSB0aGF0IHdl IGNhbiBzdXJlbHkgcGxhbiB0byBleGVyY2lzZSBmb3IgdGhpbmdzIHdlIGNhbm5vdCBhbnRpY2lw YXRlIHJpZ2h0IG5vdy4gSSdtIG5vdCB5ZXQgY29udmluY2VkIHRoYXQgYWRkaW5nIHRoaXMgYWRk aXRpb25hbCBleHRlbnNpYmlsaXR5IG1lY2hhbmlzbSBpcyBuZWNlc3NhcnkgcmlnaHQgbm93Lg0K DQoNCk9uIFdlZCwgSnVuIDIwLCAyMDE4IGF0IDM6MDUgUE0gUm9iZXJ0byBQZW9uIDxmZW5peEBm Yi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0KWWVwLCB5b3UncmUgcmlnaHQsIGJl Y2F1c2Ugd2UncmUgbm90IGhhdmluZyBIRUFERVJTIHZzIERBVEEgZnJhbWVzIGFzIGEgUVVJQy1s YXllciB0aGluZywgd2UncmUgc2NyZXdlZC4NCg0KLT1SDQoNCu+7v09uIDYvMjAvMTgsIDI6NDgg UE0sICJNaWtlIEJpc2hvcCIgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2 ZXF1ZWZvdS5iZT4+IHdyb3RlOg0KDQogICAgQnV0IHlvdSBkb24ndCBrbm93IHdoZXJlIHRoZSBi b2R5IGlzIHVudGlsIHlvdSd2ZSBzZWVuIHRoZSBoZWFkZXIuICBPdGhlcndpc2UsIHlvdSdyZSBu b3QgY2VydGFpbiB0aGF0IHdoYXQgeW91J3JlIHNlZWluZyAqaXMqIGJvZHksIHJhdGhlciB0aGFu IHNvbWV0aGluZyBpbiBhIGRpZmZlcmVudCBmcmFtZSB0aGF0IGhhcHBlbnMgdG8gbG9vayBsaWtl IHlvdXIgc2VsZi1kZXNjcmlwdGlvbi4NCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5p eEBmYi5jb20+XQ0KICAgIFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMCwgMjAxOCAyOjAzIFBNDQog ICAgVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLi5jb20+Pg0KICAgIENjOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl dmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KICAgIFN1YmplY3Q6IFJlOiBQYXRoIGZv cndhcmQgd2l0aCBzdHJlYW0gaGVhZGVycw0KDQogICAgWW91J3JlIGFzc3VtaW5nIHRoZSBkYXRh IGlzbid0IHNlbGYtZGVzY3JpcHRpdmUgaW4gdGhlIGJvZHkuDQogICAgLT1SDQoNCiAgICBPbiA2 LzE5LzE4LCA1OjI5IFBNLCAiTWFydGluIFRob21zb24iIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC4u Y29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCg0KICAgICAgICBP biBXZWQsIEp1biAyMCwgMjAxOCBhdCAxMDoyMSBBTSBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNv bTxtYWlsdG86ZmVuaXhAZmIuY29tPj4gd3JvdGU6DQogICAgICAgID4gSG93ZXZlciwgaWYgb25l IG11c3QgcmVjZWl2ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3RyZWFtLCBhZGRpdGlvbmFs IEhvTCBibG9ja2luZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2svaW50ZXJwcmV0YXRpb24pIGlz IGluZHVjZWQuDQoNCiAgICAgICAgVGhpcyBpcyB0aGUgYml0IEknbSBwdXNoaW5nIGJhY2sgb24u ICBUaGUgZmlyc3QgYnl0ZSBpc24ndCBwcml2aWxlZ2VkLg0KICAgICAgICBUaGVyZSdzIGEgcHVz aCBJRCwgYSBIRUFERVJTIGZyYW1lLCBhbmQgdGhlIHN0YXJ0IG9mIHRoZSBmaXJzdCBEQVRBDQog ICAgICAgIGZyYW1lIGJlZm9yZSB5b3UgY2FuIHN0YXJ0IGludG8gcmFuZG9tIGFjY2Vzcy4gIFdp dGhvdXQgdGhhdCwgeW91DQogICAgICAgIGNhbid0IGtub3cgd2hhdCB5b3UgYXJlIHJlYWRpbmcu ICBJIGZhaWwgdG8gc2VlIGhvdyBvbmUgYWRkaXRpb25hbA0KICAgICAgICBvY3RldCBpcyBhIHBy b2JsZW0gaGVyZS4NCg0KDQoNCg0K --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPlAge21hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7fTwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIxIiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9 ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhvbWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1z aXplOiAxMHB0OyI+DQo8ZGl2PkhpIEphbmEsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JIGFwcHJlY2lhdGUgdGhlIGRlYnVnZ2FiaWxpdHkgY29uY2VybnMsIGNhbiB0aGlzIGp1c3Qg YmUgc29sdmVkIGJ5IHRvb2xpbmc/IElzIHRoZSBpc3N1ZSB3aXRoIHRyeWluZyB0byBsb29rIGF0 IGFwcGxpY2F0aW9uIGRlYnVnIGxvZ3MgaW4gcmVhbHRpbWUgYXMgYXBwbGljYXRpb25zIHJlY2Vp dmUgUVVJQyBwYWNrZXRzPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2lyZXNoYXJr IGZvciBIVFRQLzIgYWxyZWFkeSBhY3RzIHN0YXRlZnVsbHkgd2hlbiBpdCBkZWNyeXB0cyBzZXNz aW9ucyBhbmQgZGlzc2VjdHMgSFBBQ0ssIHdvdWxkIGl0IGJlIHRlcnJpYmx5IGRpZmZpY3VsdCBm b3IgaXQgdG8gcmVhZCB0aGlzIGZpcnN0IGJ5dGUgYW5kIHJlcHJlc2VudCB0aGUgc3RyZWFtIHR5 cGUgaW4gYSBjb252ZW5pZW50IHdheT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5v dGUgdGhhdCB0aGUgcHJvcG9zYWwgaXMganVzdCBmb3IgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyAt IGNsaWVudC1pbml0aWF0ZWQgYmlkaSBzdHJlYW1zIGFyZSBub3JtYWwgcmVxdWVzdC9yZXNwb25z ZSBvbiBpbmNyZW1lbnRpbmcgc3RyZWFtIElEcywgdGhhdCdzIGFsbCB0aGF0IG5lZWRzIHRvIGJl IGxvb2tlZCBmb3IgaW4gYSBsb3Qgb2YgdHJhZmZpYyBzY2VuYXJpb3MuPGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ20gcHJvYmFibHkgZmFyIGxlc3MgZXhwZXJpZW5jZWQg d2l0aCBkZWJ1Z2dpbmcgR1FVSUMgdHJhY2VzIGJ1dCBpbiBteSBleHBlcmllbmNlIGNyb3NzIHJl ZmVyZW5jaW5nIGZyYW1lcyBmcm9tIFN0cmVhbSAzIHRvIHRoZSByZXNwb25zZSBzdHJlYW0gd2Fz IGFsd2F5cyBhIGJpdCBjbHVua3ksIGVzcGVjaWFsbHkgZm9yIHB1c2ggcHJvbWlzZS4gU2VlIHRo ZSBhdHRhY2hlZCBzY3JlZW5zaG90IG9mIGEgdmVyeSBvbGQgd2lyZXNoYXJrIGRpc3NlY3QNCiBv ZiBHUVVJQyAoTkIgQWxleGlzIExhIEdvdXR0ZSBxdWlja2x5IGZpeGVkIHRoZSBidWcgd2l0aCBk ZWNvZGluZyB0aGUgSGVhZGVyIEJsb2NrIEZyYWdtZW50IHNob3duIGluIHRoYXQgaW1hZ2UsIHRo YW5rcyEpLg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KTHVjYXMNCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGNvbG9yOiAjMDAwMDAwOyBmb250LXNp emU6IDE2cHgiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScEY3MzcwMDQiIHN0 eWxlPSJkaXJlY3Rpb246IGx0cjsiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSIgY29sb3I9 IiMwMDAwMDAiPjxiPkZyb206PC9iPiBRVUlDIFtxdWljLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJl aGFsZiBvZiBKYW5hIEl5ZW5nYXIgW2pyaS5pZXRmQGdtYWlsLmNvbV08YnI+DQo8Yj5TZW50Ojwv Yj4gMjEgSnVuZSAyMDE4IDIwOjM3PGJyPg0KPGI+VG86PC9iPiBSb2JlcnRvIFBlb248YnI+DQo8 Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uOyBRVUlDIFdHOyBNaWtlIEJpc2hvcDxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogUGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnM8YnI+DQo8L2Zv bnQ+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPk1pa2Un cyBwb2ludCB0aGF0IHRoZSBIVFRQIGhlYWRlcnMgbmVlZCB0byBiZSByZWFkIGJlZm9yZSByZWFk aW5nIGRhdGEgZnJvbSBhIHN0cmVhbSBvdXQgb2Ygb3JkZXIgbWFrZXMgaXQgY2xlYXIgdGhhdCB0 aGUgZmlyc3QgYnl0ZXMgYXJlIGFscmVhZHkgSG9MIGJsb2NraW5nIGluIHRoaXMgY3VycmVudCBt YXBwaW5nLiBHaXZlbiB0aGUgY3VycmVudCBtYXBwaW5nLCB3aGlsZSZuYnNwOzxzcGFuIHN0eWxl PSJmbG9hdDpub25lOyBkaXNwbGF5OmlubGluZSI+SSdtDQogc3ltcGF0aGV0aWMgdG8gUm9iZXJ0 bydzIGFyZ3VtZW50IHRoYXQgdGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBhbiBhcHBsaWNhdGlv biBtaWdodCB3YW50IHRvIHJlYWQgZGF0YSBvdXQgb2Ygb3JkZXIgZnJvbSBhIHN0cmVhbSwmbmJz cDs8L3NwYW4+SSBkb24ndCBzZWUgYWRkaXRpb25hbCBIb0wgYmxvY2tpbmcgYmVjYXVzZSBvZiB0 aGlzIGJ5dGUuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IHNhaWQsIEkgbGlrZSB0aGUg c2VsZi1kZXNjcmlwdGl2ZW5lc3Mgb2YgdGhlIHN0cmVhbSBJRC4gRXZlbiBmb3IgZGVidWdnaW5n IHB1cnBvc2VzLCBpdCdzIGEgbWF0dGVyIG9mIHRyYWluaW5nIHlvdXJzZWxmIHRvIHVuZGVyc3Rh bmQgd2hhdCBzdHJlYW0gSURzIG1lYW4gd2hhdCB0eXBlIG9mIHN0cmVhbSwgYnV0IG9uY2UgdGhh dCdzIGRvbmUsIGl0J3MgYWx3YXlzIHRydWUgZm9yIFFVSUN2MS4gSGF2aW5nIGxvb2tlZCBhdCBh IGxhcmdlDQogbnVtYmVyIG9mIEdRVUlDIHRyYWNlcywgSSBjYW4gc2F5IHRoYXQgYmVpbmcgYWJs ZSB0byB0ZWxsIGF0IGEgZ2xhbmNlIHdoYXQgYSBwYXJ0aWN1bGFyIHN0cmVhbSBJRCBhY3Jvc3Mg dHJhY2VzIGlzIHZlcnkgdXNlZnVsIChJbiBHUVVJQywgczxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGZsb2F0Om5vbmU7IGRpc3BsYXk6aW5saW5lIj50cmVh bSAxIGlzIGNyeXB0bywgc3RyZWFtIDMgaXMgaGVhZGVycywgYW5kDQogc3RyZWFtIDUgaXMgdGhl IGZpcnN0IHJlcXVlc3Qgc3RyZWFtIGZyb20gdGhlIGNsaWVudCk8L3NwYW4+LiZuYnNwOyZuYnNw OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGZsb2F0Om5v bmU7IGRpc3BsYXk6aW5saW5lIj5XaXRoIGEgdHlwZSBieXRlLCBkZWJ1Z2dhYmlsaXR5IGlzIHdv cnNlLCBzaW5jZSB5b3Ugbm93IG11c3Qgc2VlIHRoZSBmaXJzdCBieXRlIGFuZCByZW1lbWJlciB3 aGF0IHN0cmVhbSBJRCBtYXBzIHRvIHdoYXQNCiBmb3IgdGhlIHJlc3Qgb2YgdGhlIGNvbm5lY3Rp b24sIGFuZCB5b3UgbmVlZCB0byBkbyB0aGlzIGZvciBldmVyeSBjb25uZWN0aW9uIHlvdSdyZSBs b29raW5nIGF0Ljwvc3Bhbj48YnI+DQo8YnI+DQpHaXZlbiBteSBleHBlcmllbmNlLCBJIHdvdWxk IHByZWZlciBoYXZpbmcgc3RyZWFtIElEcyB0aGF0IGFyZSBzZWxmIGRlc2NyaXB0aXZlLiA8YnI+ DQo8YnI+DQpJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSB0byBrZWVwIHRoaXMgZmxleGlibGUgZm9y IGZ1dHVyZSB0d2Vha3Mgb2YgSFRUUC9RVUlDIHdpdGhvdXQgYSB2ZXJzaW9uIHJldiwgYnV0IGl0 IGlzIGEgZGVncmVlIG9mIGZyZWVkb20gdGhhdCB3ZSBjYW4gc3VyZWx5IHBsYW4gdG8gZXhlcmNp c2UgZm9yIHRoaW5ncyB3ZSBjYW5ub3QgYW50aWNpcGF0ZSByaWdodCBub3cuIEknbSBub3QgeWV0 IGNvbnZpbmNlZCB0aGF0IGFkZGluZyB0aGlzIGFkZGl0aW9uYWwNCiBleHRlbnNpYmlsaXR5IG1l Y2hhbmlzbSBpcyBuZWNlc3NhcnkgcmlnaHQgbm93LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciI+ T24gV2VkLCBKdW4gMjAsIDIwMTggYXQgMzowNSBQTSBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vb3BlbmVyIG5vcmVm ZXJyZXIiPmZlbml4QGZiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NClllcCwgeW91J3JlIHJpZ2h0 LCBiZWNhdXNlIHdlJ3JlIG5vdCBoYXZpbmcgSEVBREVSUyB2cyBEQVRBIGZyYW1lcyBhcyBhIFFV SUMtbGF5ZXIgdGhpbmcsIHdlJ3JlIHNjcmV3ZWQuDQo8YnI+DQo8YnI+DQotPVI8YnI+DQo8YnI+ DQrvu79PbiA2LzIwLzE4LCAyOjQ4IFBNLCAmcXVvdDtNaWtlIEJpc2hvcCZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu b29wZW5lciBub3JlZmVycmVyIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQnV0IHlvdSBkb24ndCBrbm93IHdoZXJlIHRoZSBib2R5 IGlzIHVudGlsIHlvdSd2ZSBzZWVuIHRoZSBoZWFkZXIuJm5ic3A7IE90aGVyd2lzZSwgeW91J3Jl IG5vdCBjZXJ0YWluIHRoYXQgd2hhdCB5b3UncmUgc2VlaW5nICppcyogYm9keSwgcmF0aGVyIHRo YW4gc29tZXRoaW5nIGluIGEgZGlmZmVyZW50IGZyYW1lIHRoYXQgaGFwcGVucyB0byBsb29rIGxp a2UgeW91ciBzZWxmLWRlc2NyaXB0aW9uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQombmJzcDsgJm5ic3A7IEZyb206IFJvYmVydG8gUGVv biBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIiBy ZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiPmZlbml4QGZiLmNvbTwvYT5dDQo8YnI+DQombmJzcDsg Jm5ic3A7IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMCwgMjAxOCAyOjAzIFBNPGJyPg0KJm5ic3A7 ICZuYnNwOyBUbzogTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC4uY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVy Ij5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgQ2M6 IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRh cmdldD0iX2JsYW5rIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiPm1iaXNob3BAZXZlcXVlZm91 LmJlPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIj5xdWljQGlldGYub3JnPC9h PiZndDs8YnI+DQombmJzcDsgJm5ic3A7IFN1YmplY3Q6IFJlOiBQYXRoIGZvcndhcmQgd2l0aCBz dHJlYW0gaGVhZGVyczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgWW91J3JlIGFzc3VtaW5nIHRo ZSBkYXRhIGlzbid0IHNlbGYtZGVzY3JpcHRpdmUgaW4gdGhlIGJvZHkuPGJyPg0KJm5ic3A7ICZu YnNwOyAtPVI8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIDYvMTkvMTgsIDU6MjkgUE0sICZx dW90O01hcnRpbiBUaG9tc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIj5t YXJ0aW4udGhvbXNvbkBnbWFpbC4uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIFdlZCwgSnVuIDIwLCAyMDE4IGF0IDEwOjIxIEFNIFJv YmVydG8gUGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIHJlbD0ibm9vcGVuZXIgbm9yZWZlcnJlciI+ZmVuaXhAZmIuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgSG93ZXZlciwgaWYgb25lIG11 c3QgcmVjZWl2ZSB0aGUgZmlyc3QgcGFja2V0IG9mIGVhY2ggc3RyZWFtLCBhZGRpdGlvbmFsIEhv TCBibG9ja2luZyAod2hpY2ggcHJldmVudHMgcGxheWJhY2svaW50ZXJwcmV0YXRpb24pIGlzIGlu ZHVjZWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgaXMgdGhl IGJpdCBJJ20gcHVzaGluZyBiYWNrIG9uLiZuYnNwOyBUaGUgZmlyc3QgYnl0ZSBpc24ndCBwcml2 aWxlZ2VkLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSdzIGEgcHVzaCBJ RCwgYSBIRUFERVJTIGZyYW1lLCBhbmQgdGhlIHN0YXJ0IG9mIHRoZSBmaXJzdCBEQVRBPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZyYW1lIGJlZm9yZSB5b3UgY2FuIHN0YXJ0IGlu dG8gcmFuZG9tIGFjY2Vzcy4mbmJzcDsgV2l0aG91dCB0aGF0LCB5b3U8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgY2FuJ3Qga25vdyB3aGF0IHlvdSBhcmUgcmVhZGluZy4mbmJzcDsg SSBmYWlsIHRvIHNlZSBob3cgb25lIGFkZGl0aW9uYWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgb2N0ZXQgaXMgYSBwcm9ibGVtIGhlcmUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_-- --_004_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_ Content-Type: image/png; name="PUSH_PROMISE-dissect.PNG" Content-Description: PUSH_PROMISE-dissect.PNG Content-Disposition: attachment; filename="PUSH_PROMISE-dissect.PNG"; size=73304; creation-date="Thu, 21 Jun 2018 20:13:43 GMT"; modification-date="Thu, 21 Jun 2018 20:13:43 GMT" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA68AAAHlCAYAAAAaxMrKAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAP+lSURBVHhe7P2Hn1VFvu4B+ze8N7w3n3vve++5 58yccyY6M86Y45gQQVQEc0RQFAwIEgRRkgIiIkgSEEFAUDKScw6CJEUEFQUM5KjWu7/Vuza1V6+9 d63u1U3T/TyfzwNdtX67Vq1Kq55K6zwjlMT2LZuyfwl1Ccp3oa5BZV6oa1CZL47amj7Kd0E4d3He L7/8YsTipJGL8xdrN5XvYl2jyrxY16gyX5y1NX2U76J47lLiNYBq5Oomle9iXaPKvFjXqDJfnLU1 fZTvonju8rxffv7ZiMVpG7kYf7F2U/ku1jWqzIt1jSrzxVlb00f5LornLs/7+aefjFicNHJx/mLt pvJdrGtUmRfrGlXmi7O2po/yXRTPXZ730+nTRixOGrk4f7F2U/ku1jWqzIt1jSrzxVlb00f5Lorn Ls87nflHLMJTp2wjF3tNrL1Uvot1jSrzYl1jHSzzo0aNMh988EHstXI8R9Nn7dq15u233469Zqm2 ThTPaWbE66nMH2Icf/qJRHKNXLxNMQ4YMMA88MAD5uTJE7HXxZrJyua7KJ5rrAll/sSJ42blyhVm 795v8/y//vorc/vtt5vp06fl+VeUhe4DW7RoYV555ZVy/mLt49ks8z/88L1ZsGCBOXXqZOz1qiRl vH///rHXfJ4L78Hdu3eZ1atXl/MfOnSI7XtF/WFVPNemTRtNq1atzC233GLbquXLl8faiaKYDs/r 3Lmzefjhh813332XaUhP5ZHK2KNHj3L+dY00clG/Z5991txwww0Fycjf+PHjTceOHTPi9WS534s1 n3H5Dnfu3GlefPFF07RpU9OgQQPz0EMPmd69e2c6xSdi7UXxXGGhMv/666+bm2++2bZt/H///feb nj17mo0bN8baV4RfffWVDZ/OqO+/f/9+89RTT5klS5bk+VeUhe4DX375ZTNy5Mhy/mLtZUiZv+mm m8w999xjy/yOHTti7ZNwxowZNtzjx4/HXq9KOvEady2OhdKHviP1Mu5adZGBprg4DBlSJl6j/j7T eq7Dhw+bJk2amG7dupn169ebNWvWxPanRVFMj1a80oi2bt3aHD16JOOJ0Cpjq1ZPZsXrGb+6QUQI LHOXNXL5Ntu2bbUCFfbt29fceOONOTf88ccfyv1GrOksne/UkbvuussK1unTp9sO9aRJk+zLMmor ijWfpcs85D3x6KOPmg0b1mfatzW28/3888/bdm/06NGxv0nKr776MisqV8VeT4vVdR+xpjJZmf/4 4w0ZUbLOzJw50zz22GPmllsamp07P4/9TSjPiNdjsderkmfEa/z1JOlTJvLKX6suvvJKr9g4nBGv vn/VPNcnn2yyefnll7tjr4uimD6teKWBpkPep3dvc4pZwixbPZkVr1n3oUOHzBtvvGFHmRiRbPvc c2brli15vznXySxplLaRy/xfiGPGjDH16tUr559rQLPuObNn2xdHo0aNrP39991npk2dal7p1cvO 4pGmbZ591uzetSv3m5MnTpj33nvPjvre0rCheTKTJ+sy4thdF9NhaL5v27rVvqgWLVxY7ppjqXry 1ZfZzvOqTOc567dp40br99mnn1r34kWLzBNPPGHuuOMOU79+fdO+ffuc7axMJwrxjD/1lnKFv8qK mIShZR7mOnQR/2FDh9py65eznZ9/bjp06GBXJdx99912+8ThTJ1w1+fPm2eaPfKIrRvUkXcRvxl/ Vy98Ui+OHjli//7oo4+s3afbt9u4UDdoR2+77TY7I3bgxx9z95idsaUecI/GjRubQQMHmmNHjxa9 D9d45/nvwVJ1OSQuYs1hZcv8/n377IDNUAYrM+53Ro2yZfnWzDu9YabNxY1/qXLjxKsjNu7al7t3 my6Ze9OGU556ZfoH3+3fn7sON3/yiXmqdWv7O5apDsyUb3eNwdQHM/0O3g/07ebNnZv325x49fwc K5s+Pou1A8ePHbPvNPyZ1eY52rRpUzar7YVBejOjSfpihz33ddfpO/npyIAa/vS9yA//PfnOO+9U 6LkGv/WWefDBB20ciQP5vSjzfnbXVyxfnhcH+M2ePfYaqzt4D/Nb4j5yxAhzgtn27G9FUawYM+L1 BfNcpmHdvHmzrWAffvhhpmKfsKTS9ejRPefu2rWr7QhMmTLZLF68yP4OIfbtt9/kbM4Znjhu/2ep Z5n7hE0Q/o+SRi7vtxGOGfOu7bhE/YcMGZzb8+rciFT2W61atdKmJw0djfPChQvMvEynjka2UyeW Gpf9ZuTIEebWW281kydPtqO/5AeN8jff7MnZiAlYyXz//vvvbT158cUu5sCBH8tdh6XqCSO05Dtl wP1m48aPrd+nn263bsoKHeIlSxabNWtW21ki/OmYUNbeyrxQV6xYbubMmW0+++xTe01lRYxlCm0d 7wk6dFH/I0cOZzrPt9lBTtz79++zHfYXXnjBltnZsz+ydWHAgDfs9T17vrYdwIED37RlnjLMbC7X XL2YOnWqrQfw8OFD9h74f/TRLGu3fPky62YPLPd4//33bTl394DUCeoOYVNn6MBiV+w+XOOdxxYA F06puhwSF/EssIrK/MGDB2z5RYjhprw8/fTTti2nLG/fvs36lyo3M2ZMt+WGFVyUvx07PrP+hw4d NPfee6+d4V2wYL4dsLnvvvsy93ki8yxlz7R161Ybhy5dutiwIffmmns/DB8+3CxbtiwjUl+391m6 dIm9Dq14ff11+3dVtAmwVDvg6jTpyPuN9xh9JeLmwqBO8uyPZMQi17F79dVX8/paCHvSytXjrzJ1 G//Bgwfb+zGwyyAx70vuV5HnIo8R1uQxbQqimz4Ae+a57toAntPF49ixozZvySe2IpD+48a9Z9uG t94alAtbFMWEzLaD53XONC40rDSM06ZNtZVy69Yt1k2l7d69u/2bDelUUA4ZwA1paJs2bWL69euX 86uNtI1c5v/yzDT+x4+bd9/NiteMn/87GtAHHri/oJsGnjSdOXNGzg8hTEeLv2m8aezYO+uus2yV l+CECRNyfmLVsFC+L12yxDTNvJgZFe/X7zWzPfOScr8JqSe7d5d1nhnEcDYsTcOPzg/uaFmB5D2j 7Izo+/5QZUVMg4XKPO8JOnTODj/3Nx27xx9/3P7N7AadVsqju06bRl3h782bP7HlfNmypbnrjnH1 AhIW/rNmzbRuOuW4OcjJ2bzxRn878OfcUTKbQmefvwvdB5aJ11ft3yF1uSJxEWsWS5V52lEOWKLs ctYB+Y1Q4bd+eXEMKTdsOcGGsJ0NZBUXfTAGHJ2fqzPz5s21bs7RQOSx5NjZQAQh9Sz6fujUqZMV gM7Nb9nP69sUY0XahFLtQLROQ8Q6fl98sdO6WUWE+GOwydl8+OEHtq/l3IhXPw6Oce9PZqF9d+hz RfN43769dvZ96tQp1h3XBkBEbjSfxo0bZ59pz54z+SuKYnKex8gY4pUKBhlBZ4kEezadeMX//fcn 2AqKv7OFdAgef/yxPL/aRho5lrnk82ju+rvvjrYNqv8bOHjwW/Zgk0JuyOl0Y8eOzbkZaSWdv//+ Oztyx980drzQHGk4GbH0wxHTZ7F8pzPCy5aOAfnBMiz8Q+oJJyRis2LFitz1DRvKxOu2bdusO66s uPLASLvv719TWRErw0JlnvfEU0+1jv1NmzbPWvHK35RzypxfBimTlE3aNDrr2ODHu4UVAi6cuHoB qWv4s+cQN8IXN3tXnc0HH5TNODHjgZtZEkQ1sy+QTrN7zxW6D+Sdx+wOf4fU5ZC4iDWbxco8eeuT NpnBZvdbv7w4hpQbZuqxQXCWtymrSz4ZtHzzzTdzf7NMOGpT6P3g4oMAx92iRfOMeO2XZ1OMFWkT SrUD0ToNWS2BHwce4WZ1kxN/jnzix+9r9erVMzYOce/Pl17qmucOfa64PEaYs9KJv+PaABiXTy6P WHbs+4uimIwZ8dop81JvYyst/DHTwLF8o2/fPplK+0Smg9HN+r8/Idsg0wBmbWGXLp3N449lGmTP r7aRRo6OiO2MxPDd0e+UNagRf/ZK2Aa0gBvSseL3zj1v7hybzvv2fms+3/GZ/Xti5uXz2afb8/jt N3vywhHTZ6l8d2QPKvm0YP68oHrydfbAmEWLFuaus7wRP15uuOPKiisPS+iceP7+NZUVsTIsVOZ5 T7DHzveDhw4esMKwB4OcGTdbINhnFi2D8Cgd9ezv1qxeZesEHVxmgfDbvesLW4ZZAunsIPfA34qG jHvZ0iXWzRJBZzN92lTrd+TwIfPFzs9tZ7lnzx5m48cb7P5A3nHuPVfoPpB3nu2oZv4Oqcul4uL8 xJrLYmW+RfPm5pNNG2355Z3sX4d+eXEMKTc58RopI9YG8er5wZx4zfx955132j3cUZttW7fYMDkv wfd38fkhIxpx80yv98uIV8+mGJO2CbBUOxCt0zBaLwm/Zcv8tHADQ85tZ15j4hD3/uzVs2eeO/S5 4vKYpd1Dhw61f8e1AbBMvJblmaPLI//dL4picp73QqeMeG3Txhw7eiRHOtKMkrHksHumEcJv/bq1 ttLRQXd2Bw/8aPdw9u3TJ+dXG2kbuaNH7axB3PXR75SJ16g/extoQAu5IeKV3zv33Dll4nXvt9+Y w4cO2pnZ2p6+NZWl8t1x/769Ns/eeWdUUD0hXykvfr5vWL/O/o6XG+64suLKA8sSfX//msqKWBkW KvO8JziR3veDlFPK7epVK62bMs27g45o1DaOY9591wrY77/bn6tHHLbk21B/8J85Y7p1s2wfNwfb OBsOvsOPerBwwQL7NwfGuOscouTec4XuA598go7qK/bvkLpcKi7OT6y5TFrmffrlxTGk3HANm2/2 fJ2zgbxDGHjZ8/VXOb/N2dNs2fONu13btnZGEhHobCD3oM8WfT/wHAhJ5+a3r73WN8+mGCuSPqXa gWidhru+2Gn9VixfZt1DBg+2W2HoCzmbDyZNzOtr8awPP3zm2Rzj3p+0Ab479Lni8vjee++x35Ll 77g2ALp88v3Y90r8o7aiKCbjeSx7ZHkVJzr6ZOSKCskImvNjOQWHyEydMsUsWbzYtGvXzjaW7CHi +ob16637g0mTcr+pDSxr5OKvQfZ30CBF/d8aVNaAFnJDxCu/d+45WfH67TffWPeoUaPKln6+8YZN c/bRsMzY2YtVx7h8ZxaHOsGepeXLltn8oh6Q/5R/bErVE8iBHozMUldWrlhh9zqR75xIyfW4sgI5 mZV7DXzzzVx5YPkj11RWxMqyUFvn9s2tWrnSlnsOBWMZLuWN76I6u31799qyz7fDp0+bZm2pB2vX rLHXd33xhZk4cWKmg7/OnlBMPaBuHDp40F5n1Q+nbC9butQetkJ94ORe6saMTJ3Dhs9T4fbrE4cv 4Uc4X+zcaTvOzMpwj082bbJ10H/Pxd0Hf/xefeWVnF2pulwqLs5PrLksVubtJwQj/j6j5cWxVLmh HtCOU0Zpv1kO+8P335vvv/vO3H3XXXb2dcH8sgObeA/gPnL4sP0tZZp6xz045BHxxOofrrk9lW+/ /bbdi/lG//62LBKWixt7ManLWzZvzvkVY7H0adasma3jPjkxv1Q7EK3TkHqLH7a4+R4zacb+U+op 7zP+9vtaM7OnNo977z2bjtwL/7j3J+LVd4fme1we33tPRrwOGWL/jmsD4MaPP7Zxpb9A/DmPAjHO nmTfThTF5MyJV/Ze+GS/BntfqXjO77vv9ttvmiK4GB185pmn7UEz7jofaKax4cQ751cbSCMX5+/I aCmNVNR/ULYBLeSGjRvfbn/v3JyqR0PIgQ24OdgAYUNni4OceCGQX/i734hVw7h85zAzDu3gQBY6 CdSFZ5991p5C6GxK1RPISYWcQkh9oeywh+aZZ57JvAB32etxZcWRpVOUh7L7325FK/4qK2JlWait Y6aGskzbxP8sm2PP6rp1a8vZcugYh8pw8jW2lEc64VxjVQ8dZ8onKwXYT8YyQfdbviHLdco2n7rh kBreRdyXASNsqGtlncWyugI5PAU/ToPFTTtKx5r7Q+or+9Kdfdx98Kej+kqmo+rsStXlkLiINZuF yrwTMXHXHKPlxTHkHUA7zmws1ymrnDiMP3s/+cQMQoc6xHuCw4D83/IJlieeaGl/ix1xddfee2+s PaWXsk0Z52Rj/7fUWfwRc75/IRZLH8p5lK6eFWsHonUa8u1c/NhD6vx4Tvaf0lZQT3lm2g53nTpG 28R7FLq+bNz7s2fPHnnu0HyPy2Piwud4+DuuDXDkGvuciTPLvfmN2gVRrDzPY8+FWJy2kYvxF2s3 le9iXaPKvFjXqDJfnDUpffiEHMIx7lpSKt9F8dzleezLEYuTRi7OX6zdVL6LdY0q82Jdo8p8cZ6t 9OGALD6vw5JbVkpwajKzq2yZibNPSuW7KJ67PI9T38TipJGL8xdrN5XvYl2jyrxY16gyX5xnK30+ 3b7NtGzZ0i47btCggT10auSIEfbU5Dj7pFS+i+K5y/M49U0sThq5OH+xdlP5LtY1qsyLdY0q88VZ W9NH+S6K5y4z4vWHzB9iMZY1cvHXxNpL5btY16gyL9Y1qswXZ21NH+W7KJ67PO/E8eNGLE4auTh/ sXZT+S7WNarMi3WNKvPFWVvTR/kuiucuz3v/vdFGFEVRFEVRFEVRFGsyz5s65UMjiqIoiqIoiqIo ijWZ5322fasRRVEURVEURVEUxZrM8774/DMjiqIoiqIoiqIoijWZ5321+wtT17njs+3muuuuNffe c0/s9UJ8c8Ab5tprrzW///3vzbV//7sZ8Eb/WLtSDAlHNsVtqpvFygxx/dWvflWOV199dZ4dz/H3 v19jfvfb35rLL7/cvNils9n9xed5NiEsFc6unTtMr549zNVXXWV+85vf2P9HDB+WF0YIQ8NJO792 fLrNXHHF5eaySy8tdy2tNBSLs1Q6f7lrpy0bV155pfm3f/s3c+Hf/mY6tH/efJ6pJ0nCScKKtts+ 0y4/Kqu1hwPffMO2cZTnK6+4wvR/vV/e9fPPP9/0fvWVPD9saBud++WXusa+C8h7/3fvjBppbrjh BvPbTNm45JJLzPPPt7NlybepKwyp16Vsli9dbJo2bWLr2gUXXGCefuop+5s4W5833VTP2vp+bZ59 xr7PfL/qqsvEx5WZf/mXfzGXXXaZjd/GDetzNiHl8NNtW0zb556z7RLl+YK//MW0evJJs3XzJzmb 0GcvxZA4+za//vWvzUUXXWSaNXvErFm1Ii8snsO9U2hXX+vbJ3eNZ+L3l156iX3/OP9GjW6x/u7Z QupgaPrEhUP6O5u0GJqG0fx6omVLc3EmLdevXZ2zoU3Z9PGZ35GGSfM0CdN4L4fwvK+/3GXqKj/d vtVMnDDevjT+/Oc/28SOs4vju6PfMb/73W/Nu++MMuvXrTFj3sX9O+sfZ1+IIeHIprhNdTKkzHz+ 2aflljjc0bixeaFTx5zNsKFD7Mtl1Ii37XONf2+s+eMf/mAFgB9WKYaEQ+P9l0xj/P6EcdZm0MA3 bQM9dfKHeWGVYkg4VZFf7do+Z/70pz/ZF4vvn1YaisUZks49e3Q3f/3rX83E9ydYmw8mvp/pNP7F dOrYIVE4IaxMu+2zKsqPymrt4LAhg22nulemXC+cP8+8+kov60bQOhs6rX16v5r3uzf6l4kG5962 ZbNZu3qlLa90RCeMe8+68Xc2740dY689366tWbpkkXVfcvHF5pGHH8rZ1AWG1OsQG9L2wgsvtHVx 1crlZtbM6eaaq682L3V9sZxtlDfddJN55umn8vzatHnWXJfp7Dt3ddZl4vPYYy3sfRB2PPs111xj GjZskLMJKYctmjc3V111lZk1Y7rZvGmjmTF9qhXdDz34YM4m5NlDGBJn32bdmlV2D+ONN95gbrj+ eitMsBn45gBb517p1dMsWjDPPiPu11/ra6/Tr6Le/OlP59vf47dqxTLb/uLv6lhIHQxNH+z4rU/i 72zSYmga+vlFOlEOSSvfhj4aQt359cukX9I8DWFa7+VQ1mnxSgN33XXXmcFvDTJPtHw8UWIzutP2 uTZ5fjSWt97aKM+vFEPCkU1xm+pkRcoMHSEaQkSt8+uSaUyiL9MnnmhpRa7vV4oh4dAoIzx9GxrG Bx+4P8+vFEPCSTu/6HiQdj26dysnCNJKQ7E4Q9J5QP/Xzbj3xuTZPNaiubmzadOcO638qky77TPt 8qOyWntIW0fb5vs9+cQTdlbUda5DRIMjApiO87w5s8tdo4N5++235flRlhCvrFzw/WszQ+p1iA15 Qgfa92PVkO8uxKgggFEBV511OS4+ToQhnHCHlMOLL77IdO/2cp4Ngo+ZTecOefYQhsQ5zubDSROt zeqVK6yb2cbmzR/Ns2n5+GO2DFAHnXht/mgzWxa4jkh75JGHrb8vTmGxOljR9KkqJk3D98a8a0Uq g8b+b7B5+KGHrJhkJQd+hcTrqJEjbPj0V6PXQpjWezmUdVq8+g1aksSm4jAVz1If3x83DQZLGHz/ QgwJRzbFbXz/6mDSMsNoFDNQITOPt912qx3Zi7uWhNFweAkwc+Db0Mgzuu/7lWKpcNLOr507PrWj jR9+MNE2uFFBEMe00lAszmLpzPK5SRMn2Fl6ZinibBwrkl8VbbdDWNHyo7Jae7hxwzrbiWNLhO8/ +p2R1p+ZENxpiFc6lP5sUl1mSL0Osbn7rrvsgCkrnRiEYHkv+cT7KWobZZxoCBFwVVWX4+JD22pF THbGL6QcMoiIsGA5tW/ns6LPHmVInONsaDuxYfaUZa/8/fbwoXk29CWcjROvDJqyRQn3pZl2lxlx /JOI14qmT1UxSRrOnzfHPv/gQQPz7J1N3z697Yy2a2OqSrxW5Xs5jnVavPpMkthurf3kDyflZThu /t625ZPY30UZEo5sitvEpWt1MaTMMJpHo1jqxcmSoz/84Q9m5fKlsddDGRcOLyCE5/JlS6ybxo79 IwhNZxPCUuGknV90Pp5q3cr+HSII0kpDsTiLpTNLH+mMs3yJEdjodZ9p5FeaL8nKxEdltfaQzi3t lVuK6MiSQvz5H3ca4pVZJvzP1jaYmsqQel3IBrHKTBN1DJFD2rK0NDqzFkc6+7Rf7DN0xF1MwFVl XY6KmGVLFpub6tWzK5ycX0g5ZLau8e2327LGEmr2ss6cPi3vNxV59jiGxDlqgyBjdVb9+jdZ99w5 H9m4ImidDZwxbar1Z1mvE688GzPtbrACN/5JxGto+pAmpKtPVtr4dmkwNA3vu+9eO2vMQHH0eZ0N ZYNBAN5JDCwXEq/bt242SxYtiA0nKdN8LxeixGuWSRKb2TQKOZ1yljpQQCaMfy83chTaSQ8JRzbF beLStbpYqsxwIhovzeHD8kcPfSJqO7/Qyfzxj39MvAfVZ7FwEJXNHnnE/Ou//qvdf8q+CZY9ITB8 u1IsFU6a+cULhiWY3BN3MUGQVhqKxRmSzhwMwaAGo72UC/YtRW3SzK80XpKVjY/Kau3ignlzc+2Y 709nFn+W9OJOQ7zmZnnfHp7nX9cZUq8L2bACgtlX3w/hyqFAvl8ceWfxjqMT78jS1bjOfnXUZeLD +5aZNcoVYvKB+++35cbZJCmHiMShQ96yezkRYr5ASvLsxRgSZ9+GMzJY8vrggw/kbBYtnG/rRXQZ 7PSpU8rq4IzpeeKVQ4ickKyIeHUslT6PNnvEzs76ZI+sH0YaDE1DnoftDKzu8/fn+jaUDWZFWSE3 csTwguI1TabxXi7FPPE6dswY8/rrrxekb1vbmCSxabSocNEXDm5mobju+xdiSDiyKW7j+1c3S5UZ Dt6gUXad2igRt7wsOMmSF0WcTQhDw6EBY3SNv1nue/3115WzCWGhcNLKL8InTASw8yskCNJKQ7E4 Q9I5mr+cOo2A9f3Tzq/KviQrGx+V1dpHJyjp6Pn+7CvD3y0bdrN7vg15T4fT94OFOs7UDd4RnBbr +0P/jIS6xpB6Xcjmjjsam9atnszz4wBBBECprSt09n3BAuOWzlZXXSY+CEhmkJmlj+tLJCmHPocM fsuWSbdUNvTZSzEkzr6NHej84x9ze13h1s2bbNwQkv7v3IouRKYvXj/ZuME0bdLE+ldGvPoMSZ+q YmgaMkhDG8KSYso3Z09EbdzABv/Xq3ejXT5c68RrbReoxZg0sTlg4emnWuf5tW7dKnbTfrHp+JBw ZFPc5myxVJnhwJp77s4fAXak03vfvfeam+vXN1s+KT5yV6z8hITD6CX7tZybxo7GiyWevh0sdq+Q cJLkV6F7MapKQ8xSGEdexM7PLdtLkoZixVkqnSkHLF3itEPfnz04zNBzHXdaZd5nqTpY2brjqLJa d0h5Je+i7Vj759vZT0A5AcTywqgNndurr74qzw8W6zizX9I/RRSyBJWBH04f9v3rCkP6Y4VsyCeW Drt2B8YdohbHOIESFXDVWZdDBFOpcsjps7yXWRXj27jZzTmzZ1l3yLOHMCTOUZt77rnbNLj5Zpu2 zo8tSdHZRA5sYusSf/vi1bdJKl4rkz5VxYqkYZfOL9hJguhpw068IoAZJOBAq7g8DX3nhjCpnqoI 67R49T9pgtBgFMO5S43Qcdw20/mMzrK5nMMdGEFlmWTU1t//F70WEo5sittUJ5OUGUZlo6cSOnZ7 +SW71IOj/GksHGlAorbFyk9IOOw9ZGnRtKmTzcZMA42YpBGLO+K92L1CwkmSX4XuxQuMI+J98pws e+FvRr2xS5KGYsUZks4d2re3MwBjx4y2+T7lww9sJ4M6kiQcx2LlMEkdrGzdcVRZrVvs1LGD3cfI EmLczL5Qvv32nKWotH/sqeQ6K0z4jW9DHtOZdieF0j7ixt/ZsI+PJYJ0RJcsXmgHCREeLBN0NnWB IfU6xIY6xqAZ35mmLWJWiryLHjYYxzjREBVwoXWZ/YWUB75T6gvpJAwRMaXKISdWc5ARe0oZTPt4 /VoryJo0ucO2U66NCnn2EIbEOWpDf4I0pd45P/ob1BkGHhBkffuUfSrHHUxEnnO9lHjl/2J1MEn6 cCgXv43S2cDqyveoDeWfgTAGM9zJwtj4S8o7dmhvBW5cnhZ7V4Yw9L1cLH0YDOKZGEggf+L+drZ1 WrySgWRWHEPEEZmMQKFzzkbxQnsbSxWKkHBkU9ymupikzCDi4vb8Qb6JGRdG3FKfYuUnNBxeZH/7 299sw0UjXWjpTKmyGhJOaH4laSzjlmImSUOx4gxJZ0Qc38SkE0C+k1ec+Okvd0qrzCepg2nUHaiy WrfI6dF8AozOMh1Y9r/x6Ro6Xr7NM08/bT+fQ3vITBGCyZ894tNicfnOdgtnA9lf26DBzTYcVjG0 a9fWdqp9m9rOkHodWvcRIczk0RYxW07bFB3YimOcaIgKuNC6PHvWTOvvfxs4KUNETEg5ZKk7n35i 3y8DJQhFZuBYlupsQp49hCFxjrNhWT71zd/nOuCN/rm+BP+zFcVdCxWvIXUwNH3iwoH+4U7Vle9x NgjvCy64wM5QOxtfvDKgSlrG5WmSd1wcQ+tmsfRxeccgDHGN+9vZatmwKIqiKIpihOw3YwAO4Rp3 XRQLkW0UCAlmpOKui7WTyvfiTCt9zmPa1hHx6rtFURRFURTrKpn9YTaGFSQcJLPjs+2xdqLo8647 77RLjOOunWtk1vqB++8rSVYLxP2+LrE25XtVMK30OY+12o6IV98tiqIoiqJYV8myTPbisVyUJXfs 646zE0VH9hz+9a8X2GWccdfF2knle3GmmT7nuQ21EPHqu0VRFEVRFEVRFEWxJvC8qVM+NI6IV98t iqIoiqIoiqIoijWB523/wRjHbq+9kftbFEVRFEVRFEVRFGsKJV5FURRFURRFURTFGs86L167DR5r fn9NffOf/+188y+XXWtad3vdbP3u51jbKLsNec/88dqbzX/97Z/NH/5e34YVZ1eKIeGkYbPt+1/M 832GmH+74gbz//2XP5j/+9fLTYsXeplN357Is/to/U7z9zsftmnyv/98ibn/2c5m4zf5No4f7zlu /vXy68yvLrkmzz/0Xmk9e3WT9Dj/2gbmxvual7tGXP8//+/fyvF3V9XLs+M5Klr2fJYKZ8v+n2xe /PaqGzN58Uf7f793p+SFEcLQcNLOr0JlDKaVhmJxlkrn4PqeYn4Vq4OhTLv8qKzWHnYfOi7b1v0h k6fXm66DRudd/x9/+Kvp2G94nh82tI3O/UyPN2LfBa1e7pf3uwHjZpo/39DI/Kd/Pd/888VXm+Yd e9qy5NvUFZaq1yH9kyR9GJ9/vel2a+v7PdTuJfs+8/2qqy6HxAebuDJG+fR/BzsPGGmvPdG1T7lr Lpx//8+/tWl284NPmAkL18faROnfy7f5d//0G/OPf7vC3Nr8abPgk69zNhu+Pmoead/NtpP/8de/ z9zvYnPPUx3Nmt2HcjZp0Y8Pz/brS/9u03T5Z9/l2UTT+c5W7c3/u/BKs3jrtzkb6ueKHd/nbEjP aNlIi9X5vijV/oS0Yy6di5WfNFmnxWvvUR/YF83rY6fZAjrkg3nmv/3uAtOuz+BYe59vjp9lC9WA 8TPtbwdO+Mj8l9/8yfrH2RdiSDhp2bR9dZD5//3lUvP21EXWZsT0JbbReLzzqzkbGo9//NvltmGZ t3G3mbBgnRVdT3V/PWfjE7t/+OOF5TprIfdK67mqk+u/OmKGT1loK/r/PP+i2BcsL0kaZ59X3XG/ afnimRdGZcqez5BwaHj+158uNsMmL7Q2PTKdMl4Yo2etyAurFEPCqYr8KlTG0kpDsThD0jmkvqeV XyF1MIRVUX5UVmsHe4+cZDvebXu/Zaas2Gra9x1i3QzMOZsQ8cr7lE475ZWO3dAP51u330l/a9Ic e+3RDj3MzDU7rPufLrrK3NKsdc6mLjCkXof0T5L2YXzGiZioWKzOuhwSH2waP9bGliufC7fsyfsd JG0vaXinFShRIeTCmbNhlxk5fakVHwgR8iRqU+xe2NzR8jmbNvi/+9FK85fMff90/S12kBMbwvjN lTeY8fPXmZWf/2jem7vGCrQGDz+ZCyct+vGZv+kr+zy/u/omc3HDpnk2fjozEEueTs3Ufd+GgSxf sFWVeK3OMhbS/oS0Y65sFCs/aZG2ok6L11YvvVauQWO0BaHh+8Xx0kZ3mYeffznPj8byslvvzvMr xZBw0rJ5adC7ZvCkuXk2jR9/zo5QOjcvYxo432bzvtN5bkdeCjQ4z70ysFxnLeReaT1XdZKXIqPC vd5+39z55PNBHWc6QqSTP/JbmbLnMyQcXhIIT9+GxpzGxfcrxZBw0s6vYmUsrTQUizMknUPqe1r5 VZE6GMe0y4/Kau0hbR1tm+93V+sOttPvOuAh4tURAUyn74Mlm8pdo9N3xe335flRlug81qXZ15B6 HdI/SdKHiTIqYmBULFZnXQ6JT5xNHBFiDMDMWrvDDjC/M2t53vW4cCiDzP4Vs4kyzgYxQ/mft/FL 62ZGs02vgXk2iNyuA/NXN6TBuPg4EYYAi9oMmjjHilQGYP3fYNPwkVZ2YGXD18esXyHx2n/sdBs+ fb/otRBWdxkLbX9KtWOlyo9jZdOHtkJ7XiO84rZ77ehB3DVHXl5Mr7/x3ow8f9y8uEKn9kPCScvG 94csAR0xbbGdSWOUx/lfd3czKzZadultX+AUPF4G0TBYDsjo1agZS20FjnbWfMbdq6qeq6r5yd5T ub9DOs6MEDEDFTLzGFL2QhgNh2UyzBz4NoweMrrm+5ViqXDSzq8kZcwxrTQUi7NYOhdqW+JYkfxK WgeTsKLlR2W19nDp9v22Y/Xa6PwtESytw5/ZG9xpiFc6wQiKLgNG5fnXRYbU65D+SWgfJo5xHfCo WIxjVdXlkPjE2cSRmTUnUhAVTZ9ol3c9LpyhkxfYcrtoyzcFbaKMs6FdJJy5H++ybgY1Gaj4aN3n eXZVwbj48H4iPgs3l80YO5vJyzbb7U69hk/Is3c2L/QfYWeQXX2tKvEax6ooY0nbn6TiNVp+HCub PrQVEq8emZL/r7/9i532jrvuuO7LIzbh35m5LC8TcPP3ml0HY38XZUg4adn496URYzqfZQiMcvrX aOgZWSItaGgQXf/wh7+VGyXjxXDvMy/Yv4t11grdqyqeq7oZ0nEm3WikEXZx1x1Dy14pxoXDyw7h yT4g3DTQ7MtDaDqbEJYKJ+38Ci1jjmmloVicxdK5WNsSZRr5laZ4rUx8VFZrD+mY0V4xE+T7s8QR f/7HnYZ4ZSYK/7O1DaamslC9DumfhPZh4kgHnM48bZgj7mLitSrrckh8sMGfcueTFSDOhgFFtnU4 UTbo/dk2zogXP5yo+Ji2cpstn+8v3JCzKXWvaDgIRFZe/a1+45wfM55XNr7Phs2S7gfbdjXj5q3N XU+T0fgw83xBvdvsKjHfpt79j9kZYQZd/eWwvg31ve87k237TpoWEq9rdx8201d/GhtORVhVZSxp +5NUvEbLj2Ma6SPxmiHCgg3s//33FwTtA2Q2jQyhU85yCDKNEQY3uhTaSQ8JJy0b/75sVEd4MIpE J5ODKdw1Zg8YufTtn+31pmHTvXNTcFkeh1jBXayzVuheVfFc1c1SHedP9p60L80+73wYex0mLXuF WCwc8qnRo0+Z//Cr39n9p+z1eLp7f5sfvl0plgonzfxKUsbSSkOxOEPSuVjb4phmfqUhXisbH5XV 2sUpy7fk2jHfn841/iypw52GeHWzvBU5QK82s1C9DumfhNgUIu8s3nF0rB1vb/FsrECpjrocEh9s OBCJWUyf7CV1NuyZZJAZ0YCblSLEGyHmhxMVHxy4Q/mctHhjzqbUvbChj8AMJsuTORejwUNP2LLu bBwRtq+OmGj3uiKKo/dPg358qJuI//oPtsyLDzY8J1sDWCkXt/cWG+o7S9BZbdZvzNSC4jUtVnUZ S9r+JBWv0fKTJuu8eEVg0DhwmiANQ5xNlBQoKmU0w3HTQIQujwwJJy0b54etb8OJZnQync3VTR6w p775Nhy+Q4XHhop7/nUNrThx1wt11ordK+3nOhss1XFm4zt7J1ynNsqKlL04hobDUgv38mK5L/kY tQlhoXDSyq8kZSytNBSLMySdS7UtMO38qqx4rWx8VFZrH3Mdukzn1PdnLxz+btmwm93zbch7Osm+ HyzU6aPO8I7o0G9Ynj8MOR23trJQvS7VPwm1KcS4DnjcsuHqqssh8YmziRLxiDhkwMUR9zVNH8rZ xIVDHaDcuhN2Q+6FDQKbWW8GMRFebq9rMb6SEbHcCzEcd72i9ONDPOL6Y9gw4EF9ZEkxZYVzHKI2 brCK//9y4612uW1VidfqKGNJ25+k4jVaftJknRavdDzq3dfCXFi/sVm188zIUQjZO3BfJKPuebpT 7IbqYlPkIeGkYUMhZUkEp6j5NiwjYRbNNeockc2yG78j6h9AwpIpKjZLKxx5WdMQ8jfXQ++V1rOf LZbqOHNgzfX3PBp7LUnZK1Z+QsLh4AH2azk3+UODyxJP3w4Wu1dIOEnyq9C9QsoYdpWpv2I4S6Vz aH1Pq8z7LFUHK1t3HFVW6w4pr+RdtB3j3cgnoFx5Zrlj1IbOG5/X8f1gsU4fe9n8k08hywMZ+OH0 T9+/rrBQvS7VPwm1KcS4DnhULFZnXQ6JT5yNT+KIQGEbB8t1HRlUpp1asm2vtYsLh4EAf7lvqXvB qM0N9zY3F958h0033BwcRT/B/1QNdEtM056lq0icn+za1w64R08bduIVAYwob9TsqVjxGvr+KsTq LGNJ2p+k4jVafhwrmz6wTovXZ3oOsEsEOE6dRHQkYePsfXJUNEsQGFlgMzKHO9BAsEwyauvv/4te CwknLRu+u8hoMfsdsOG0OfYwIrKcDWlBh7N5p57WhlEofuMO6mHWjaO7fZKOLKPgb0aLQu+V1nNV J/3P4PAsjNY5t+vUODJixrJa388xSdkrVn5CwuGlxUjrmNmrzLJP91sxScMbd5R+sXuFhJMkvwrd K7SMVab+iuEMSeeQ+p5WmU9SBytbdxxVVusW+cQTe8xYQoyb2SDKt38CKHsoaf/YL8Z1xAC/8dt8 8hihUOwTE2PnrrbLGun4zVj9mR0kRACztNHZ1AWG1GvqT7H+SahNIcZ1wKNiMbQusyeS8sC3r6Pt UihD4oMNB/n4wtSR9ocTfCmn0W9uEz+ew6WLC4eVBez3ZtaPJb9j56zK/abUvZyNH2f6CtzHfTaN E2x/dfE1dh8sg3tLt++zgvWaJg/adtOFA6sqDaOM2nAvRB0DVG5fMDb+NoHHOr9iBW6ceC323glh dZaxkPaHe5PHIZ/KKVZ+HCubPrQVdVq8soGdBIwybtlPHEl4BAoZxKl2hfY2lsqokHDSsGE0h+/W 0XAgKBiJ5FS+6DIKGhRGyrBhpJnfFKsYccvkQu+V1rNXF2moouXFMSrQEHFxe/5gkrJXrPyEhkOH 6v9ccJltbHlpxI2cwVJlNSSc0PxK0oDFlbHK1l8xjCHpHFLf0yrzSepgGnUHqqzWLdLRd98ppEPN /5zQSmfRt3mgTRf7+RzaQw6vQzAxoOFsQj7uD9lfe1GDJjYcVjE069C9Tn0mB4bW65D+SdI+jGOc 0ImKxdC6zCE1+PvfBk7KkPhgE42LI/u0uc5Mth+GIwclubD8cJh1Q0xGD1EqdS9nE40zS+5ZoeI+ P4PA4VNU7ENGOCHUmMVkaa//u6pKwyjjbBDV//vPl+ROZcbGF68MTtLH8fPCMcn7Io7VWcZgqfYn pB3zy0ah8uNY2fQhzev8nldRFEVRFMUo2SPHABzCNe66KBYi2ygQP3F7B8UwKg2Lsy6nj8SrKIqi KIpiDDl4jNkhTmblxHR1pMUQXnfXI/aU47hrYhiVhsVZl9NH4lUURVEURTGGHPzDAS5sl2AZKvu9 4uxE0ZHl5Sz99D8hIyaj0rA463r6SLyKoiiKoiiKoiiKNZ4Sr6IoiqIoiqIoimKNp8SrKIqiKIqi KIqiWOMp8SqKoiiKoiiKoijWeEq8iqIoiqIoiqIoijWedVq8coog30n6tytuyH3MusULvezHx+Ps o+TDwHwslw8H/+Hv9e2R+nF2pRgSTlo2jnyAmI+qRz+m/8IbI3IfGvZJOvl2H63faf5+58PmP//b +fY7U3zg2f+EQEjaht6L5/j9NfXtvf7lsmtN626vB31wvCrJs55/bQNz433Ny10jD+Ke63dX1cuz S+u5SoXDqXSk6W+vujGTF3+0//d7d0peGCEMDSeteuFYqKzCmlg2aiNLpXNoW5pmfhWrg6FMu/yo rNYedh86LtvW/SGTp9ebroNG513/H3/4q+nYb3ieHza0jc4d8nF/OGDcTPPnGxqZ//Sv55t/vvhq 07xjT1uWfBsx/N3qWKw+xvGvN91uw/v3//xb26+5+cEnzISF62NtOw8YaW2f6Nonz58y4MctymiZ KRROmnTPBXm2X1/6d9tnW/7Zd3k2+Pm/u7NVe/P/LrzSLN76bc6GMrpix/c5G+JPvjh3Wqxs/zwp S9XBkLqcpPykxTTeg+ci67R4bfvqIHvU9NtTF9nKOWL6kkyBu9g83vnVWHufb46fZTshA8bPtL8d OOEj819+8yfrH2dfiCHhpGXj85H23cw//PHCco06HaqLGjQxG74+msfN+07nbNbsPmT+8W+X2zDm bdxtJixYZ18eT3V/PWcTkrYh9+o96gPbGXh97DQbzpAP5pn/9rsLTLs+g3M21cn1Xx0xw6cstI3c /zz/otgGg8Yk+kxX3XG/afnimZdTWs8VEg6N7v/608Vm2OSF1qZHplP2H3/9ezN61oq8sEoxJJyk 5TCEhcpqTSsbtZUh6RxS39PKr5A6GMKqKD8qq7WDvUdOMv/un35j2vZ+y0xZsdW07zvEuhmYczYh 4pV35YJPvrbllU4tn9nBjb+zeWvSHHvt0Q49zMw1O6z7ny66ytzSrHXORixjyLvVZ6H6WIiIj8aP tTFzNuwyI6cvteIDIUL+RW1pfy5peKcVOv4gFO0TeRyX73Ddl0eCwkmTPNcdLZ+zbc/8TV/ZeP3u 6pvMxQ2b5tn44hXhSBs1NVP+fRuEpC/Yqkq8VqZ/npQhdTCkLicpP5VlWu/Bc5V1Wry+NOhdM3jS 3Dy/xo8/Z2cUfb84XtroLvPw8y/n+dFQXnbr3Xl+pRgSTlo2johNRv6fe2VguUb9wbZdzU0PPJ7n FyUvbCqM7+cLThiStiH3avXSa3miGDIayAvL96suItoZ5er19vvmziefD2ow6AiR3rx4nV9azxUS zm+uvMEKT9+GFxkNq+9XiiHhpFUvHIuV1ZpWNmorQ9I5pL6nlV8VqYNxTLv8qKzWHtLW0bb5fne1 7mAFBjNCuEPEqyMCmA7vB0s2lbtGh/eK2+/L86Ms0XHW7Gtxxr1bHYvVx0KMCjhIPrBiwvdD0DGY MWvtDjtY+86s5XnXHYvlOwwNp7KMey4nwhBgUZtBE+dYkYpg9H+DTcNHWlmxtOHrY9avkHjtP3a6 DZ88il4LYWX650mZpA6Wqssh5QdWNn3Seg+eq9Se1yxZEjli2mI7s8QoeZyNIy8vlha88d6MPH/c vLhCR89CwknLxvmx5IIRt1EzltpGJ9qo39biGXPJLXeZevc/ZkeesO06cHReGNfd3cwKkpZdetuX PBWTl3ih5y6UtiH3iuMVt91rR7firlU1P9l7Kvd3SIPB6BijhSEzj2k9VzQclggxc+DbMHJKmvt+ pVgqnLTqhWOpshrHs1k26hKLpXOStrQi+ZW0DiZhRcuPymrt4dLt+22n8rXR+VsiWFaIPzNXuNMQ rwgAxEuXAaPy/MXSLPZurUh9hHHiY+jkBTbvFm35JufHDJ0TO4iTpk+0y13zWUq8hoZTWcY9F200 cVu4eU+ezeRlm+2Wn17DJ+TZO5sX+o8wf7r+llyZrSrx6jPJOyUpk9bBpOI1rvzAyqZPVb4HzwVK vGZIA8LUPkskGMWIs/HJsg8K3Tszl+UVQNz8vWbXwdjfRRkSTlo27p4IznufecH+HdeoM6rGPp9B 78+2o4Hs02JEkOVTzgaxysgbS97mfrzLvjz+4Q9/M216DcwLCxZL25B7Rck9/+tv/2KXZcRdr06G NBikCaNjCLu4645pPVdcOA+1e8kKT/Yp4+blxD4ghKazCWGpcNKqF46lymqUNals1GYWS+ckbWka +ZXmS7sy8VFZrT2kU0p79e5HK/P8x89fZ/35H3ca4nXexi+tf2W2VdRVFnu3Jq2PjnHiY9rKbTaP 3l+4wboRUixndeKO/gt12c1E+iwmdJKEU1lGn4v+1gX1brMrpXwbJhLY44pI9JfD+jaU+b7vTLZp yjMUEq9rdx8201d/GhtOEibtnydl0jqYVLxGy49jWukDJV7rqHhl0zodcUaUqCAc1BBn58iIH4WR Tjnr2imwjK4wyod/aCc9JJy0bLgflY1lNIgM3KGNOsvd/s8Fl+XcjGgy++rbPNvrTfOPf7sizw8m TdvovRx5QXGgwX///QWJ92pWFUs1GJ/sPWlFfZ93Poy9DtN6rmLhkN+NHn3K/Idf/c7uP2Wfy9Pd +9v88O1KsVQ4adULmKSs1sSyURsZks4h9T3N/ErjpV3Z+Kis1i5OWb4l1475/uPmrbX+LCfEnYZ4 dbO8FTlAry6z2Lu1ov0cyDsrKj44cIc8mrR4o3WzX50BW8QHbmZ5qc8IOv93sJjQSRJOZclz8d5m RpXyyUxj/Qdb2vLn2xBXlsczo93g4SfzwnA2lHm2ibHiqt+YqQXFa1pM2odMyqR1MKl4jZafqqDE ax0Ur3QmfDezf1SQYksc+Q0zhNHCjpvGKHR5ZEg4adnQ2Jx/XUMrKtz10EadZZ80dm5f69VNHjD3 PNUxz4YDerDxn70iaRu9F+RFhWjixEdGqnz7s8lSDQab/tk34l6iUab1XKHhsMzEvShZ7kt5iNqE sFA4adWLJGW1ppaN2saQdA6p72nnV2Vf2pWNj8pq7WOuM5vpmPv+7APE3y0bdquPfBvyHoHg+8FC HV7qDO+IDv2G5fnDuH2cYhkLvVsr08+BceKDckDeuRN2GzxUdggPgxeOuK9p+lDe72AxoZMknMqS 57q9xbN2pRwzjXF9EmyYlKBMskSXfhj7TqM2bsCG//9y4612uW1VideK9CGTMmkdTCpeo+WnKijx WofEKwWW5RGcqOb7s4SDWaVSlYN9CvdFCuk9T3eKPYCj2PKAkHDSsGGpE40Ry0EcecnSWPK3WwrF bzhFzQ+Hk/xYLurcHCHO0mG/YfEPRQhN25B78TKqd18Lc2H9xmbVzh/zbM82SzUYHC5w/T2Pxl5L 8lzFyk9IOBy6wH4t5yZ/eNmwHMe3g8XuFRJOGvUitKzW5LJRm1gqnUPre1pl3mepOljZuuOoslp3 SHkl76LtGO89PtfhyjMn7Edt6LiyFcb3g8U6vOx99k99hSwnp5POyae+v1jGQu/W0PpYiHHig8H6 v2XqLX9TdxE6LF91pwdDBmi5x5Jte/N+Wyjfk4ZTWcY9V5RRmye79rWDztHThp14RQAzU9yo2VOp LxsOfaekxSR1MKl49cuPz8qkT5QSr3Vs5pVvRjF6yl4DNlNz0hvCiYYxzt4noovlF4yq8FsOd6Ax Yplk1Nbf/xe9FhJOGjbMlnHcuM9neg6wSz/4m1kB7BAaNBos9aQBZQkLjYU/AsfncfBr3qmnvRej dKSjf5hPSNqG3Is4soSFe1LJHan4zqY66R/Vz7MwUunc0QaVGRaW1fp+jkmeq1j5CQmHFySjumNm rzLLPt1v052XzsItZQc1+Cx2r5Bw0qgXoWW1ppWN2sqQdA6p72mV+SR1sLJ1x1FltW6Rz3Gw/5Al xLg/Wve5Ld/+idHsuaT9Y68c1xEe/MZv88ljREmxz2uMnbvaLumk0ztj9Wd2kBABzLJOZyPms9C7 NbQ+FiLig0PUmF1nzzMrJfgc3Ng5q+x1DpQkz1ni6/+OvZ/U7+iBhoWETpJw8KNc8b3Tioq2iohX 7oWoY5DG7cP1xSt8rPMrVuDGiddibW8IQ/vnaaRPSB0Mqculyo/PyqZPkvdgbWSdFq+MhnM40K8u vsZ2sJk55BTdQss8o6TQ0YhSODl1t9DexlKFNCSctGx8xi2noULw4qaRIE1oEHoOG59nAxnBvPDm O6wNo9Gko19hQtI25F4caEDaRRm3NKs6SCMdFx8YFWiIuEL7M5I8V7HyExoOL3r2EvOi4bM1caOG sFRZDQkntBwmabzjympNKxu1lSHpHFLf0yrzSepgGnUHqqzWLSIq3DcaET78z2mwdJR9mwfadLGf z6E95PA6BnQRUM6GT4vF5bv/nUzI/lq+eU44DOg269Bdn8kpwmLv1iiTLht2ecSs2zVNHrR7nf3r zHL5v3Hk039REVdIvCYJh4N+CMP/xnBScr+k4hUu3b4vI6YvyZ2CjI0vXhkQ4D1fFeI1tH+eRvrA UnUwpC6TPs4/rvz4rGz6JHkP1kbW+T2voiiKoiiKUbI/kAE4hGvcdVGsarJ0FgHJYH/c9bpOpU/d pMSrKIqiKIpiDDkkhiWFbGvhxHR1ksXq5HV3PWK/5hB3TVT61FVKvIqiKIqiKMaQw2M4vIbtEixf ZK9bnJ0opk2WqbPlYOXnOuQtjkqfukuJV1EURVEURVEURbHGU+JVFEVRFEVRFEVRrPGUeBVFURRF URRFURRrPCVeRVEURVEURVEUxRpPiVdRFEVRFEVRFEWxxlPiNUs+RsxHxkM/Zg35KDIfCuZD83/4 e317pH6cXSmGhJOWzUfrd5q/3/mw+c//dr79NhYfpfaP/i/04ePfXVUvUTgwSfoUS/+00jlN8qzn X9vA3Hhf83LXQtOQ5/j9NfVtGv7LZdea1t1eN1u/+znPJoSlwuFEPr6F9turbrQfd+f/fu9OyQsj hKHhpJ1fRctGSmkoFmepdOZEVsrGv11xgz2R9f/+9XLT4oVeZtO3kTYhxfwqVgdDmXb5UVmtPew+ dFy2rftDJk+vN10Hjc67/j/+8FfTsd/wPD9saBud+5keb8S+C1q93C/vdwPGzTR/vqGR+U//er75 54uvNs079rRlybepKyxVr5PUo6T9ur/edLvty/h+D7V7yb7PfL/qqsvEx5WZf//PvzW/vvTvNn7L P/suZxNSDjd8fdQ80r6bTYf/+OvfZ/psF5t7nupo1uw+lLMJffZSDImzb/Pv/uk35h//doW5tfnT ZsEnX+eFxXO4dwr52HnAyNw1nonf/+ria+z7x/lf2ugu6++eLaQOhqZPXDikv7NJi6FpGM2vO1u1 N//vwivN4q3f5mxoU1bs+D5nQxomzdOkTFrvKkKJ1ywpuP/wxwuDE/vN8bNswzVg/ExbUAZO+Mj8 l9/8yfrH2RdiSDhp2VAR//Fvl9tnnbdxt5mwYJ0VVE91fz1nw4uDiuzzqjvuNy1f7JMonJD4+CyU /knDqWqu/+qIGT5loe1o/M/zL4p9wYakYe9RH9iXy+tjp9nnGvLBPPPffneBaddncF5YpRgSDo33 //rTxWbY5IXWpkemU0YDPXrWirywSjEknKrIr0JlI600FIszJJ3bvjrIfrLg7amLrM2I6UtsB+Dx zq8mCieEIXUwhFVRflRWawd7j5xkO9Vte79lpqzYatr3HWLdDMw5mxDRwLuSDjnllY4on9nB7XeK 35o0x157tEMPM3PNDuv+p4uuMrc0a52zqQsMqddJ61Gh+liIcYIgKuCqsy4TnztaPmfvM3/TVzZ9 fnf1Tebihk1zNiHlsPFjbcxvrrzBjJ+/zn5W5r25a6zobvDwkzmbkGcPYUicfZuFW/aYdz9aaf6S yfc/XX9LTogyeESdY1B0aqYO8owIuS4DRtnr9KuoN//wh7/Z3+M39+NdNr/xd3UspA6Gpg92/NYn 8Xc2aTE0Df38Ip0oh6SVb4Pw94V6dYjXpPWuIpR4zRDxRUF97pWBwYnN6M7Dz7+c50eGXXbr3Xl+ pRgSTlo2VH5eDL7N5n2n89xR8hInbRBkzi8knCTpUyz900rntIhoZ1S419vvmzuffD6o4xyXhq1e ei1P7ENGzRC5vl8phoRDo4zw9G1oGG9+8Ik8v1IMCSft/CpWNtJKQ7E4Q9L5pUHvmsGT5ubZNH78 Obs6w7nTyq+K1ME4pl1+VFZrD2nraNt8v7tad7Czoq5zHSIaHBHAdJw/WLKp3DU6mFfcfl+eH2UJ 8VqXZl9D6nWSelSRfl1UEMCogKvOuhwXHyfCEE64Q8ohs3Fteg3Ms0HwdR14ZjVByLOHMCTOcTYj py+1NvM2fmndzDbe3uLZPJumT7Sz5YRZbideb2vxjC0vXEekNWr2lPX3xSksVgcrmj5VxaRpOGji HCtSGTT2f4NNw0da2cGgDV8fs36FxGv/sdNt+PRXo9eSsCL1riKs8+KVZW2MaIyasdRmakhi8/Ji Kv6N92bk+eOmwQhdPhISTlo2uK+7u5kVEi279LYvZ5a90OgVii8jocyeRGfNSoWTJH2KpX9a6Zwm P9l7Kvd3SMe5UBrG8Yrb7rUje3HXkjAaDi8BZg58Gxp5Rvd9v1IsFU7a+VWRuplWGorFWSydWV4+ YtpiO0vPLEWcjWNF8itpHUzCipYfldXaw6Xb99tO3Guj87dEsLQXf2ZCcKchXulQMrvkZpPqMita r+PqUUXqI4wTDSECrqrqclx8aFspSws3l834hZRDBhEZGPho3ed5dj4r+uxRhsQ5zoa8wobZ00Vb vrF/931ncp4NfQln48Qrg6ZsUcLNEmJmxPFPIl4rmj5VxSRpOHnZZvv8vYZPyLN3Ni/0H2FntF0b Q32oKvFa0XpXEdZ58YoAu/eZF+zfoYm97ssjNpPfmbksL8Nx8/eaXQdjfxdlSDhp2XA/RCYjMCxv ofIjqFhyER1xcsSfCo0o8f1LhZMkfYqlf1rpXFUMecEWSsMoScv/+tu/mDkbdsVeD2VcOLyAEJ7s U8ZNY8d+BISmswlhqXDSzq+kdTOtNBSLs1g6s/SRpV0sX2IGJXrdZxr5laZ4rUx8VFZrD+nc0l65 pYiOLCnEn/9xpyFemWXCvzLbKmojQ+t1oXpUkX4dpLPPYAJtmCPuYgKuKutyVMTMWrvDXFDvNrvC yfmFlENm665sfJ8ta2zxerBtVzNu3tq831Tk2eMYEueoDYKM1Vl/q9/Yuidl6yAiyNnAsXNXW3+W 9TrxyrOxEpBtWUym4MY/iXgNTR/ShHT1yQyjb5cGQ9Ow3v2P2VljBoqjz+tsKBsMAlAHGFimPsTl 6drdh8301Z/GhhPKita7irBOi1cKMdPbdLpxhyY2s2kUcjrlLHWggAydvCA3chTaSQ8JJy0b7seI CLOmfhye7fWmYbO87wc/2XvSCtI+73xY7lqpcELjUyr900rnqmKpF2yxNHRE1D7RtY/577+/IPEe VJ/FwiF9Gz36lPkPv/qd3X/Kvomnu/e3AsO3K8VS4aSZX0nqZlppKBZnSDpzoASDGoz2Ui7YtxS1 STO/0hCvlY2Pymrt4pTlW3LtmO9PZxZ/lsXhTkO8ulneihygV5tZql4Xq0cV7ddB3lm84+jEO7J0 Na6zXx11mfjwvmVmjXKFmKz/YEtbbpxNknKISHx1xES7lxMh5gukJM9ejCFx9m04I4OzMxo89ETO ZtrKbbZeRJfBjp2zyvozgOSL1xfeGJETkhURr46l0odDpZid9ckeWT+MNBiahjwP2xlY3efvz/Vt KBts62OFXL8xU219SJqnIaxMvasI66x4JTPPv66h7WQ7v9DEptGiwkVfOLiZhQpdHhkSTlo2uK9u 8oA9Qc234WAdKkY0zhwawRp6VxB9lgonJD4h6Z9WOlcVS71gi6UhRNzysuAkS14UcTYhDA2HZVmM rvE3y31J/6hNCAuFk1Z+JambaaWhWJwh6Uz++25O5ETA+vmedn5VVrxWNj4qq7WPOUGZ6ej5/uwr w98tG3arj3wb8p4Op+8HC3WcqTO8Izr0G5bnD/0zEuoai9XrYvWoMv06SGffFywwbulsddVl4oOA ZIUbs/RxfYkk5dDnKxmRRpl0S2VDn70UQ+Ls2zDQyQCA2+sKV39xwMYNIen/zq3oQmT64pXTdK9p +pD1r4x49RmSPlXF0DRkEok2hCXF9L85eyJq4wY2+P8vN95qlw+nLV4rW+8qwjorXhm5IbOZbnek sjPawt9uaVAhcsDCfZGCfM/TnWI37Rebjg8JJy0bjt9nya/fySy0qZrDVq6/59Fy/jAknFLxCU3/ JOlc3SzVcS6WhlT2eve1MBfWb2xW7Sw+cles/ISEw+gl+7Wcm3yj8WKJp28Hi90rJJwk+VXoXqFl I0kaihVnqXSmHLB0idMOfX/24DBD78RrWmXeZ6k6WNm646iyWndIeSXvou0Y7z0+AeXKM8sLozZ0 bvm8ju8Hi3Wc2S/pnyIKWYLKwA+nD/v+dYWF6nWpehRaHwsxTqBEBVx11uUQwVSqHHL6LO9l/zMr 0M1uTlq80bpDnj2EIXGO2txwb3Nz4c132LR1fmxJis4mcmATW5f42xevvk1S8VqZ9KkqViQNn+za 104SRE8bduIVAcwgAQdaxeVp6Ds3jpWtdxVhnRWvzB5xDLXPZ3oOsFPr/M3IWtzvHDlum+l8RmfZ XM7hDoygskwyauvv/4teCwknLRs+a0NnsnmnntaG0RpG7aKH8EBGFFkSGvWHIeGUik9o+idJ5+qg /xkcxCkjX84dnVksloY8K0s9SEsaC0cakKhtsfITEg57D1laNGb2KrPs0/1WTNKIxR3xXuxeIeEk ya9C9wotG0nSUKw4Q9KZb7rSBgx6f7bN93dmLbedDOpIknAci5XDJHWwsnXHUWW1bpFPPLGPkSXE uJl9oXz7p8xyngHtH/tVuc4KE37jt/nkMZ3pYp/pYB8fSwTpiM5Y/ZkdJER4sEzQ2dQFhtTrUvWo sv26ONEQFXChdZn9hZQHvlMabZdCGSJiSpVDTqzmICP2lCIilm7fZwXZNU0etOni0iTk2UMYEueo Df0J0tT/tBr9DeoMEyMIsk6vv23FkDuYiHLB9VLilf+L1cEk6cOhXPw2Sr9cVVe+R224FwNhDGa4 k4Wx8ZeUP9b5FStw4/K02LuyFJPUu2Lpw2AQz8RAAvkT97ezrbPiNY5Jp7nJZAQK6/XZKF5ob2Op QhESTlo2VE5GuBAUjCLzHbu4CoYAiduv5hgSTmj6OBZK/6ThVCWp9ORlHKMCrVga8k3MuDAYrYra Fis/oeHwIvs/F1xmGy4a6UJLZ0qV1ZBwQvMrSWMZVzaSpKFYcYakMyPmtAF0AmgTyCtOJPeXO6VV 5pPUwTTqDlRZrVvk1Ew+AUZnmQ4Y//PpGjpevs0DbbrYz+fQHjJTxIAuHTlnw6fF4vKd7RbOBrK/ 9qIGTWw4rGJo1qF7nfpMDgyp1xWpR0n6dXGiISrgQuPw/sIN1t//NnBShoiYkHLIUnc+/cS5JAyU IBSZgWNZqrMJefYQhsQ5zoZl+cze+ftcX35rTK4vwf9sRXHXQsVrSB0MTZ+4cKB/uFN15XucDcL7 f//5EjtD7Wx88YqQJC3j8jTJOy6EhepdsfRxeccgDHGN+9vZSryKoiiKoihGyH4zBuAQrnHXRbEQ 2UaBkKjLe5frIpXvxZlW+ki8iqIoiqIoxpDZHmZj+NwEJ6arUyqG8Lq7HrFfYYi7dq6RVXUsYy9F ZoHjfl+XWJvyvSqYVvpIvIqiKIqiKMaQA8k4DIXtEnb//ofzY+1E0ZHl5SwvrorPqIg1l8r34kwz fSReRVEURVEURVEUxRpPiVdRFEVRFEVRFEWxxlPiVRRFURRFURRFUazxlHgVRVEURVEURVEUazwl XkVRFEVRFEVRFMUazzotXl94Y4T98G2UfIcozj5KPrLLx375OPUf/l4/7wPKSRgSTho2nPTFs/32 qhvN//df/mj/7/fulDwbWCqckHQLvlcm7N9fU9/853873/zLZdea1t1et8eyu+uc9Eg4/3bFDfak x//718tNixd6nfUj2flcwvnXNjA33te83DXSLi59fndVvTy7Us8eylLhhOZFKaZVfpKSj/Xz4fW4 D16nlYZicaZVT9PMr2J1MJRplx+V1drD7kPHZdu6P2Ty9HrTddDovOv/4w9/NR37Dc/zw4a20bmf 6fFG7Lug1cv98n43YNxM8+cbGpn/9K/nm3+++GrTvGNPW5Z8m7rCUvX6o/U7zd/vfNjWI74Xef+z nfM+XxT6/o3jX2+63Ybn+z3U7iUbpu9XXXU5JD7YxD0v5dP/Hew8YKS99kTXPuWuuXD+/T//1qbr zQ8+YSYsXB9rE6V/L9/m3/3Tb8w//u0Kc2vzp82CT77O2Wz4+qh5pH03207+x1//PnO/i809T3U0 a3YfytmkRT8+PNuvL/27TdPln32XZxNN5ztbtTf/78IrzeKt3+ZsqJ8rdnyfsyE9o2UjDVZWmyRl qfYnpB1z6Vys/KTJOi1eaXAuatDEViSfm/edjrX3+eb4WbbhGjB+pi3cAyd8ZP7Lb/5k/ePsCzEk nLRsKID/608Xm2GTF1qbHpmXMw3H6FkrEoUTkm4h9+o96gP7on997DRrM+SDeea//e4C067P4JxN 21cH2aO13566yNqMmL7ENnSPd341Z1OdXP/VETN8ykJb0f/n+RfFvmB5kUbT5qo77jctXzzzwgh5 9hCGhBOSFyFMq/wkJS+5f/jjheUEQVppKBZnWvU0rfwKqYMhrIryo7JaO9h75CTb8W7b+y0zZcVW 077vEOtmYM7ZhIhXOuN02imvdOz4zA5uv5P+1qQ59tqjHXqYmWt2WPc/XXSVuaVZ65xNXWBIvSbd /vFvl9t6Nm/jbjNhwTorSp/q/nrOJuT9W4hxIiYqFquzLofEB5vGj7Wx5crnwi178n4HSdtLGt5p BUpUbLtw5mzYZUZOX2rFB0KEPInaFLsXNne0fM6mDf7vfrTS/CVz3z9df4sd5MSGMH5z5Q1m/Px1 9rMp781dYwcBGjz8ZC6ctOjHZ/6mr+zz/O7qm8zFDZvm2fjpjEgkT6dm6r5vw0CWL9iqSrxWRpsk ZUj7E9KOubJRrPykRdqKOi1eH2zb1dz0wOOx10rx0kZ3mYeffznPjwb1slvvzvMrxZBw0rKhsUCA +DZUagqZc4eEE5JuIfdq9dJreS8dyGgXLxrnfmnQu2bwpLl5No0ff86OvPp+1UVenIwK93r7fXPn k88HdZzpCNEw+6PDIc8ewpBwQvIihGmVnySkc0LaPffKwHKCIK00FIszrXqaVn5VpA7GMe3yo7Ja e0hbR9vm+93VuoPt9LsOeIh4dUQA0+n7YMmmctfo9F1x+315fpQlOo91afY1pF6T3ggw369Uhz7u /VuIUREDo2KxOutySHzibOKIEGMAZtbaHXaA+Z1Zy/Oux4VDGWSGuZhNlHE2iBnK/7yNX1o3M5pt eg3Ms0Hkdh2Yv7ohDcbFx4kwBFjUZtDEOVakMgDr/wabho+0sgMrG74+Zv0Kidf+Y6fb8Cl70Wsh rIw2SUqeK7T9KdWOlSo/jpVNH9qKOi1eb2vxjLnklrtMvfsfsyMNjMZQeUot/+DlxfT6G+/NyPPH zYsrdPlISDhp2eBmuQQjyL4No0g8O3+HhhOSbqXuVYhX3HavHb2Ju8ay1RHTFtvZP0Y/42yqmp/s PZX7O6TjzAgRM1AhM4/Fnj0Jo+FUNC+iTKv8hJIlp5StUTOW2pdEVBDEMa00FIszrXpakfxKWgeT sKLlR2W19nDp9v22Y/Xa6PwtESytw5/ZG9xpiFc6wQiKLgNG5fnXRYbU6+vubmYHQ1t26W0HGOgY kweF3i1J3r8wrgMeFYtxrKq6HBKfOJs4MrPmRAqioukT7fKux4UzdPICW24XbfmmoE2UcTa0i4Qz 9+Nd1s2gJgMVH637PM+uKhgXH95PxGfh5rIZY2czedlmu92p1/AJefbO5oX+I+wMsquvVSVeK6pN kjJp+5NUvEbLj2Nl04e2ok6LV0ZR2NMy6P3ZdjSKfQyMSLFUKM7ecd2XR2zCvzNzWV4m4ObvNbsO xv4uypBw0rLhfjR6CBD2jOCmorI/C8ERGh/sQtKt1L3iyLKb//rbv9hlB9FrNLwsQWApByOz0etn gyEdZ0YXaaQRdnHXHYs9exLGhVORvIhjWuUnlHRQ7n3mBft3iCBIKw3F4kyrnqaRX2mK18rER2W1 9pCOGe0VM0G+P0sc8ed/3GmIV2ai8K/MtorayEL1GrHKzBf1ByFEuv3DH/5WbhbPMfT960gHnM48 bZgj7mLitSrrckh8sMGfcueTFSDOhgFFtnU4UUbfjTgjXvxwouJj2spttny+v3BDzqbUvaLhIBBZ efW3+o1zfsx4Xtn4Phs2y76ZaRw3b23uepqMxoc+6wX1brOrxHwbhCIzwgy6+sthfRvqe993Jtv2 nTQtJF7X7j5spq/+NDacEFZUmyRl0vYnqXiNlh/HyqYPrNPiNY4sB/k/F1wWe82R0TwyhE45yyHI NEYY3OhSaCc9JJy0bLgf4qLRo0+Z//Cr39l9iKz5f7p7f9vRDI2PH3+f0XQrdS+fvFg4QOC///6C gvsw2VyPWGLkizA4TCPOrjpZquP8yd6T9sXa550PY6/DkGcPYbFwkuRFMVZl+YmSxpGlXtwTdzFB kFYaisWZVj1NM7/SEK+VjY/Kau3ilOVbcu2Y70/nGn+W1OFOQ7y6Wd6KHKBXm1moXjMDxeyr7/ds rzcNhwL5fjDk/Rsl7yzecXSsHW9v8WysQKmOuhwSH2w4EIlZTJ/sJXU27MtlkBnRgJuVIsQbIeaH ExUfHLhD+Zy0eGPOptS9sKGPwAwmgotzMRo89IQt687GEWH76oiJdq8rojh6/zTox4e6ifiv/2DL vPhgw3OyNYCZ+ri9t9hQ31mmzmxovzFTC4rXqmCINknKpO1PUvEaLT9pUuI1QpY4UriL7aOg0aJS RjMcNw1E6NR+SDhp2fj+TLm7Roxln+df19D+XZnnKpRuhe515vpJ2zhzmiMNs3/NkXj5bkah6BiH pnNVsVTHmY3v7J1wndooQ549hKHhlMqLUFZF+fFJGSJMBLDzKyQI0kpDsTjTqqdp51dlxWtl46Oy WvuY69BlOqe+P3vh8HfLht0MoG9D3tNJ9v1goU4fdYZ3RId+w/L8YcgezdrKQvX66iYP2FNpfT8O B6TvEX2/lHr/xjGuAx5dpgurqy6HxCfOJkrEI+KQARdH3Nc0fShnExcOdYBy607YDbkXNghsZsYZ xEQku72uxfhKRsRyL8Rw3PWK0o8P8YgrD9gwKEJ9ZEkx5YlzHKI2brCK//9y4612uW11idcQbZKU SdufpOI1Wn7SZJ0Wr/c83cmemuX7cSIdSyN9vziyd+C+SEYRXtymfTr6NHBxU+Qh4aRlwwZ09u04 NwWXisdSP+cXEg7uUukWci8qYb37WpgL6zc2q3aeGblz5Dcs44geD87SF2b+arp45cCa6+95NPZa qWf3Waz8hIQTkheOxe6VVvlxLHQvluXRSLN8x5EOIS9b/nbL9pKkoVhxplVP0yrzPkvVwcrWHUeV 1bpDyit5F23H+HwEn4By5ZnljlEbOm8s9/P9YLFOH/sl/ZNPIUtQGfjh9E/fv66wUL0mD1g6TJvj /OIOSIPF3r+FGNcBj4rF6qzLIfGJs/FJHBEobONgua4jg8q0U0u27bV2ceEwWOAv9y11Lxi1ueHe 5ubCm++w6Yabg6PoJ/ifqoFuiWnas3QVifOTXfvaAffoacNOvCKAEeWNmj2VlxeOoe+vQgzpY6fF JO1PUvEaLT+OlU0fWOfFK50uljVSgVlCQWcrOuISRwoWSxAYWWAzMoc70ECwTDJq6+//i14LCSct GxovRtzGzF5lln263z4/FdA/5jwknJB0C7nXMz0H2CUaHHlPIXakYDsbvhXJCDdr/4kPJ+RRgXkx OZvqpH8MP3FgtM65o2KaUVmW1fp+jiHP7lis/ISEE5IXjsXulVb5cSx0L2Z2OdbeJ8/JUh3+ZtQb uyRpKFacadXTtMp8kjpY2brjqLJat8gnntgTyBJi3MwGUb79U2bZT0n7x34xriMG+I3f5pPHCIVi n5gYO3e1XdZIx2/G6s/sICECmKWNzqYuMKReU3/oazTv1NO2M8ySkS/RgwRhsfdvIcZ1wKNiMbQu syeS8sC3r6PtUihD4oMNh0X5wtSR9oeDfiin0W9uEz+ew6WdC4eVBez3ZmaZJb9j56zK/abUvZyN H2f6CtzHfTaNE2x/dfE1dh8sg3tLt++zgvWaJg/adtOFA6sqDaOM2nAvRB0DVG5fMDb+NoHHOr9i BW6ceC323glhSB8bppE+Ie1PSDvmykax8uNY2fShrajT4pUEoELRyaKDTQHoOWx8rG0cSXgaSDKI k+8K7a0olVEh4aRlQ2POunkqHY1H3AhKqXBC063UvThAgHSJ0l92xWgdm9Rp7LgXI6ycNphkKVCa pKGKizOMCjREXKG9uSHP7lis/ISGE5LvsFRZTaP8OCZpwOKWYiZJQ7HiTKueplXmk9TBNOoOVFmt W6Sj775TSIea/zmhlc6ib/NAmy728zm0hxxeh6hiQMPZ8GmxuHxnu4Wzgeyv5buOhEOntVmH7nXq MzkwtF4jeJjJo51hJpx2J67jXuz9W4hxQicqFkPrMofU4O9/GzgpQ+KDTTQujuzT5joz2X4YjhyU 5MLyw2HWDTEZPUSp1L2cTTTOLLlnhQrCCDcCh09RsVcZ4YS4ZRbTnUbsWFVpGGWcDaL6f//5ktyp zNj44pXBSfo4fl44JnlfxDG0j51G+sBS7U9IO+aXjULlx7Gy6UOaa8+rKIqiKIpihOyRYwAO4Rp3 XRQLkW0UiB+ESNx1sTSVhsVZl9NH4lUURVEURTGGHDzG7BBL9zgxXR1pMYTX3fWIPQk57poYRqVh cdbl9JF4FUVRFEVRjCGHA3GAC9slWMLHfq84O1F0ZHk5y4v9T8iIyag0LM66nj4Sr6IoiqIoiqIo imKNp8SrKIqiKIqiKIqiWOMp8SqKoiiKoiiKoijWeEq8iqIoiqIoiqIoijWeEq+iKIqiKIqiKIpi jWedF68frd9p/n7nw+Y//9v59ntJfKg49Ch8PgzMx3L5OPUf/l7fHqkfZ1eKIeGkYcPpZHwX6rdX 3Wg/4M3//d6dUs7m6e797QfX/8tv/mQ/jox7877TeXZB8cn4/f6a+jZt/+Wya03rbq+X+5h4KZvQ +FQ3KSPnX9vA3Hhf83LXSBf3sWafv7uqXp5dSPqEMCQNS+V7CEPDSateOPKxbPL/V5dcU+5aWmko FmepdOZEVsoG9ZMTWf/vXy83LV7oZTZ9m9+WpplfxepgKNMuPyqrtYfdh47LtnV/yOTp9abroNF5 1//HH/5qOvYbnueHDW2jc4d83B8OGDfT/PmGRuY//ev55p8vvto079jTliXfRgx7B73wxojYNOd3 vl0c/3rT7db23//zb21/8OYHnzATFq6Pte08YKS1faJrnzx/yoB/3yijZaZQOGnSPRfk2X596d9t X3f5Z9/l2eDn/+7OVu3N/7vwSrN467c5G8roih3f52yIP+97506TlemfJ2WpOhhSl5OUn7SYxnvw XGSdFq9rdh8y//i3y80j7buZeRt3mwkL1lmB8VT312Ptfb45fpatUAPGz7QVe+CEj6y4wj/OvhBD wknLhsr3v/50sRk2eaG16ZF5Of/HX//ejJ61Is+Gijtt5TbbsZqyYqtNo2d6DsjZhNyr96gP7Mvl 9bHTrM2QD+aZ//a7C0y7PoMT2YTEpzq5/qsjZviUhbaR+5/nXxTbYNCYbPj6aB6vuuN+0/LFMy+n kGcPYWgalsr3EIaEE1I2kpL6+Q9/vLCcIEgrDcXiDEnntq8Ossf2vz11kbUZMX1J5uV9sXm886uJ wglhSB0MYVWUH5XV2sHeIyeZf/dPvzFte79l3znt+w6xbgbmnE2IeKWPseCTr215pVPLZ3Zw4+9s 3po0x157tEMPM3PNDuv+p4uuMrc0a52zEcsY8g5iUOiiBk3KvYNDBrwRH40fa2PmbNhlRk5fasUH QoT8i9rS/lzS8E7bP/EHoWifyOO4fIfrvjwSFE6a5LnuaPmcTbP5m76y8frd1TeZixs2zbPxxSti nzZqaqb8+zYM5viCrarEa2X650kZUgdD6nKS8lNZpvUePFdZp8UrLx4y3vcLndG7tNFd5uHnX87z o5JdduvdeX6lGBJOWja/ufIG2/j7NjRoVDDn5qPHd7fukGfT9Il25vp7Hs25Q+7V6qXXyjUyjOIh 4pLYhMSnOkljyihXr7ffN3c++XxQg0FHiJkWf8Qw5NlDGBJOSL6HMCSctOqFIy8s0u65VwaWEwRp paFYnCHp/NKgd83gSXPzbBo//pwdNXfutPKrInUwjmmXH5XV2kPaOto23++uzHsIgcEqA9wh4tUR AUyH94Mlm8pdo8N7xe335flRlug4a/Y1nyHvoAfbdjU3PfB4nk0oowIOkg+smPD9EHQMZsxau8MO 1r4za3nedcdi+Q5Dw6ks457LiTAEWNRm0MQ5VqQyCOn/BpuGj7SyYmnD18esXyHx2n/sdBs+/Z/o tRBWpn+elEnqYKm6HFJ+YGXTJ6334LnKOi1er7u7me1Yt+zS2zaKFDAqTKnRL15eLC14470Zef64 eXGFjp6FhJOWDW6WijCC7NswgsYIk3O/MmKiXfL34dJP7O+mr9qeqSRXmFcz/lyvzLNfcdu9dlQq 7ppj1KZUfKqbn+w9lfs7pMFgdIwZqJCZx5D0CWE0nJB8D2GpcNKqF44sOWV0eNSMpfYFGbcUM8q0 0lAszmLpzNK+EdMW2xkSZhzjbBwrkl9J62ASVrT8qKzWHi7dvt92Kl8bnb8clWWF+DNzhTsN8YoA QLx0GTAqz1+MZ8i77LYWz5hLbrnL1Lv/MetPvew6cHTQ+ydOfAydvMDm3aIt3+T8mKFzYgdxwoC6 u+azlHgNDaeyjHsu2mjitnDznjybycs22y0/vYZPyLN3Ni/0H2H+dP0tuTJbVeK1ov3zpExaB5OK 17jyAyubPlX5HjwXWKfFK5WBESSWbs39eJcVGP/wh7+ZNr0Gxto7suyDQvfOzGV5BRA3f6/ZdTD2 d1GGhJOWDfd7qN1LtvFnHwFuGin2ZyE4/HjRWPA7KjT/+8tdK/rspPF//e1f7HKKuOuwkE2x+JxN hjQYlCVGxxB2cdcdQ9InhHHhhOZ7KZYKJ6164Ui+3/vMC/bvEEGQVhqKxVksnemMsUyK5WaMCEev +0wjv9J8aVcmPiqrtYd0Smmv3v1oZZ7/+PnrrD//405DvM7b+KX1r8y2irrEkHcZM4PshR30/mw7 o8lec2Y1WQLubAoxTnywZYk8en/hButmcI4tEk7ccR/qspuJ9FlM6CQJp7KMPhfpckG92+xKKd8G wc8eVwYe/eWwvg1lvu87k20bxzMUEq9rdx8201d/GhtOCCvaP0/KpHUwqXiNlh/HyqaPT4nXOiZe GZFjdMf3e7bXm3Zmz/eLktk0CiOdcta1U2AZXWHUHf/QTnpIOGnZcD/ERaNHnzL/4Ve/s/sQ2e/A 4Ud0NF2c2OdAo0RF+2TvSVtBOYTFLXlL+uyINg4i+O+/v6DgHstiNqXiczZZqsEgvjS2fd75MPY6 DEmfEBYLJyTfQ1gqnLTqBSSfWYLJPXEXEwRppaFYnCHpzAEgdCgZnadccOhN1CbN/ErjpV3Z+Kis 1i5OWb4l1475/uPmrbX+LCfEnYZ4dbO8FTlAry6you8y+gv/54LLYq/55J0VFR8cuEMeTVq80brZ r45YRnzgZtUF9RlB5/8OFhM6ScKpLHku0owZVconEwH1H2xpy59vQ1xZHs9qsQYPP5kXhrOhzLN8 l1ntfmOmFhSvlWVF++dJmbQOJhWv0fJTFZR4rWPi9eomD5h7nuqY58dBM1TsYksT6IAwkhct7Lhp jEKXNYSEk5aN789yA9dgsuTm/Osa5q4x4hZdPvHyW2Nso8rfSe6FeONFw0mNjDD59qE2peJzNlmq wWDTP/tGXKc2ypD0CWFoOMXyPQkLhZNWveDFSJgIYOdXSBCklYZicYakM/nvu5nxoFOZtE1Iwsq+ tCsbH5XV2sdcZzbTMff92QeIv1s27GaFfBvyHoHg+8FCHV7qDO+IDv2G5fnDqjpVtTYw6buMrSv0 60rtmYwTH5QD8s6dsNvgobJDeBi8cMR9TdOH8n4HiwmdJOFUljzX7S2etTOYzDTG9UmwQSxSJllS THpxlkHUxg3Y8P9fbrzV9s+qQrxWtH+elEnrYFLxGi0/VcE6L16HjP3ACthC9G1rAzkKm6UJfqcr 7rCNOLJP4b5IIb3n6U6xB3DQyNJZiVseEBJOWjZsvmffjnPz3DQ6LPVzfpyUyayJc0MaJ2YQnTvk Xrwk6t3XwlxYv7FZtfPHPNskNiHxOVss1WBwYM31BQ6WCnl2x2LlJySckHx3LHavkHDSqBcsy+MF xcCFIx1CXuz87ZbtJUlDseIslc6UA5aaRT9FwXI4ZkdcRyOtMu+zVB2sbN1xVFmtO6S8knfRdoz+ AucvuPLMyadRGzquLFn1/WCxDi97n/1TXyHLyRn44eRT37+uM+QdxPuGk2CdG7LViOXGvl8c48QH IupvmXrL39RdhA5bItzpwZABWur8km17835bKN+ThlNZxj1XlFGbJ7v2tYPO0dOGnXhFADOJ0KjZ U7HiNbQNL8TK9M+TMkkdTCpe/fLjs7Lp47POi9e6Ro7fpnPVvFNPu5ma0SZGU6MHAsSRxpHlF4yq 8FsOd6AxYplk1Nbf/xe9FhJOWjY0lIzujZm9yiz7dL9t5Gl8Fm4p27APH3juRdvIs/SPl/SM1Z/Z l/EDbbrkbELuxadsWHpCGlM5HamwSWxC4lOd9D+DgzhlpNK5XafGkRkWljT5fo4hz+5YrPyEhBOS 747F7hUSThr1glF1jvT3yXOyTIm/mcHCLkkaihVnSDrzTVfaTvZtke+cmkm9pY4kCcexWDlMUgcr W3ccVVbrFvnEE/sPWUKM+6N1n9vy7W9XYe8d7R975biO8OA3fptPHiNKin1eY+zc1XZJJ51e3m8I NN5xLOt0NmIZQ95B+DGYxnYVRCDLcOnnRWcR44j44BA1ZtfZ88xKCT7FM3bOKnudg5+4X/T71ez9 pH5H+46FhE6ScPCjXLFdKtq+hbIi4pV7IeoYpHH7cH3xCh/r/IoVuHHitVjbG0LaypD+eRrpE1IH Q+pyqfLjs7Lpk+Q9WBtZp8UrZGT8wpvvsB1sRlXZ1B+a8RQ6BAqFk9PQCu1tLFVIQ8JJy4YXK3s/ aHD4fEm0UaVCMOJGONiQJg+3e7ncceGl7sVBBDxzlP6SqhCb0PhUF2mk4+IMowINERe35w+GPLtj sfITGk6pfHcsVVZDwgkphzBJ4x23FDNJGooVZ0g6M7NI2/mri6+xbSl5xUmR/vK0tMp8kjqYRt2B Kqt1i4gK941GBiL4n9Ng6Sj7Ngyi8vkc2kMODqKjzYCGs+GzLnH5zlJXZwPZX8u3SQkH4dWsQ3d9 JqcAQ/owDD4weEZbhKjpOWx8nk0hIj5cHjHrdk2TB+1eZ/86s1z+bxz5RE9UxBUSr0nC4bwPwvC/ MZyU3C+peIVLt+/LiOlLcqcgY+OLVwboeM9XhXiFIf3zNNIHlqqDIXWZ9HH+ceXHZ2XTJ8l7sDay zotXURRFURTFKNkfyAAcwjXuuihWNdmOgYBElMddr+tU+tRNSryKoiiKoijGkIPHWFLI8lNOTFcn WaxOXnfXI/aU3bhrotKnrlLiVRRFURRFMYYcGMPWFZaq2v37H+YfBiSKVUWWqbPlYOXnOuQtjkqf ukuJV1EURVEURVEURbHGU+JVFEVRFEVRFEVRrPGUeBVFURRFURRFURRrPM8zgiAIgiAIgiAIglDD IfEqCIIgCIIgCIIg1HhIvAqCIAiCIAiCIAg1HhKvgiAIgiAIgiAIQo2HxKsgCIIgCIIgCIJQ4yHx KgiCIAiCIAiCINR4SLwKgiAIgiAIgiAINR4Sr4IgCIIgCIIgCEKNh8SrIAiCIAiCIAiCUOMh8SoI giAIgiAIgiDUeEi8CoIgCIIgCIIgCDUeEq+CIAiCIAiCIAhCjYfEqyAIgiAIgiAIglDjIfEqCIIg CIIgCIIg1HhIvAqCIAiCIAiCIAg1HhKvgiAIgiAIgiAIQo3HeYsXzDGiKIqiKIqiKIqiWJN53qGD B4woiqIoiqIoiqIo1mRKvIqiKIpiyly/ZqU5ffp00b9FURRFUUxGiVdRFEVRTJkSr6IoiqKYPiVe RVEURTFlSryKoiiKYvqUeBVFURTFlCnxKoqiKIrpU+JVFEVRFEVRFEVRrPHUp3JEURRFURRFURTF GsVY8Zr93qsgCIIgCIIgCIIgnHXEidcfvv9O4lUQBEEQBEEQBEGoOYiK14MHfjRLFs6TeBWEuoaN GzeaK664wmzevDnrkwzbt283l19+uVm7dm3WRxAEQRAEQRDSQ1S8bt/6iZkx9QOJ14pi/Pjx5sIL LyzI0aNHZy3PPdx///2557j44ovNLbfcYnr27Gm+//77rIUx11xzTblnJE0uu+yyrMuYY8eOmT59 +tjfX3rppeb666833bp1M4cPH85alN2LsH28+uqr5s4778y6whASZ9/moosuMvXr1zcdO3Y033zz TdaiDDzH7bffbp/l1ltvNWPHjs1eKXsmft+wYUPzyy+/ZH2NadasmfV3zzZkyJDcvXwOGjTIXgeh 6RMXDulfERw/ftze7+233876nAHPGXevkSNHZi3OYNSoUTYNeAZBEARBEARBSBNR8Trvo+lm29bN Eq8VxdGjR63ogUuXLrWd/MWLF+f8jhw5krU894Bg6ty5s9m3b5/Zs2ePfb4mTZqYhx9+OGsRJl5f eOEFKwI//vhjc+DAAbN+/XrTqFEj065du6xFuuK1VJx9m2+//dasWbPG3Hvvvebuu+/OCdFJkyZZ YYtg+/TTT+0zIobfe+89e92J17///e/29+DLL7801157rfV3wpP/48qGL0xD0wc7V64ciX9F8M47 71jRfvLkyazPGbz11lvmoYcess/ok896RHHq1CkbzogRI7I+giAIgiAIgpAOouJ18vvvmR+//17i NQ2wjBKBsmXLlqxPGZYvX26FD2LDB7OBzLQhaACzf4iqoUOHmuuuu85ceeWVpn379lY4+GBmDEHG ks+bb77ZCit/9s9h9uzZNj7Tpk3L+iRDnKB0Isw9S4h4JY7Dhg3LusqA4MPOIU3xWirOcTYrVqyw Nl9//bV1MyvZqVMn+7fDiy++aG666Sbz888/2zzBnjzr2rWrvc5sKvmFvy9OQaGyASqaPhUFZaWY 4HzllVdMmzZtsq7SIJx69erFlkFBEARBEARBqCii4nXS+HfNsaNHJV7TQCGBQqcesfnmm29mfcpA p58ZNsQQQByxZBQRxIwt4SAKBg8ebK+DiRMnWhtm5/jd1q1braDyl7Q6VIV4RYgTZhLx+uSTT5q7 7rrLfPHFF1mf8qhK8RqNc5zNypUrrQ2zp3v37rV/z5gxI3u1DC49sXHiddGiRXaQATfLZz/66CPr n0S8VjR9KgoXF/6PA4L8kUceMc8++6wV1pRd8tSV0yiYmSY8yqIgCIIgCIIgpIU48Xo80++WeE0B xQQKovOGG26wyywBgpZ9lL7wYwaPGTF/BmvAgAFWPDg0bdo0T8wCwmjcuHHWdQYI4B07dpQTUqGI CibE1X333Wf3dTqEiFdE42OPPWbT5o477rAzexs2bMheLQP3YpkuM9SOuCsrXuPiHLUhfo8++qh5 4IEHrJsDjIgrgtYHAwb4878Tr/z2nnvusfnE0l/c+CcRr6HpQ5qQrj6HDx+etQgHopywColRlitT nubPn2/Tj7LLLH+hmVrKKysIpk6dmvURBEEQBEEQhMpD4rUKUUygcEAOS4Fnzpxp3atWrbKC4ODB g9YNEK8tW7bMusrw4YcfmquuuirrMuaSSy6x94gS8VBIjFQUCCbux8wiQgkxyXLS7777LmsRJl4d EGkIHMQR4skXkNyrQ4cOVmw7smy3IuK1VJx9G/KAtGvbtm3O5rPPPrNpylJiH+vWrbP+7E31xSuz 3k5IVkS8OpRKH2ZEEZM+2SObFGPGjLFlMQkYMGEVQCEw+88+WkEQBEEQBEFICxKvVYhSAoXZOZZj AvZGcqKsD8Rrq1atsq4yfPDBB+bqq6/OuowVWuPGjcu6qhYIJgQky2TZCxp3+BQiKDojh5hDGBbD lClTbFohwAD38sUaqOiy4VJx9m0Qcghwt9cVMKBA3KIziW7ZMCLTF68//PCDeeKJJ+zflRGvPkLS p6KoiHjl2RkIiDu0CSBeo4MYgiAIgiAIglAZSLxWIUoJFE63ZcZv9erVVoRi7wPxetttt2VdZUDw +gKOU3G7dOmSdZWBg5+Y2Y0i7WXDcWCZa48ePbKuMvAbt4yZ/ZAtWrTI+1QNcLOb7hujaYrXUnGO 2jz99NPmwQcfzBNmLOn2T/sF7EnmICfgi1cfScVrZdKnoii1bJhBFXeImAPl0D17FFo2LAiCIAiC IFQFJF6rECGzayz9vPHGG/P2YDogXpmxZOYSIbVz5067VNM/iXby5Ml2ieqcOXOsDTNzfOKld+/e WYszqIoDm6Igbsxczps3z8aFZdEsc3b7chHVHGTEnlKW2+7fv98KMpZHcxiQ2wN8NsUrwpFDsPr3 75/1KUtn0o6lwAjMd9991wo+/EGoeOV//Ap9KidJ+sR9Kgc6m1A4YRwdPHFAvHJv9vwy4ILYpVxO mDAha5EPd2BTofAEQRAEQRAEoSKQeK1ChIjXjRs3WhuEZRSIV0547devnxVTCIaXXnqpnDhhTykz tIhYZsOYFYsTMNUhXvlOaK9evUyDBg3M5Zdfbmcsib8fH763yieAOIyKmWeejWXTLNt1OJviFSxY sMAui/X3ub7//vs2nZlV5H8OLnIIFa9Dhgyx7ig5UdohNH3iwoHRw51CgDgtdADTiRMnrJCnbFHG OIiKvdeFoE/lCIIgCIIgCFUBidezDGZMEQ4//fRT1ucMEK8sYRWEqgaHK/kzuxUFvy8mhAVBEARB EAShoogTr0ePHJF4rWowK8XMLB19DmGKg8RrPNibyYnBpcgssBAGZo6ZWa2s6OSQJsr00aNHsz6C IAiCIAiCkA7ixOvaVcslXqsa7GHkhNeBAwcWXF4p8SpUJ1jCzqeCQk9AjoK9rvx+zZo1WR9BEARB EARBSA9x4nX6lEkSr4IgCIIgCIIgCELNQZx4XbFskcSrIAiCIAiCIAiCUHMQJ143b9og8SoIgiAI giAIgiDUHMSJ1+1bP5F4FQRBEARBEARBEGoO4sTrp9s2S7xWNTgJ1/82p//NUEEQBEEQBEEQBCEf Eq9VgL59++YJU8fLLrssa1EGBCysV69erRKvPMudd95prrzyStO0adMKP1uScI4fP25uvfVW+7kX QRAEQRAEQRBqHyReC+Dbb7/N/pUciNfGjRubb775phzjUJvE67x58+znUubOnWv27dtn5s+fb8Un /kmQNJw+ffqYa6+9VuJVEARBEARBEGopJF4LgJnSIUOGmFOnTmV9woF4ZcYwFIXEK/d+9dVXzc03 32wuv/xy06RJEzNnzpzs1TJg061bN3P11Veb66+/3gwaNMj07t273Pdhx4wZY2677TYrAAlvwIAB 5qeffspePYPZs2fbZ582bVrWJxmaNWtm7+8DYfnoo4/av7knNp06dbJuh7Zt25oWLVqYn3/+2bpL heOD75M2atTIDB8+XOJVEARBEARBEGopJF4LAAGH2GvQoIFZtmxZ1jcMaYlXxDPXdu/ebUUqNpde emnerDCilBnHzZs32yXI/AYR26ZNm6yFMStXrjTXXXed2blzp3Xv3bvX3HPPPWbGjBnW7aMy4vWX X36xIpswfOBmybQTpsykEsdZs2ZZ9+TJk80NN9xg9u/fb92h4QCeGVHPM44dO1biVRAEQRAEQRBq KSReCwAB9+KLL9qZPoRf69atCy77jSIt8co+zh9++CHrKptlJV4LFy7M+hjz8MMPm169emVdxgo7 ZiF98YoQvfHGG83333+f9SmMI0eOmB07dpjDhw9nfcLBb4nfqlWr8kQwbv4+dOhQ1tKYpUuXWtG9 Zs0ac80115gVK1ZkryQL54033jDdu3e3f0u8CoIgCIIgCELthcRrASCSEK/t27e3wvWiiy6yfiEC FvGKPbOEPps3b561yEch8YrY7Nq1q2nYsKGdmcSOOPgzkiwBRrT5QLj64hUhiggnDi1btjQjR46s 1J7eQjh69KiNHyITMXr//febJUuW2FnRqOgE/fr1MxdffLEZOHBg1qcMoeFs2bLFCnXELpB4FQRB EARBEITaC4nXAkAkVWbm9fbbbzdffPFFHpMe2MSsKsJtz5491s2sKvHyxSvLb6PitWPHjnni1WHb tm1mxIgRdj8py48XLFiQvZIOWO7LIUszZ87M+pQBN8uA/eW+4Nlnn7WzrtG4hoRz+vRpc9ddd+XN 2Eq8CoIgCIIgCELthcRrASASz+aeVw42Ig6TJk3K+hizdevWcuIVAcf9HBB2xNsXhPgxm+mjZ8+e 5vHHH8+6zqAyy4YBhy716NEj6yoDB0pF78VeXWZNEfRxs8elwvn444/t7Dbi3ZHDqJjJ5W+uC4Ig CIIgCIJQeyDxWgCIxKo8bdh949V953X8+PE5NzOPAFHHacOAZb7PP/+8nanE1uH111+3v9+1a5ed jRw2bJjd3+qL19dee82KQbd/luXILGFm2W4U/h7TimDx4sV2eTKHMXEwFLOluFn268DhUgjNTZs2 Wfe6devsjCr+DqXCIV84+Mnn0KFDbZrxd0XyTRAEQRAEQRCEmguJ1wKo7HdeS4lXBGIhbt++3dow 48ssKuIUsclpwQhRhJ8TsMyQtmvXzh5+VL9+ffP222/b5c74OTDryqwl4bhP5fAZmhMnTmQtzqCy 4hXwW+LN0mSWT0+fPj17pWxm133Wxgef+GHJrz/jWyycOGjZsCAIgiAIgiDUXki81gK4mVqHp556 qtw3UgVBEARBEARBEM5lSLye4+DEXZbc8vkc9sny6RmW1/oHGQmCIAiCIAiCIJzrkHitBWAJMUtx EbEsr/X3xAqCIAiCIAiCINQGSLwKgiAIgiAIgiAINR4Sr4IgCIIgCIIgCEKNh8SrIAiCIAiCIAiC UOMh8SoIgiAIgiAIgiDUeEi8CoIgCIJQKXTs2NFSEARBEKoSEq9VhIkTJ5o777zTXHnllaZp06bW LQiCINQO3H///ebCCy+0vOiii0z9+vWtePvmm2+yFnULVSle03qf6r0sCIJw7kPitQowb948c8UV V5i5c+eaffv2mfnz59uXJf6CIAjCuQ/Ea+fOnW0b/+2339pvbN97773m7rvvNr/88kvW6uzj559/ zv5Vtagq8ZrW+1TvZUEQhNoBidcqQLNmzUzv3r2zrjL06dPHPProo1mXIAiCUN3Ys2ePueaaawry yy+/zFqWBuK1Z8+eWVcZVqxYYWdiv/7666yPMWPHjjVNmjSxwunmm282o0ePLidux4wZY2677TYr prAZMGCA+emnn7JXy1AqHAQZ9965c6cZPHiwqVevnnW3a9fOXl+2bJl1b9++3bodsMd/yZIlWZ/S 9zp16pTp1auXueGGG8z1119v+vbta9q3bx8rXmfPnm3DnzZtWtYnGUq9T0knbDp16mTdDm3btjUt WrTIiXe9lwVBEGoHJF5TBi/4yy+/3L6wfeC+7LLLqm0UXBAEQcgHQodlvYV4+vTprGVpxInXlStX WqHmRDDLUhF369evt23/1q1bzU033WTFoQO/ue6666yIBHv37jX33HOPmTFjhnWDkHAAArxVq1am devWZteuXebQoUPm+++/t9f4XcOGDa3Q9NGvXz/r795NIfcaNWqUufHGG82OHTuskB0/frwVummL 19D3KcKdOM+aNcu6J0+ebIX1/v37rVvvZUEQhNoDideUceTIEfuiXrVqVd5LGzd/05kQBEEQzm1E xSvil1m8Bx54IOtj7L5KZkF9MIvZuHHjrMvY9wNC0InMOISEA+644w7ToEEDKyjjMGzYMCvynEjn f0Te8OHDrRuE3Ivl0YheH/wuTrzyTkTkHj58OOsTjiTv06VLl5prr73WLt9GxDML7qD3siAIQu2B xGvKOHr0aO4lycuTDg7LsdyIvF6SgiAI5z5o2y+55BK71JdZx0svvdQuVf3uu++yFsZep92PEls3 24eoQ/QyA9iyZUszcuRIu4fWR0g4gMOIWM5bCMxQXnzxxXa/J+B/wk4aZwRw9LAjlienvec16fsU Qc3zDRw4MOtTBr2XBUEQag8kXlMGy5PoyMycOTPrUwbcLFvS8iRBEISzg7T3vLLPkt+wZ5Xf+3td AYJv3LhxWVdxbNu2zYwYMcLuzeR3CxYsyF4JDwfx6s+ixuGZZ56xBE899VRuT6xDyL0QrywV9tGm TZvUxWvS9+mzzz5r84G4+NB7WRAEofZA4rUKwCERPXr0yLrK0K1bN/P4449nXWcQsqQqLZsQVGd8 FGfFuRAUZ8W5ECoT56rc8/r000+bBx98MC8Mltd26dIl6yoDy4OPHz+edZXtRWVm0Afh+u+LkHBA iHhdtGiRnV394osv7Cwls5E+Qu7Fnlx/2TDPcMstt6S+bBiEvk8ZQGjUqJHNRw6Ziu4HTvJeFgRB EGouJF6rAIsXL7ZLwDg8gsM3GN3F7Z/m6ODvvymEtGxCUJ3xUZwV50JQnBXnQkgrzpVFVLwi8JiR 7N+/f9an7OAg2v45c+ZYUYtg5FM6/qm3r732mhVWP/zwg3UTTvPmzfPEYUg4IES8IjQRd4i222+/ 3c5K+gi519ChQ+0+3S1btlhx6vbSpn1gEwh5n27evNku3960aZN1r1u3zs6o4u+Q5L0sCIIg1FxI vFYReFHz6QOWYNFBmD59evZKPmpah64646M4K86FoDgrzoWQVpwri6h4BSz1veiii/IOC2J5Le8C hBKzk3wGxz9QiVlXZgD5tI37VA5C8cSJE1mLMpQKB4SIV/DWW2/ZNOQgpjiUuhdxe/nll61ghYMG DTLdu3e3n8uJIo384reF3qeIZ2Zco89NnIi7P+NbLBxBEATh3IDEqyAIgiAIgiAIglDjIfEqCIIg CIIgCIIg1HhIvAqCIAiCIAiCIAg1HhKvgiAIgiAIgiAIQo2HxKsgCIIgCIIgCIJQ4yHxKgiCIAiC IAiCINR4SLwKgiAIgiAIgiAINR4Sr4IgCIIgVDk6duxoebbBd2dHjhyZdZXHp59+ah577DFzzTXX 2O/2XnfddfZ7vFGUCkcQBEFIHxKvZxETJ060H5Xnw/RNmza17ijSsglBWvdKyyYEad0rLZsQpHWv tGxCkNa90rIJQVr3SssmBGndKy2bEISGc+LECXPXXXeZp59+OuuTj7TCqS4cO3bM9OnTx9xyyy3m 0ksvNddff73p1q2bOXz4cNaiDMePH7ciqDZhyJAhVrhFOWjQoKxFPKpSvCZJ58mTJ5vPPvss6yoP yleLFi2siP3+++/NN998Y37++efs1TMoFU5NwdixY2PzS8JbEIRzERKvZwnz5s0zV1xxhZk7d67Z t2+fmT9/vu204e+Qlk0I0rpXWjYhSOteadmEIK17pWUTgrTulZZNCNK6V1o2IUjrXmnZhCAkHGas li5dau655x47gxUnOtMKpzrxwgsvmNtvv918/PHH5sCBA2b9+vWmUaNGpl27dlmLMuDPsyRFnFiq KUCgI+jID0TQ4sWLrTsq3KOoSvFa0XSO4tSpU/aZKINnA1WR72+99ZZ56KGH7ICLz9OnT2ctBEEQ zh1IvJ4lNGvWzPTu3TvrKgOj+I8++mjWlZ5NCKozPoqz4uygOJ9BbY3zTTfdZGeymKXq2rVrrOhM K5xS2LNnj52dK8Qvv/wya1kaN998sxk2bFjWVYY1a9aY8ePHZ13G9OzZM2+myxGh54BYx2/nzp1m 8ODBpl69etYdFcHMnjVp0sSKfO49evRo88svv2SvlomuV1991V67/PLLre2cOXOyV8vEHWKbdK5f v76dPeV+zBwjxCuC7du327hu2bIl63MGxKdXr17mhhtusLPSffv2Ne3bty8nXks9V4cOHUyPHj3M m2++ae69914bd8JgptUhJJ1dXB3jZh0vu+yyPBvH2267LWsRFg4o9Vyh+Q5mz55tr02bNi3rkwyv vPKKadOmTdYlCIJwbkPi9SyAFxidC15IPnDz8mTkNS2bEFRnfBRnxdlHUpsQKM41J84AEeMQJzrT CicEP/30kxU0hZhkJurJJ5+0YvqLL77I+pQH95s6daqdETx58mSOPLMPhHOrVq1M69atza5du8yh Q4fsclUHllAjABGgpMfWrVutmEcgOSBGEUC7d++2acVvWM787bff2uubNm0yl1xyiZkyZYpZu3at Tdt3333XfPXVV1YY8fxJUUy8jho1ytx4441mx44dNj6IeoScL15DnuvFF180V111VU64HTx40D6n LxpD0pm/nX/jxo1jRSfxZBadZ1q2bFnO3i97IeGEPBcole8O1IXKiFfS/JFHHjHPPvusFdKIavLD 1S1BEIRzCRKvZwFHjhyxL6JVq1blvZRw8zcvsLRsQlCd8VGcFWfFuTxqa5yjiBOdaYVT3UDscagP cbzjjjvs7NaGDRuyV89g5syZJZez8vsGDRrkiSQf7AFmds4HM3mIJwdmIn/44Yesq0yIEbeFCxda N+IV93fffZeb9du2bZsVYxxKtHHjRmuXBMXEK7Ok/fr1y7rKwHP44jXkuchrBgl8MIPLjKyPkHR2 IL0LzZiynJZnovyVQqFwQp4LlMp3B+oIgwCllmUXArO53Jul0Ay2IK4ZSBgxYkTWQhAE4dyBxOtZ AHu33MtxxYoV5v777zdLliwxK1eutP501tKyCUF1xkdxVpwV5/KorXGOIk50phXO2QIillk/BMLF F19sl7D6CBFVHFTFEttCYMaUtIiSmVU3e8aMHenSsGFDu1TXLUNlQAA48crsMrb87ZZJE29mY5Oi mHhl5hGR5IM08sVryHPxTNElr3H5X5PEa8hzgVL5XpVwS5UFQRDONUi8ngUw0s2oJy9bH7hZPsfL LS2bEFRnfBRnxdlHUpsQKM41J85RxImOtMIJQZp7XuPAklxEir+UmOcIEa/Dhw/PusoD0TNu3Lis Kx4PP/ywFf48IyDdiEtUvLLEtrrEq7//FyBCffEa8lznongNeS5QKt+rEpQLZtx1aJMgCOcaJF6r EMWW+nAMP4dQ+OAzC48//njWlZ5NCKozPoqz4uygOJ9BbY2zj0KiM61wSiGtPa98QoU4R/cn8tkU hM/mzZuzPumIV5bgdunSJesqA/d2hxbxXNx30qRJ1g3YZ4nf2RKvnArtLxtGTHM4lC9eSz0XOBfF a8hzgVDxWtllw9QlToT2MWDAAJsfgiAI5xokXqsQ/v6tKHiRcGDGrFmzzN69e+2LFzfL5RzSsglB dcZHcVacFefyqK1x5rusCALYuXNneziNc7tZ1bTCqS4gQliey2nIfCpn//79VrC2bNnSHojj72Fc vXq1fQ/wWRn2pDIr62ZHHUqJGE5YJj04PRiBTRh333133gnN3JfThgGHND3//PN2NtnNfqYpXkM+ lTN06FDDgU0IW8QXJzMzG+uL15DnChWvpdKZPPEPWiK9ndsvP5QnwikkXkPCCXkuECpei/UlQoB4 pXywFJ/9zjNmzLBCf8KECVkLQRCEcwcSr1WIUi8c/DmCnyVGfMJg+vTp2StnkJZNCKozPoqz4qw4 l0dtjDMddNrBOPriNK1wqgsII0Q0n25hjyPCjIOEokuPETQvvfSSFZI8G7NdbjbUIUTEIEJJH0QR YTBz5otkTsflOvsYmzdvbj/B8tprr1mRwm/TFK+cbOynv+OgQYOyFmWDDS+//LJNF8i17t272zTy Ueq5QsVrqXTGPy7O0H/2UuI1NJxSzwWqS7ySF/3797fxID7Urw8//DB7VRAE4dyCxKsgCIIgCIIg CIJQ4yHxKgiCIAiCIAiCINR4SLwKgiAIgiAIgiAINR4Sr4IgCIIgCIIgCEKNh8SrIAiCIAiCIAiC UOMh8SoIgiAIgiAIgiDUeEi8CoIgCIIgCIIgCDUeEq9VCL6d538Djo+YVwf4CLz/Ifjairhv/Z1t +PkNBUEQBEEQBEFIBxKvVQjE66xZs+xH4aGP+++/PydwsOPj4T179rQfj68sKiJe+bg6cfniiy+y Pmcfx48ftx+EL4TqFq8TJ060H5Xno/9Nmza17ihcXs+fP1/iVRAEQRAEQRBShMRrFQJROnv27Kwr H4jXzp07m3379pk9e/aYpUuXmiZNmpiHH344a1Fx1Bbxun79eisUCwHx+swzz2RdVYt58+aZK664 wsydO9fmGeKUuOEfh4ULF0q8CoIgCIIgCEKKkHitQpQSr8y0+kDAIni++eYb6z516pR59dVXzc03 32wuv/xyK27nzJljrzlg06tXL3PDDTeY66+/3vTt29e0b9++ysTr2LFjbTwQcsRr9OjR5pdffsle NaZDhw6mR48e5s033zT33nuvqV+/vo0Ls6gOxLlbt27m6quvtnEeNGiQ6d27d94sKmlDfKJ0aQMQ r23btjUjR4409erVs7O0DAj493IgH/j9tGnTsj7J0KxZMxtHH3369DGPPvpo1pUPiVdBEARBEARB SBcSr1WIpOJ1+fLleQJtyJAhVpTt3r3bCj6WqV566aXm22+/tdfBqFGjzI033mh27NhhbcaPH2+F ZVWIV+6P2GRG9OeffzZbt241N910kxW0Di+++KK56qqrciLx4MGD9hkQmA5jxowx1157rdm8ebPd B8xzEm6bNm2yFmXLb6dOnWpnN7Fx9IUy4pVn79+/v/nxxx9teAhi0iSKyohX7sngQTQvcV922WU2 LaKQeBUEQRAEQRCEdCHxWoVIIl4Rjffdd5+d4XNgBvGHH37IuspmLBFECCMHZjf79euXdZWB/ZhV IV4Jd/DgwVlXGZh5bdy4cdZVJijvuuuurKsMzAQzI+vA0mhmix0Qf40aNcoTr2DmzJkllw3fdttt eYL2ueeey7uXw5EjR6zAP3z4cNYnHPyWtFm1alWeCMbN34cOHcpanoHEqyAIgiAIgiCkC4nXKkQp 8XrJJZdYccbs3UUXXWTF23fffZe1MPbwJgRaw4YN7bJgZjARRH6YzFhGDw5q165dlYhX4otNlMwG u9lH4hsVofj5S4JZbuzP1gJ+UxHxGt3zGr1XGjh69Kh9TsTqihUrbN4tWbLErFy50vpLvAqCIAiC IAhC1UPitQpRSrx26tTJfPnll+brr7+2s3tRMEOJHQc6AQQigigqXlkq7AMRWBXiFZE6bty4rCse IeKVOEfFK/GtiHgtda80wMwuS7GJjw/cLCfWsmFBEARBEARBqHrEidftWz+ReE0DSfe8+mDPJ+Jn 0qRJWR9j95hGxes999yTt2wYIcVnd6pCvLJEuUuXLllXGZgd9g9IChGULCvmYCkH4szy36oUr5VZ NgxatGhhD6LywaFTjz/+eNaVD4lXQRAEQRAEQUgXceJ12uQPJF7TQGXEK2B5LacNAw5pev755+2J uv5M69ChQ+2hRVu2bLECbdiwYXZms6LidfXq1fbAKJ9uZnHy5Ml2iTMnHp8+fdoK3bvvvjvvFN4Q Qfn666/bJdC7du2y4RBnniH6O+JCnDiFmb2/3M/NQoMk4pV8IKyKnja8ePFi++x8t3fv3r1WWONm +XAcJF4FQRAEQRAEIV1Exeu4MSPNqLeHSbymgcqK12XLltkZSYRe8+bNzc6dO81rr71mZyOdgD1x 4oR5+eWXrWCFfHame/fu9pCkJHDiNY4HDhzIWhl7X+KEcGOGd8CAAfYgKYcQQcnsJ/tyOXGYT+m8 /fbb9pRi/Hwgml966SUr2FmyzP389KxO8Qr4Lc9OXG6//XYzffr07JXykHgVBEEQBEEQhHQRFa8j hw82H29YL/GaBoqJ17oO/4Rg8NRTT5X7juq5DIlXQRAEQRAEQUgXUfE6dNAA8+OPP0i8pgGJ13iw xJmDjhB47O1ds2aNncnlJN/aAolXQRAEQRAEQUgXUfE6eOAbVk9IvKYAxCsCxvHkyZPZKwLLj/m2 KyKWJbjRE5PPVfj5DQVBEARBEARBSAdx4pWthhKvgiAIgiAIgiAIQo1BrHjVzKsgCIIgCIIgCIJQ k6CZV0EQBEEQBEEQBKHGQzOvgiAIgiAIgiAIQo2HxKsgCIIgCJVCx44dLQVBEAShKiHxWkWYOHGi ufPOO82VV15pmjZtat2CIAhC7cD999+fO1X8oosuMvXr17fi7Ztvvsla1C1UpXhN632q97IgCMK5 D+15rQLMmzfPXHHFFWbu3Llm3759Zv78+fZlib8gCIJw7gPx2rlzZ9vGf/vtt/Z71ffee6+5++67 zS+//JK1OvvghV4dqCrxmtb7VO9lQRCE2gHNvFYBmjVrZnr37p11laFPnz7m0UcfzboEQRCE6sae PXvMNddcU5Bffvll1rI0EK89e/bMusqwYsUKOxP79ddfZ32MGTt2rGnSpIkVTjfffLMZPXp0OXE7 ZswYc9ttt1kxhc2AAQPsB9d9lAoHQca9d+7caQYPHmzq1atn3e3atbPXly1bZt3bt2+3bgfs8V+y ZEnWp/S9Tp06ZXr16mVuuOEGc/3115u+ffua9u3bx4rX2bNn2/CnTZuW9UmGUu9T0gmbTp06WbdD 27ZtTYsWLXLiXe9lQRCE2gGJ15TBC/7yyy+3L2wfuC+77LJqGwUXBEEQ8oHQYVlvIZ4+fTprWRpx 4nXlypVWqDkRzLJUxN369ett279161Zz0003WXHowG+uu+46KyLB3r17zT333GNmzJhh3SAkHIAA b9WqlWndurXZtWuXOXTokPn+++/tNX7XsGFDKzR99OvXz/q7d1PIvUaNGmVuvPFGs2PHDitkx48f b4Vu2uI19H2KcCfOs2bNsu7JkydbYb1//37r1ntZEASh9kDiNWUcOXLEvqhXrVqV99LGzd90JgRB EIRzG1HxivhlFu+BBx7I+hi7r5JZUB/MYjZu3DjrMvb9gBB0IjMOIeGAO+64wzRo0MAKyjgMGzbM ijwn0vkfkTd8+HDrBiH3Ynk0otcHv4sTr7wTEbmHDx/O+oQjyft06dKl5tprr7XLtxHxzII76L0s CIJQe6A9rynj6NGjuZckL086OCzHciPyekkKgiCc+6Btv+SSS+xSX2YdL730UrtU9bvvvstaGHud dj9KbN1sH6IO0csMYMuWLc3IkSPtHlofIeEADiNiOW8hMEN58cUX2/2egP8JO2mcEcDRw45Ynpz2 ntek71MENc83cODArE8Z9F4WBEGoPZB4TRksT6IjM3PmzKxPGXCzbMnvaAiCIAjVh7T3vLLPkt+w Z5Xf+3tdAYJv3LhxWVdxbNu2zYwYMcLuzeR3CxYsyF4JDwfx6s+ixuGZZ56xBE899VRuT6xDyL0Q rywV9tGmTZvUxWvS9+mzzz5r84G4+NB7WRAEofZA4rUKwCERPXr0yLrK0K1bN/P4449nXWcQsqQq LZsQVGd8FGfFuRAUZ8W5ECoT56rc8/r000+bBx98MC8Mltd26dIl6yoDy4OPHz+edZXtRWVm0Afh +u+LkHBAiHhdtGiRnV394osv7Cwls5E+Qu7Fnlx/2TDPcMstt6S+bBiEvk8ZQGjUqJHNRw6Ziu4H TvJeFgRBEGouJF6rAIsXL7ZLwDg8gsM3GN3F7Z/m6ODvvymEtGxCUJ3xUZwV50JQnBXnQkgrzpVF VLwi8JiR7N+/f9an7OAg2v45c+ZYUYtg5FM6/qm3r732mhVWP/zwg3UTTvPmzfPEYUg4IES88oJH 3CHabr/9djsr6SPkXkOHDrX7dLds2WLFqdtLm/aBTSDkfbp582a7fHvTpk3WvW7dOjujir9Dkvey IAiCUHOhA5uqCLyo+fQBS7DoIEyfPj17JR81rUNXnfFRnBXnQlCcFedCSCvOlUVUvAKW+l500UV5 hwWxvJZ3AUKJ2Uk+g+MfqMSsKzOAfNrGfSoHoXjixImsRRlKhQNCxCt46623bBpyEFMcSt2LuL38 8stWsMJBgwaZ7t2728/lRJFGfvHbQu9TxDMzrtHnJk7E3Z/xLRaOIAiCcG5A4lUQBEEQBEEQBEGo 8ZB4FQRBEARBEARBEGo8tOdVEARBEARBEARBqPHQzKsgCIIgCIIgCIJQ4yHxKgiCIAiCIAiCINR4 SLwKgiAIgiAIgiAINR4Sr4IgCIIgCIIgCEKNR5x4/en0aYlXQRAEQTgXwXdVR44cmXVVDzp27Ggp CIIgCFWJqHgdMuhNc+DAjxKv1YGJEyfaj8rzYfqmTZtadxRp2YQgrXulZROCtO6Vlk0I0rpXWjYh SOteadmEIK17pWUTgrTulZZNCNK814kTJ8xdd91lnn766axPPkLDqQ7cf//9ViTCiy++2Nxyyy2m Z8+e5vvvv89anD1MnjzZfPbZZ1lX9aAi4vXYsWOmT58+Nu0uvfRSc/3115tu3bqZw4cPZy3KcPz4 cXPNNddkXbUDQ4YMyZUfn4MGDcpanCljlK8bbrjBPPfcc2bjxo3Zq+mD+tSkSRNzxRVXmEaNGpm3 3nrLfn5CEAShJiEqXkcOH2w+Xr9O4rWqMW/ePPuCmDt3rtm3b5+ZP3++7ZDh75CWTQjSuldaNiFI 615p2YQgrXulZROCtO6Vlk0I0rpXWjYhSOteadmEIK17HT161CxdutTcc8895rrrrosVryHhVCcQ Fp07d7Zx2bNnj40/Hf+HH344a1EYtVEQVES8vvDCC+b22283H3/8sTlw4IBZv369FU3t2rXLWpQB f/I6KWpyOiPQv/nmG1tuEKiLFy+2bl+4U8ZIoy+//NKsWLHCileELL9JG9OmTTOXXXaZ+eijj2yZ XrRokbn66qvNiBEjshaCIAg1A1HxOn7MSDPq7WESr1WNZs2amd69e2ddZWAE+tFHH8260rMJQXXG R3FWnB0U5zOoy3G+6aab7IwrM4Zdu3aNFa9pxBmRyQxeISISQoGwYKbVhxMiiBCACMC9c+dOM3jw YFOvXj3rjoqzMWPGWNGGOEcAjx49Oie8EG4IPJ69fv36dsaOsJitRNg4bN++3YbtWGjZMPe67bbb rBi8+eabzYABA8xPP/2UvVqGsWPH5mbgsCE+v/zyS/aqMadOnTK9evWys4HMlvbt29e0b98+sXgl 7GHDhmVdZVizZo0ZP3581mVsGvvP5ejSGISmc8hzvfrqq/ba5Zdfbm3nzJmTvRqeF0ng8m3Lli1Z nzOIK2PPP/+8jVcUs2fPtuEgQiuCgQMH2mfxQV18/PHHsy5BEISagah4nTT+XTNt8iSJ16oEL0te jLxsfOBm5JNOS1o2IajO+CjOirOPpDYhUJzPrTgDRINDnHhNK86INERPIZ4+fTprWRpxwmL58uXl hBWiuFWrVqZ169Zm165d5tChQ3lLixEbV111lVm5cqWN34YNG+xvhg8fbq9v2rTJXHLJJWbKlClm 7dq19nnfffdd89VXX+XdizQ6efKkZePGjWPFK/dgZhuRB/bu3Wtnu2fMmGHdgKWjCFKEGum6detW O7iA8HMYNWqUufHGG82OHTts3iE2EYRJxeuTTz5pBy2++OKLrE95kCZTp061Yts9H+R5fZRK55Dn QowifHfv3m2fi9+wnPnbb7+110PzIgmSitclS5ZYe/LOB3UB/4qK1zg0b968wqJcEAShqhAnXrdv /UTitSpx5MgR+5JZtWpV3gsHN3/z0k3LJgTVGR/FWXFWnMujLsc5ijjxmlac00RUWCDA7rvvPjtD 7OOOO+4wDRo0yBPoPu6++247g+yjf//+djYPIJh4xu+++y43w7ht2zYr3i666KLYPZDcM068kmaI zmL7ctlLHJ2BY4YSQexw7733mn79+mVdZeB3ScUrYu+xxx6zz0ScX3nlFSveo5g5c2bJZcOl0jnk udhb+8MPP2RdZYMqxG3hwoXWXZG8KIWk4pW9zNgTFx/UEQYTovuFKwqWCzOokmQ1giAIQnUgTrx+ um2zxGtVgv1dvHzoeLGPhRcUo6mMiuNPRywtmxBUZ3wUZ8VZcS6PuhznKOLEa1pxThPEgVk4RBUz cIiXNm3aWGHjgwOmWGJbCMxYMpPnA7HGczHr6AQTs8KITv52goL9j8wARlFIvCJsWGZNfFu2bGlt 3KyiA8/EPaJkBtLNcDODGT0siyW6UfHKkmQ/DJYXxwERy+wqYfBMUcEWIl5LpXPIc5G+lL+GDRva JdFu+TEDJiBJXoQ+e1LxikDGfvPmzVmfdIEQf/PNN+1MNku4BUEQahokXs8CeDnQYeGF7AM3S+N4 kaZlE4LqjI/irDj7SGoTAsX53IpzFIWWDacR57T3vHbq1Mn+5uuvv7YzX3FAVLklwFHwXIge9vr6 4LkQKL545e/KilcHZguZWWOWGPG2YMGC7BVj3ePGjcu64oF49felAoR7VLwSX2YDHXGXAkKeZ/SX EpMeIeK1UDqDkOfisC3ylXICKFfEJSpeQ/Ii9NmTitdZs2ZZe3+GOC0w09yhQwe7J5o4C4Ig1ERI vFYhii3jadGihenRo0fWVQY+EeAfjpCWTQiqMz6Ks+LsoDifQV2Os4848QrSiDOig1m+Qqzsntc4 lBJVHL4TPYiKZcNuOWua4hUxxiy2D57BT0OWBHfp0iXrKgP3ZUmtA/tk/WXDhMsy5yTLhj/99FOb p1FR55bF+jOLaYjXUs9F+nLfSZMmWTdgXyx+FRGvoUgqXsmrBx54IOs6g8ouG6bsP/PMM+bBBx+0 Jz8LgiDUVEi8ViH8vVlRcCw+S7cYReXgBV7OuFkK55CWTQiqMz6Ks+KsOJdHXY4z33flm5+Qz89w 6I5zu1nVtOKcFtISr8xgsreQg4SYiXUHNr333nv2eqhgYtbMP7CJezq3S8PXXnvNCkY3a0d4HMrj C1FmgUlXTtlF0DADyr5cX2APHTrU7p1FcCGaODGY2dgk4hXRyPJcljHzqZz9+/dbwcpyZk779feu rl692j43pzkTd+LkZkcdSqVzyHNxX04bBiyn5mRf8sLNMqcpXhGZDJiEfCqHZ2UJL7OizCCvW7cu a3EGxfobISBPyUMOnyIOjoVWFAiCIJwtSLxWIUq9TPBneQ4vI47fnz59evbKGaRlE4LqjI/irDgr zuVRV+OM8KCtjKMvTtOKcxpIS7wiWFnCy2wp39VkJpbTfPEHoYIJkeWnm09nw6wrs9Xs5WQmE7GG eGPwwAdijXRG7DGjyv5NX0xi//LLL1uxAwcNGmS6d+9uP5eTBIgyBiv47Ax7UgmLMNzzOSC+X3rp JfuM5D1xcrOhDqXSGZR6rmXLltnrpA+inlOZEfykFb9NU7xysrGfR46kpQNlzPlTNhD2cQdagcqK VwYj3L18lprxFgRBqG5IvAqCIAiCIAiCIAg1HhKvgiAIgiAIgiAIQo2HxKsgCIIgCIIgCIJQ4yHx KgiCIAiCIAiCINR4SLwKgiAIgiAIgiAINR4Fxev+xy80oiiKoiiKoiiKolgTWFC8Hm5/oxFFURRF URRFURTFmsDC4vX5G4x4bvL0xwst466dE+xwk/l5/1fmxNSB8derm4pPcSo+xan4FKfiU5w1LT4R gpOzhuf7Kw2Ls4bn6cmZw8wvxw7ZvP3py62xNr8c/M4c6XxL7LVKU/lVnIpPcSo+xVkL4lNQvB5q d70RK8afvv7UnFo5Lc/v1PLJ5ue9u/L8qopOvMZdq0k8MbXsY+wnF7xX7tqx0S+ZX44eNIc7Nyp3 LcdMAT4xc7j5+bs9mTfsafPL4R/MyUXvm0Mdb87ZnJj6lr1HFPzO2ZAvcfh5/5c5m6D4ZHj8g/7m 5327jTl10vz8w7fm5Lx3zaH2N+auh9yrpsUnJA2VX+Wh/CqzUX6VR5XkV4bHP3jd3vOXk8ft/8Qv zyYgT2HJcDwen/iaOdKveTl/lbHyqMllzPHIqw8Y88sv5tjwDuZQplPp3+tIr/vM6U+W2niDX44f Mae3rbK/8cOwtn2bmZNz3jFHXitfNg61r2dOzh1tfv7+G/PLqRM2/3Hb+2VtVH7KoyaXH+VXeZzz +ZVh8Lug083m52+/MKe3roy9fqT3w+b0p2vtc/1y5ECZRsr8xl1PWn4Ki9e21xmxYvzpq4x4XZHJ GM/v1DLE6xd5flXF0x8vsIy7lpgUmDj/FPjzns/NT7u2mF8O7Iu9z0+7t5iT88eW83c8MevtTCX4 0b5kD3e/yxwb9rwt/CcXjs/ZnJz7biacreZwp4Z55OWZC6tj/XLXf9qxISOqx52xybBUfI6Pf8WY 06fM8THdy+Iz8gXzy4ljZQ2Gswu5Vw2LT1AaZqj8KmKTofLrDJVf6ecXL386Bvxv4/NOVysMcDub kDwNCSeUKmNFbDKsaWUMHhvRKdMT/qmcP/zpy23m9IYF5vCLt9mZ18Pd7jSnNy4q69tE3uH4//TF J+b0piV5/hBRy3vfCdsj/VqYXw59b07MHpVnp/JTxCbDmlZ+lF9FbDI81/Ir5F1w+IWG5tjbHW1/ ntUaVrx6YVibjCClfp9c+oE50ut+c/TN1lZs2wErzy5J+SkiXq/NGIsVYZl4nZrnd0a8nvE7MWVg boTllwP7zYlpgzMNOZmUtelQz/6Ol4Q5fdLaHnuXQnMmDEZkTi2fksnQA2WNwJJJmZcGM6+I1zN2 pe51uPuddmTmSJ+Hy14sh3+07tObFueFA4+N6WavHR//arlroWSkntHdI70fsnE6OuS5cjZHBz1t K8rhbk3LXYPHP+xvK7fvd2r9XDu6k3Mvn2xOb16WZ1OKPNfPP3yTaSRuyvMvFZ+T88ZkK+MZv1Nr ZtmGxffzWehePs92fELTUPlV3Eb5VUblV9XkF0KBzoHvd3LppIz/ppw7JE9DwrHtt4cTM4fl2Tuq jBW3qWllDB4b1dl2oMtdy/QXzM8/ZzqOz1u3Fa+dGti4s3rqcOdbcrb40ck83PV226E90uOuM+Fk eHr7anNq9cw8v1NrZ9tZXN9P5ae4TU0rP8qv4jbnWn6FvAsQpcy4Hn+/TyauH2XE64o8e4je+HnP jnx/ZpN9d4ZJyk9B8Xrwub8bsWL86avt5mRGvPp+J5d9aDPYuY9P6mfF5pGBT5mDmYw48vpjthAc z4hMZ8Mo5C+HfjCHX7nfHMxkNL9hqQUjIDmbGUOs0Dzc95Eymw/fsGLw1IYFOZuQe0G7BGj7GvsC OfzKA+YQL6OXGufZwGPvvmw7LMfGvVLuWihPLp5ofvr8Y/v3qY2L7IsragOpgLzk4q7lsd315mh2 FO/YuF45/1Mb5pufdn1iTm9Zbn7OiHYEPGlEOuT9PkuWMfxyJBPGOy/GXg+OT5Y/fb7RNs5x10rd C9aE+CRJQ+WX8kv5dRbyK2PLACeDm74/boTIwYzw8P0t4/I0NBzi1r6epd2rNGNonr1PlbFzq4wd zXQObV5H/KGdeUVgvtzEileWe8bZnZj3rjm5aIL9m87vifnv5V0/lulw07ehL0KZov9CePj7dlDl 59wqP8qvWpJfGdugd8HzN+SuOfHq3I60GUysMcj183dfmZ/3ZuIz7a1KlZ/C4rXNNUasGBGvzCoy Spljxm3Fa9aGteMn5ryT9zsyk46Ac9sp/hdvO2OTqezg6IgXcn4/ff1Z2UvC2WRI2BRe313qXvDn fV9mCvq+ssLo+Ud5iNHW3g9n/m8Ye70k215nBfexCb2t++jIzuaXk8fsfpeo7eFXHywT7Jn7Ra85 nlz8vk1fllfYl593DWHMc3IPwrIDABlxz0yBb+fIsoSfv91ZVkFirofEx5EOHc91uNd98ddL3AvW hPgkSUPll/JL+VX9+YWIsO+GwW3KOhcZ0CHEDQ69kN9WF8rTpOFA3hs8e9TfMSQNVcZqThljUBpB EfWHh3vcY07vWG/zCp7+ZIk5Nrpr/v0y/Qc7oJ6NI4PvdLAPPn/jGZsM6chaEFYGJ+aPzbvuqPJz bpUf5VftyK+KvAuYJT69JSNeI/52z+zRQ/Z5Dve81xwb9aL55fhhG/+obUj6UH4KitcDz15txIoR 8crM5+FXH8qRkZOfMuLV2bCnJBaZTDuQyRxsDna5zZxcPcv8/OPeTON/wG5uB0dHv5QLB/9jE1/L ueGpjYuteHXukHtB4ndy2eScu6p49O2OdkTnYKZyWL92mZfdiaPm6Nju5WzhyZXT7Dr6uGuQdDr8 2qN2Jtk2hu/3jbVztDPambQsd63d9eaXY4fNsbE9yl/zWCo+pOmJeWPsMx0Z9Ey8Tci9alp8PBZM wwyVX8ov5VeEVZxfBzvcZJv0I289a44Mfs6+g44Mb5/5u6yjcbBTg3z7AnmaNByIeD0+fUg5f58q Y+dAGcvc49ArD5if9nxuTi75IM82ykMv3WH7Hqww456nd2wwB5671l479l4vu4LLt8eNSHFuysvP P+w1h/u3tPE+3K+F+fm7r22c/N85qvycA+XHo/Lr3M+virwL0CuI16g/M7/Mvvp+xxHeB7/L83MM KT+FxeszVxmxYiSTTy6fkufH0hkrXrNuhOOxD/rn2UT5067NNqxD3e4s88sUaHD0na45G7vkYtLr OTc89cmSjFjOiNesO+RekPgdnzks9lqaRFzbUbfjR3Jkdtq+8GLsD714u10Hz7LnctcpzJ772Puv 2cYw6u/z6Dsv2vvbl63vj6jOpBWV1vePsmh82l5nBw54ETOCVO56liH3qmnx8VkoDaHyS/ml/Mpn ledXJj/wO/ruy3m2uBkozMuvYnmaJJwsrXidlhGvEX+fKmM1v4wxSwM4RPFguxvK2UfJcsSDz9fL CNkm9r5Hhj1v/Tnzg7j4tkeHd8iI4h05N/0WljH6NgzC/3L8aJ6fo8pPzS8/PpVftSC/MvmBX5J3 QZl4XV7O//Rn6zKCdHqe39FRXcrik9E1vj8MKT8FxeuPmYtixejEq+93IiteczYs913zUZ7Ngc63 mgPP31jmbvN3+yI5OqFP7vqhvo+W+WXEq/PjhXBi4fic+8dMxnK8NuI1Z1PqXlk68er7xfFAh/rm EJWq482x14vxQKeGtsIdZb/sy01ztBUiU5APdm0c+7vjc96x6crzWT+eM/PypNPk2x0d/6ot9M7u 5IppmZdq+zwbRrRII98Pnlw7x5zaurKcfxzLxQdmGoVTm5fb7+LxnL59lCH3qinxSZKGjsqv4lR+ FafyK2F+Zcjs18nlU/PsCPv0Z+vL3IF5WjKcCJ14jbvmU2WsOM96Gcvc92DPe83pLz6xA+C+LTwy pK09wdTFj7w7kBGv7u+j43rl2RejnTGa/Gae37GMmMXf9/Op8lOcZ738RKj8Ks4an18ZJn0XIF5P ZcRr1P/Ewgnmp7278sJGa1Sm/BQWr09facSK8acvM+J12eQ8vxNLEK87c27EGyLuyKguVqge6nlf mRBdMilnQ0bxO/4+2PUOc+rjBXZk8tjEfjkbpt7ZX4KwPdD+pkyBGG5HNU+tn5ezCbkXJH7HZ2TE q+cXR8SzFdFje8ReL0ZmiXmGH5+7Lv/as9eULYGe+la+f5YH2tez11ky7fxOLBhn19EfebuTFb2H Bz5tK8PJtbNzNlQ00vHwoGfNwRdvz4jkbrahZJTX2Tgy0nX8o5Hl/OMYFx+bFxm/g93usgI/x0y+ +L+FIfeqKfFJkoaOyq/iVH4Vp/IreX4x88VBGviRX3ZAkHZ/6PM5m5A8DQmHTpZtwzO04pX3RtZt OxrOzqPKWHHWlDLG+51vOkb96UwTFwbmD3a51YZHWLyzCevgy3eW+00hnlj6oc3nQ32a2U7poV4P 2HJ0ItJv8qnyU5w1pfw4Kr+K81zIr5B3wYG215sD7W60JB8R1M5thWfGhufh/uQ/4bAMmXJQqL8P S5WfguL1h6euMGLFyIl8NMK+H0IRcej7Hc2IUAoghYMKfHzuu+aHjIhz1w9nMpjrPx/63pzmZN6M 6Dy+YLx9sfBbbOgsnFg5PZOhBy2Pzx5lTiyfak5umJ8LB5a6FyR+x2YMzfOL45FRL1rxemRMj9jr xUjanFw1M/aaE/hx1+DRjPDlSPBcvDP/H5s2xO4JpkLxXCcWvW9+fP7G3G9In+PzxtrfWRs2sWfE vLvu01bS8b1jr8UxGh/3eaEoyK/ob0PuVVPikyQNfSq/ilP5VZzKr/K2PsvlV4a0ybadz4ZzJNNp 8X8TkqewVDh2q0cBHBrQKs/Wp8pYcdaEMnZ4eAcbVtQfHuT8ji0rbAfSxoMvFGT6JsXyPI42PnNG 2zL2y+mTto9zYvFE6x9n76jyU5w1ofz4VH4VZ43PrwxLvQvosxfC4SHtcnaHXn/cnN69pSycTH2n HPzwzFV5YUVZrPwUFq+tLzeiKIqiKIpi3eDhoe1tBzPumk9mdn5se33sNVEUxapkQfH6fevLjCiK oiiKolg3eLD3w3bW5ODrj8deF0VRPNuME6/bt36SEa+tLjWiKIqiKIpi3SHbijibApzetTnWRhRF 8WwxTrxu3rTenPfdk5cYURRFURRFURRFUawJjBOvK5YtMuftf/xCI4qiKIqiKIqiKIo1gXHidfrk SeY8u15EEARBEARBEARBEGoA4sTr2lUrJF4FQRAEQRAEQRCEmoM48Xrs6FGJ1zRw8cUXmwsvvDDH kydPZq+cfXTs2NFSCEPXrl3N008/nXXVLvhlFAqCIAiCIAhCTUSceD1+7JjEaxpAvM6aNcv89NNP lj7uv/9+07Nnz6yrDK+++qq58847s66qxdkUr2vXrrUi6Ysvvsj6nH0cP37cXHPNNVlXeZwN8Xri xAlz1113FbzvxIkTbXm58sorTdOmTa27EHi+W2+91dxyyy1ZnzNw5XP+/PkSr4IgCIIgCEKNhcRr FQLxOnv27KwrH7VJvP7888/Zv8JQE8Xr+vXrrQgsBMTrM888k3VVLY4ePWqWLl1q7rnnHnPdddfF itd58+aZK664wsydO9fs27fPCk/ij38c+vTpY6699tpY8eqwcOFCiVdBEARBEAShxkLitQqRhngd O3asadKkiRUqN998sxk9erT55ZdfsleNOXXqlP0d1y6//HJrO2fOnOzVMmDTq1cvc8MNN5jrr7/e 9O3b17Rv376ceC11L0QS4mbnzp1m8ODBpl69etbdrl27rEUYQsVrqfh06NDB9OjRw7z55pvm3nvv NfXr17fPxCyjA8/erVs3c/XVV9tnHzRokOndu3eeICQfiE+U33zzTdaiTLy2bdvWjBw50j43s7Sd O3fOu5cDec7vp02blvVJhptuusnOuE6ePLngjG+zZs3sc/hAoD766KNZ1xls3LjRNGrUyAwfPlzi VRAEQRAEQThnIfFahaiseGUZKIKLWUFmN7du3WqFDaLOYciQIVZM7d692wo1fnPppZeab7/9Nmth zKhRo8yNN95oduzYYW3Gjx9vBaEvXkPuBRBtrVq1Mq1btza7du0yhw4dMt9//332ahhCxGtIfF58 8UVz1VVX5UTiwYMHbVogMB3GjBljZxw3b95s9xyTXoTbpk2brEXZstmpU6famUtsHH2hjIgkDfv3 729+/PFHGx6CmLSNorLilTxyiBOvxIuBimjZwn3ZZZflzYTzHAwArFy50qadxKsgCIIgCIJwrkLi tQpRSrxedNFF1sYRty9e2cfIDKcPZh8bN26cdZXtZfzhhx+yrjLhgwBBiDgwK9mvX7+sqwyE7YvX kHuBO+64wzRo0CBPYCVFiHgNiQ/CjhlKH8woMyPr8PDDD9tZZweEHbOQvngFM2fOLLls+LbbbssT tM8991zevRyOHDliBwoOHz6c9ak44sQr4ZN+q1atyhPKuPmbAQWHN954w3Tv3t3+LfEqCIIgCIIg nMuQeK1ClBKvCB9EjmOnTp3yxOsll1xixUSUzKy62TVmPRE4DRs2tMuC3VJe/77MNEYP82Gpry9e Q+4FiJ8vBiuCEPEaEh+eOypCo2KP5cbR2WN+UxHxGt3zGics00bcPdgTS1ogVlesWGHL0pIlS+zs Kv5OvG7ZssUKdcQukHgVBEEQBEEQzmVIvFYhSonXUsuGEWrjxo3LuuLBzCJh7dmzx7oRdgiQqHhl qbAPxJsvXkPuBYgfeycrgxDxGhKfEPHKs0fFK89dEfFa6l5Vgbh7MPvLsm/i7AM3y4kpA6dPn7az 0ohbB4lXQRAEQRAE4VxGnHjVd15TQmXFK8t9u3TpknWVgZlWd0gQezURG5MmTbJuwN7QqHjl1Fp/ 2TDiBhHji9dS93KoLvEaEp8QQYmA44AqB56d5b9VKV6retkwaNGihT2sygcHUz3++OP2748//tgu Q0e8O/J8lEn+5noUEq+CIAiCIAhCTUZUvH448T3zw/ffSbymgcqKV06b5QAeTg9mJg2xd/fdd+ed MsuyWH4HOKTp+eeft4cq+TOtQ4cOtYcNsYwUYTVs2DArYHzxGnIvkKZ4Xb16tT3R16dbEhwSnxBB +frrr9ul1BwuRTg8O2kR/R1xIU58ooY9xNzPzWaDJOKVPCesih7YxPddjx07ZsmJxhyO5dwufRYv XmzTh+8I792714pv3CwfBuxJ5nRon5QDygt/x+1ZlngVBEEQBEEQajKi4nXeR9PNtq2bzXlcEEVR FEVRFEVRFMWaQl+8btvyiZkx5QNznu8piqIoiqIoiqIoijWJBw/8aJYsmi/xKoqiKIqiKIqiKNZs /vjD9xKvoiiKoiiKoiiKYs3neRw7HMJxY0aaEcPeMkPfGmAGD3xDFEVRFEVRFMVKkr71yOGDzfhM XzuuDy6KdYkfvv+emfvRdLN962a7VLiceOV7OXzwtRCPHD5sPpjwnhn19lCzYf1ac+DHH+ynWzgN 9Wf/f0ffHb0miqIoiqIoinWBxfrIWf50+rQ5cOCA+Xj9ukxfe5iZOmVSptP+ifl022ZRPKdJOd68 ab1ZuXSRmT55klm7ark5euRIrN50RJfyORx3ONOShXOtO0+8xv3Q5wfvjzcfTpxgP9/BZzdOnjhh Tp48af8/lf0f8tkP6+/5iaIoiqIoiqJYxlx/2ffP9p/pd3846X0zPdNp/2z7FlGsNUTIzp8z06xb vbKc1izEw4cOmSUL5pqlixfkzcAWFa+bN31sRg4fmlHBRzKV7XhBnvT+d8yzOX5MFEVRFEVRFOsG o33hDG3/2F2LseH60Uyf+523h5m1q1aYHZ9uE8Vaw0+3bjazpk823+75OlZ3xhEB+9GMKWbHZ9vK i9evvvyy3A8mvPeu2bB+XaaCHbduZl+PHTtqedz+7/x8ZvwzFa/sepYZtyiKoiiKoijWCUb7wZn/ /b7z0aPZv9m+lxGyltbmmFm/bq2Z/MH75vPPtotirSJLh9esXGbLeZSPPfaY2bRxYzn/z7ZvNUsW zcsXrwjXDz74oJzxsMED7ZHER48cthWP/+ER/j8KM35Zf/ysf+561t7ZiKIoilXKMe+MMKDY36Io imI10e8Xu/8z/rbPfPiQ/f+Y7U9n+8vZ699/t9+MGDbY7NzxqSjWKnII0/yPppfTnBDx+tRTT5UT sGjROTOnnhGvHMg0YcIEM3PmzDxDyAlozLraCnboYIaHzOHM//bHmf+Zyj2c+Rs/y6y/ZfRvURRF sUrpRGqxv0VRFMVqoOsDR0h/mT41NrYPffCMf1lf+qDtgw8ZNMB88flnoliriICdM3NaOc0JEa+d O3e2/x88cCDnzyFP/MbVLTvzuufrrwvOvO7fv88c/PEHc+jAj/akYcuMAj7w/ff29CfU8I+Zv3/8 br8lfowY8b8oiqJYfXQitdjfoiiKYjXR7w9n//4R8vd3Zf65fjR960wfmz43fW9mXnft3CGKtYqf bd9mFi2YXU5zwsIzrz+YBXNn5YtXiID1DeHE8WPN6pUrrFilsn2/f7/5bt8+s3/fXvPd3r1m/95v Myz7f9+335i9GfL/vozb/m39RVEURVEURbFucL/7m35wlNn+se07Z0lfmv719xkiYlevWmmmfjjR 7P7ic1GsVfxkw1qzKcOo5oSF9rwyY7tmxdLy4jWO2zZvMiOGDjY/fI9o3Wsr2N5v9phv4Z6vM/zK fPv1Vxnh+5X55usvM/+X8ZuvssQ/8/8eURRFURRFUawDdP3gPH/6x5l+M/1l/i/rO2eY6U/vzRJh y+pFvvTx8fq15stdO0Wx1nD3FzvM8sUL7GBNnO6MI1tXV2R+g/ANEq9w2uRJ5v1xY21l2r/3GytW bYVEqH652/LrL3dlyP8Z7t5lvsqQv/dk/GHZdVEURVEURVGs3cz1f7P94Tzm+sll15zY3fvtHjv7 Oun98eajGVMzNl+IYq3h7i92mnWrVtjvvcbpzThyLtPH69bYmdq877zaI7pjfuDID6dO+cCMGDbE rFy+1I4SHcz80G0qLwvI/z/KshuJoiiKoiiKYt1ifr+4XN/5wAE7IbQi08ceOXxIRrhOM1/u+iJf 8IriOUgGaXbt/Nxs3bzJrFq+xHy6bUvZp6Fi9KYj1w/++KPZvWunWZ35zeaNG+xecL9OnUdgK5ct Lsl5s2ea8WNHm+FDB9lTiEVRFEVRFEVRrBzfzvStJ2T62PNmz4rtg4tiXeLq5UvNxo/Xma+/2p03 45oTr1EPURRFURRFURRFUaxplHgVRVEUxZS5fs1Kc/r06aJ/i6IoiqKYjBKvoiiKopgyJV5FURRF MX1KvIqiKIpiypR4FUVRFMX0KfEqiqIoiilT4lUURVEU06fEqyiKoiiKoiiKoljjed7iBXOMKIqi KIqiKIqiKNZkntMzr4IgCIIgCIIgCELdwHkHXm9hDvQ7N3n4jZaiKNYi7n/1YfNJm5vNmieuNase v8b+f/D1x2Jt47i9/a1mS9uGsdeKcWu7WyzjromiWHNJGxHnL4qiKNZOnndw+3pz8NMNefx82Ryz 4sOxZtGEkfZ/3GfTphB/2rMjiPPfe9t0bnG/eeKOm80Lze8z88YOj7U7vmur6fLYA6Z/x2dir4cw 5F6h8SnGj94ZbJo1vK4cp7/9Zqx9ZVnT0hA/rj1++03m+YfuNB+89Zo59dWn5exKMa1wQlhdZcMx jbxIm8e+2GLaP3yXafdg09jrxPeVZx83u1YtND9sXWf2bVplTn/9WaxtHIf3eMG80enZ2GvF+FbX 5y3jrqXFUs9ejKQBdbvDI3ebx26rZ56993Yz/o1XbB47G8ot5Zd7tGxc39riPvnl9rywQliqHFbn vUJtkrBQXqTZrp6N56oJ/HLNYvPh4H5m9+pFsdfTIPVh1qi3zHeb19h2m7Zi9ughidqKtDl3zLBc /aRsUZbi7CrLNOteKb785COx9aFV04ax9qIoitXB86KCcPeqBWbR+JFm18oFmRfD6pyb/8+GTTHG PVCUq6dNsMJk1dTx9kWHmwaf/53N0Z2bzYaPPjQvPv6geequRhXu7IfcK8QmhLysurd+1MbdZ1W8 wELiXJ1puGTiaNtBWDH5PWuzbuYk82STBmba8AF5YZViWuGEMOS5QmxCmFZeVAXHvNbdtL7zllgB d2L3NtsxSvq8PmuyeC327KVImXzmntvMx7Mn27Kxcc4U8/Tdt1oB62wQDG0faGJFA534LzLtapv7 GpvJQ17PC6sUQ8phdd4rxCYpC+VFWu1qSJxDbM5FDnqxnen5dAszsEvb2OtpkDyZNKivzSvacP6f OLCP9Y+zr2ouGDfCPHrL9XaQg4E3hDVuBHWcfWWYVt0LIeJ1yMsd7CCiz/2frI61F0VRrA6WE6+r p403n8yblueHmxfq2bApxrgHipKXKB0V3w93r2cey7lp+JnxWTRhlO38VrSzH3KvEJsQju7zclAn ndFfRvTpJPHC46WadHS6pqUhnRY6mb4N9+z93BN5fqUYEg6C6t2+3cxz999h05C0pLPp/yaE1Vk2 QvMijbKRhNsXf2RnSaYOe6OcaKADGh3dh8wq+HalyPMOeKGN7cgh9hDvI3p1yZuhRIhQf9z1sf16 2A53UvGapGwUe/YQMiPH4IrvN7RbR9O3Xauc+7XnW9tn9W2Gde9k+rV/Ks+vFEPKYXXeK6164Vgs L0Lb1VI8G89VE4gIp14d2L7B1q2qFjmjXu1q22v+j7teXaQcDX6pfZ4f9YG2OO02Na26F0LE69lO W1EUxSjLideymdD5eX648XdLjKvTphjjHsgnLw06lSunjMvzx01n2S0P9UfVKyq8Qu4VGp8Q8qKk 80NHC+HR6dF7zZx3h+a9KOnw0oHYtmiW9f98+Tz7Mk2ynKmmpaHv75OlpowQx11Lwmg4jHKzRHPP +mVWrLDMj7gk6ZSFPFdlnj3KkLxIo2wkIeKRMsrgFPeIigbS9uCnH1vByuwi9jDpjBfPy3MxMHF4 xyb7XHSm/RlKZkfwY+aC+7Lcj7RPKl5Dy0apZ09KygJpxHOyesD5M1hBfHhmbHg+8nTx++/k/b4Y Q8thdd0rzXoBS+VFSLtaimfjuWoKqXfj+veyfyPE33+zdzmbtLh98UemW6tmNq0QWZ8umR1rV9VE sNNuLftgTJ4/eYn/tx+vyPOvLNOoe6GUeBVFsSYyT7z+uHWtWZDpgH21ZrEVkfy9M9NA4ubvH7as qVYbP25xjHsgn0c+/8S+POiosDSUv+ns4ebvQ59tLPebigqvkHtVJD6FyJKsjs3usbPUX61dYsUI nSF/ySszQdGZxZkjB9nf+X7FWNPSMO53PDN7xr7ZsDz2eijjwmFvHLMIzo2YIi5rZ0zM+ZVidZcN n4XyIo2ykYQTBrxqRr7yov27kIBjyZ9Lg+i1UPK8iA5fbCBc/Rncri0fynWwHUmPpOI1tGyEPHso 33u9p12OyPJ2OrHR69yLOGDD/0nFQ5JyWB33SrtelMqLkHa1FM9mfT+bZACHQSHXfjKow9J2Bgyi tmmROsj/Z2u5MEREurz0/bcunGn9GSD0/dNgZeteKBGvzRvdYAdUfLJqIc5eFEWxOlhQvMJVU8aZ L1cvKig6q9rGj1sc4x7Ip98Z3jR3qm2I2QtYrINQUeEVcq+KxCcJESN0Hpy7xa032nCj5OUTOpNQ 09LQt+cZeGnTkd88f3retSQsFs6P29bb56GTS9pC4kKH07crxrNZNgrlRRplI5R07limSYcdd1WL V5bV+X7sR+O5nJsONaLEt0G0JBWvIWUj9NlDyT13rphvl3hTXnk2d40ZZcL+bOkcKyS4tzvMxQ+j GEPLYXXdK816UdG8iLarpVjdz1VTiPj2l7FD3HGDLLWJzHySZ+xD9/2deGWG2PevLNOoe6GkXNIu fr1uaR5ZJRNnL4qiWB2MXTb8xYp5eX647VLes2BTjHEP5JNOOKPmyz8cm+ePG/+4TnpFhVfIvSoS nyRkmRIjsW6pJR12lrxF7ZKwInGuyjR0fry02afIS5vTLX37JCwVDgeB8ALfu3GldbNMiw5JEvEa 8lxJnj0JC+VFGmUjhJRFDo6ig+78qlq8Rp8XgYfQc26W27JU2LdhmWhS8VqqbCR59hBGywACnOdy /jxX9IAYZ+P7FWNoOayue4XGpxQrkxfRdrUUq/O5ahJfeuLhcqsO2KdNuvt+tY1uu0N02a6bUeeA I9+/skyj7oWS9k3LhkVRrGksJ17XTJtgPpk7Jc9v05wp1v9s2BRj3ANFyR7GaOPLsrFCh/tUVHjB kHsljU8h8pv1sz7I82P20O+MsTySgxx8G2ZuEAm+XynWtDSkE0n47HeqzAhwqXCcGPFntxjl9gVK KKuzbPgslBdplY1SZNaBjj8dLkeWZjs/rjvbtMRrdOkzy4Y5wMq56Uz7y4YRCtSbJOI1pGzwbKHP XozEj0OhmHHx/ZnR4nRaJ3Q4PZcZWd+GTm7Sz1qElMPqvFca9YK0DskLwi3VrobwbNX3ypA94gzg 8X/cdRhiE8Ladi8+WxM9XZn2Na7cVDY+SepeZe+VRLyG3EsURTENlhOvX65emJ0RnW+++2SVnQld mOmgsaT3bNgUY9wDRUlHhFkmRrQ5WIFDFXCzRMvZsCeHjjPkBE9O7XNuOql+eMUYcq8QmxDSyaFD S0ffhUNH1l8OSeeWsDkBFaHGHi467tETLkuxpqUhJ8my9JODMHhR+vTDKsWQcEhjTpTlbw7iYZaW Ee7ozF0pVmfZCMmLtMpGKRI2z+KTdGdfKn8z8+1siV9lxSsdRuoBs8o8K50plnz6exbdScSITfJ6 ytD+VsAknXktVTaSPHspIsCJI3sx+S1pRMeY/HU2nJSLH8uK3bMj5N/p/VJeWKUYUg6r815p1IvQ vAhpV0NYnfU9LbqZQpb/xl2HITYhrG33oj3l9+wF9T+VE7dkurLxSVL3KnsvxGvcp3JgtP2qbBqK oiiGspx4hRyctDzzIkVILv9wjHWfTZtCjHugONKYsiyUjgGN/NJJ7+Zd5yPxNLpxTNqRKHWvUJtS RKDQoeUlRjiEt3D8yHJ2dOLdvbBlFoGOXNSuFGtSGrq9hVEyk+LblWJIOJzqSlw43ZGZEkQeh+Zg k1TAVlfZCM2LtMpGUlblsmEEJIKOukH+Ivjo7PnPRd3hUxNcg5yQimjht35YpViRslHRZcPEHwHu 6jv/M9Dg9m9CnotvXRInlp4SL2zcoTZJWKocVue9Qm2SMi4vQtvVEJ6t56ooKyt0krA23osBDpeX /F9owKOy8UlS9yp7L8Qr1+K4PbJyJI00FEVRDGGseD1XGPdAoiiKoiiKoiiKYu2jxKsoiqIoiqIo iqJY4ynxKoqiKIqiKIqiKNZ4SryKoiiKoiiKoiiKNZ4Sr6IoiqIoiqIoimKNp8SrKIqiKIqiKIqi WOMp8VqLObzHC+aNTs/GXhPF6ibfP3y1TUv7MX2+gchnavg8TpxtmuT7rUm/4VpbWJefXUyf1VWH +fb2m52fs58P4pMwo17tWqH7pBVObSffpz799Wex10RRFGsaY8Xr58vmmBUfjjWLJoy0/+OuiA08 sG2dvb5uxsTY66HhxDHugeI4/7237bcv+f7iC83vi/3+WohNCPesX2b6tmtlv7/GdyZ5WfJdtqQ2 Scj33do/fFe5bxamJV55qU1/+83cN+z4rhzfQqxMnENY6LlgWvlVnWXDsTqeC5I/XR57wPTv+Ezs dRhikxa5D99DpQP8w9Z19kP31dFhigo40jf6zUJIB9f/XU1k0vyqiHjl+6dx6UMbEGdfWVLGKeu0 h88/dKf54K3XzKmvPo21rWpyX+5P/WzZuL5t83BX5PvHoXW5OutgZVmsDvNNUN5lvj3voOfuv8N8 t3lNnn8xEibp7r5JTZ5MHvK66df+qXK2xZhWOOciGVSIq8OQdMGGfJs16i2bN9Q78nP26CESsaIo 1niWE6+7Vy0wi8aPNLtWLsg0aqtzbv5PYvPj1rXmyzWLzMrJ75nFE0bFiteQcIox7oGiXD1tgu0U rZo63jbSuOmU8H8SmxAe3rHJtLmvsf1gOCO+fMSbDjGdnyQ2SUlYre+8pcrE67ThA6zI/nj2ZJs+ G+dMMU/ffasVsHH2abHQc6WVXyHhhNgkZVU/FzMLdNhefPxB24mJ6xSH2KTJE7u32Y5TZdKtoowK OMQCz++z93NPmPff7J33u5rEiuZXRcQrbVH31o+WS6OKCLhSXDJxtB0QW5F5T1Dm182cZGeBaHPi 7KuaHw7uZ9o+0MTsXr3IduK/yLybaK8RPXH2hRhSlyuap2eLpepwVLwy2EFeInR9uyipj4syfQTE E27SgXSL2vV4qrnZunBmOf9CTCucc5GUOUSqI32Nl5542PRp+2ROnFL+Jg3qa+s6dZD/Jw7sY/2j 4YmiKNYklhOvq6eNN5/Mm5bnh5sXVhKbpZlOiZ1JXT7XbMyInjjxGhJOMcY9UJQ9n25hxYLvh7vX M48lsgkho5h0RHy/aIcvxCYJEb+Mmk4d9kaseB3wQhvb8UJ80kEa0auL7Sz4dqXIjAGdSt9vaLeO dvbY98OOZ6OTRlzoBFd0BqXYc6WVX9VZNhyr47nobDNDQoeQMhDXKQ6xSYt0jPyRf0dmRXw7Zvzc DBwCgrqSdBaAujS6z8u58j62Xw8z6MV2RQUcAoo8SVov6My/27ebnVkizsQ9rrOcRr0Iya+KPHsc CaPUoFfos5cinefowB3Px2CCc6d1L1iqjL32fGvbRvq/Gda9U+LZupC6XJ11sLIMqcO+eF0z/X37 GwY63fUoEVTj+veyZZV3ycFPPzb7P1ltB3PJEwYwSEfSn9le3mOhg7xphVNbyPNS3g5sL99vIs+o b9FZc1EUxZrKcuK1bCZ0fp4fbvwPbl8fbJP7P8NC4jUonCKMeyCfvLjopKycMi7PHzcvVjqQITa+ fzHSwaGDMmHAq/bFSScp2jkKsQklne1Oj95rBT+dsjjxSseADiIzvp8vn2c7tpWZMSU9mIElXDr9 zp8OGPugELl0Qj5bOse+LCsym1XsudLKr+ouG7A6ngv6gyHFhI77u6o7zogPygSdXcoO6QD9OCDw KFPbFs2yaUFZpfyQTn5YpchsD2WcmTPuO3fMMJuuhQQcswysIig0m1SMzNKxhJ5tANyLZaLkFR1n Z5NWvQjJr6TPXoiDX2pvO/sIWAQeZXbOu0NtvjibkGevKBEYQ17ukHOnda+QMkZ+cS+uUedIS2wW v/9OXljFGFqXq7MOVpake6k67MTrzhXz7VJp0tIPA5I21AUGCagXDEp8vW5p7jq/QdAyI/16h6et PfnD4BKzpQhQP7xCTCuc2kAGECh3lPvote2LPzLdWjWzZZL8+3TJ7HI2oiiKNY154pWlvgsyHYOv 1iy2IpK/d2Ze4rj5+4cta4Js/DBhnHitSDhRxj2QzyOff2JftogFlqXxN4ILN38f+mxjkE1c2HFE iNI5YqSXUWU6xLygpwztn8gmlAjgka+8aP+OiiFIh4jOJy9u54dwjc54hfK913vaQzpYChbtmPBc zPT4frwY18/6IM8vhMWeK638qu6yAavjuaIM6RRXR8cZkeieL+465Sc6GzJz5CA7wOP7lWLXlg/Z TqvvR9iFBBz1jtkvv46Ekr3L/kwGHXmecW2mrXN+adYLx0L5lfTZC3Fgl7Y23Wmbvlq7xIo+xJi/ lDfk2StC7oHw+WbD8pxfWvcKLWPUU8L//7d35u9RHNfef/+5lxtnvYkTJ3YSJ7HjON53m30HI0Ds +76IHbEIEIsQAiSzix2B8R7s+zq5TmKBhkXkeert7xn1qLqnZvr0dGkYie8Pn0fq6jO1dK2n6lQV 2jr8TTvRUEldrnXlFSTVYSg/mPDACjn6OEyY2u///fFFafMwGYKJFZd5Ksovyhu+BZRkuEHpx6FL mEjQboPx5c9gB+bDmJw7sG6p8z1A/cJfmgsTQgYLJZVXcDZo7G8FDb2tUGpkbD9BkvKq9SeOK0E2 dmd79cg+6VwxE2sPIjQyLr9doFOOm5dhcIyZ+zQyGrAygFlkDJTwXEp5xQy37XZs2zqZhbXdtGDw gVl1rBRDgYVfcMfAHwO98DkLSenylV/VLhvVSlecwaK8vvrUT+R9HJTVNIolBmoYtNpuUMZcChxW kzBxdGLXpqJ3GlAf8O2Qj1jxBIgzFBa891kvbErlV5q0pwVKH9IXPielPS34VlAS0a50Hd0feecr LE0Zw+o1wsEKOcoH6i0m+9KYmVZSl6tRB7OSVIeRTrxfO2OilEWUPfs99l6+8qsfS1rxXe13IXiH SRP0h+GEBSY0ACZ94ibdpfDlz2AGkzzYxwpFPU0bSgghtU5EeQUw2f3ydFvEDc9iyptCxqac2XAa f+K4EmSDBhsrBqeatkTc8Qx3vNfI2O7lwL6ReKeIvVkYwIamYhqZJNApYQ8dBkahWynlNT4gwkAa A0TbTUP8O2CQDH/sb5h1kK5Jl6/80vjjK6xqpiuOZlCskclK0sAXCgRMU13v0oAVH6zq2G4YvLkU OKzcIdxwQiEtGBhiwP73K2fkGfUXabSVV+RdtZTXNGlPC1at0EahLOM5Ke1pgJKIvblQEm91dhS9 9xWWpozhG+LEVdstbOtst3JUUperUQezolFeMTGL9GG1E+UlPpkCayNY/+A7I1/xTcIyBWDOC7Ni vEd4cMMhQ1D+UY8wcRrKlsOXP4MZbE9CH1PpxCchhNQqRcprZ3OjuXZkb8TtautecU8jY1NKeU3r TxxXguJg/1T8IAKYbtoHgmhkNMCsFqZp9uAkfjCPRiaJmx0tMjBAxxwCU7vQDe8hhwFR3CQOAweY Sdpu5UA8YQYWvyYDZsM4gCZMB5Sz+AElGORgf5rtVg7EW5MuX/lVrbKBeFczXTaDRXmFyWt8HxpW 3MKBpxaUQ9t0FuUTdculwOHQsbgVhJZQgbIVU6wmxZUqH/UiTqn8SpP2cqDMxc2asSoatlHatGuA 4oK0YN8d9lTG3/sMS1PGcAp4XLGBMosVetstibR1uRaUV5j5YvIgbu4bklSHobzaacbJtVDWXacN Y78sTKmR71hJx8o2zFdRfpHXOBEYq9/Xjx2Q/uezk0fkflnbnByUirMvf9Ki8acaMpgQx2RNqRXu tGSNDyGE+KRIeb117njfiuhR8921s7ISejzoBGDSm0YG97vCNBhcbmkKlNcdhefwMCaNP+VwJSgO BmFoxDHDi/0fJ3dvlmfMwKaR0YBZZSh06DjhD2afoZzYip9GJgkM+PBbG5ygiP2t+B8rGZDDQA1h YbUBg0B0LBgowHQq7mc5wplymGHBfwxeMJDF4D+UwYEmWJ3AN8MgBObFiA8Oi7L9Koc2Xb7yq1pl o9rpwsAQA00QKmjhM8qBVsYn8LfcwBeTIUgrBl34Xthr6VL8ksB3RRnHoA2DKJjko+y6FLi05qBx MBjGgTP4H4cHYfUQdcBe/fRRL4Amv9KkvRxQspA25FVYDtGO2KtomrRrQJxhYop2EXG2CWV8haUp YzhpGW0b8ilsMzEBuGH21IhfSWjqcrXrYBKYDEAdhVLpeo94pVFekQYo8fh++K0ta4PyCuUdZQDf CXmAQ5VwMjPyBt8MSm58FReUirMvf9Ki8WegZXCwGeoH9m7b1+WE2HVLi684E0KID4qUV4CDk04F jT8UyVNNm+U5rQyuycHeVRe2cqoJqxSuBLlAY4qBKgYP6Ehde9w0MhpuduRP74M/OLUSimJ8IKKR SYvLbBiDPAyKoHxiUIuBLDp0DNxsuSQgjzjCf8QZfzEYiJtbYoUi/IZjXnxWBs8DkS7gK7+qWTZs BjJdE199XgYRLsLBs0bGJ0kDX4BJljDt+DZY7UtbVqEQwCwfZR1ASYQyhroQl0U49opeWjDxhPii DmOQDmUIlhVYVbcVKx/1QpNfadJeDviDNiOs74j78e3rIzLatCeBdsmVJvgTyvgKCySVMaQdK4aQ waohwkRbFx5qk4akulztOphEkvKRVnkF/7x+XvI4vuJdCihWmNyJr8LDisCVB6Xi7MuftPhS8rLI wHIA7qVIM1Ee4ivOhBDiA6fyOlhwJYgQQgghgxNMMGCSAquEeMZfnBKc1tTelz+EEEJqCyqvhBBC CKkZYPYL6ySsWGOfcOf+HU65JHz5QwghpHag8koIIYQQQgghpOah8koIIYQQQgghpOah8koIIYQQ QgghpOah8koIISlxtUeE+MRV7sjQxVUGhgKutBJCSBaovJJEcAffovEfON8NNXAnZtp7MYmOr84e N7OGv2He/t2T5uVf/kiucyl3/6MvBiJPXe0RIT5xlbtaAHeI4soZ1ztSOa4yMBRwpZUQQrLgVF4/ P9kq97S2N66Xv3iuVAaXtLdvXy93uX58/IDpvnmxSCbJn1K4EuQCR+PjTj3cCzjhleecl5TDDe9w t9/ov/ze7F4+r6I7Sn354wPcJWrf7xaS9p63aiuvSflV6n5EnChpy1WCS9HRlB8NGn98hKXN92qX 1Umv/VmuroAS+68bF+TqCnsQ7Os7x3HlKS7ynzvqbUk77qHE/ZS449OWKUfYBh1qWGbGv/wn88bT /y3l79D6pZE26t83zhfuTH2j7zvjGe62nIaksEK+6zpnJgRySJ/rvQZNWNr4JMGw3DKucveoQD09 1LA8KFudUoZRf3F/8WBXYnE3bdg+YkJt+HNPS1sRXq9TTexyMZRwpZUQQrJQpLz+7ewxUTa/OnNM BkHhM/6mkfniVJu4fXn6qMjcOnc8UFAbzM2OQ6n8KYcrQXHONTfKAPXsvu3S8eIZAwX8DWVwqTYu kscl25C5cHCXzC43r1kc8SsJX/74AspI3Tsvy+qWjX0pv4ZqKq+a/IKSEU8TrkHYsWR2xK9KiCs6 mvho0PijkdGgyfdql9X7f/tYBoil0uIr7S7ieXrns6sySN08r858e/l00Ca1iOKA72b/rhxofzp2 NEicO4J2De3bRzs2iIIK97CNagwU1RHPP1OYuLtxbL8oy42L6wsyGjRh/e/VM+bMni1m0qvPm3d+ /8uKlVdNWBoZDQyrtIyr3D0q0H7sWjZX2hW0G/i7c+kccXfJDxagvK6uGy9tzv9eO2e6ju43U974 i5n8+gtVV8zDcjHUcKWVEEKyUKS8nmvebq61NUfc8IxBZBqZG8cO5AdslsyVw3tMZ0p/yuFKUJwZ 770qg1TbDc8z33+t8IxOOT5whcIGhch2S0LjDwbxm+ZOkwEtBi5YYcKA3f6NFqywhStnI//8W5kZ tzvcjXM+9KJ0Ig2LJww3e1YukIE3zD3XzZxUtFKFlTJ0+lA6sNKEb5F2JU+TX3GgiGE1IM3KGYAy h28UpmnL/Olm2eRREUWnkvi40PjjKyxNvvsq8xow2A1XN2zG/vUPBRlfadfkKeoJymn8d/ZzEmh/ cH/k+vrJkTapIXjGwD58xvdc9eHYiMzyKaPM3JFvRdyS0ISFNGPFtXXjCrMiSG+lyqsmLI2MBoZV WsZV7h41sFBAmcZf1/vBBpTXeFquHtkn7RMmtmz3gcYuB0MJV1oJISQLRcprfiX0aMQNz3APTX41 Mi6glF5uaSo8V+pPiCtBNlDkoNid2bst4o5nDKjLKVYwb1wZDDpd79IQ96dpxXzzwZ9+I2aLUGRh Kom4YNbX/l0SUBQxOP+4/ZCk8/NTbbKaBIU2lFkxdYwoBVBkoNzCPK1106rUM8pQahAWFB6sWiEs DJRh/hjKYFUdexmxgtf9yWXz6YlWiU+a1dBK8gsz/+/94SkpW/F3ScCMFun427l2yYsjm1dL+KGi k6X82Gj88RUWqDTffZX5OPi2KBMYEF4+vEcmGUCoMPpMe1Kegvlj3hXFuHHxLFlxxQRQfOInCbRP iBu2O9htEp7h/v3HF+S5ddNKiU9XW7O43Ww/KPX/SJAf9u/KogzrX9c7C+8qVl41YSnjkwjDKivj KnePkpsdLaJwoz5C6fvko8NOucGES3nFBDqVV3+40koIIVmIKK/Yh3UsUKa+7uwQJRL/w/wXz/gf gyONjO1nCMyFoeD848oZea7UHxtXgmx6Pr8mnRA6I5hH4n+s0oWd0+1Przh/B9NJ7Lv7f5dOOd9r cflz98vr5vub/XHHAB5xOX9gZ8FNAwbc8ZWzg+uXyWA8fF46aaQ8Q7H7+vxHovBiIJ/WNBTKK5Qg e3APxdVeOUN8sMoVPgMMdi4e2h1xK0cl+bV31ULZS5lG8QiBedi2hTMjbkhHqOhUWn7iaPzxFRao JN99lflSYJIhTF/8nc+0J+Vp+IzJGKQZA1R8J0y8oCzZvyvHP66clrjBkqR9+zr5v23zKnnG/99e PlVop6Aoww176vAXz3Y7lkSasEIqVV41YVUSHxcMq7yMq9w9atB/4e9gNxcOiSuv2OsKaw8o6bZc NXCVpaGAK62EEJKFksorOLt3m7l1rj2iUGpkbD8B9nlBcf3mfEfBrRJ/4rgSZGMPmGEKhI7qUktT yUExFCCsFGLvH/a+2O/SUM6ff398UZRBmNViRQYgLhi023JJvPrUT+R3cTBrX06Rg8KLMF3vSoH4 zhv9TsTt2LZ1Ehb+R3gYmMPNlklL2vzCyhqUjhO7NkXctWDFNn4oEBS/UNFJG59SaPzxFVYpSuW7 rzKfhJ2+cu+ypj0pTwFWorH6astAcYWlgO1WDuwvRdygbGD7A8yQceAcFGG4h4oOvjsmfq627jH/ 7OqUNOUPbZpZ1J6VQhuWTaXKqyasSuLjgmGVl3GVO+IXtDXoSzFxhwk+9GlLJo4w/7x+3ik/kLjK 0lDAlVZCCMmC02z4y9NtETc8iylvChkA0ycMQnHS8N8vn468A1p/SuFKkA0G5uiQcOKx7Y5nuNtK HhQh7I3DauKtQIG25dOQ5A/2M6HD/PuVM/IMEywMVtIqr+hkYQrqelcOmGJC0Uyzxw/K68Jx70fc oKhC4cH/4XfOqrymyS+A1Wp8B6zc2e5asPoGs1LbDaa2oaKTNj6l0PjjK6xSuPLdV5nXUE559Zn2 pDwF2LOHPdu2DPad4/toTZRh9om4Hdu6JtIm4RllEu/xjIOTsMJryxxct1Tqju1WFmVYNlnMhhPD qiA+ThhWWRlXuSN+QV+MbRawwMDWAdTLapsLh9jlYCjhSishhGShSHnFTPC1I3sjbldb94p7Ghl0 vhcP7pQV1VKrqCp/yuBKUBzs44vvacEhGfbBNBjQQzmDqRD25tmyaUjyJ1RUbSUP+0crUV5hHolT Em03rOpCSQifkc642S5W2bDqa7slAeXVNkcGMBuGuW74jJWD+IE7UFSwp9d2S0KTXyGrpo0rWkFL A+Jsm5hCScK3sRWdNPEph8YfX2Fp8t1XmddSTnkFvtKuydOtC2aI6bCtFO9bvShVvUD7g33FqIN2 m7S6bpyYHYbPsAzYt2phRAbKbCrlNUATlk2WA5s0YaWNTykYVmkZV7kbSHCeASax8Nf1XovGn1qR gfJqtzsLxr4nbWKayV2bLPGxywEm+7HVyjXpHzJYZOw0EkKID4qUVxzZn18RPWq+u3ZWVkKPB8oW THrTyOBgEhz9D/MoKK8hMBdO4085XAmKg0E8ZrKxioPj8E/u3izPWBEOZXCKLswNMeOKDsXG9isJ jT84ZRinDeN/HNKElS8MZOOrRUnADBvpwIoROlrsbYwrkBj8IzwoDGHacRJw3KwyCQyw8Dus9EIB R8cLE1R7D2VHkNdIB74r9kV9EeQpzCVxyJPtVxKa/ArBimF8328awtOTMYGAPILpKFbubEUnTXzK ofHHV1iafPdV5rUkKa++0q7JU6QZ3wNKLsLCIVKQSXP/MdqfU035OB7btlau9zoafF88w/wzbKPW zpgoSnHX0b4Dm4LB3di/PmvWTp9QkNGgCQvXjaG9BWhX5ox8s/CMsG3/yqEJSyOjgWGVlnGVu4HE 3m/ueq9F40+tyMSVV9xfi3bRPowwDVniE5YLYO+Dtt1tBouMnUZCCPFBkfIKcHASTH2hSKKDxXNa GSiu2LsaJ366oiasUrgS5AKdBBQdDAywghjfI4nBLhrdONgHY8slofEHA2XEBSeOYrUJSidWgiCT VoGFMhmmCwNkrK7ZM8Y40RWdMN5BBrLHt6+P+KEBA2GscsIvpBEDfVxHEp+dxqX1YXzGvPisKA5a M0ybpPwKwfsspsr4PjAfRXoAFG0ofkivLaeNTxIaf3yEpcl3X2VeS5LyCnylXZOnN/tOTkVYqIuY iElTVsM2CAM17GHFvjmUeUwQ2G0UFMqt86eLDMLCd19fP0ncbTkNSWFhL288P0PSKl9JYWllNDAs t4yr3A0kGsVLQ1aFMqQaMnHlFXTu3yFbCK607o24a8gSH7tcDBbF1KaUjJ1GQgjxgVN5HSy4EkQI IQONqz0ixCeuckeGLq4yMBRwpZUQQrJA5ZUQQlLiao8I8Ymr3JGhi6sMDAVcaSWEkCxQeSWEkJS4 2iNCfOIqd2To4ioDQwFXWgkhJAtUXgkhJCWu9ogQn7jKHRm6uMrAUMCVVkIIyQKVV0IISYmrPSLE J65yR4YurjIwFHCllRBCsjCklVfXbwghhJBax9Wn+cYVLiE+cZU7QgjJApVXQshjxYopo838Me86 3xF+n1rB1af5xhUuGVhe+dWP5UqZkH92dTrlhgquckcIIVlwKq+fn2yVewFxJyv+4rkSGdylGN7h emLnBnO976J+W0bjTylcCbIJ5Q41LJM7EN94+r/l/shD65dG/NHKaHicwwK4v3JCIDd31NvO90kg DLtjD8H9n6HMvtULnTK7l8+L+KUhMV03L4q/uIsxvKdz05wPB3zAge+Ie1pH/vm3zvcasuZFNfGV pxp/BkI585FfZVGUw3/fOF+43/eN3/xMZPEM94hfCWi/D+oK6szrQVgIc/vCmUXteyLK+uUlrIBE fzzW989OHDazhr8uYb33h6fMmunjnff7lqqnrj7NN3Z4pDpAeT22ba3Uy1J1s3nNokj7dalld+Gd r3oOtPWq/oPXzLeXTsr/55q3m83z6opkSuEqd4QQkoUi5fVvZ4+Z9u3rzVdnjkmnGj7jbxqZmx2H zEc7Nphbne0i83VnhzxfP7o/lT/lcCXIBjIdOxqkYe5obDC3zh2XOKDBh3voj0ZGw+Mc1v9ePWPO 7NliJr36vHnn97+sWGFCOYBfNjPffy3SWaKD/fCtF4vk0nbemnTtWjpHBp5n9m4VmXP7tpl3n/1V EJ9pEb9801A/2bz9uycrUobwLXzkRTXxlacafwZCec2SXxo05bAxGMCOeP4Z8/HxA6KE3Ti2X5Sv xsX1Eb+S0Hyfti2rRbnDxCTic6pps3nzmZ8Hit9cp3wpNOnyFZbGH1/1/e+XT8u3R7n4/NQRc7ml SSbgti+aWZBBuSxXT119mm/s8Eh1gPLavn2d813IP66cNl+ebjOd+xuLlFdf9Vxdr4IwJr/+QuEZ dQSLERGZMrjKHSGEZKFIecWs2rW25ogbns81N6aS+exEqzSItgw68PP7dxSeNf6Uw5UgG8hMe/sl sz4YQNi/w4Ci7p2XC88aGQ2Pc1joPLF60LpxhQx+fSlMbZtXyYwwlNrQbd3MiWb+6HcicpWgSdeB dUvMqd2bIjLLJo+SFRXbTQNm08NZ7uHPPW32rJwvA4O4HOoJ0rxz6eyKlCFtXmjjkxWsWq2fOckM /9NvZLCEMNsboxMovvJU4w++yYKx78pgD4oKFIdV08ZFylgayuWXJu0aNOVw9og3zaoPx0Zklk8Z ZeaOfCviloTm+2xdMD2iiMnvpo6RiSbbLQlNunyFpfHHV31HXYJSarvFJ2KS6qmrT/ONHV6tgG8R nzwp144NNjTKa8inH7UUKa++6rm2XiEOSyaOKDwjb+yxXVIb5yp3hBCShSLlNb8SejTihme4hwNb jUyEwO1WZ4escH1xqq3gntqfGK4E2cAPNKYwSbZ/h2e4i3mMRsZyL8njHFbw/K/r/WZ1vgYaWJnA qkd8pRgdKRTPeYGSAqULneX+NYslrrZcWSr4Phh8nt27TQbzmLWOvy8HzLPwOxmEBGF3tTXL4BVm rrYcBgJIDyZwoFxWorxq8kIbHx9gpQB+Y0IL6YOp9qtP/cR8ZVlYeMnTAI0/+CZI+7aFM2SFDBNm UNI2z02/mp6UX5q0p6VUOWzdtFLCQl6i/N5sP2g+CAaURzativw+iUq/z/R3XzHLJo10vtOQpn5l DSuknD9Z6vuckW/KRBgsRsa8+KyUkfjkUFI9dfVpvrHDqxXwLai85nEpr77quQu7PsB6DlYsMEse +fwz8j/AFhv8Pbguv8UmqY1zlTtCCMlCRHlFZ31s61ox8YUSif+hbOIZ/6Oz1cjYfqKBhTtm4mA+ lSYs2x8XrgTZwPQGDX9nMLBEZ4H/sZKHZ/z/7eVTKhlX2HEe57Div/E10Ni5ZLasTMQVmEXj3zdj //qsmC590tEiihhWD3cv05sRpk3XhllTzMu//JGYVWGlxH6nAYPX+Cz3nhXzJR22Gwa7q+vGy/+V Kq82pfJCGx8fYMXufy58VHhG3cY3Prmrf4XLR54CjT/4JlBs7XIFxQyDtPBZS1J+adKehqRyiPjA f8jgr21ur6WS7wNTQ8QpzZkFNmnqV9awQsr546O+Q+lFGOj3MAH31m9/IW2aS95VT119mm/s8GoF fAsqr3lcyivwUc/jlKoPa2dMLIQPhTRu2ZLUxrnKHSGEZKGk8gow63zrXHtEodTI2H5iJu7bS6ek ERYF9mRegU3rjwtXgmywcodGFAoJTJSxbwOHQmGVBO5QUDQyrrDjPM5hxX/jY6CBcoPBXtuWNc73 caCIYfbX9c5F2nR9c77DdB1tNvtWLZQO/lDD8sj7JDATDX/jwD1UErDCBfNTKNZ4HkjlVRMfX+Db IR6YvccKHvIJYSUN4NLmaSni/iAuML2zZZCfWHG33ZLQ5FelaS9FuXKIg4YQ/tXWPVJ/EL/8YS7R SYokUn2foKxsmV8nddXeEpIWVf3yFJbGn6z1HcorVl9ttx2LZ8kKme0W4qqnrj7NN3Z4tQK+BZXX PC7l1Vc9L5BQH7DKinDwP8Zw8QnFpDbOVe4IISQL/8duhABMdnFQgO2GZzHlTSHjAjN69l6ISv0J cSXIBo0yVl2ObY0qQHiWgVjwXiVjuZfkcQ7Lcgc+BhqYtYX/oWKQBMx9MQuNSRHX+yLSpCuWRqzm YUDrSnspoBQ2w3zV8Q4g3hNeeU4U6dBtoJXXcvHxyYdv/VUmB8K6DlM3jQKXOk9LEPfH9U2gnGDw ZruVQ5tflabdSUI5xEpfPE9h2pcmXUD7fTCgXTzhAxk4w8TQfpcKRf3yFZbKH0V8ksDprNgnbLth 2wzKoWtLguubu/o039jh1Qr4FnHldfnkUZn7lFqhEuUV++pDN1/1HJSrD00r5pkpb7wg/oYmw1BM MTGD/+XAqEAuqY1zlTtCCMlCkfKKlahrR/ZG3K627hX3NDIndm4MGsOWiAzMp2zFVONPOVwJsoHM jPdeLZj1hayuGxc5lEAjo+FxDsumlMKUBhySUuoACoSNkxFtN5hNYRXMdksiMV3BYBWHUGCm25Y5 vGGFnEqcZjA76bU/ywDMdsOM9XfXzsr/GJxgYIuBSQj2FoVu9uAlDaXyIik+voCSh4GMvXKFrQRx Bc5Xnmr8wTfBPsSozLS8ibrlVg5NfmnTnoiyHOK0Y6wU2jIY5FaivCZ9H6QN5WrqG38pXKGRGmW6 vIQVkOiPMj4aNs6eKoN8+zflDmBz1VNXn+YbOzzsb4YCg7+2u001ZNZOn1C08o+22tWOZQ0rRCOj QeNPOeUV9ddO56VDu6S9sCf509TzcvHR1Cus+GLvdviM8wRgtRQ+a9o4V7kjhJAsFCmvOEUuvyJ6 VAayaDTzR6m3p5LBna6Yaca1N5CBOTBW0+xBuMafcrgSZAMZDGSxkoZ71RCXo1vyK2swEQ390cho eJzDwr4XdGoAiidM5sJn10pDEnkzKPfR/1BQMMiEiS+uYoJpMQaXOCnUJV8KTbpwxyOUEeyhhAyu LoAihDTafiWBfXPwG5YH6PCxH3Piq8+b9fWT5D3M5FEfbHDaK/Ye4v/QbEuDJi+S4uMT5BVOo8T/ 2DO1aPwHMtA6sLY/v3zlqcYfnMwJNwz4kHYM7rCigD1ftl/l0OaXJu0aNOUQe9PgBnNX5DPShf2/ UAZsv5LQfB+kFYepYUISA2Mb268kNOnyFZbGH1/1HWHgG26cM1X8CQ9+arIU46R66urTfGPHGcoG lA7s/bfdbaohg3KHfAoVKlwnhJVvl/JazThr0PhTTnkNt63gG+AgptnD3xALD3sSJE09LxcfTX1A PMLDytAWYIU1fBeS1Ma5yh0hhGShSHkFODjp1O7NokhigG+fEKyWCRpbNKpQWCGDv9ibgQbQltOE VQpXgmxCOTTcUIZgKokVBdc+So2Mhsc1rPEv/0k6SRdplWUAxcqezbXBoA8rQejAIYd4tWxItyct JCldKK/Y44P9PAgLKyeYidaaM9vg1FuEFfqDFcFye7srNRvW5kXa+FQK7sxEOFCApr/zsijKWJnC SmU4wPGVpxp/YCYHZQGKCvZoQanAgDBr2l35pUm7Bk05RNq3zp9eyFOEickIuNt+JaH5PnB3lS+k y/YrCU26fIWl8cdnfcdE7dQ3XyzkBfy1J/KS6qmrT/ONHV9fSl5WGSjvC8e+J98Mq/0oww2zJjst caoZZw0af5LMhtEuoNxBYZ/53qtiOmy/T1PPy8VHUx9gnQMlGv/DTDhurQOS2jhXuSOEkCw4ldfB gitBNq7fEEIIIbWOq0/zjStcMrCk2fM6FHCVO0IIyQKVV0IIIaTGcPVpvnGFSwYWKq+EEJINKq+E EEJIjeHq03zjCpcMLFBebTPdNOcZDEZc5Y4QQrJA5ZUQQgipMVx9mm9c4RLiE1e5I4SQLFB5JYQQ QmoMV5/mG1e4hPjEVe4IISQLVF4JIYSQGsPVp/nGFS4hPnGVO0IIyQKVV0IIIaTGcPVpvnGFO9i4 crjJvP6bn5lrbfuc78mjxVXuCCEkC07l9fOTrXLPXHvjevmL50pkQnC3He5yxV2v8Xdp/InjSpBN KHeoYZncqYd7x8a99EdzaP3SiD8huCcN98q5LkPXgDsCty+qlzsmcUE97j7DM9xtOW18kkj05+ZF s3v5vMh9cLi7sZIDIjRxrlq6lDIa8Dv8HoMf5Nv2hTMjdzFq81RDUpz3rV4YOcgjBHloy2lI831Q 7pG++B2lPqlqnj6mYVW7/AzFb6iV0aAKK3DDO1f74+rTfBOPz2Dju2tn5bvtWjrH+Z48elzljhBC slCkvP7t7DHTvn29+erMMRnUhs/4m0bG5lpbs+lobChSXtP6E8eVIBvIdOxokIEBwr917rj5aMcG UULgHvqDS9HP7NliJr36vFzIX6ny2hgoNSOef0Yu84bieOPYflEYGxfXF2Q08dGg8QcdOi4ixyXi kDm3b5t599lfmc3zpkX8SkITlkZGQzXDatuyWpT649vWiT+nmjbLxfC7l88tyGjyVIMmzhi4fvjW i1IebdIqymm/T0P9ZPP2754cMOVVE5+0cS7F4xxWNcuPRkbD4xxWUvvj6tN8E8ZlsNK0Yp754E+/ GfIn9g5mXOWOEEKyUKS8nmveLsqm7Ybnc82NqWRC/t/FE7LqerP9UJHymsYfF64E2UBm2tsvmfXB 4Nz+HQbrde+8XHiGMoIV19aNK8yKKaMrVl5nj3jTrPpwbMRt+ZRRZu7ItwrPmvho0PhzYN2S4NtH v/myyaPMrOGvR9yS0IRVzXT5Cmvrgulm+6KZEbcVU8eYme+/VnjW5KkGTZzXzZxo5o9+JyJTCWm+ z+WWJlm52Ll09oApr9XM08c5rGqWn6H6DasZVlL74+rTfGOHPei4eVEUV3uykdQernJHCCFZKFJe 8yuhRyNueIY7OgutDBBz4aYt5uvODvPpR4eLlFetP6VwJcgGfmBmGybJ9u/wDPfQPOtf1/tnbbMo r62bVooi3BUo4PD7ZvtB6VyPbFqVl1HGJ5EK/MHqy9m922RlGTP+8fcl0YRVzXT5CqsE0999xSyb NLLwnJinGpRxXjJxhAx65wUKyPDnnhZzwv1rFsvv7d+VJcX3wWoFwsBkUfOaRQOjvFYzTx/nsILn qpWfaqZrqIZludvY7Y+rT/NNPPzBBKxgYBaPv673pDZwlTtCCMlCRHmFgnNs61pRNqFE4v8vTrXJ M/6HkqeRCf27fnS/udq6V/6PK69p/CmFK0E2/7hyWjq3zmBw3r59nfzftnmVPOP/by+fKvIzi/IK Ns+rE79f/uWP5C+ew3eVxMdFWn82zJoi8YFJGlaX7XdJaMKqZrp8heUCM/j4RvF91+XyVIM2zovG v2/G/vVZc2LnBvNJR4vsh4Pp4e5l+pWFNN8H6VhdN17+HyjltZp5+jiHBblqlZ+h+g2rGZbrd/H2 x9Wn+SYeh8FE25Y10iZjssD1ntQGrnJHCCFZKKm8AqzU3TrXHlEoNTLw69tLJ8VcGPJ4Lqe8lvOn HK4E2WC/VziIgIny5NdfkEOhsNJUahCRRXnFwShQAK627pFVLZhA5w/4yZuGVRIfF2n9+eZ8h+k6 2mz2rVoog6NDDcsj78uhCaua6fIVVoRg8LNlfp1567e/MOf374i8S8pTDVnijHCw8ut650IbFtIB c2EMtPE8UMprNfP0cQ7L9TswEOVnqH7DaoYV+U2J9sfVp/kmEo9BBvozWBK53pHawVXuCCEkC06z 4S9Pt0Xc8CymvFqZoDNGZw1FNHxfymw4KaxyuBJkg3hg5eHY1jWR3+EZ5luuGdssyis60maY6Vlu B9ctlUGJPFcQHydp/In5idUYKLBew9LIWO4lqWZYfUAhXTzhA1FIb3YcKnqfmKcaMsQZpoZYXQgn gRJRhAW/JrzynAysw/cDaTZctTx9nMOy3G0GovxkiU+ExzmsPrdy7Y+rT/ONHd5gg8rr4MBV7ggh JAtFyitmi68dyZv6hsD0F+5amf+5cCLoqNfKSYshGESFbniv8ScJV4JsIDPjvVcLppEhq+vGRQ7l scmivOLEVnSothsUH1vRSRufUiT6EwyQhsthFtFrMg5vWCGnXqoHYgGaOFctXUoZDRjQI6+nvvEX sRRwyWjyVIMmznjGiaO2DEx7sUJquyWRFBYOaYJCg4FfCK7zCN3w3v5tVqqZp49zWHiuRvnRymh4 nMNKan9cfZpv7PD+fvm0KND4a7vb1JKM1mzYR1hafIU1lGRc5Y4QQrJQpLziyP78iuhRuUMNK6H5 o/zb9TJBZ4Krb2xw0M2JnRvl//DACk1Y5XAlyAYyGMxhtvvYtrVyBc/RoMPDM1aGQ38QJ5h6AZzG O2fkm4Vn9SEdAWtnTJSBIkx08Ts05NiDtnb6hIKMJj4aNP7gTlcoI9gDB5nO/Y0SP6TR9isJTVjV TJevsHDdDa4O+vzUEelwbUIZTZ5q0MQZg1tMOMC88FZnuwzOMNGAU6Ntv5JICgsm+ah7NvgWOOQH /2M1KO5nFqqZp49zWNUqP1oZDY9zWEntj6tP800YF2Dvz7XdbWpJBteX4f2NhAObfMVHQ7XSDgaL jKvcEUJIFoqUV4CDk7BfFYokOmE8VyJj4zIbBmn9sXElyCaUQ2MKs6xXn/qJGfPiszKos/3BRfJo dF2kGbRACd46f7qEhYEK9pqtr58k7rZcUny0JPmDmX0c1jLy+WckPjALxXUN4T7HNGjiXK10aWWS wB24rjzHKmQoo81TDUlxhp+4gxfKMsKCbMsG/f5km7TfZ8DMhvuoVp6CxzWsapefofgNtTIakvxJ an9cfZpv7PgMFmXIJm9dVP5AMl9haahm2geLjKvcEUJIFpzK62DBlSAb128IIYSQWsfVp/nGFe5g omnFPFFgfVuLEH+4yh0hhGSByishhBBSY7j6NN+4wh1MYGsPLEaSVl/Jo8NV7gghJAtUXgkhhJAa w9Wn+cYV7mADB8zhdGdc/+V6Tx4trnJHCCFZoPJKCCGE1BiuPs03rnAJ8Ymr3BFCSBaovBJCCCE1 hqtP840rXEJ84ip3hBCShSGtvH7/wf8lhBBCBh2uPs03rnAJ8Ymr3BFCSBaovBI1t2f8yTw4s988 /OKq+c83n5qHn1823aN/4pQlfrh/dIvgepeFe4cbzP2OHc535PFmqJaNStNVSR30EZarT/NNPPzB CNKR21bvfJeG3NaZ0qfBv97zh50yGno/6TTdo9gvhtjljRBCfOBUXjubG82mudPMiqlj5C8uvU8r c2bPVrNk4ogicKerLacJqxSuBNnEG9HuUT8yvddPm94bZ4veFd5faTcPPtrtfJ/I8B9IJ9rbdcL8 59bH8rdn9agiuVzDZNN7tcM8/Nt1ic/dXfOD3/5XkVxZNGEFMnd3zpMwJKyuU/L8/YgnonJK5NsE yiuU2O4JT5ruyb8O3IcVySV9Zw1l88Jjurqn/c48OLVX/Hn42SVz7+AaCbsgo8zTRCr0p5KBc++V Dmd96L12oiBTbQUlTZnPUn5ym+ucafcxuC1mWF+enjL/+fqmefjJBXN371Lz/cgf9st4roNl8RSW qmz4qhcBuYZJUmYfftUlZQRlxSWXFSqvxdhh5zZPE7e7TYsi7rVObt2EoE/6o/Odlu6pv5UJ2TuL 3szXl5T9cfeUp8399kbpQ/ANH35xxTw4sVv8jcvervuDubtjnrk93RHnarYXVcIub4QQ4oMi5fVq 616zfMro4O8e8+2lk+bakfB5byqZ9sYGs33hTLl/zeb7jy+k8qccrgTZxBvRe83LpVOJD4qxenhn 0dum9/IxmXmtVHlFh4Tf31n8tume9JTJrZ8og9o7818ryOTWjJXBXs/KUSLTs/Rd8/DLLpPbnm5w rQkLMr03z/V17MPM7ZnPBQPs8ya3Y25BRs3IJ+Sb9ix/3/3eotR31qDJC1/p6h77M/kd4ts99Rlz e85fRcGTwUKfjOY7a6jUn0oGzlD+MPNv8+B0czAoXVyQqabymrbMZyk/UIqxahJP/0AM/nKNs8zD Ty8G5fUtSRcGvhi83t3T/5291sEEfIWlKRu+6kXP8g9kkN6zfHi+bBSeP3DKZ4HKazF22Ghzeztb pAyh/Njvhjp3lrwdlN9PnO809J5vNffbtpjucT/Pr7xOfMrcP7ZVJmXi31LcOw+Z+8cbI+6gmu1F tXCVO0IIyUKR8rp9Ub1p27w64ta2ZbVpDNzTyLRuWmn2rFwQkYmj8accrgTZ2A2oKCbXTwcDztlF g2J0Dljly60bL4OOSpXX3q6T0vnYbvePbJQZ2fD57u4FEeUISJiBcmG7JaEJ68HJJnOvZX1E5l7r BvPgRFPELQkoHq7v29t1uki23HfWoMkLX+nKbZkuA7aIe0zJ0XxnDSp/grDvHVgtChAUg7uBEoeB TtqBc5zcmnGSJ/aKsgyug7AxKArDu9eyLiLjizRlPmv5ubd/lUppwCpTYSX4ZqeUhbQD9tyGKaKI 2273j2ySlfzw2VdZBbJ6ffl4Ps43zuS/6fAfFN77CktTNrzVi2AQf695RcQNkxcPzh2MuPnIL1WZ 91QHfYTlanN9E8YF1jRYeeyue1a+8Z0Fr/fHswaBUmenI6tlRc+y96Sfc71LZpgovrJqGzyHZsNQ YDFh2D3mpwVZuGHCq3v8LyTP89ZL/X75bC9qBTufCCHEB0XK67LJo8yVw00RNzzDvftm0OgqZfav WSzK6Z6V8826mZPMxjkfmrP7thXeA40/5XAlyKbQgI78oem99pG5s/D1/CAoPii2FBYZVFeqvAYD Suybsd3u7loggy3bLc6DswfM/bbNznel0ISVWzs+UAYvmNv1fxYzKJgpoWPNrR0X+V0iI5+QGWV8 U6wyiVkkiCl6id9ZgyIvfKVLBgrBgBEDDAzGxWQxNiiuNE/jqPILe66CgY2YkwXfPLdxigwksyiv WMnG4Di+koVvKwPmIA5Ygb5d/4LI3d2zJCI3UDjLvIfyg9UPrB7d79gp3xb+5TZODd715ymUQKT9 zryXxB3lSFY3NtcVZFITKJGy8hr4i5Xm0N1XWYVpJPaaQ1nuHvff5vbsF8UfezXdV1iasuGnXgSD /ls3TM+KERF3PIsi0We66Su/NOnyVQd9hBXvzwaCMC539y2XLSH4//6xbaIwhe9qk6A+9/VDMFl/ tMprUB8uHBEFs3vir6TOibWHQ04m8rC1IPgfkzZ2/QXe+uwawlXuCCEkCxHl9buuc7Iv9Wb7QXM5 UCLx/8WDu+QZ/3937axKBn7tW73IbJg91Vw7ss/c6myXvawwCT65a5M6LDtuLlwJsgkbT3QQ9w6t lf+TBsWlFCYN9/avlEEd9lHi+Xb987KKhAFaXDYkt71e9np1f5j/jRZtWEi7fI9vPpW/8c5SCzpj /L7cjHya76yhXF74SJes5EDZCPIAe5PEZPGLKybXOKcgU0meutD403uprTCwKbgFccyivCItWMm2 lTeAb5tXNPrdMbB2rab7plSZ91F+7h/fLoNZmLdjFUkUn0AhyG2fVZDBN42vBOe2zJDf2W5aMPCX A8xgCr1ufPF7T2UVK3O22525L5meJe9E3HyEpSkbPupF9+ifShzRpvSsHCn/w0oAz/gfSh/kfOWX Jl2+6qCPsCQfBxgJd/gPRInGBAmeUXekfo76cSFetQy2emRVXqEcoi9wvdPQPeUZsSSReheAVfee FcODd1a7O/KJ/KprX7uHuoMJDVHCQ5kAH3W4lrDLGyGE+CCmvHYWFMqPjw6UnUYAAB48SURBVB80 WxdMN9ePNkcUSo2M7acN9sGumT5B/s/iT4grQTZoODHjjUEVBkp4HkjlFWHcP7pVTIgwYMYKEAZd GNQWyw8LOqVFwbtrqfeJAU1YcqBKkFas0qDjlG8RHgBh+aUhSXlN+501lMoLX+nCqhxWX203UfY+ 6V89SpenpdH4g4FM/LAa7IuqWHnFYAnK+JoxRe/k28bT3jApiN/NiJtfSpf5gSg/IfKdP71QeEYe xNsKQdJuDTaVdI9/Moj/84FCVSf5ie8YvvNTVofJQBb7St3v8/iqF5qy4aNewCoA3x1typ2Fb5je i22y9xAr73APlVdf+aVJl6866CMsZ5o9g3Cwmo9Jh4J5a6BMoY72rBldiFctk015HSaTXDDHv9e8 0vE+Hdi3jXy9d2iNtL2ymt1n2o+JGXtLAcCzPeHls8+uFVzljhBCslBkNozV0UstUVNePNumvBoZ FzAJhmIaHtpUqT8hrgTZwAQVnRIGRmFDOpDKa4Eg3HAgIKZ0QRwi74NOCQM/zMLfrsPBDNa7tJQJ S1YVN03rlw3IbZgsAxPbTUNZ5bWC76yhVF74ShdmyrEPzXbDwTFQFEKTxQJJeaolKb82TumXDcD+ zUqVVzGFCwbLoUJo4/q2GFxXUjZUlCvzA1R+QsQMFXkahINnfJPcpg+L5CojqjzJSq8ocHl3P2U1 b15rK8UufNWLVGUjU70YJopv/JRiPOdXcPPf0Fd+adLlqw76CCvenw0EEmZ7o9QPmKWHYMLgwal9 kbjVKlmUV1jb4DvkD3nzs98/NBvGflaUXUzIiPvFNmmTbVlMHNjnLviqw7VEvMwRQkhWipTXHUtm mcMbVkTcWhqWm51LZ6eSwXNXW3NE5vi2dWZ9/eTCs8afcrgSZHN7zkv5TjnoEAp81VVww/t4Q1tK YdKAPW95U6HQbZicNgizwoJbMNh70LFL9shgH2m/bDo0Ycmq25bovjB0jHC33TSUU14r+c4aSuWF r3Td3bdMzPTCQTKIHxSkylMFGn8wiImaEQYyQVwqVV7l8KASB33g22Kfr+2GU3LzJsZR2cwklHmf 5edey1qnKS1MXMPn3ktHzf3WjREZrJ6mM5MM8gZ70WKDZtmbGihkYZnyVVahFMYPNkJdtBVaX2Fp yoaveoGVKaxS2W7IQ/swLz/5pUuXrzroI6x4fzYQyFkGmBxYNz5Qtn5TQCYQgvqHA4b64xd89zE/ lcmncFXcRTVlQJLyWt6fYWK+C8uBSk6HBqgLOG04rPP2ntf8ftXirQSlSFOHay0vSsm4yh0hhGSh SHmFwomVz8stTXJ9zaWW3fIMk940MlBC182YKGbA314+JTJYaT3XvD2VP+VwJchGVgUmPRUBpz9i LxL+x2qQNLqj+q8WkQH/yabCc9EKXBkwAMCs9Z15r8g9qBiEYcYUM7AFmb7TJ3E1Cxr5AkHDb/uV hCYsnGSJQTtMGuXwh7o/BAOqE3KXqe2XBnwLfNNSK6+a76xBkxe+0oU8gKKBAWT3pF/LIATKkn0Q jeY7a1CXDRzgUv+ClAeYMCM+lSqvWOUsZW6GA1mQdlnRGv4DGXTAtBb7UV3yWUgs8x7LD74rBoww PcXAG6aPks4N/StcyAsM2EX5QtgVmg2i3CB/ZH8tyk9QN1AuUW5DGV9lVfbkBeVFrqYJ6ojsMQ2+ D1Y7QxlfYWnKhq96gYkGuUZp1Sj5hj2rR0dWq4Cv/FKly1Md9BFWvD8bCHCYGfItvu8ScRaz5tih XPbeZNvdpioyaBPsA5saZxeeQyUyRBfWKJkwc71LQk4O7jMV7p7wy7zyGrQ9ciBXUAawH9b1Oxdp 6nDN5EUfpWTgRgghPilSXgEOTmqYNUUUSRy6dOnQ7tQy/7reaY5tWysrrZCB7Pn9OyIyQBNWKVwJ srEb0BCXOSJWDFy/B/YgSoPs+woGKTB7w3UPGJjY7zFYcYVTSceZFBYGuXd3LxQlBjI4xRADvkrM o8oqrw5c31mDJi98pgurepg1x+AY/sjBPn1KckjSd9aiyS9ck4ABLIBiggOMcH2GLacFSkEpU1OY 8ELJEgUsKJMIDwMnKAcu+SxUUuYrLT9SNrDCFQwAkafYL5Zbnz+IxgaD9nz5+VjCkUNR0qY9kEd5 6f34bD6swB+5M9gy0/ZZVrECg/RIWNdxndCcSFn1FZa2bPiqFxjsSpwlv04Gz8V7tH3klyZd+FY+ 6qCPsFx1xjcwZcUqcRgnG1w7hfbYdqsVhQkTJ3jnAhMqtqwqrIynDeOqIVi5IB8RFuL34OzBorgk kaYO10pehJSSgRshhPjEqbwOFlwJsrEbUEIIIWSw4OrTfOMK93FEDq36uv8wrSzYZsOEyishxD9U XgkhhJAaw9Wn+cYV7uMI7lXF98jfJeyWIZURL3OEEJIVKq+EEEJIjeHq03zjCvdxBabo2P+L74LT h10yJD3xMkcIIVmh8koIIYTUGK4+zTeucAnxiavcEUJIFqi8EkIIITWGq0/zjStcQnziKneEEJIF Kq+EEEJIjeHq03zjCpcQn7jKHSGEZIHKKyFDDFx9UemF+0MR3JtZ6V25vpCrNM7sz1/x8c2ncqVG 92ieSEpK4+rTfOMKlwx+aqkPcJU7QgjJglN57WxuNJvmTjMrpo6Rv+eC50pkbnV2mF3L5prlU0ab 1XXjzeGNK+T+V1tG408pXAmyCRvP7mm/Mw9O7ZULw+Uy8YNrnPem+QD3auJuPNxh2Xu1I3ieHJUZ /gO5HxH3NCI+uLcRz2nvLASJYSllNCT5g3euPOi9diIil4jy+yB8xENkAtm7u+YX3c+qoWrfMGW+ o3xCtpK7TlUDlyA+uW31QTxO5O/ODP72rB7lls1IbnOds2wg/IKcx3oRp1h5HdaX9vydqbhLEfdx fj/yh5aMBr0/vVfaRXmFEts94UnTPfnX8vu4XEkU38dbHQzQtJk+6qCqbHjKL11Yfuq7j7Bcv/eN HRdSGd1TnpH8Q17a7rjvFHe1oi7Z7uXAhJbcU93VX89zO+ZK/XfJl0LTB+A6H9xLjT5G6hXqecs6 0z32ZwUZ3ANcKC9ffxLInsm3BeOfVMsU3hFCiCeKlNerrXtF2bzausd8e+mkuXYkfN6bSua7a2fN 2hkTTNuW1eab8x3msxOtZuOcqaa9sSGVP+VwJcgGDSca4oefnJdGunvqM+b2nL/KYE4Gfn2Nry96 ln8gHU7P8uGme9JT1vMHBZm7O4IB6M1zwSD2j8HzMHN75nMSP+mgLL+S0ISlkdGg8QcDW3SGNg9O N8sJjrZfSWi+T27NWFG4elaOysdn6bvm4ZfB4GF7dGCYhCZdGhkNafMd5fXhF1cGTHlFfLD6d2fx 25Ku3PqJMoC5M/81p3wWoNTg9M54+bAVL1/1wkVcec01zjIPP71o7ix6S9J+Z9GbMnDDoNH+XRJq f0Y+Ie1Rz/L3o+4p0HwfX3VQ02b6qoOasuErvzRheavvHsKK92cDQRgXko3cxilyUnH3JExKBXVo wi+l/c5tqSuSLcf9jp0yiXFn4euBUvx0UBbel3Y6bVnX9AH32zYHyvHJoH6/FCiav5BrgjAJdf94 Y0EGiun9IxulfCI+dxa9HbQFH5nezha1jKvcEUJIFoqU1+2L6k3b5tURNyigjYF7GplTTVvM5nl1 EZnvP74Qedb4Uw5XgmzQcOa2TDe9l48VGlrBGkCE5DZPk04Dg4fem53yOwwS43Ll6O08FAz4VkTc MAB8cO5g4fnBySZzr2V9VKZ1g3lwoiniloQmLI2Mhkr8wawzOsK0K9ya73N394KiyQd01hio225J VPMbpsl3URaCb5drnF258treKIoNBvkY/MiMupUXGLRAIbJ/hwEIfme7+eDe/lWJAylf9QJ1+96B 1YV03w3y6v6xrVHldcMUUbbs390/sklWGm23JDT+QMFztU1YWbF/l0Ql36fSOqhpM33VQU3Z8JVf mrB81XcfYbnKjW8Qzv2jW829Q2vM3aZFpvdSm+n9pFPqS/eoH0fiRsoxTCwrwvqIdjSvvOnHEN1T fyt5cnvWCxF31DUog7ZbEqo+IMjnXOOcyO/uzH81UMSn9ssEiilWUSMygXKKeHZP/o1KJixrhBDi iyLlddnkUebK4aaIG57h3n3zolpm9/J5ooge27bObJg91Wya86EotOF7oPGnHK4E2aARlUFfMCDA 6gMG7GKaFVNMYaolq1ByQfkwubBcVjU2p5k1HSYmQj0rRkTc8YwBbGhOl1s7PvD7goQBt9vT/5jv RNaOi/yuPJqwdPFJJr0/MH1Ch5l2tQJU+n0enD0gM8mud26q+Q1TpGvkD2Wggpl3mVCpUHkVxW3X AllFu13/Qt9K1ZKCDEy7cltnRn4HeUzc2G4+uN+2RQZysqoQ+I/05QdIVh30Ui8Cf4I0YZUOv8eK p6yI/O16RHmNMPwH+ZW84HthNdEpo6GUP0Ecusf9XNojrByKqStwTKCVI+33yVIHNW2mi/R1UFc2 ImTIr+Sw/NV3H2HF+7OBAGFiEkTMXtfky1L3uP+WshY3cSblCc2HMRmAvE1jLpwnKBsOU3ishKad xNP0AZj8wXaG7mm/j/zWxq2YvillJ7/1IVnGLm+EEOKDiPL6Xdc5s2TiCHOz/aC5HCiR+P/iwV3y jP9hCqyRgV9QVrHP9eTuTWI2DFPgVdPGmRM7N6rDsuPmwpUgG2lYsZqKgc72epnZFNMsmPNYM46Q ia8i5LbMCAZu+r1i3aN/KmHeWfC66Vk5Uv7HYADP+N/eR4JBocTxm0/lb2qzPkVYaeJTjkr8wbdF p9g/UEtH2u+DvMWgofvDNHuLqvcNQzTpgtu9Q2vl/yzKa14J7f/+GLTYq3339q8UBTYcYN2uf15W 6TDoCmV8cf/4dqlLMIHrrns2P1kUKJS57bMicmnz3QVWjmQ/pO0W1G+X8np33/L84Ukwd103vui9 liR/YC6K9KDcxN+lIc33yVIHNW1mnErqINCWDZA1v5LC8lnffYSFvwMN4iLtxeXj0fiLtcLWiBtJ BpM8+K6wmnG9T8ewoI4vkrqHvfJuGTeaPgCrolgtRnyxLQDWAnfmYgK/35+4YoqyDDdYDWhl7PJG CCE+iCmvnQWF8uPjB83WBdPN9aPNEYVSIwO/NgbKK1Zfbf8/2rnBrJ0xUR2W/VsXrgTZSMN67SNZ SQgbViADu0/6V5hwyIDr99gDqB38YaUDv8Hg487CN6TxvrPkbVlBg3s48JGDRwKF5PbsF2VVBjOi hcNXYn6WQhOWNj5JpPYnSJMMdNeMiborSfd9+jr3L6+l3qtZzW8INOkSN5h5BgNb+U0G5bWozDdM 6ivP+WeEISsEQdnHoBqrRIgLFAP7dwOFhPXphcKzj3oBsLoARcF2w8qFS3nFgSJQ2rEvTRSi2IEr WpL88aG8pvo+Geugps3sp/I6WIp42QjxlV82dlg+67uLtGHh70CDuKC9iJs4Sxvy0e6IG0kGK6Ro T/Pm85VN3gpBHUYd7L1wRPaROmXKoOkDQrA6CgsOtJPoD2xFFOVS+oivusQiAJNHKCvY06uVcZU7 QgjJQpHZMA5MutQSNeXFs23Kq5HZuXSOOdSwPCKDg5mgmKbxpxyuBNmg4UQngr0eYUMLcEAGGtjQ DAwNem7ThxGZ9AyTTit+Yiue86tZ+Y5MVjQ2TYvI5DZMlsGf7VYeTVi6+CSTzp+eZe/J9wwVsLSo v0/QuUP5wkzy7TocYmO9U1HNb6hI14gnZPUDA9nC+yzKa2zgiYGLs4wF4XaPyeeVmA3HVmAGCjGP RB3sM5/1Uy/6/Nk4JeKGgVSx8hrNO1kZE8Vdn6d5kv3xobym+T5Z66CmzRQy10E38bKRx1d+RYmG 5a++u0gbVrw/GwgQJpVXP4hpP1ZJp/8xX19jk2hpwHgEK6eY5HC9TyJVH2CBNKBchKbEUEyxFQAW GDCLdrUpSTLxMkcIIVkpUl53LJllDm9YEXFrCZTQnUtnp5Jp27JGTIdtGZgMr6+fXHjW+FMOV4Js 0HDe3bdMzODsgUf8IJzeS0fN/daNhWeAWf60B1bABAcHX9hu91rWRg4xkRWR2AmEGJTC3XZLQhOW RkZDGn/kIJW0h+xYqL5PMPh70LErPys97ucR2TRU8xsmpQsnPmJgi0FPAcxk97nhvf3bcmDggr2K tptcvyBmpPln7EnqWTHckhkmV3bANLPfzQ/4Xj1L3om4weQVZsvhsyrfFeCgoajZcJCuoK73K6/B M/aKbotdWbJugigTdjtRHr0/XpTXFN8nax3UtJm+6mBy2fCVX7py6Ku++wgr3p8NBBJmCuUVE12Y qCi3Cj1UZcqBk3Zxh3Nozt6zenTejL7vUKOIrCIsmO8mtRfl/EnqA8J7p8PrbEJwmjnKRXhoFBTT +H7WOEky8TJHCCFZKVJeu9qaZeXzckuTXF9zqWW3PMOkN40M9rliZfVooMRC5sbxA7IH9lTT5lT+ lMOVIBs0nLjqAYMcDGhxjH3hsA/rsBp0OFipkMF8MCiTPRuXj5t7zSsLMhowWIHZTM+qURIWOjD4 C3OwUAYnoWIAA/M3OXil7g9BJ3MisYOIowlLI6MhjT9YhUlr6mmj+T7hCYrIW3TcBYLO3PYriWp+ w8R0odzhqgELpFNm34P/scoV97MUcgBLUObFmmD4D2SAA3PF3PZ+BQBlHoOtO/NekXtHMWjGrHx4 CIdP4DcUEJhEdk98yvSsCQZ2iN+G/hVSX/VCygYObKp/QcoDzF1R3+2VV7QFcJP9iEGeYpCIsKH0 2X4lofXHh/Ka5vtkrYOqNtNTHdSUDV/5pQnLW333EFa8PxsIJK4plFd7f278XchQlSkHTHTjExz9 btEJFlV8lr0flPfyh62V8yepD8Cpw70fn5WTreWqnIm/EoX1wal9+b2yff0NlVdCSC1SpLwCHJzU MGuKKJI4KfjSod0VyXx24rDZtnCmyKyZPsGc3LWpyBxY408pXAmyCRtPNM6951tlYCCnKOLQjGAA aDewOAkSgz4MJrDCIIehiHlXv4wGdCTiTxAWZj7j+87QadzdvbAvrBsSHyjJaa+zAElhaWU0aP3B 98uyF03zfaCcuPIbM922Xxqq9Q0ryfdKzYZhyomBvQz6g2+FgT+Un3h5DvfgIT4yiAkUPvu9LyTt mPUPFI78NzxlcusnFMt4qBeQx5UySDOAKTQOwMIBNAW54DugDcDgTeITfGOcrpvazFbpjw/lNc33 yVoHQVKb6asOSroSyoav/FKFFeCtvmcMy/V9fYNwqLzqZEohE4GBooiJHNsdE4GoDzDvt901YeHb x/esxinnj6YPwF5aXI+GSRbZs/rZJWknYf4bylB5JYTUIk7ldbDgSpCNqyElhBBCah1Xn+YbV7iE +MRV7gghJAtUXgkhhJAaw9Wn+cYVLiE+cZU7QgjJApVXQgghpMZw9Wm+cYVLiE9c5Y4QQrJA5ZUQ QgipMVx9mm9c4RLiE1e5I4SQLFB5JYQQQmoMV5/mG1e4hPjEVe4IISQLVF5JVXDlDyGEkEeHq61+ lLjiSAghhNhQeX1EhJeE467N/3zzqRxl3z36J07ZoYArfwghhDw6XG11Fm7PfE6ucsL90a73Sbji SAghhNg4ldfO5kazae40s2LqGPl7LnhOKwO3JRNHFLFxztSInCasUrgSZOPqHAeU4T8wuW31prfr hNy1iL89q0c5ZXuvtIvyCiW2e8KTcidc/DLzJHINk03v1Q65Y673+mlzd9f86P21KeJTlsAf3AmK MCSsrlPybN8Z13ulw5kHvddOyHvXO0IIIY+OQhvvkdzWmXInL+43dr0vhyuOhBBCiE2R8nq1da9Z PmV08HeP+fbSSXPtSPi8N5XMv653mn92Rdm5dLY5vm1dKn/K4UqQjatzHEju7pgnK6h3Fr9tuic9 ZXLrJ8rl83fmvxaVHfmExK9n+ftR9xTk1owVhbRn5SgJq2fpu+bhl10mt72+IKOOTwLwp/fmuUDR /mPwPExm1x9+ct7kdswtyOBSfgxWbB6cbjZ3mxbL+3jeEEIIebSE7bdXgv6t95POoC+a5X5fBlcc CSGEEJsi5XX7onrTtnl1xK1ty2rTGLinkYlz8eAus75+sii1oVsl/ti4EmQjHWLQkd7bv1I6U5gz YaWyZ8Xwok4zt3la/yrmzaDj3TI9cE+3EtrbdVIUPdvt/pGN5n57Y+EZCqcrrr1dpyO/S+Lu7gX5 1U/L7d7hBlEYw2dNfDQ8ONlk7rWsj7jda91gHpxoirjZ5NaMk5VaKLV4dqWZEELIoyPebvsCk6gP P70Q/J+uD3XFkRBCCLEpUl6XTR5lrhxuirjhGe7dNy+qZWy+6+o0q+vGF62opvUnjitBNugMZfXx kwum+8PfiSKba5gkq495M918hwnzW1mhnPdS8DzM3K7/c35lcXNdQUZD740zYjJlu93dtUCU4YJb EIfucT+X+N1Z9Fbw/MM8lglupTw4e8Dcb9tceFbFR0Fu7Xj5hvguMEu+Pf2P+Zn1teOc8ti7+/Cz S6Zn+QcFt3jeEEIIebTY7bZPsB0G/kuf4Xhfinj8CCGEkDgR5fW7rnOyL/Vm+0FzOVAi8T9WTPGM /7+7dlYlY/sJTuzcaDbPmxZxq8SfOK4E2aAzFHPW8b/o7yADJRHvepa9V3DDimt8FTO3ZYbsEbXd kpAV3kBh7J4WKMrB8+3652X1ESu+thxMahGHOwtej7hnQWa6v+rKK+l9btr4aID5r3zXbz6Vv6E5 sItc4xzZ02vPustvCSGE1Ax2u+2XYTJJXGqCsxSuOBJCCCE2MeW1s6BQfnz8oNm6YLq5frQ5olBq ZGw//33jvFk1bZy5dGh3xD2tPy5cCbJBZ9g9/kkxp8UBElgNhCkT3vWsHNnfYX79SdFvhaDzTWP2 1D36p+b+0a3in5gfd7aIUoy9qBE5r8rrsECRXBSEca1oL6s2PknIoU83zprbs1+UlePb9S/0H9oU lw/eP/ziismtGRNxL/q2hBBCHil2G+0bsV6KWf4k4YojIYQQYlNkNowDky61RE158Wyb8mpkQq61 7RN3rLTa7iCNPy5cCbJBZwiFrfdim+me8nS+gxz+X/IuqrzeNLlNHxaeMzPiCdM95qfyv5jpXj4e ee9NeQ0URSin2C97uw6HKTlkQEJ8koBJdW7TtIhbbsNkUZhtN4AVbTHLDhRn293OF0IIIY8eu432 jSivW2Y435XCFUdCCCHEpkh53bFkljm8YUXEraVhuZwUnEYm5MC6JWb38nlF7iCNPy5cCbLBFS/4 i32uYeeIPThws5XX3ktHzf3WjYVngBXb7lE/jrglcWfRm7HDoIbJFTJ39y233Dwpr4FC+qBjl+m9 cET20LpktPFJQlZSt0T3/0KZhbvtBu4f2eQ8yCnME0IIIbWB3UZjghOToN1jfxZxt9HI5ClvNlzK H1ccCSGEEJsi5bWrrVlWPi+3NMn1NZdadsszTHrTyIQ0zJpiOhobitxBGn9cuBJkg84QBwth76d0 mJN/be4f2yYrhrmNUwodZm7deOloRdHDKmXds7I6ea85/zst8OfhF1flgnbc3XqvZa2EZR8OBXwo r7imBmbQ3VOfkQFAgb4VVpFRxieJewdWy95Z7JmVA5vq/iD7ge8dXFMki1VglzlxPG8IIYQ8Wuw2 GhO6cMNJ8ba7jUYGFA5smhn0GY73pfyBGyGEEFKOIuUV4OAkKJ1QJDfMnlq0X1UrA/C+s7nR+Q5o /XHhSpANOkOc6AuFCqflPjh7UBTTu/uWyeFGEQV241SRw1U22N8pBxIFimz4XovsKcW+2ls3zINz B2V/aFzGh/L68NOLRekFSJctp4lPEjj06u7uhX3f54Z8Syj24TU4Nvh+9kp3wd0RV0IIIY8Ou432 qbzKAYJBP1HqzAgqr4QQQirFqbwOFlwJsrE7RfJoceUPIYSQR4errc7MyCfyV6kFCqzzfRlccSSE EEJsqLySquDKH0IIIY8OV1udFblm7man3Pftel8OVxwJIYQQGyqvpCq48ocQQsijw9VWZwF7XXEt 2535rzrfJ+GKIyGEEGJD5ZVUBVf+EEIIeXS42upHiSuOhBBCiA2VV1IVXPlDCCHk0eFqqx8lrjgS QgghNkNaeSWEEEIIIYQQMjSg8koIIYQQQgghpOah8koIIYQQQgghpOah8koIIYQQQgghpOah8koI IYQQQgghpOah8koIIYQQQgghpOah8koIIYQQQgghpOah8koIIYQQQgghpOah8koIIYQQQgghpOah 8koIIYQQQgghpOah8koIIYQQQgghpOah8koIIYQQQgghpMb5zPx/ZGI32eX9aEsAAAAASUVORK5C YII= --_004_7CF7F94CB496BF4FAB1676F375F9666A3BB5B27Abgb01xud1012_-- From nobody Thu Jun 21 13:27:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64A1310CD for ; Thu, 21 Jun 2018 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 OGOy3Of5P4vD for ; Thu, 21 Jun 2018 13:27:13 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 0308613109F for ; Thu, 21 Jun 2018 13:27:12 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u124-v6so1637012ywg.0 for ; Thu, 21 Jun 2018 13:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1i63ERZV/eKqPzy2PIcHJHZb43fTkY97keLuE21VKWw=; b=N6XSbrzV3xUKwuSA68lNL1YPKwubmFdsTFsPnr4ZApmxSjptO4+X5nDCtUU3iyr5+j mieu5a5OsIGrjl9nujc3GHAX1Ff+QiOpvJ1ZQ88KYeiIiVOesZsgx3fI6OLutxZ9rm9x KiIqJ3Oh5NX80JyOwbqDLYZc9CF/LoP6b0qccMTnmlEhYbth1KsHlLfYUQnB5tzutaXO qMcl/Td+tGj7Zht25PAAmaOMs0C5/MkB2o4VKkC9igd7Q1XrfEVZj6Z3oeFHy+8tOzWT H7Zfri8Ayfd8dBWEOjIf0IyZZbKes+VOW2apqqQcyiYhGTw1ylZm2IWJM6CZHzDpeKKz gb8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1i63ERZV/eKqPzy2PIcHJHZb43fTkY97keLuE21VKWw=; b=tMRyKKNHpZbpXjQ2IR0dqGFq8uEMEgdC2DPF9/rPuXgFKsSZNhmVlOglqTlm9ey1qn +6ycUtNC8tfcKAjX9iYw68dbvntHY2JQTeZy+RH+GT2ayD63qPfYOlHmtEbftY481nzr jSxI0e/txVDuKB8iyxx/EBfLJSM8Z6jXfOzI8s7D3PP6AOYSxnP3y47/CY0+hjT/YQeO eF7fW11W0WxgYnDPOxMEphg1hqd/5FIr63cXxeAZ+ayZgP7ombPMpjmgXYyDN//tG+8p XCg0MCiEbU9obk6bGig1WwVY1PBGL3fFvnZ4LlhQiNkIoOC8/I4lips8byAJR/vHOQg5 4T4A== X-Gm-Message-State: APt69E3Wama9lW14IxFtUSKD6zUeBM6nXBBoA8mWQSq/gnC6WWYD64+f xZFgeK0ss2WuIdiqKeLP3guY/znlqrX7GH+sC3z7Vw== X-Google-Smtp-Source: ADUXVKK3SfkXTfgJZOavQKhgBNias2Y3RQYrVLx+SajxImZt5HZTYviusV5l9KC9xofrAbmMeyDL1HUj5RYJ4tXOxo0= X-Received: by 2002:a81:3208:: with SMTP id y8-v6mr11666952ywy.361.1529612831864; Thu, 21 Jun 2018 13:27:11 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Ian Swett Date: Thu, 21 Jun 2018 16:27:00 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Marten Seemann Cc: "Deval, Manasi" , Kazuho Oku , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000007d52fe056f2cbde5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:27:18 -0000 --0000000000007d52fe056f2cbde5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree the ack blocks should be at the end of the ACK_ECN frame, and I asked Magnus to move them there(and he has kindly done so in his PR). This will make it substantially easier to truncate ACK blocks when necessary. But like Marten, I think this would make most implementations, including mine, more complex. On Tue, Jun 19, 2018 at 9:44 PM Marten Seemann wrote: > Hi Manasi, > > > The risk of disagreement between ack blocks and ack block count is same > as the risk of disagreement between ack blocks and ack length. Either way > this needs to be counted up while creating the ACK and counted down while > parsing it. The possibility of error is the same. Getting the ack block > count wrong is as problematic as getting the ack length wrong. Do you agr= ee? > > I disagree. Let's take an example of an ACK frame with one ACK range, tha= t > needs a 2 byte varint to represent the First ACK Block and another 2 byte > varint to represent the Gap. > With your proposal: > > 1. The values 0 and 1 are invalid, since the length fields itself is > included in the length. > 2. The values 2, 3, ..., (2 + len(LargestAcknowledged) > + len(AckDelay)) - 1 are invalid, since the length needs to include th= e > Largest Acknowledged and the Ack Delay. > 3. The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the > first valid value, and correspond to an ACK frame with no blocks. > 4. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is > invalid, since it would cut the varint for the First ACK Block > 5. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is > invalid, since it would cut the frame after the First ACK Block (but e= very > block must be followed by a gap length) > 6. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is > invalid, since it would cut the varint for the Gap > 7. Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + > 4 is valid > > There are *a lot* of invalid values that you can encode into the ACK > length field. More importantly, *none* of these error cases exists with t= he > current frame format. > The *only* error case that can occur with our current format is that the > packet is too short for the number of ACK blocks that are supposed to > contained in the frame. This can occur with your proposal as well (in > addition to the error cases listed above). > > My concern is not that it's impossible or even particularly hard to catch > these errors, but I dislike the property that some (in fact, most) > encodable values are invalid. > > Best, > Marten > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > wrote: > >> Hi Ian, >> >> >> >> Here is another attempt to solve the objections you raised: >> >> >> >> >I'm not a fan of this proposal, because I think it is impractical to >> drop the number of ack blocks, because with the ECN proposal it becomes >> impractically complex to parse. >> >> Is there a reason the proposal from Christian does not solve this >> problem? >> >> >> >> >If we don't remove the number of ack blocks, then the ack frame is >> larger, but I don't think the extra size field is useful for most >> implementations. Also, it means the length can disagree with the actual >> length, which add complexity and the possibility of writing error-prone >> code. The idea of someone offloading ack processing and then proceeding= to >> trust the length seems like someone could get wrong and cause some >> concerning issues. >> >> The risk of disagreement between ack blocks and ack block count is same >> as the risk of disagreement between ack blocks and ack length. Either wa= y >> this needs to be counted up while creating the ACK and counted down whil= e >> parsing it. The possibility of error is the same. Getting the ack block >> count wrong is as problematic as getting the ack length wrong. Do you ag= ree? >> >> >> >> >My experience is multithreaded packet processing is more cost and work >> than it's worth. Sure you can't fill a 100G NIC with one connection, bu= t >> that seems like an academic problem, not one for workloads I've seen. >> Typically the extra cost of multithreading outweighs its value. >> >> The value is two fold =E2=80=93 pre-processing and multi-threading. If w= e >> pre-process the received packets such that ACKs and streams can be >> coalesced, the receive side can indicate a large chunk of information >> though the kernel, reducing the cost of system call and protocol >> overhead. This is the same concept as UDP segmentation taken a step furt= her >> on receive side. After this chunk is indicated into the QUIC protocol, t= he >> protocol may process stream and ACK in parallel. While folks may or may = not >> utilize this, there is an advantage here. >> >> >> >> Thanks, >> >> Manasi >> >> >> >> >> >> *From:* Ian Swett [mailto:ianswett@google.com] >> *Sent:* Tuesday, June 19, 2018 11:26 AM >> *To:* Deval, Manasi >> *Cc:* Marten Seemann ; Kazuho Oku < >> kazuhooku@gmail.com>; Eric Rescorla ; Jana Iyengar < >> jri.ietf@gmail.com>; Praveen Balasubramanian ; IETF >> QUIC WG ; Martin Thomson >> >> >> *Subject:* Re: Proposal to replace ACK block count with ACK length >> >> >> >> I'm still not interested in this change, for the reasons I stated above. >> >> >> >> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi >> wrote: >> >> Hi All, >> >> >> >> Do we have agreement here to create a new PR? >> >> >> >> Thanks, >> >> Manasi >> >> >> >> *From:* Deval, Manasi >> *Sent:* Sunday, June 17, 2018 2:25 PM >> *To:* Marten Seemann ; Kazuho Oku < >> kazuhooku@gmail.com> >> *Cc:* Ian Swett ; Eric Rescorla = < >> ekr@rtfm.com>; Jana Iyengar ; Praveen >> Balasubramanian ; IETF QUIC WG ; >> Martin Thomson >> *Subject:* RE: Proposal to replace ACK block count with ACK length >> >> >> >> Hi All, >> >> >> >> I have made a list of objections to the proposal and the solutions to >> those objections discussed on this thread. >> >> >> >> a. Co-existence of length field with ECN field and ACK blocks. >> >> >> >> Christian suggested to move the ECN fields to precede the ACK blocks. >> This is an elegant solution. Parsing entire list of ACK blocks to review >> ECN bits would have been annoying, even though it can work. >> >> >> >> b. There are two cases to be parsed =E2=80=93 entire ACK and parse = ACK to >> identify length. There are some reservations when ACK parsing gets harde= r >> for the case where the entire header needs to be parsed. >> >> >> >> Agreement from several folks here. In the original ACK defined in draft >> 12 of the slide, one would count down number of ACK blocks to get to the >> end of the packet. In the proposal I made, one would count down the leng= th >> to identify the end of the packet. The logic is very similar in cycle co= unt >> and complexity. Several folks also commented to this effect. >> >> >> >> c. Multi-threaded packet processing >> >> >> >> I would expect that there are 10s of 1000s of connections in use at any >> time for a server with a high speed link. Multi-threading to handle each= of >> these flows / connections in parallel is necessity to be able to support >> large number of connections on a high speed link. Tx segmentation, Rx >> coalescing are well known strategies to reduce the processing cost. In >> initial stages, code is often written as a single-threaded and then >> re-factored to parallelize cycle intensive operations. In order to allow >> this protocol to scale in future, I would suggest we do not preclude thi= s >> case. >> >> >> >> d. Increase in ACK size by 1 byte. >> >> >> >> I do not see this as a serious issue but if folks but we can consider >> making this a varint, if others have strong feelings about it. It=E2=80= =99s a >> trade-off : 2 reads to save 1 byte. >> >> >> >> e. Every encodable value should be valid >> >> Not every length will be valid. This is inherent to lengths. This same >> issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only= does the issue >> exist for small values, it also applies to large values since data strea= m >> will be sent after crypto negotiation. E.g. - how does one craft a >> payload with 62 bit payload length in a large header? >> >> >> >> >> >> Thanks, >> >> Manasi >> >> >> >> >> >> *From:* Marten Seemann [mailto:martenseemann@gmail.com >> ] >> *Sent:* Sunday, June 17, 2018 6:59 AM >> *To:* Kazuho Oku >> *Cc:* Ian Swett ; Eric Rescorla = < >> ekr@rtfm.com>; Jana Iyengar ; Praveen >> Balasubramanian ; IETF QUIC WG ; >> Martin Thomson ; Deval, Manasi < >> manasi.deval@intel.com> >> *Subject:* Re: Proposal to replace ACK block count with ACK length >> >> >> >> Maybe it's specific to Go, but I'm using a single io.Reader for the whol= e >> packet, so as long as the packet payload is long enough, the varint pars= ing >> will not fail. >> >> I don't think that specifics of programming languages matter here though= , >> and I'm sure both frame formats can be reasonably implemented in C as we= ll >> as in Go. The reasons I'm opposed to Manasi's proposal are that it moves= us >> away from the principle that only reasonable values should be encodable, >> and that it increases the size of the ACK frame, for the questionable >> benefit of being able to parallelise the frame parser. >> >> >> >> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: >> >> 2018-06-17 22:36 GMT+09:00 Marten Seemann : >> > At least for my implementation, parsing doesn't become easier, it >> becomes >> > more complex with this proposal. My varint-parser always consumes as >> many >> > bytes as the varint requires, so after parsing a varint, I'd have to >> > introduce an additional check that this didn't overflow the ACK length >> (e.g. >> > consider that I parsed the ACK frame so far that only 2 bytes are >> remaining >> > according to ACK length field, but the next varint is 4 bytes long). >> >> Isn't your varint parser checking that it has not (or will not) run >> across the end of the packet payload for every ACK block it parses? >> I'd assume that you would be doing that, because I think that is >> necessary to avoid buffer overrun. >> >> What I am saying that that check could be converted to a overrun check >> against the end of the "frame payload", and that checking the >> remaining block count becomes unnecessary, in case we replace ACK >> Block Count with ACK Frame Length. >> >> > >> > In general, we've been moving the wire image towards making every >> encodable >> > value valid. This proposal moves us away from that principle: >> > * some small values are always invalid (the length can never be betwee= n >> 0 >> > and 3) >> > * a lot of intermediate values are invalid (if the boundary falls >> inside a >> > varint, as described above) >> > Both these cases can't occur with the current ACK frame format. >> > >> > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote= : >> >> >> >> 2018-06-17 8:34 GMT+09:00 Ian Swett >> >> : >> >> > I'm not a fan of this proposal, because I think it is impractical t= o >> >> > drop >> >> > the number of ack blocks, because with the ECN proposal it becomes >> >> > impractically complex to parse. >> >> >> >> For the ECN proposal, as Christian has suggested, we can move the ECN >> >> counters before the ACK blocks. Then, it would not be complex to >> >> parse. >> >> >> >> And my view is that parsing becomes easier if we replace ACK Block >> >> Count with ACK Frame Length. >> >> >> >> Now, with ACK Block Count, we need to check the remaining number of >> >> blocks and the remaining space in the packet payload for every block >> >> that we parse. Failing to check either leads to a bug or a security >> >> issue. >> >> >> >> If we switch to ACK Frame Length, we need to only check the remaining >> >> space in the frame. >> >> >> >> I think that this is the biggest benefit of replacing ACK Block Count >> >> with ACK Frame Length. OTOH the downside is that you need extra one t= o >> >> two bits (one if the size of block / gap is expected to be below 65, >> >> two if they are expected to be above that) for encoding ACK Frame >> >> Length compared to ACK Block Count. >> >> >> >> >> >> >> >> Having said that, I honestly wonder if all the frames could have it's >> >> length being encoded (either explicitly or either as a signal that >> >> says "to the end of the packet"). Consider something like below: >> >> >> >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | >> >> or >> >> |1| frame-type (7) | frame-payload (*) | >> >> >> >> When MSB of the first octet set to zero, the length of the frame >> >> payload is designated by the varint that immediately follows the fram= e >> >> type. >> >> When MSB of the first octet set to one, the length of the frame >> >> payload spans to the end of the packet. >> >> >> >> In this encoding, we can always omit the Length field of a STREAM >> >> frame. So the overhead for carrying stream data will be indifferent i= n >> >> practice. >> >> >> >> For the ACK frame, we can omit the ACK Block Count field. And the >> >> overhead will be one to two bits if the ACK frame is sent in the >> >> middle of the packet (thereby using the encoding with explicit frame >> >> payload length), or one octet or more shorter if ACK is the last fram= e >> >> of the packet. >> >> >> >> We are likely to see increase of overhead for most of the other types >> >> of frames, but I do not think that would be an issue considering that >> >> they will be far seldom seen compared to STREAMs and ACKs. >> >> >> >> To summarize, my anticipation is that we can make all the frames >> >> self-contained (i.e. the length can be determined without the >> >> knowledge of how each frame is encoded) without any overhead, if we >> >> agree on making the frame type space 1 bit smaller. >> >> >> >> Finally, the biggest benefit of using a self-contained encoding of >> >> frames is that we would have the ability to introduce new optional >> >> frames without negotiation. By making the frames self-contained, QUIC >> >> endpoints will have the freedom of ignoring the frames that they do >> >> not understand. >> >> >> >> Being able to send QUIC frames defined in extensions without >> >> negotiating using Transport Parameters will be a win in both terms of >> >> security (because clients' TP is sent in clear) and flexibility >> >> (because we will be possible to send the extensions before we figure >> >> out whether the peer supports that extension). >> >> >> >> > If we don't remove the number of ack blocks, then the ack frame is >> >> > larger, >> >> > but I don't think the extra size field is useful for most >> >> > implementations. >> >> > Also, it means the length can disagree with the actual length, whic= h >> add >> >> > complexity and the possibility of writing error-prone code. The >> idea of >> >> > someone offloading ack processing and then proceeding to trust the >> >> > length >> >> > seems like someone could get wrong and cause some concerning issues= . >> >> > >> >> > My experience is multithreaded packet processing is more cost and >> work >> >> > than >> >> > it's worth. Sure you can't fill a 100G NIC with one connection, bu= t >> >> > that >> >> > seems like an academic problem, not one for workloads I've seen. >> >> > Typically >> >> > the extra cost of multithreading outweighs its value. >> >> > >> >> > To be clear, I don't think this is an awful idea, but I also don't >> see >> >> > the >> >> > value and it adds complexity. I read Manasi's email, but I don't >> think >> >> > I >> >> > understand why any of those matter in practice. >> >> > >> >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: >> >> >> >> >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> This proposal increases the size of the ACK frame by 1 byte in th= e >> >> >>> common >> >> >>> case (less than 63 ACK ranges), since the ACK length field here >> always >> >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-lengt= h >> >> >>> integer. >> >> >>> Considering how much work we put into minimising the size of the >> >> >>> frames, >> >> >>> this feels like a step in the wrong direction.. >> >> >>> >> >> >>> Regarding the processing cost, I agree with Dmitri. Handling an A= CK >> >> >>> frame >> >> >>> requires looping over and making changes to a data structure that >> >> >>> keeps >> >> >>> track of sent packets. This is much more expensive than simply >> parsing >> >> >>> a >> >> >>> bunch of varints in the ACK frame. It seems unlikely that a >> >> >>> multi-threaded >> >> >>> packet parser would offer any real-world performance benefits. >> >> >> >> >> >> >> >> >> I don't want to overstate the benefit here, but my point isn't tha= t >> >> >> parsing is expensive but that if you want to have a multithreaded >> >> >> packet >> >> >> processing system, then it's nice to have a simpler data structure >> (the >> >> >> unparsed ACK block) to hand to the ACK processing thread. >> >> >> >> >> >> -Ekr >> >> >> >> >> >> >> >> >>> >> >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >> >> >>> >> >> >>> wrote: >> >> >>>> >> >> >>>> When we discussed this before, some people observed that this >> creates >> >> >>>> a need to encode in two passes. That's the trade-off here. (No= t >> >> >>>> expressing an opinion.) >> >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar >> >> >>>> wrote: >> >> >>>> > >> >> >>>> > I don't have a strong opinion on this. I'm certainly not >> opposed to >> >> >>>> > it. >> >> >>>> > Does anyone have a strong opposition? >> >> >>>> > >> >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> I agree as well since this can help reduce per packet >> processing >> >> >>>> >> overhead. ACKs are going to be the second most common frame >> type >> >> >>>> >> so no >> >> >>>> >> objections to special casing. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric >> >> >>>> >> Rescorla >> >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM >> >> >>>> >> To: Deval, Manasi >> >> >>>> >> Cc: Jana Iyengar ; QUIC WG >> >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK >> length >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> I agree with Manasi here. This change would allow ack frame >> >> >>>> >> parsing >> >> >>>> >> to be more self-contained, which is an advantage for the pars= er >> >> >>>> >> and also >> >> >>>> >> potentially for parallelism (because you can quickly find the >> >> >>>> >> frame and then >> >> >>>> >> process it in parallel). >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> -Ekr >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >> >> >>>> >> wrote: >> >> >>>> >> >> >> >>>> >> In general, varints require some specific logic for parsing. = To >> >> >>>> >> skip >> >> >>>> >> over any header, I have to read every single varint. As the >> code >> >> >>>> >> sees Stream >> >> >>>> >> and ACK headers most frequently, that is my focus. The Strea= m >> >> >>>> >> frame has a >> >> >>>> >> length in its third field. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identif= y >> >> >>>> >> length. There are two reads each for =E2=80=98largest acknowl= edged=E2=80=99, >> =E2=80=98ACK >> >> >>>> >> delay=E2=80=99 and >> >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the tota= l number of cycles >> >> >>>> >> parse an >> >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packe= ts >> >> >>>> >> have a >> >> >>>> >> piggybacked ACK, these cycles becomes a significant bottlenec= k. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> Thanks, >> >> >>>> >> >> >> >>>> >> Manasi >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana >> >> >>>> >> Iyengar >> >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM >> >> >>>> >> To: Deval, Manasi ; QUIC WG >> >> >>>> >> >> >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK >> length >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> You're right that we no longer have the ability to skip an AC= K >> >> >>>> >> frame, >> >> >>>> >> and this crept in when we moved to varints. >> >> >>>> >> >> >> >>>> >> I believe your problem though is generally true of most frame= s >> not >> >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all fram= es >> >> >>>> >> are now all >> >> >>>> >> varints. To skip any frame, you'll need to parse the varint >> fields >> >> >>>> >> in those >> >> >>>> >> frames. If you have logic to process and skip varints, then >> >> >>>> >> skipping the ack >> >> >>>> >> block section is merely repeating this operation >> (2*num_block+1) >> >> >>>> >> times. Do >> >> >>>> >> you see specific value in skipping ACK frames over the other >> >> >>>> >> control frames? >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >> >> >>>> >> wrote: >> >> >>>> >> >> >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote= : >> >> >>>> >> > - Moving the ACK length to the front of the ACK allo= ws >> >> >>>> >> > the >> >> >>>> >> > flexibility of either reading the entire ACK or >> reading >> >> >>>> >> > the >> >> >>>> >> > first 16 bits and skipping over the length. This i= s >> a >> >> >>>> >> > useful >> >> >>>> >> > feature for the case where ACK processing is split >> into >> >> >>>> >> > multiple layers. Depending on the processor this i= s >> run >> >> >>>> >> > on, >> >> >>>> >> > there are different advantages - >> >> >>>> >> >> >> >>>> >> Just a note. In my experience, the cost of parsing an ACK >> frame >> >> >>>> >> is >> >> >>>> >> negligible compared to the cost of processing an ACK frame: >> that >> >> >>>> >> is, >> >> >>>> >> poking at various memory locations to discard newly ACKed >> packets. >> >> >>>> >> >> >> >>>> >> - Dmitri. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Kazuho Oku >> >> >> >> -- >> Kazuho Oku >> >> --0000000000007d52fe056f2cbde5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree the ack blocks should be at the end of the ACK_ECN= frame, and I asked Magnus to move them there(and he has kindly done so in = his PR).=C2=A0 This will make it substantially easier to truncate ACK block= s when necessary.

But like Marten, I think this woul= d make most implementations, including mine, more complex.

<= div class=3D"gmail_quote">
On Tue, Jun 19, 2018 at 9:44 PM = Marten Seemann <martenseemann= @gmail.com> wrote:
Hi Manasi,

>=C2=A0The risk = of disagreement between ack blocks and ack block count is same as the risk = of disagreement between ack blocks and ack length. Either way this needs to= be counted up while creating the ACK and counted down while parsing it. Th= e possibility of error is the same. Getting the ack block count wrong is as= problematic as getting the ack length wrong. Do you agree?

<= /div>
I disagree. Let's take an example of a= n ACK frame with one ACK range, that needs a 2 byte varint to represent the= First ACK Block and another 2 byte varint to represent the Gap.
= With your proposal:
  1. The values 0 and 1 a= re invalid, since the length fields itself is included in the length.
  2. The values 2, 3, ..., (2 + len(LargestAcknowledg= ed) +=C2=A0len(AckDelay)) - 1 are invalid, since the length needs to includ= e the Largest Acknowledged and the Ack Delay.
  3. The value=C2=A02 + len(LargestAcknowledged) +=C2=A0len(AckDelay) would be the first valid value, and corresp= ond to an ACK frame with no blocks.
  4. The value 2 + len(Larges= tAcknowledged) +=C2=A0len(AckDelay)= =C2=A0+ 1 is invalid, since it would cut the varint for the First ACK Block=
  5. The value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 2 is invalid, since it would cut the frame= after the First ACK Block (but every block must be followed by a gap lengt= h)
  6. The value 2 + len(Largest= Acknowledged) +=C2=A0len(AckDelay)=C2=A0+ 3 is invalid, since it would cut = the varint for the Gap
  7. F= inally, the value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ = 4=C2=A0is valid
There are *a lot*= of invalid values that you can encode into the ACK length field. More impo= rtantly, *none* of these error cases exists with the current frame format.= =C2=A0
The *only* error case that can occ= ur with our current format is that the packet is too short for the number o= f ACK blocks that are supposed to contained in the frame. This can occur wi= th your proposal as well (in addition to the error cases listed above).

My concern is not that it's impossible or even particularly hard to ca= tch these errors, but I dislike the property that some (in fact, most) enco= dable values are invalid.

Best,
Marten


On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <= ;manasi.deval@i= ntel.com> wrote:

Hi Ian,

=C2=A0

Here is another attempt to solve the = objections you raised:

=C2=A0

>I'm not a fan of this proposa= l, because I think it is impractical to drop the number of ack blocks, beca= use with the ECN proposal it becomes impractically complex to parse.

Is there a reason the propos= al from Christian does not solve this problem?

=C2=A0

>If we don't remove the number= of ack blocks, then the ack frame is larger, but I don't think the ext= ra size field is useful for most implementations.=C2=A0 Also, it means the length can disagree with the actual length, which add complex= ity and the possibility of writing error-prone code.=C2=A0 The idea of some= one offloading ack processing and then proceeding to trust the length seems= like someone could get wrong and cause some concerning issues.

The risk of disagreement bet= ween ack blocks and ack block count is same as the risk of disagreement bet= ween ack blocks and ack length. Either way this needs to be counted up while creating the ACK and counted down while parsing it. Th= e possibility of error is the same. Getting the ack block count wrong is as= problematic as getting the ack length wrong. Do you agree?

=C2=A0

>My experience is multithreaded pa= cket processing is more cost and work than it's worth.=C2=A0 Sure you c= an't fill a 100G NIC with one connection, but that seems like an academic problem, not one for workloads I've seen.=C2=A0 Typically = the extra cost of multithreading outweighs its value.<= /p>

The value is two fold =E2=80= =93 pre-processing and multi-threading. If we pre-process the received pack= ets such that ACKs and streams can be coalesced, the receive side can indicate a large chunk of information though the= kernel, reducing the cost of system call and protocol overhead. This is the same concept as UDP segmentation taken a st= ep further on receive side. After this chunk is indicated into the QUIC pro= tocol, the protocol may process stream and ACK in parallel. While folks may= or may not utilize this, there is an advantage here. =C2=A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: = Ian Swett [mailto:= ianswett@google.com]
Sent: Tuesday, June 19, 2018 11:26 AM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <kazuhooku@gmail.com>; = Eric Rescorla <ekr@rtf= m.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com&= gt;; IETF QUIC WG <qu= ic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>


Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

I'm still not interested in this change, for the= reasons I stated above.

=C2=A0

On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi All,

=C2=A0

Do we have agreement here to create a= new PR?

=C2=A0

Thanks,

Manasi

=C2=A0

<= b>From: Deval, Manasi
Sent: Sunday, June 17, 2018 2:25 PM
To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <kazuhooku@gmail.com> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorl= a <ekr@rtfm.com>= ;; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= ;martin.thoms= on@gmail.com>
Subject: RE: Proposal to replace ACK block count with ACK length

=C2=A0

Hi All,

=C2=A0

I have made a list of objections to t= he proposal and the solutions to those objections discussed on this thread.

=C2=A0

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Co-existence of length field with ECN field and ACK b= locks.

=C2=A0

Christian suggested= to move the ECN fields to precede the ACK blocks. This is an elegant solut= ion. Parsing entire list of ACK blocks to review ECN bits would have been annoying, even though it can work.

=C2=A0

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two cases to be parsed =E2=80=93 entire ACK= and parse ACK to identify length. There are some reservations when ACK par= sing gets harder for the case where the entire header needs to be parsed.

=C2=A0

Agreement from seve= ral folks here. In the original ACK defined in draft 12 of the slide, one w= ould count down number of ACK blocks to get to the end of the packet. In the proposal I made, one would count d= own the length to identify the end of the packet. The logic is very similar= in cycle count and complexity. Several folks also commented to this effect= .

=C2=A0

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multi-threaded packet processing

=C2=A0

I would expect that= there are 10s of 1000s of connections in use at any time for a server with= a high speed link. Multi-threading to handle each of these flows / connections in parallel is necessity to be ab= le to support large number of connections on a high speed link. Tx segmenta= tion, Rx coalescing are well known strategies to reduce the processing cost= . In initial stages, code is often written as a single-threaded and then re-factored to parallelize cycle int= ensive operations. In order to allow this protocol to scale in future, I wo= uld suggest we do not preclude this case.

=C2=A0

d.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Increase in ACK size by 1 byte.<= /p>

=C2=A0

I do not see this a= s a serious issue but if folks but we can consider making this a varint, if= others have strong feelings about it. It=E2=80=99s a trade-off : 2 reads to save 1 byte.

=C2=A0

e.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every encodable value should be valid<= /span>

Not every length will be valid. This is inherent to leng= ths. This same issue ails the =E2=80=98payload length=E2=80=99 in QUIC head= er. Not only does the issue exist for small values, it also applies to large values since data stream will be sent after crypt= o negotiation.=C2=A0 E.g. =C2=A0- how does one craft a payload with 62 bit = payload length in a large header?

=C2=A0

=C2=A0

Thanks,<= /span>

Manasi

=C2=A0

=C2=A0

From: Marten Seemann [mailto:martenseemann@gmail.c= om]
Sent: Sunday, June 17, 2018 6:59 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; E= ric Rescorla <ekr@rtfm= .com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= ;martin.thoms= on@gmail.com>; Deval, Manasi <manasi.deval@intel.com>
Subject: Re: Proposal to replace ACK block count with ACK length

=C2=A0

Maybe it's specific to Go, but I'm using a s= ingle io.Reader for the whole packet, so as long as the packet payload is l= ong enough, the varint parsing will not fail.

I don't think that specifics of programming lang= uages matter here though, and I'm sure both frame formats can be reason= ably implemented in C as well as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us away from the principle that= only reasonable values should be encodable, and that it increases the size= of the ACK frame, for the questionable benefit of being able to parallelis= e the frame parser.

=C2=A0

On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com= > wrote:

2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.= com>:
> At least for my implementation, parsing doesn't become easier, it = becomes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have = to
> introduce an additional check that this didn't overflow the ACK le= ngth (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every = encodable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format. >
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is imp= ractical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>=C2=A0 or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibilit= y
>> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack= frame is
>> > larger,
>> > but I don't think the extra size field is useful for most=
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.= =C2=A0 The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with= one connection, but
>> > that
>> > seems like an academic problem, not one for workloads I'v= e seen.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I a= lso don't see
>> > the
>> > value and it adds complexity.=C2=A0 I read Manasi's email= , but I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my po= int isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler d= ata structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.=C2=A0 That's = the trade-off here.=C2=A0 (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I= 'm certainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.=C2=A0 The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*num_bl= ocks reads to identify
>> >>>> >> length. There are two reads each for =E2= =80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>> >>>> >> delay=E2=80=99 and
>> >>>> >> =E2=80=98ACK block count=E2=80=99. The p= ain point is the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have = the ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll n= eed to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wrote: >> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000= , Deval, Manasi wrote:
>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= eature for the case where ACK processing is split into
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.=C2=A0 In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku

--0000000000007d52fe056f2cbde5-- From nobody Thu Jun 21 13:48:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67F2130E0E for ; Thu, 21 Jun 2018 13:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlSHHe38G3qa for ; Thu, 21 Jun 2018 13:48:02 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690139.outbound.protection.outlook.com [40.107.69.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348F81294D0 for ; Thu, 21 Jun 2018 13:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=81T620yUq3wHnNymCQHui6ylGDgyDwpH5YKIIMOkqK0=; b=VmuYiSiNiP35FqE4JSB1QUdsgGCXSnJj1zJBf8nxTP/tQDvQeWaCfTgOwXqa8hoyYG5qjcDXJizFdaA1PA8gE2wKu4vsMzMbBUdTnnEM+OKWbpHRMRC2FwyE5Y0gOT033gjT3NZYJaNffbmKFLMlIFTu0yB3MoQjZMOfIEwNr7Y= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0933.namprd21.prod.outlook.com (52.132.131.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.3; Thu, 21 Jun 2018 20:48:00 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Thu, 21 Jun 2018 20:48:00 +0000 From: Nick Banks To: "quic@ietf.org" Subject: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3Nw== Date: Thu, 21 Jun 2018 20:48:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-21T20:47:57.8082397Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:0:e04f:689c:e707:26ee] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0933; 7:GiN2DnwYgkM9QQtQjJvUF3UtgBm8xeHC2gCQO7zS7FttUiRh1O2fsIZlYWtLVPuPxAo/Z+FpZDA7EdPebJWCETi2vN8+yGICjir/YlZV0+Gq+8626b4YjaqOMxivJzUB/oKsoZwGAOdPrpc/Lkvw5r2BGdjgBkChRgOpI2VjHSbS+9p2skZvfe4lqdXhD1ME+Z6DzOpLOuJBbZ6l/p+qHtvg3bzdL7Zrg86grsr+QAz9BVDKzFVAzuBBC2xpx3nx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7a6136d6-62dc-4c0a-00c5-08d5d7b846bc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989088)(4534165)(4627221)(201703031133081)(201702281549075)(8990095)(5600026)(711020)(48565401081)(2017052603328)(49563074)(7193020); SRVR:DM5PR2101MB0933; x-ms-traffictypediagnostic: DM5PR2101MB0933: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0933; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0933; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39860400002)(346002)(39380400002)(189003)(199004)(14454004)(10290500003)(3280700002)(2906002)(46003)(97736004)(790700001)(6116002)(316002)(5630700001)(33656002)(99286004)(106356001)(22452003)(6306002)(3660700001)(6506007)(54896002)(102836004)(55016002)(9686003)(54556002)(186003)(7696005)(6436002)(478600001)(6916009)(733005)(5660300001)(5640700003)(74316002)(10090500001)(25786009)(561924002)(8990500004)(99936001)(1730700003)(3480700004)(8936002)(68736007)(86362001)(53936002)(86612001)(7736002)(105586002)(81156014)(81166006)(476003)(486006)(8676002)(5890100001)(2351001)(2501003)(5250100002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0933; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1g0R8eybz4dhGbjNKuDs94s6TjE1jIZGwEP/2F2AJ5ellzIwhZRz5+XjlHeSreva8Vcch7GwH1lKK9/KuGVBby7/bnrvmqvqqAa/qztZOc66aD19BmsDyXzSpeiNBcmBIG6TfnXYlMqi5ul2kcw95rOtCmwo9vNCSGXitM+oc5B6sTW2naAfQf0JHMg+hUnIJArNrsHOKkX5FxDZSASi2/MLdoxAEnjKjVvnGx7Z4ClgmM8RXX1/bst+ETfpFl7adyp57YLNARAw9MkalOwTEI0tJvhAIAp1X1qFvE0FiI8B/UQO1T8LQsX4o2HiqBfFpGIIkiaNn0JboukfPe6fow== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_006_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a6136d6-62dc-4c0a-00c5-08d5d7b846bc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 20:48:00.1872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0933 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:48:05 -0000 --_006_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: multipart/related; boundary="_005_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_"; type="multipart/alternative" --_005_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_" --_000_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): [cid:image003.png@01D40966.7655B6B0] Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick --_000_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.=

 

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

 

 

Time (ms)<= /span>

Rate (Mbps)

Bytes

NO PNE

PNE=

PNE Overhead

No PNE

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 

--_000_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_-- --_005_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=29298; creation-date="Thu, 21 Jun 2018 20:47:59 GMT"; modification-date="Thu, 21 Jun 2018 20:47:59 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --_005_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_-- --_006_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="bcrypt_perf.xlsx" Content-Description: bcrypt_perf.xlsx Content-Disposition: attachment; filename="bcrypt_perf.xlsx"; size=30079; creation-date="Thu, 21 Jun 2018 20:42:36 GMT"; modification-date="Thu, 21 Jun 2018 20:42:25 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCsOXjt5AEAAFEKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE lstu2zAQRfcF8g8Ct4FFJwWKorCcRR7LNEDSD2DIsUWYIgkOndh/3xEtB0XhWE8gG8u2NPfcuaRI Lm52lcneIKB2tmBX+ZxlYKVT2q4L9uflYfaTZRiFVcI4CwXbA7Kb5cW3xcveA2ZUbbFgZYz+F+co S6gE5s6DpTsrFyoR6WdYcy/kRqyBX8/nP7h0NoKNs1hrsOXiDlZia2J2v6O/D05etWXZ7eG5GlUw 4b3RUkQyyt+s+g8yc6uVlqCc3FYknaMPIBSWALEyuQ+aiOEZYqTGkPGTzAAG+0GbrnKqTMaw1B4v qfVPCPWdz7tq6n7TcAStIHsSIT6KinrnO8PfXdi8OrfJz4v0jSZFlFdC26PvM/z0MPJ0uZrYSN1f Em7xEWmOAU+f4y0kmRYgxr0BnDr2JNpGLkUA9Rxp9q4nN/CvdosPFcR7bYE3X8bn3gi1cCV5jMjT ZTImLQdJsBs7DX4XdoXNEnRQT3Ud23PGBRzAkKmwnkg9crwePZGbsRuQYxf22BwHMAbl+P0Lc+zC HpvjAEb3HIWRtyVtORMvqvKoe+59oCPCU3CelhUXoL+B45ZfV888CUGIGj42/VOb5weRjjCjO4b6 jKRA9WXLLUZXjcYfZE7AeToQLv8CAAD//wMAUEsDBBQABgAIAAAAIQATXr5lAgEAAN8CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAArJJNSwMxEIbvgv8hzL072yoi0mwvRehNZP0BMZn9YDeZkKS6/fdG QXShth56nK93nnmZ9Wayo3ijEHt2EpZFCYKcZtO7VsJL/bi4BxGTckaN7EjCgSJsquur9TONKuWh 2PU+iqziooQuJf+AGHVHVsWCPblcaThYlXIYWvRKD6olXJXlHYbfGlDNNMXOSAg7cwOiPvi8+bw2 N02vact6b8mlIyuQpkTOkFn4kNlC6vM1olahpSTBsH7K6YjK+yJjAx4nWv2f6O9r0VJSRiWFmgOd 5vnsOAW0vKRFcxN/3JlGfOcwvDIPp1huL8mi9zGxPWPOV883Es7esvoAAAD//wMAUEsDBBQABgAI AAAAIQCSB5TsBAEAAD8DAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHMgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskstqxDAMRfeF/oPRvnEyfVCGcWbRUphtm36AcJQ4 TGIHW33k72tSOsnAkG6yMUjC9x6Ju9t/d634JB8aZxVkSQqCrHZlY2sF78XLzSOIwGhLbJ0lBQMF 2OfXV7tXapHjp2CaPoioYoMCw9xvpQzaUIchcT3ZOKmc75Bj6WvZoz5iTXKTpg/SzzUgP9MUh1KB P5S3IIqhj87/a7uqajQ9O/3RkeULFjLw0MYFRIG+JlbwWyeREeRl+82a9hzPQpP7WMrxzZYYsjUZ vpw/BkPEE8epFeQ4WYS5XxNGY6ufDDZ2gjm1li5yt2ooDHoq39jHzM+zMW//wciz2Oc/AAAA//8D AFBLAwQUAAYACAAAACEASe3kcEEDAACtBwAADwAAAHhsL3dvcmtib29rLnhtbKxVXW+jOBR9X2n/ A+KdYvMNajpKINFWmllVnc7MS6WRA6ZYAczapklVzX/faxPSdjoP3c5GiY1tOJxz77k35x8OXWvd UyEZ7xc2PkO2RfuSV6y/W9hfbjZOYltSkb4iLe/pwn6g0v5w8ecf53sudlvOdxYA9HJhN0oNmevK sqEdkWd8oD2c1Fx0RMFS3LlyEJRUsqFUda3rIRS5HWG9PSFk4i0YvK5ZSQtejh3t1QQiaEsU0JcN G+SM1pVvgeuI2I2DU/JuAIgta5l6MKC21ZXZ5V3PBdm2IPuAQ+sg4BvBDyMYvPlNcPTqVR0rBZe8 VmcA7U6kX+nHyMX4RQgOr2PwNqTAFfSe6RyeWInonayiE1b0BIbRb6NhsJbxSgbBeydaeOLm2Rfn NWvp18m6FhmGv0mnM9XaVkukWldM0Wphx7Dke/piQ4zDamQtnHrI8xLbvTjZ+UpYFa3J2KobMPIM D5URRakX6jvBGMtWUdETRXPeK/DhUdfves5g5w0Hh1vX9J+RCQqFBf4CrTCSMiNbeUVUY42iXdh5 dvtFgvzbnm1Jv5O3c1nI22feJK8L4T+4k5RasguaJ17T9c/6gZ7IZgdeKWHB9WXxEbLwmdxDTiDz 1bFkLyHo2P/elyLD3x83cbxCqYecuECxE3hJ6KRLb+2E2M89VGAfF5sfIEZEWcnJqJpjujX0wvaD Xxx9Iof5BKNsZNUTjUd0/Dh6/mmYz35owbqxfWV0L5+MoZfW4RvrK743ih6eXe/N9jdWqQbkoSgK bWva+4uyuwa4pqHxv/A0pYX9GIUeDoogd/wQhkDHYIkS3/FTlG+WSeKneWCouM+4mN4JnMxs9cbv n3U/xdCk9Wyia1si0+8QlxU22ZsfK0lbgr/1ZG6MU4RjfQc9qI9SmRmsxYAeDtAyRmngoLUfOkGS ek4S+J6TB4W3DuN1sV6FOjG692f/Rwc0Ds/mPxXNsiFC3QhS7uCv6JrWKyLBSZMg4Puc7CpMVsgH isEGb5wAp8hZraLACYuNH8a4yNehcdFEVsuv39l/Etc8TYkaoTZ1WZp1psfNcfe0WU8bxzy9KLrs ujCZ+eXjrpGnR5MUdw7Kxb8AAAD//wMAUEsDBBQABgAIAAAAIQAeLy7w7AAAABkCAAAUAAAAeGwv c2hhcmVkU3RyaW5ncy54bWx00c1OwzAMAOA7Eu8Q5TQOLG0H25jSTALBjW5C4wFC662RmqTULmJv T9AuqDJHf/6RZevtt+/EFwzoYihlPs+kgFDHxoVTKd8PL7drKZBsaGwXA5TyDCi35vpKI5JIvQFL 2RL1G6WwbsFbnMceQsoc4+AtpXA4KewHsA22AOQ7VWTZUnnrghR1HAOVclFIMQb3OcLTBfKVNBqd 0WQezwSoFRmtfuGCB+ch57DgcMHhHYf3HC45XHG45vCBXT6barUT++p5qgxV8Z9CsUuPbNOhp0Pe LIGYvX70eMPtImb+b0Kl15ofAAAA//8DAFBLAwQUAAYACAAAACEA6r9mRkQNAACnNAAAGAAAAHhs L3dvcmtzaGVldHMvc2hlZXQxLnhtbJxb224juRF9D5B/EPS0G8BU894t2F6MdZd2F0E2l2eN3B4L K1mOpLklyL/nsLtJdrObsrXGzHhsHhbJOsViVZG6/enbftf7kh9P28PLXZ+SpN/LXzaHx+3Lp7v+ P/4+vUn7vdN5/fK43h1e8rv+9/zU/+n+z3+6/Xo4/n56zvNzDxJeTnf95/P5dTgYnDbP+X59IofX /AUtT4fjfn3Gj8dPg9PrMV8/Fp32uwFLEjXYr7cv/VLC8PgeGYenp+0mHx82n/f5y7kUcsx36zPm f3revp6stP3mPeL26+Pvn19vNof9K0R83O625++F0H5vvxkuPr0cjuuPO6z7GxXrTe/bEX8Y/nI7 TPH71kj77eZ4OB2ezgSSB+Wc28vPBtlgvXGS2ut/lxgqBsf8y9YQ6EWxPzYlKp0s5oXxPyhMOWFG Xcfh5+3jXf+/PBlRMabjmweV0BtB04ebdDzWNyM60uwh1XL8Yfy//v3t4xYMm1X1jvnTXf8DHf7M WX9wf1sY0D+3+ddT7f+98/rjb/ku35xzDEL7vf8cDvvfNutd/quxwB1+l8C2jdV+PBx+N90XACYY 6FR0MwOtN+ftl3yU7wD/wDDp07/LsRkfzsvBB270+1v/fzuTaWHtfz32HvOn9efd+W+Hr/N8++n5 jOEldGCMaPj4fZyfNrBeDE+YNEvaHHYQgX97+63ZhrC+9bfi+9ft4/n5rp8RKhIFMDbjd2OPtOpW dsDviw74bjv0e5vPp/Nh/69SQBOvKzy+V/iUsFRSWQxxoSO8QTEQvruOUiecmqm1+w3KhRU6G6/P 6/vb4+FrD4aOFZ5e18Zt0CE1ptapGajEgD8YdNEHKjuBsS/3lN4OvoCBDf5CpJMLUQ25ZbdyYiU5 hZzLwxkhzeESN1oxoYc2ws+nQIzaCNaUMW4jeBMxaSNEEzFtI2QTMWsjVBMxbyN0E7FoI9ImYtlG ZE3EqkNjXqkNCs22e79pGLThyhhFoJ0HXvyW84QRqXVivwIiRhVMUkVUlmT2K1jj2EpjlGRaOFiw 0EkJYyzjRAkVg00tLM0IxnRzC8xo5qQlRGYeFixh7qQJonR0CYsKxqkkWvLY3JYWliREq+hKV25u GnrzX15vDVrFVbQatKWVBhb7IApeGaWayARuvfoKebUwlhGesiivTlpKskzFmJg4GCNa0yivDqaI VFEVzywMpimSkE3XmBKZBht64VbFCWwsyqGDCUIzHYOtLIynoNrryBt1g0Nz/Lx/axq05VCFe1OW HLJEEZ6lMa2PLAwWS1kaW8bYSZPYdF4pwRaeOBglikeVMnWwhKhUxOxr5mCcpDo66NwtgZKURglb OJgA6YF7rdpolpI0bskrNyFGVOJ16s2rQaa6ikyDtmQyGe5IVbKps8I3RnekhcmUBGfd2DZphSUG 56BtS8EHRdpQfQW+cupEcEJDnzGrychElPq5g/FLTn7hYIykskvTRRCwdDCYZRK13pWDUcJqsIgj Rcx2xSY0aLcJkzCO0eW5qTKzb/zuCugdWVgK20yCA2/sGo19Rx3jpIJprohIo0fU1EpTGQJS7rgO 3MfMwrRGYBzY0tytSpGstuMCs1rYGSWIfYNFLRtt3uSCaawsjMEOmFdghDmTSr/ffRq0OwKhiCAE TQvqFOUJTNDrM4jdRhYmEUBwb4JhcGNhQhAeN+iJg2kkLv64CAad1qSlCeKW6iswq1ltCaAptq/n FqbNSj0s4GLxvpUuLSwF60zGDGxlYZnC+en15pfQ8KXZVcwatGMWxhUwm5XMCg0vmfrwJrDykYXB mSod1d7YSUMwx6KH2cTCFKIgBK+RIHjqYDhBqXd84fZ0MMSjIqrkeQWTiQCz3k7CjWqlZZpkNZ8Q hE1LB8tIGihrZUdiknDug7zI0UhRKbgmPTVwRyjWGxAKcSY90SkONx53kSOHgzsONDq2bVmCuI/5 /R6EhxOPg0uXgYqmrhUOS4Wpou+KUxw7zX0FCaPDUUEy6c/SYHsv/HIUYdSnCAFuWeHSRGmcIEHe 6AYTyM5El/02NqKpJVzDXEdaGrOJ6/JSahPTnqtZtMyiDQmrCB1SwjJCBySsI3RAwkJCB6RlHu3p hqWEDilhLaEDEka7HZCwmtABoYF6f3YY1NeaNnJdKkrruWiYxqDRbG2eSEok8/FKi0iLgxmLeJY5 9vJwEF+IphxOUAS7cX9dl5dJH8gEVjTz8iQC32icMPfyuMlvY2f2wuE4ErdapNDi2uqFoYiAQmIk l195eQnCx9gWvS4/NRXZeJEBrYZZlhqvlHTFdmWhz+MkkSjSRrKTscNJaC5Q/8Q3UqJFtAgx9bjs 0mAzj9NEsAuu3C5SoAyVevUH5rtw8hiipiQaRSwdTiSE13Atr+7GVUSnXett7tjrclVaT1ZblQe0 FsRmMDmUkKLJqsfhNA7c2Ng34gyMK27icDgrFW15XTcVZLYtf+saGbZQPGV1QyQoh8XLnAs/FXDN faLW2pJ2XJoSQYNZreoLYjS2ERs5Kqr3b5T360lqu7hAyyyLS9T7NPXRZMvHOpxJMaPGPHbykPhp HQ07Jx4nYKQ+5AoOo2l9fjIwlJltFCiNKBa0zl1XbpxCvDjkp4K6RMjJ0o+BQItFa84rj8O9UyRH pY0k9W3q6lkq9nEY+ZZplBQStil9LhNshBFGNXtSCo2oNZ5XjB1OImO4dDxaecqU8KK2PnXyGCob 8fR45sfFcVsrV4aVB4fjphAWHXfhx8XxmHl/Guhl6XDC3CZ4EwwCr5XHIcvrNNWmP23kq2+T3EhY 26UIWmVXGWo7rWrMyLWmWGutxhysYexwuGAJ2ia+DbX8mo9rOVQ7E4k8r7UVbaNiqF6ESY1tFKjI s2jWvfAzgeOPF5eWDgevjBqIO2XCxNTjUOz3M25eajbS0TfpYo10tF1fQHuRjjIYKavVQsOqn8OZ mFVGa3FjjxNE8KiRTjyOosgULeRMHQ4XN6q2icLykV8H0mrhN1vrgtOuF7UNmUWpWNT1IhMflASU LT0OtZLWAelbQfzbpQbWuAl/m1t7FV5cgrdLDRBnWnD6cQSSrUvpqlWhqsVrNwRhSddKURluj2rM h2GrH82UYX2IEpYdPA4lrTjzM4/DQVZjKljH3M8PlhTWAV2jqbbUYt9AyNLjEvil8Lraakqj3OIN oLktGxWBt6h7KN6TBK8YWibdURLwnqo5eiOLdS8krn3qYJPbeJmCtSG11xfVa4cOTMtYOjBh3bBr rPCM7cJE4tDivYyruL+9ueoJYZjpQ9b97VOhpuf1MX/sl8+SHpgcPuBpUO+0LV4T/bL49YcHPlzx H28HT0WewXBrcuFSfhQRjN8PR1YwrLEQTMUQqbAVjYcNF7PmSbH+uz4zM7//ARJvMN0fB/inmhyy NNTxE4EyM6aIg1UH2p6Vs7tP//KByb/YY3HwA0QUP9mpIPElCe67kfRhVgj3Wk64UF9LDubUlJMg AEQBOs3g20x9Pmb9jYzwbWbrGWHrPQEzGU+D2pJMFI5QAKBdd/Sj7j7FKytTNLicJ0/Q25QeCmJa JoXW4cQyDwiIUyBOGeKg1sKqQJyQ0A8uxTFBAW2F735aaypess0ge2Zl4wGH4VU1eC1/srzi2hI3 W1ogq6BCovISxk1tPRTjzDGOeTFXbAvUeMJxsKQG71gMrr1FIpjmkmGcyEULuy6zLODRNwhovcT7 5dv2UXdvawHZ5Wx8Us2sZQHG8opXjl/uzebEVYxmGopPOOMqfB3UPQVungbCCDmMEJzhuhsqTcNA Zd7dWZSdqUbmlFHsaJqiXKmT2Hu769JFVk8X25k+mi8QotvPBkbdPSoSuMgaiW5xVk2qOVzWPFOS Q214EIRsCklLS/OdM600j+2C9FRxOEWO3E6Fcdi8e9aV6qWpOJqrOp0JwbEVIo9x2HVJXAGPvwRA c1z1Ql2+jh91965okEYdF7LrSTW1y4xQRfHqLsX74CQTmQwv/WfdU6gYgQ/XqHqha4K1IENuubHO 5VeMpKkwd6wpw2MzQZEYRBjh1+VpBfzCDT/a45QUF/8Xbs1H3b0rSvDO8WJaOqnm9gYlTOGaEO+t 0gxFEZzZwRnUPQVLCe5MsDtBJ3x+wjIR1CHn3b2tf6IyRSkmwfGH0jxLa2+Gmo9Jr0uveCO9aqfO aL9Aibh8FT/q7l1RouHqL6W7k2pub1BCM/gtqhnehcDYw2iuewaWEQGfBc+T4CCG30GqHNRIuntb RjjDgwVFcVbg2ELhOFJgLIKC98fkBfzC3Tra44y8eePe3btiBH64nRmWgVlH6NY4uBEo4xKNw/3D Z2g80wx3RuesHQ848onG9hBaCzzWDavG3bN2POBlI8rAiOvx3kDy1vFRfmqhfI3/uv6U/7I+ftq+ nHq7/Kn4RAIirGP5kQXUEvu98+HVfE5BIzf6eDjjAwX2p2d8lifH63yEKf3e0+Fwtj8g+jByf8vP n197h+MWn3QoPp5z1389HM/H9faMEYbmsyDHxWOh68fj+is+cOR/W0RAA/cRo/v/AwAA//8DAFBL AwQUAAYACAAAACEAGPmCiBwDAAB4CAAADQAAAHhsL3N0eWxlcy54bWy8Vk1v2zgQvRfY/0DwrlCS Ldc2JBV1HAEFuosASYFeaYlyiPJDoOis3GL/+w4pyVLapu1msXuJOaOZ4bz3hmTSN50U6JGZlmuV 4egqxIipUldcHTP84b4I1hi1lqqKCq1Yhs+sxW/y316lrT0LdvfAmEVQQrUZfrC22RLSlg9M0vZK N0zBl1obSS2Y5kjaxjBatS5JChKH4YpIyhXuK2xl+StFJDWfTk1QatlQyw9ccHv2tTCS5fbdUWlD DwJa7aIlLVEXrUyMOjNu4r3f7CN5aXSra3sFdYmua16yb9vdkA2h5VQJKr+sUpSQMH6CvTMvrLQk hj1yJx/O01or26JSn5TN8AIadRRsPyn9pyrcJ1B4iMrT9jN6pAI8ESZ5WmqhDbIgHTDnPYpK1kdc U8EPhruwmkouzr07dg6v9hAnOXDvnMT10Xfz/+1zcN3855g8tBawcSEuTMeOVHDkKYykZUYVYKBh fX9ugFIFp6enxsf9JPpo6DmKk1kC8Rvm6UGbCk7rqLGTs3flqWC1BQ4MPz64X6sb+HvQ1sJE52nF 6VErKpw8Y8awADglE+LOneiP9RNUXY3USRbSvqsyDHeDE3ZcApBh2dfrDaj/JGkzJUWw/H4Sok0j zm5E/S69BaGTtfO4J/ut4Ecl2Tzh1mjLSusvstBTN0fVY5zBWwB1/xwe6urv45yREz+Pc8yeA/an 7TnOXNlnOOtrAakz8nwt4nAD0pmsT0S90ILcGc/wH+6KFnBbDNDQ4cSF5eoC9OuEW2ZKoH7MgBZm Gf3UXlKgi6qbhsoLY90F7cft0hfgrFhNT8LeXz5meFr/zip+ksDsEHXLH7X1JTI8rd+72Y9WTnzW 2fctXELwi06GZ/jLze71Zn9TxME63K2D5YIlwSbZ7YNkeb3b74tNGIfXf82eiX/xSPhXDcYrWm5b AU+JGcAOzd9NvgzPjL59P7rQ9rz3TbwK3yZRGBSLMAqWK7oO1qtFEhRJFO9Xy91NUiSz3pMXPiYh iaL+WXLNJ1vLJRNcjVqNCs29IBKYPwBBRiXI9C9D/jcAAAD//wMAUEsDBBQABgAIAAAAIQDBFxC+ TgcAAMYgAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZzYsbNxS/F/o/DHN3/DXjjyXe4M9sk90k ZJ2UHLW27FFWMzKSvBsTAiU59VIopKWXQm89lNJAAw299I8JJLTpH9EnzdgjreUkm2xKWnYNi0f+ vaen955+evN08dK9mHpHmAvCkpZfvlDyPZyM2Jgk05Z/azgoNHxPSJSMEWUJbvkLLPxL259+chFt yQjH2AP5RGyhlh9JOdsqFsUIhpG4wGY4gd8mjMdIwiOfFsccHYPemBYrpVKtGCOS+F6CYlB7fTIh I+wNlUp/e6m8T+ExkUINjCjfV6qxJaGx48OyQoiF6FLuHSHa8mGeMTse4nvS9ygSEn5o+SX95xe3 LxbRViZE5QZZQ26g/zK5TGB8WNFz8unBatIgCINae6VfA6hcx/Xr/Vq/ttKnAWg0gpWmttg665Vu kGENUPrVobtX71XLFt7QX12zuR2qj4XXoFR/sIYfDLrgRQuvQSk+XMOHnWanZ+vXoBRfW8PXS+1e ULf0a1BESXK4hi6FtWp3udoVZMLojhPeDINBvZIpz1GQDavsUlNMWCI35VqM7jI+AIACUiRJ4snF DE/QCLK4iyg54MTbJdMIEm+GEiZguFQpDUpV+K8+gf6mI4q2MDKklV1giVgbUvZ4YsTJTLb8K6DV NyAvnj17/vDp84e/PX/06PnDX7K5tSpLbgclU1Pu1Y9f//39F95fv/7w6vE36dQn8cLEv/z5y5e/ //E69bDi3BUvvn3y8umTF9999edPjx3a2xwdmPAhibHwruFj7yaLYYEO+/EBP53EMELEkkAR6Hao 7svIAl5bIOrCdbDtwtscWMYFvDy/a9m6H/G5JI6Zr0axBdxjjHYYdzrgqprL8PBwnkzdk/O5ibuJ 0JFr7i5KrAD35zOgV+JS2Y2wZeYNihKJpjjB0lO/sUOMHau7Q4jl1z0y4kywifTuEK+DiNMlQ3Jg JVIutENiiMvCZSCE2vLN3m2vw6hr1T18ZCNhWyDqMH6IqeXGy2guUexSOUQxNR2+i2TkMnJ/wUcm ri8kRHqKKfP6YyyES+Y6h/UaQb8KDOMO+x5dxDaSS3Lo0rmLGDORPXbYjVA8c9pMksjEfiYOIUWR d4NJF3yP2TtEPUMcULIx3LcJtsL9ZiK4BeRqmpQniPplzh2xvIyZvR8XdIKwi2XaPLbYtc2JMzs6 86mV2rsYU3SMxhh7tz5zWNBhM8vnudFXImCVHexKrCvIzlX1nGABZZKqa9YpcpcIK2X38ZRtsGdv cYJ4FiiJEd+k+RpE3UpdOOWcVHqdjg5N4DUC5R/ki9Mp1wXoMJK7v0nrjQhZZ5d6Fu58XXArfm+z x2Bf3j3tvgQZfGoZIPa39s0QUWuCPGGGCAoMF92CiBX+XESdq1ps7pSb2Js2DwMURla9E5PkjcXP ibIn/HfKHncBcwYFj1vx+5Q6myhl50SBswn3Hyxremie3MBwkqxz1nlVc17V+P/7qmbTXj6vZc5r mfNaxvX29UFqmbx8gcom7/Lonk+8seUzIZTuywXFu0J3fQS80YwHMKjbUbonuWoBziL4mjWYLNyU Iy3jcSY/JzLaj9AMWkNl3cCcikz1VHgzJqBjpId1KxWf0K37TvN4j43TTme5rLqaqQsFkvl4KVyN Q5dKpuhaPe/erdTrfuhUd1mXBijZ0xhhTGYbUXUYUV8OQhReZ4Re2ZlY0XRY0VDql6FaRnHlCjBt FRV45fbgRb3lh0HaQYZmHJTnYxWntJm8jK4KzplGepMzqZkBUGIvMyCPdFPZunF5anVpqr1FpC0j jHSzjTDSMIIX4Sw7zZb7Wca6mYfUMk+5YrkbcjPqjQ8Ra0UiJ7iBJiZT0MQ7bvm1agi3KiM0a/kT 6BjD13gGuSPUWxeiU7h2GUmebvh3YZYZF7KHRJQ6XJNOygYxkZh7lMQtXy1/lQ000RyibStXgBA+ WuOaQCsfm3EQdDvIeDLBI2mG3RhRnk4fgeFTrnD+qsXfHawk2RzCvR+Nj70DOuc3EaRYWC8rB46J gIuDcurNMYGbsBWR5fl34mDKaNe8itI5lI4jOotQdqKYZJ7CNYmuzNFPKx8YT9mawaHrLjyYqgP2 vU/dNx/VynMGaeZnpsUq6tR0k+mHO+QNq/JD1LIqpW79Ti1yrmsuuQ4S1XlKvOHUfYsDwTAtn8wy TVm8TsOKs7NR27QzLAgMT9Q2+G11Rjg98a4nP8idzFp1QCzrSp34+srcvNVmB3eBPHpwfzinUuhQ Qm+XIyj60hvIlDZgi9yTWY0I37w5Jy3/filsB91K2C2UGmG/EFSDUqERtquFdhhWy/2wXOp1Kg/g YJFRXA7T6/oBXGHQRXZpr8fXLu7j5S3NhRGLi0xfzBe14frivlzZfHHvESCd+7XKoFltdmqFZrU9 KAS9TqPQ7NY6hV6tW+8Net2w0Rw88L0jDQ7a1W5Q6zcKtXK3WwhqJWV+o1moB5VKO6i3G/2g/SAr Y2DlKX1kvgD3aru2/wEAAP//AwBQSwMEFAAGAAgAAAAhADkxtZHbAAAA0AEAACMAAAB4bC93b3Jr c2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc6yRzWrDMAyA74O+g9G9dtLDGKNOL2PQ69o9gGcr iVkiG0tb17efdygspbDLbvpBnz6h7e5rntQnFo6JLLS6AYXkU4g0WHg9Pq8fQLE4Cm5KhBbOyLDr VnfbF5yc1CEeY2ZVKcQWRpH8aAz7EWfHOmWk2ulTmZ3UtAwmO//uBjSbprk35TcDugVT7YOFsg8b UMdzrpv/Zqe+jx6fkv+YkeTGChOKO9XLKtKVAcWC1pcaX4JWV2Uwt23a/7TJJZJgOaBIleKF1VXP XOWtfov0I2kWf+i+AQAA//8DAFBLAwQUAAYACAAAACEAgcVevcoAAAA1AgAAIwAAAHhsL2RyYXdp bmdzL19yZWxzL2RyYXdpbmcxLnhtbC5yZWxzvJHPCsIwDIfvgu9QcrfdJoiI3S4ieBV9gNBlf3Br S1NF396CCAqiN08hCfl+H2RdXcdBXChw76yGXGYgyBpX97bVcDxsZ0sQHNHWODhLGm7EUJXTyXpP A8Z0xF3vWSSKZQ1djH6lFJuORmTpPNm0aVwYMaY2tMqjOWFLqsiyhQqvDCjfmGJXawi7eg7icPMp +TfbNU1vaOPMeSQbP0Qo02GICYihpahByseEH2Uukyyozx7F/zyKbx75/zzyp4d6e3Z5BwAA//8D AFBLAwQUAAYACAAAACEAgBvcgdIAAACPAQAAHwAAAHhsL2NoYXJ0cy9fcmVscy9jaGFydDEueG1s LnJlbHOskMFKxDAQhu+C7xDmbtPsQUQ23YMg7FXXBwjptA2bZMJMEPv2phexi0ePM8P/fT9zPH2l qD6RJVC2YLoeFGZPY8izhY/L68MTKKkujy5SRgsrCpyG+7vjG0ZXW0iWUEQ1ShYLS63lWWvxCyYn HRXM7TIRJ1fbyLMuzl/djPrQ94+afzNg2DHVebTA5/EA6rKWZr5hp+CZhKbaeUqapin4jWrMnqr9 4ri+UCR+r2vERnM8Y7Xgt52YrhUE/bfb/If7Ritbix+r3r1x+AYAAP//AwBQSwMEFAAGAAgAAAAh ABHKeiHTAAAAjwEAAB8AAAB4bC9jaGFydHMvX3JlbHMvY2hhcnQyLnhtbC5yZWxzrJCxasQwDIb3 Qt/BaG+cZCilnHNDoXBre30A4SiJOdsyljkub19nKc3RsaMk/u/70eF4C15dKYvjaKBrWlAULY8u zga+zu9PL6CkYBzRcyQDKwkch8eHwwd5LDUki0uiKiWKgaWU9Kq12IUCSsOJYr1MnAOWOuZZJ7QX nEn3bfus828GDDumOo0G8mnsQZ3XVM137OBsZuGpNJaD5mlydqN23Z6q7YK5vLHn/FlWT5WGeaZi wG476ZtaEPTf7u4/3Hda2Vr8WPXujcM3AAAA//8DAFBLAwQUAAYACAAAACEAoXjI99MAAACPAQAA HwAAAHhsL2NoYXJ0cy9fcmVscy9jaGFydDMueG1sLnJlbHOskMFqwzAMhu+DvYPRvVHSwhijTg+D Qa9d9wDGURIz2zKWGc3bz7mMpey4oyT+7/vR8XQLXn1RFsdRQ9e0oChaHlycNHxc33bPoKSYOBjP kTQsJHDqHx+OF/Km1JDMLomqlCga5lLSC6LYmYKRhhPFehk5B1PqmCdMxn6aiXDftk+YfzOg3zDV edCQz8Me1HVJ1XzHDs5mFh5LYzkgj6OzK7XrtlS0s8nllT3n97J4qjSTJyoa7LqTQ1MLAv7t7v7D faeVtcWPFTdv7L8BAAD//wMAUEsDBBQABgAIAAAAIQCevHWlnQQAANomAAAUAAAAeGwvY2hhcnRz L3N0eWxlMy54bWzsWm1v4jgQ/iuWf0ADdOm2VVOp12qlk+httbfSfTaJA7517JxtltJff2Pnhby2 cAQKe/2GJ8HxPDN+Zjzjm0BfB3OizJ9mxSl6jrkAgfbx3Jjk2vN0MKcx0WcxC5TUMjJngYw9GUUs oF6oyJKJmTcaDEfeehacTUMas8iECvhEJFVMjD6TapbPEXOYZXDhxYQJjFjo49GnAb69geWRZ6a/ M8OpG3HxjUbwwrOPB9hzoohx3hDSKKKBab4rxVoYMyEVfIRcOzXpPVfoJ+E+Ns9DJ+aL+FGGqexi PBi4L5JrEH+NolR8nou90iy3Nx4sPEq/5dYY0ujbk0L6xcdDOw/6QZWA36C01cK+XtUzIIbOpFrd gfanrLhOnpRFmAu09PHVeDTGKCCJjyNODPyME7C1FjOMCJ8BIoHJLCI5C7+AZTc0z6jdPJ87zAPG Kn9AyYUIrR3sQlNzpAsHu5RMd9VuuYat3F64U5SgWIawmQjncvmHtOp8/UmVYiEFdZ1swgTNZam/ H8zDM78ru2lurQo4tc0xnQ2dy9Yg3LeBh+0GvuzVwF17szBoupmJIRMypeCb4B/vxkiFb1cZqdgJ GzNSh1uHFTWL0b313IU5nO7hj77ZeBM356bDzR0hvcJObcvdhZ225yRwyqkMVxBvlDQ2TiKdBF+Y 0mZCtHkiCiLzECNgImOpJwIiAuLlLMFoLtVLXWbfg1AOTzBaKsvd+p8FURQj/rsAdju/GH++wMi4 wfBydHmJkSo/mZafEBHAVCnRo3Rwb2Cc2lgndwsDRGkyckr1SBm51QOt8EkysZk/2o8AOtomO0W0 J/DFPAhnuYR7a+cUok6wNspX11uMzh822k9HtP5sxYUGNpA1dXgDbsedzSTO7TwAq3cLWNtXEpLh 1WAM+8NlJEqEaTL4yuZO5uA2beGvM4OoGL0AqYDtkShIBfsD7j39u4GuS/fe4ssOSBu0VwGyBFsN yglZQXRCehVPJaTyAVMBB6rS7IX6eJwdGYr//MUUjRSJe3Pd/FCyk+vaEPJKdtZItQ7guVWgLH7f yfS0z2Q5EwiXmAPe+z+lHCSJfSWdW9sslEvxG2khnn2eqf/jiaMto9oy+T3wYWXLYsGmp1FHgSXD hUom7XH3nay470NgUW2pHnkKuGtHnq1wLWMJZ3Spjml77BvYPTpsBUs4a8jjIZ0K81v+LwSt2cd6 8TMo4XBIeB/J30ekzomWYCyrNQEtJLZIe9hCyzapV89lzPYi19WORa4KwgWeczaR/6voYVFsKeEX 4h2iRxVLSkKqPgKzj/sIzLyGJp1REf4ivaCOVJ2vdUy4NCfXSbB8ky/cWSofnD+cVEekrEdW79JU MapPvSv3dk+rpmc6/KC0fiithqb5lbrbn2yPdOq6DqUet+1AONmUaGoz56x9b3fYWn2jgNrt077q ob1U4+xtgDdTwt4KyQm0aR6InqfXC/RKP0iTFZyrrWkHXQWwAr4jaE72dl2iI0S26LpITqWg1dlb 3O8diT0e8tfYwwWaBf24tbLZpaL3vLVSNdQSuvpHc8resi6Trt3y4foS2u2/AAAA//8DAFBLAwQU AAYACAAAACEAHBSnqP0AAABuAwAAFQAAAHhsL2NoYXJ0cy9jb2xvcnMzLnhtbKSTQW7CMBBFrxL5 AHESIK0iwqbrigUnGE1sYsn2INulcHucUGhDIRLBO/vrv/l/JC/RV0ia3CYctUgORtv44GvWhrCr OPfYCgM+NQodeZIhRTKcpFQoeOPgW9ktL7K84NiCCz2F/WDgH4V2wsYRkpyB4FNy2wvD6EjJSm5A WZYYEdqa4RG1YIlqapZnbLWEqk8jPrRL9qBrBojChpzxh1oxos1GtPmIthjRyk6LK92DUxAU2Ztr F1R/mU9qzg3KLJ7Ow/+ahohbz/vF06PWUp5RcX3TUU+Mv0Yejp9PGL+Y4Hm73372CuqJ9tfIw/aP mnTk3++1OgEAAP//AwBQSwMEFAAGAAgAAAAhABwUp6j9AAAAbgMAABUAAAB4bC9jaGFydHMvY29s b3JzMi54bWykk0FuwjAQRa8S+QBxEiCtIsKm64oFJxhNbGLJ9iDbpXB7nFBoQyESwTv767/5fyQv 0VdImtwmHLVIDkbb+OBr1oawqzj32AoDPjUKHXmSIUUynKRUKHjj4FvZLS+yvODYggs9hf1g4B+F dsLGEZKcgeBTctsLw+hIyUpuQFmWGBHamuERtWCJamqWZ2y1hKpPIz60S/agawaIwoac8YdaMaLN RrT5iLYY0cpOiyvdg1MQFNmbaxdUf5lPas4NyiyezsP/moaIW8/7xdOj1lKeUXF901FPjL9GHo6f Txi/mOB5u99+9grqifbXyMP2j5p05N/vtToBAAD//wMAUEsDBBQABgAIAAAAIQAcFKeo/QAAAG4D AAAVAAAAeGwvY2hhcnRzL2NvbG9yczEueG1spJNBbsIwEEWvEvkAcRIgrSLCpuuKBScYTWxiyfYg 26Vwe5xQaEMhEsE7++u/+X8kL9FXSJrcJhy1SA5G2/jga9aGsKs499gKAz41Ch15kiFFMpykVCh4 4+Bb2S0vsrzg2IILPYX9YOAfhXbCxhGSnIHgU3LbC8PoSMlKbkBZlhgR2prhEbVgiWpqlmdstYSq TyM+tEv2oGsGiMKGnPGHWjGizUa0+Yi2GNHKTosr3YNTEBTZm2sXVH+ZT2rODcosns7D/5qGiFvP +8XTo9ZSnlFxfdNRT4y/Rh6On08Yv5jgebvffvYK6on218jD9o+adOTf77U6AQAA//8DAFBLAwQU AAYACAAAACEAnrx1pZ0EAADaJgAAFAAAAHhsL2NoYXJ0cy9zdHlsZTEueG1s7Fptb+I4EP4rln9A A3TptlVTqddqpZPobbW30n02iQO+deycbZbSX39j54W8tnAECnv9hifB8TwzfmY845tAXwdzosyf ZsUpeo65AIH28dyY5NrzdDCnMdFnMQuU1DIyZ4GMPRlFLKBeqMiSiZk3GgxH3noWnE1DGrPIhAr4 RCRVTIw+k2qWzxFzmGVw4cWECYxY6OPRpwG+vYHlkWemvzPDqRtx8Y1G8MKzjwfYc6KIcd4Q0iii gWm+K8VaGDMhFXyEXDs16T1X6CfhPjbPQyfmi/hRhqnsYjwYuC+SaxB/jaJUfJ6LvdIstzceLDxK v+XWGNLo25NC+sXHQzsP+kGVgN+gtNXCvl7VMyCGzqRa3YH2p6y4Tp6URZgLtPTx1Xg0xiggiY8j Tgz8jBOwtRYzjAifASKBySwiOQu/gGU3NM+o3TyfO8wDxip/QMmFCK0d7EJTc6QLB7uUTHfVbrmG rdxeuFOUoFiGsJkI53L5h7TqfP1JlWIhBXWdbMIEzWWpvx/MwzO/K7tpbq0KOLXNMZ0NncvWINy3 gYftBr7s1cBde7MwaLqZiSETMqXgm+Af78ZIhW9XGanYCRszUodbhxU1i9G99dyFOZzu4Y++2XgT N+emw80dIb3CTm3L3YWdtuckcMqpDFcQb5Q0Nk4inQRfmNJmQrR5Igoi8xAjYCJjqScCIgLi5SzB aC7VS11m34NQDk8wWirL3fqfBVEUI/67AHY7vxh/vsDIuMHwcnR5iZEqP5mWnxARwFQp0aN0cG9g nNpYJ3cLA0RpMnJK9UgZudUDrfBJMrGZP9qPADraJjtFtCfwxTwIZ7mEe2vnFKJOsDbKV9dbjM4f NtpPR7T+bMWFBjaQNXV4A27Hnc0kzu08AKt3C1jbVxKS4dVgDPvDZSRKhGky+MrmTubgNm3hrzOD qBi9AKmA7ZEoSAX7A+49/buBrkv33uLLDkgbtFcBsgRbDcoJWUF0QnoVTyWk8gFTAQeq0uyF+nic HRmK//zFFI0UiXtz3fxQspPr2hDySnbWSLUO4LlVoCx+38n0tM9kORMIl5gD3vs/pRwkiX0lnVvb LJRL8RtpIZ59nqn/44mjLaPaMvk98GFly2LBpqdRR4Elw4VKJu1x952suO9DYFFtqR55CrhrR56t cC1jCWd0qY5pe+wb2D06bAVLOGvI4yGdCvNb/i8ErdnHevEzKOFwSHgfyd9HpM6JlmAsqzUBLSS2 SHvYQss2qVfPZcz2ItfVjkWuCsIFnnM2kf+r6GFRbCnhF+IdokcVS0pCqj4Cs4/7CMy8hiadURH+ Ir2gjlSdr3VMuDQn10mwfJMv3FkqH5w/nFRHpKxHVu/SVDGqT70r93ZPq6ZnOvygtH4orYam+ZW6 259sj3Tqug6lHrftQDjZlGhqM+esfW932Fp9o4Da7dO+6qG9VOPsbYA3U8LeCskJtGkeiJ6n1wv0 Sj9IkxWcq61pB10FsAK+I2hO9nZdoiNEtui6SE6loNXZW9zvHYk9HvLX2MMFmgX9uLWy2aWi97y1 UjXUErr6R3PK3rIuk67d8uH6EtrtvwAAAP//AwBQSwMEFAAGAAgAAAAhAGCG/ODnCAAAOy8AABQA AAB4bC9jaGFydHMvY2hhcnQxLnhtbOxaTXPbOBK9b9X+By4rh5makkSC36rIU7ZsZ7bWSVxxZg57 g0hI5pokGBCyrUzNf58HgJQlRfLnpjbZkQ8yCQINoNHdr/GA1z/floV1zUST82pku33HtliV8iyv ZiP714+nvdi2GkmrjBa8YiN7wRr754O//+11OkwvqZAXNU2ZBSFVM0xH9qWU9XAwaNJLVtKmz2tW 4duUi5JKvIrZIBP0BsLLYkAcJxxoIXYrgD5DQEnzqmsvHtOeT6d5yo55Oi9ZJc0oBCuohAaay7xu OmmpGwryhcQyTwVv+FT2U14OjLBuUhDmBoPlrA6gpIxK5iaOb13TYmQ79kAVFrSamQJW9X69MIWC z6uMZWMuKizHSv0yHR4WkokKosa8khh1q6/yURovqbia1z0Mt8YkJ3mRy4Wetn3wGrLHlxz6sD6w T/NcsGZkp65/pwL/qQpwokE8IO26YrKuP2zkomBmQq5D1GwHy371EE5pUUxoeqV0s1J5WfXuu2q4 qQzVSpuRepC5LJh+uFW/Ik8vD17T4YRni3NhCS7VIlhNnZ7mopFntJHnVMDuXFt5gXyPn2nBb0Y2 KwrYQg5rUOXQAhefbetG0HpkN5/mVDDbolWKYmhMiu5lLPHuqjnSYdHICzV1/VKrkvpcqH8Zm37A aJrPqOo7GM9EjyrXv/ORXcHVlNuJ/AouV/EL/WRbVzACNIHj6Cno6hPasCJXrulgPemw4UWeneZF oV+UH7JxIYz25a2r6xTz8i3PTFkYOBBnxjsv30+nptjrigcQ2UnBwm10oNymsuSiZlPEgZH9U1n1 CmnEMbrxgVHzIW02PqSNNopOMbqbVlVaXwLKUj6DVen8hQ7lwTlMhknrpErFolbuq4YndWs0wzN0 PuhsAA9SmwTHehZ0seaQTdtbxZXmjDIqpcBlAaQVuoRNpyyVZ41UZgxz1S2VbLO0e0NTce47NDRW ZSoSKL/cMLWlIZk1VobUBRk6l/yjejlmBZOsdak2ytcFl4eCURPxF3yuTAYWk1KJaD5W6LnyriOF Mcqm5FxevkXYZsJgwzUVizEv+BouQBSDnafDPLtds2YuMtZ6fDsUY/kIKB/YVLWYHlxcMibdf7x6 84r4yo51MSqMKZxdVanlGIAk27BthlFLC32ZSJMOrw/ecev83Ylqfq2doVbOp0J4J8a86E6X/tf5 WlFZCLPAxgDRLFVhVVTZgyGMpinwTwfYzVikAVR55QOuqvDQKK5ZlBOO9EeZbJqLtGBmnk3+ucWr oC1o48N9wfWekZmpJgEJnj+/+2cF7d5N6/Y3iuifDqt5+cV6H74iwfDV4SuPLFcd1ZarbjK1Mc/Y wRuGPIQWuprO33TppmXE2y1D29SdUShzMqajAEiZixuum81dDdLWCHfK8NoaJNgpxO+EOM6uftRa 6JEA/3bVCbs6gNxddaKujh9s1MGi3OnWvHSu0C3R4p6lgmtiqd587aVCBtJ3Qi/xHN9ziB9EO5Xa rV3oxP2YRD4JE9cP/JgED60l8UjcR9XEj7yAxO7OBt3SQrjfj0MPg/OQIYW+u6uLbqWRWUZJPwkc JNthGMXOzj6WC+8h9PRJFDg+iRyS+PGDZuBjSP2IOEHse34cJDv7uDOKiET9CB35UeR7bhB9ES13 mUhnGgYN1uIwu1UJiDJfPFlzgcTx97Hnxc547PeC4/Ck5zvJuHd04pHeSUSOSQK1e+PxHytbmydv bPyVnD4czqv805z9s0W83+FD+q/nHAZOzz/1HfSexL2jIIqDI4IhnJz8oZM8PWYNE90sFEi08XgD z3SYT4creNaW7MazX16CZ/8bMDPbnI3E+psAs60jezKYbZGyB7MlIP5FwAx+CTD75auDmRP0w4SQ OAEaExLsRoEOzPyA9BHOFQYAmgBmDyYmbhQ6/cQFZLpxEjqRsxOburUN4hAgQHwnSnwFHCR5CM3i 2I/7QDEQSo7vho6zs8USzdwgdvtAwZj4SULi+GE080iETlzMwCPER/sHUxzPA8YS6JXEURh4m/O4 J+H5HtHMfRmaZWeTotE7vEt+c8Zm2GH+i23wDviCDHCdi0DZmMp3tGz3IO0erkH5BRNby8+ZUNui L+QczSeTgl0stzNaFFZpOTR620G47zowhTjS0TodbnzQnFPLeGzsX7F7OtTEyk5Z2PGCoZopVXCR Y5yaazWDLfPqLb1tM4OVipneUK9NiN6e85YXnZhdR0n/w8UbkWeKADOqbjdqKyBl9pZTMFXYZpZ1 BvqumoGuK2bg0hRz9xzWzN3OmsWPY80eB+56T7c5we+O31Ts4nP4zT2vqd32h8lCsubHPbOp2PMd FPrexJBPmzOFVer8WYwmdqOnpbTueKCR3RJBOHLgc8DMWV5dMUTRdiumY/DHPL1SfKWJ1/r4QnOd iO5c7Poo0QgQuQzqFTaEH/k64bZGyCu+UJNoXyWkI1ncdhACesAU338Q8tj92rZzgh7yO/33LR1M Jfu4/SKnwpkkzombw5aa1+lVl0W131ibzahThH8z0Zq+bnbE5A1jVZcjZUgI2xxpmW7tyrvuOvnv 513FPu8y1NO2c+VeAKZSY9E3dLy8x8at2HjfsfIH3LOwfng7qb+5tGtvYd/PxYV99vWkayj77Gvt WtA++3rZlmZb9nVHbukU62XZ10tvDIHcWbsfoulBfVNEP20yXX/RS0t7N3jxzr5YWpayt9/y5n1V tCR0u4PP8qY+wp2nq+aw3ZDMaG0S/W0HzUF4lJyM3eOeFwc4aHb9uJc47mkvio9jB4fwUTR2Vg+a hffko+Zo4Hirp83CU/do6TEGipt77/Vdv8YN4S64ootvKH9HDxs9iZWD8kH7eWtTOCBmt3YQjXNo cOzHirZX90DBS6/wz6i/vGTaOf9914Ems62XlP4fiOnN246Puexq7mW17PyjcyMESZFX8oJJXDOd aYb/klHcbjvFDTkmNMdU0xkD9zTLq0bzzP0osC1117of2RYu4+r/6tqv/mCaqzfPBsulpJiXpSx0 Nq/NUcdG550J6DvvB38CAAD//wMAUEsDBBQABgAIAAAAIQDSi8FA4wIAALYMAAAYAAAAeGwvZHJh d2luZ3MvZHJhd2luZzEueG1s7JfNbqMwEIDvK+07IN9dsDHmRyEVCWFVadXtYfcBLAMNEuDI0CZV 1XdfY6BpWrL9UavtoRcyjJkZe2Y+25md7qrSuM5kU4g6BOjEAkZWc5EW9WUI/vxOoAeMpmV1ykpR ZyG4yRpwOv/+bbZLZbBtYmkoB3UTqNcQrNt2E5hmw9dZxZoTsclqNZoLWbFWvcpLM5Vsq1xXpYkt i5rNRmYsbdZZ1sb9CBj8sTd4q1hRg7meWbsVy6wso5qvhexVuRRVL3FRzr2Z2a2gE7WBEn7l+dxB CLnO/Vin0sNSbOcY9/pOHpXaxvZHEzWkTbTvfcBW7ANjezoy8i3HsqYjk2FGjyNTSicjj/EuJdus C55IVmVGxbgUIRgSVF//eDB4MeSIn19fSKNIQ4CBUSurECzXTLYGUmYsyHbtz6YdJONKFiG4TRK8 cFYJgYmSILEWBC5WxIcJtr0VdpMltuldZ41owFW1W9VoZ+lYZUSf1Lkq1DwbkbcnXFSmyPOCZ2Pf qK5BxNR11rO8dVcujaIkhsSNVHR7ZUPPdWJIEbJclxAcEe8OmPOZqWc//upV9A3QrXiozvmjnHRm XZNM52qXS9VPLFAzNHYhUODcdE9lpEMZvFfyUatdjUZDZbpvBzFmLetT+mqKeFcilWIeaGnILX8D Qb2nwcGLgO7rEwt+VWV121Mts1KXuVkXmwYYMugaSp6laCjEgxXrgtwnQ6foYdMOhSkL5btL0FiR CbyfJR6hafBsinziT4M3mDzmDlnEfQXy6Nhm42DiHEEeD/onm42LRpODzeYdkLcPkcefFHmUxChy UQyRG9mQOH4C/SRKIIpiisjSXdBV8oX8i4/gj0Ue/1/k91gfnPL/OmuPIY89x3PvLwDPnvJ0erMh vmMfO+WPIU9civcXgH3kd0DeOUSefFLkowStsONb0LdjColnURjZvgPV5SKyo8iKYy/6Qv6TIG9/ FPL6dtD95Zj/BQAA//8DAFBLAwQUAAYACAAAACEALEuMQP8LAACwWwAAFAAAAHhsL2NoYXJ0cy9j aGFydDMueG1s7Fzbcts4En3fqv0HLStvW6J4v6giT9mynckkmaTizDzsG0RBMte8KCSV2Jmaf98D EBQpSrQoydY6tvyQiCAJNhqNPmigcV7/chsGnW80Sf04GkiqrEgdGnnx2I+mA+mPL5ddR+qkGYnG JIgjOpDuaCr9cvLPf7z2+t41SbKrGfFoB5VEad8bSNdZNuv3eql3TUOSyvGMRrg3iZOQZLhMpr1x Qr6j8jDoaYpi9XglkqiA7FBBSPyoeD9p8348mfgePY+9eUijLJcioQHJoIH02p+lRW2eaiXaSo2h 7yVxGk8y2YvDXl5Z0ShUppq9RatOoKQxyajqKkbnGwkGkiL1WGFAomleQKPuH1d5YRLPozEdD+Mk QndUng+9/mmQ0SRCVcM4yiC10FfYSuMhSW7msy7EnaGRIz/wszvebOnkNeoeXsfQR+cz/Tr3E5oO JE81ShUY2ypAsXtOTxP9isaqRj/N7gKaN0hVNNba3uK7XIRLEgQj4t0w3VQeXjxa3mcv1pXB3uJm xH5kfhZQ9iOGUQfkbknv6exTcvKa9KP40g8CyEH6QbRU0CtK6GRCvex9mjFpIRV/E9Xf5jWM4vHd p6STxBnr1E468y79JM3ekzT7RBLYsSqxUZV9xD+TIP4+kGgQwLZ8WBcrh1bj5IfU+Z6Q2UBKv85J QqUOiTwUoweypLgYZrhWmc4gWZpdMVXyixkrEe0Z08lnSJP+wKOGAnlGXCqf/zsfSBGGLhvGiX+D IRzFV/yX1LmBUeEVDETeBP74iKQ08NlQV2AfpJ/GgT9m6uIXbFzTYZDkas1uVf5MMA8/xOO8zDIV VJfLOw8/TiZ5sV4UQ8PcO7BaoNraB9gwjDrZ3YxO4FcG0r/DqBtkeXWU1G5Qkt/w0toNL+VGRvq5 YvhnhKpoNGYdxNTFRiH6pRiBEAU6RV/nfcx+FLZE5ln8hV2c04BmVLRUDOZZEGenCSX5wL6L58xk YDEeyTBoh8xJVq55B+YqScM4zq4/YHTSJHcB30hyN4yDeGn4oyoKTXl9f3y7ZM1xMqaiI4Qo2W0+ gpLPdMJ+TU6urinN1H+9Onul6qxtvBiGMCToSfbILBvC72RidOZizLIOvpUbgNf/dvLFD6nK3v7G 9TNDe9iQWNSSX/BvcvVxIYS+g6gD44cHNGFjHjP2JBpvNCziefBy3OzrFsLdJBuUG0Yq83q53tK7 cBQD5JgD9vzEC2jezNT/IbySKQqEzPeZ/D2S5U11Tc3cvX33twraLZt1+yfBmPT60Txc6e7TV3C7 r05fabzbeKfjsUWn53g8jMf05A0F2pCA2wZHaV5aNwxnvWEYy0bBrCm3HOYWmLmoVtMTmnjCaqxD F09oZmMlRlGJojR9h/UFlwReqekZq3gGjrDpGbt4xjBrz6BTSt3mF8VQKLro7p6uwshEV509dlfp iqnKpqZDDflfbUCv9p3mWLbsKIZb/Dmb+lJzNVtWVXvxDa3pjaJvdVO1ZVtl2LBBqqKrTcO0ZdNU F2802k/R85arW7JqcPdXOrCyvUXv25quypphL9rbaHaFLTi2osu2seoam+yhsIPc8y/5XHrLJhvM VvGrM0+A3X8Ndd1RhkOja55bF11DcYfdswtd617Y2rnm2rqpD4d/V2arW89Vjco0zerPI//rnL4V 6PZXoeGudeqYXcNWL7uu7ipd81LRVcMxdeXU/JvjLJeZY0LRCoYIwvnWsIv7dMzOSuwSJc3YNdwX u2pmeBDsyueutdnNk8CutZJtjV1rajli1wL/Xgh2YWQCu4aPj12GJRuutRV2mbLJYqFNuFLMQ4Bd pmzYLQALosDxbwFYtilbqrMNYDmmrFraZiAqoYspCB65+GsExQV0Wa4l60oplbsyv39OIKY+LIhx 57cEYqKkGcTO9wWx2vzlICCmizB6KSB6EiC2VrKtQWxNLUcQe2kghpEJEDs/QABmyLqqLrx6zeOu C8BMHSFbi6jLkN02kFRGXYoj27a5ObKrRF2G7LQRvoy6NFVujKAqwGXIhq5sEXNZriGrFahbndw/ J+DSHha4uMNbAi5R0gxcF/sCV20uchDgMp4scK2VbGvgWlPLEbheGnBhZAK4Lg4QfalY1SvDkcZ1 wGLVV3Ow1mgbLeK1MvpSDQRJG9eCsYtkyLZT4kUjiJbIZSmy5ZSw2yh9BblcWbfLEK9RqgqKqbJu uluEX7aCldLKWuPzRjH9YVGMe78lFBMlzSh2uS+Kmf+H/S++LfUk97/WSrY1iq2p5YhiLw3FMDKB YpcHCb+wN7vw0Y1xVQXF3K3XEIE1NU9RxnVLm15m41JjiVyaIZu6szlKK5HLNIFcm7Y5bU1zZcsu IbHNRpdzH8DdswX6M255GQ8LVyK7oLLlJUqa4erNvnBV69KDBF3Wkw261kq2NVytqeUIVy8NrjAy AVdvDhB0mbJrt3D+FbiyZUMrF/UaQ6PKlpeGpbQy4aHxjQVyGS4W9bQW0IUAUHXL3aXG5IsSuixN 1hqhs5KjgW0rYzvosmTNbcwweWbQZT4sdHGXtxRpiZJm6Pp1X+iqWdeBMg15fm01jZVNFAtAK7Je V/NVn0g24o7S75CxuNOXjjD50mASXgAw+esBojpskVlbZTUabrvdshImsVZnVtYDW2Q16mzjTt+8 1VfGesg9dCshWYtVSkMD3Jd5kC3yGy1HNitI2PhGJUkE65qr+zfPaYPNeljAtPNE6UqsJ0qaAfPt voBZs5UDpTf+zIDJhjaOD2wP9zukSR4B83gMQKT/33cMAF4AgPn28QFTR26hudVmnubImlKmUrZI SFEBsXqLLbdKQoouu2pj+FdZEoX0bilLi+R/LKK6agnFjcC6dAzAVMrNyxYwaSMorUTez/tAgP2w iCmOFlUQU5Q0I+Zv+yLmarLr4x9mY7a+E+Y8kXzLQyHmjno6hpgvLcSEFwBi/vb4iIlDbZbZ4lBb uRJrKMit3+rwgerIRjP+VdZfsZipWdsEloYuWzg6Vvw17vWVK7EIdx0c1y3+2hycc+5D7zKctBWc a3jWBw2chwVHdyWcFCXN4Phu75Peq+dbHx8d2Qzv50XHnaXfIfHzGE8e48kW8STcANDx3QHiSQXn 4Vok0+CEmu1smxKqqZsXWw1XkbXGsK4MHQHKrTJHK0CI9dIW2TQ68FIvW9YocQUHdVlbPc/1nJZV 3f1wcPx+FKScRuQ6/v6eTsHa8o7WuHxwB+Ngmd8HZUOS/U5CQewheFFSlF/RZG35J5owrpGVes7m o1FArxYcIflmIAidCtHIbXFUHjM91dUMS2ShLt9wbNPI0/VXOWFASXLKKVsa6wKLDMh4ppzQKPEh J6epyoUN/egDuRUn8CsPjjlJzVKDyO2nWFBKjfIpRUj+GydvEn/MuH5yVS8xtnAak5ywZQJSHnC3 hLMxmIqiKZiJgilogxhJ0S4EQZztISfuwQrsgiDIaUcQ1C4a5kQp9QZifF2GWackPxlIgv0E7Efx HGbw3o9uKFopKAm4jr743g3j6Mn1yZmUOL8PtB8nTTczvAQ7WSg9AjHCl3iZZWaJhIqR5DyeyrX1 nEz2Q6p8PTdWt/CLT4kjC4n6O1FkHamxcmos0K2BAi89FXRUzP0tvJy4R4W3YcxZ/6GJMH3+2hnN vlMaFT5sDIctfNjCHTb4xcpHHt4vBke/yEgaGf3T0S8+aO7POs7Ao198hpSBa/xiZVrInd9+fnFf /kpMi5bYCvnEmvMW8l/1OeILpdA8Tg+wmbIfc2awsCxmb3/66ccoEOGbmFuP/XR2BgbOm/RUTBWm ZJZD8DoqNNM6cy+G6nlXd0xQoYF/rOsqYCSznXNkGWu2bQ+VKhVaom9Nhmb3FL3Kh5bojLyXnENQ 8Mh+nHF+YNXCcAEvMO6h/HdymvJGVKjceuL22lcxANG6Jao0RIWITs9ZVMnIYhHRVSI3PL9gti0G /33slKPpWs7MyjLjTxvS1eOLNoy4OU3otsyvcJKJH2VXNAMX7ZTHxteUgGv1EnytNOHR34xMKaLC qR+lnGxXtk2pwwieZVvqgLGX/8+4gfmN/HV2pUuIP1kt+cWiLnxsPsuphmsfL0yAE22f/A8AAP// AwBQSwMEFAAGAAgAAAAhAN7u/8UUDAAA21sAABQAAAB4bC9jaGFydHMvY2hhcnQyLnhtbOxcS3Pb OBK+b9X+By0rty1RBN9URZ6yKMt5TlJxZg57gyhI5poPhaQSO1Pz36cBggRFiRZlSS7Hlg+JCIJg o9HoDw00v9e/3YZB5ztJUj+OBhKSFalDIi+e+tF8IP3xddy1pU6a4WiKgzgiA+mOpNJvZ//+12uv 713jJLtaYI90oJEo7XsD6TrLFv1eL/WuSYhTOV6QCO7N4iTEGVwm8940wT+g8TDoqYpi9lgjEm8A P6CBEPtR8XzS5vl4NvM9Moq9ZUiiLJciIQHOQAPptb9Ii9Y8ZCbqWouh7yVxGs8y2YvDXt5Y0Slo DBm9sldnoKQpzghyFL3zHQcDSZF6tDDA0TwvIFH3j6u8MImX0ZRM3TiJYDgq9UOvfx5kJImgKTeO MpCa6ytspfEQJzfLRRfEXUAnJ37gZ3es29LZa2jbvY5BH50v5NvST0g6kDykCxXouypAsXp2T+Xj Cp1Fej/N7gKSdwgpKu1tr3wvE2GMg2CCvRuqm0rlsqq4Tx+sK4M+xcyI/sj8LCD0RwxGHeC7Fb2n i8/J2Wvcj+KxHwQgB+4H0UpBryghsxnxsg9pRqUFqdiT0Pxt3sIknt59TjpJnNFB7aQLb+wnafYB p9lnnIAdI4nOquwT/DML4h8DiQQB2JYP1kXLQatx8lPq/EjwYiCl35Y4IVIHRx4UwwhkSXHhZnCN qM5AsjS7oqpkFwtawvszJbMvIE36E6rqCsgzYVL57N/lQIpg6tJpnPg3MIWj+Ir9kjo3YFTwCExE 1gVWfYJTEvh0qitgH7ifxoE/pepiF3ReEzdIcrVmt4jVCZbhx3ial5mGAs3l8i7DT7NZXqwVxaBh 5h1oK6Da2gvoNIw62d2CzMCvDKT/hlE3yPLmCK7dIDi/4aW1G17KjAz3c8Ww13BVkWhKB4iqi85C GJdiBoIooFMY63yM6Y/ClvAyi7/SixEJSEZ4T/lkXgRxdp4QnE/su3hJTQYsxsMZTFqXOsnKNRvA XCVpGMfZ9UeYnSTJXcB3nNy5cRCvTH9oioCmvL4/vV2x5jiZEj4QXJTsNp9ByRcyo79mZ1fXhGTo P6+Gr1TaNVYKduBiGEhaY5G54HYyPjlzKRZZB16Vj7/X/3721Q8Jok9/Z+pZQHfojChbyS/YK5n2 mAxc3UHUAdsHB2iAiXnU1pNoutWusOeBk2NWXzcQ5iXpnNwyUanTy9WW3oWTGDCO+l/PT7yA5N1M /Z/cKRm8gMt8n8XfI1neVcdQjYf37/5egXZFt27/xDAlvX60DNdG+/yV1n91/gop5ZhDrXLMczR2 4yk5uySANThg1RhGs9K6Xdib7UJftQlqTLnhUKdArQWZTTVUXsNsbEPjNVSjsRG9aERh/RTWKSSh Q8EkAZ/UJItZ1AE32FTHKuroRq0OjInQbX5RzIRihO7uGakhHanhsUdK0xRVNiwLtJD/MWewSWHF 0KkIWbKhoO1PFEOpqoopa45dPlFzGWJQyqG1HCQ7FgDWNqmKkdZNx5BN3Sn/Gm2jGHgTaYpsG0r5 hLXNDEzdsmXNFj3XthmFZVvQc4SEWGvOsslECtPIoWDFC5Nbuvqg5gu/OssEwPwvV9NsxXX1rjEy L7q64rjd4YWmdi8sdaQ6lmZorvt3Zfm68+JVr6zbzP4y8r8tyVsOd38Vw9QdDm2nq9vDi+5wbI26 LtLH1vn5uWrazt8MeJnMDCWKXlCM4O64BmbMy8NyTYAZL2kGM3dPMKtZ/6OAWb6Wra12ngSYbZRs ZzDb0MoJzApAfCFg5lIwc48OZgYyZdMRLt3etg5RkeqAS1dLB934hAAzZMhItZtc+iYwMwA2miQR AGbrAKtOUz0BW4YiG5p4f6PExerF1OH9puVsh99iLWPZAKa19dc9q5lfEarQYaGK+bgVqOIlzVA1 2hOqahb1KFCl8eB5JQ56ElC1UbKdoWpDKyeoemFQNaJQNTp+3KWyCGc7jFTiLlt2HHO7G6/EXTQm 0raDm4i7IF6xGxGlglVItpvDmvUo20S6LmuGCAEbw0yBWpYiW2qLELBELUfRZIg1y+4azzrYUg+L YMz1rSAYL2lGsIs9EWx9hXH8nUP9ySLYRsl2RrANrZwQ7IUh2AVFsItjI5iqOhqgi7kTgqmyZTXu hgnYqCAYkk3N2iXYshXZpOdW/K9xr7EEM0szZd1uETSKEEy3ZNUQQWOLnUMTsBs0Vvw1QmwFzAC7 jfX9qOe0X6gdFsKY71uBMF7SDGHjPSFsfYlxfAhjZ1JP8vBro2Q7Q9iGVk4Q9sIgbEwhbHx8CLMd GbYLt4NFJQgzZcMUIVXjfl0FwgCQ7BZxTCUI02TUfEIqojDTkVVbK6VvPDGtAJcu24qx/ZBMRGEm ADAScVvjOwRwqSoA17MOvfTD4hZPMqicc/GSZty63BO3aqejj7J5aD7Z0GujZDvj1oZWTrj1wnDr kuLW5SOEXnAG5AjcapG0AWkeutJYr4JWmmxbO20ZQsDl6C1CNIFbliUjvfFEbCVBA2kt0LmCVjqE pDSfMP9rgVYKbMPaAhFreP7MTr2MwwIX83grARcvaQauN3sCVy3UfqRsQ5ZiW81kpeZVwFmR+Lqe svpEMhIfKP0DshYf9KYTSL4wkHxDQfLNIwR3AAbWTskgii0bdi122bQriejxV4sgUIR0tkbzGbfv Y1byGU3ZqbyjccdQwCUcmAGSbQe/Ei4NBcJBQ4Bfi11JpMuOIcB+PY54TvuT5mHh0sqTpStxHi9p hsu3e8JlbUQfKZ/xV4ZLuhKGDwh2B/sH5EWe4PL0IUD+qcZ9HwK8pXD59uhwqUFeo2W0ADWxF6pC voWz014owIfRiDIVtFQBl1oki4gzPEBu9Si5k44F8aHYY22MoCu5k6asInEs+rwh0josRPLviSoQ yUuaIfLdnhC5HvEf/wiPWvqDQOaJ5Fo+FkQ+UE+niPKFRZTvKES+Oz5EKpCSWP3IrMXnBbqMnBab o+UGLHJsyMBskSlSQUvIFFFafJBQQ0uRI9Pi4NAGfFVbbKyKrVjHke2tH8jZimlBKP2sTwvtw0Kk sxZF8pJmiHy/7yfe61+2Pkam5q+MkXSuPU4Y+cA3nTDyhWHke4qR7x/haNKCT/DEX4tP8DQbUFUg XpuUGkgxUVrEhxWMRLJawcjtnzhYkMZiq2LHtsX+q2MC1gscbvwCXey/qoasaeKLju3BpaPDB456 YzLRMzuudPZDzumHSZAyypHr+McHMgeCl/ekRvsDd4CDYZUKCMpcnP2OQ04CwilUUii/IsnG8s8k obwka+0Ml5NJQK5KPpH80BC4nwrR8G3xET3wERiGiix+hFq7ocMHNPwD+jp9DNCXnDN2l8a24Ang 7Zkz7qPEBzkZo1UubOhHH/GtaLqoOGV8NisdwrefY84+NckXISH+f5xcJv6U0gLlql5hd2GUJzm5 ywz4e4DnJVxMgdQomgOJUTAHhiHKZ/QQLiG0mUsI+BwOdzDLSFXqHYTzjXGYdQRTykDiVClAlBQv wQw++NENgV5ysgKmo6++d0PpfHJ9MtIlRgUE2o+TppsZPAR2Uio9AsqEr/EqI80KXxUl1Dmeytny n76drWtK+ibrkCrfTKPVLVzkU6LTgoO2B7FpnVi0chYtYGYDtrz0nDNXMfdXeDl+j3BvQ0m2/kcS bvrssSHJfhASFT5sCg6b+7DSHTb5RfGSw/vF4OQXKZ8j5Yo6+cWD5ghtohc8+cVnyC64yS+KZSFz fvv5xX2pLmFZtEJsyBbWjOKQ/aqvEV8o2+ZpeQA7TPuRbAalZVF7+9NPP0UBD9/42nrqp4shkHXe pOd8qTDHixyCN5GkGebQuXDRqKvZBpCkId3uOgoady17BJsJqmVZrlIlSUu0nWnSrJ6iVZnSEo3y /OIRCAqUs58WjEoYmTBdgEIY7kH57/g8ZZ2okLz1+O2Nj8IEhN6tkKgBhxpEpyMaVVJeWYjoKpEb 1C9JcIvJfx+T5WS+kV+zkuDyy4Z09fiiDXluTim6K0ksOMnEj7IrkgFt7ZzFxtcEAy3rGKhdScKi vwWeE4gK536UMl5eyL+QOpQLWrakDpD7sv8pjTC7kT9OrzQJ4k/aSn5RtgUvWy5yVuLaywsTYJzc Z/8AAAD//wMAUEsDBBQABgAIAAAAIQCevHWlnQQAANomAAAUAAAAeGwvY2hhcnRzL3N0eWxlMi54 bWzsWm1v4jgQ/iuWf0ADdOm2VVOp12qlk+httbfSfTaJA7517JxtltJff2Pnhby2cAQKe/2GJ8Hx PDN+Zjzjm0BfB3OizJ9mxSl6jrkAgfbx3Jjk2vN0MKcx0WcxC5TUMjJngYw9GUUsoF6oyJKJmTca DEfeehacTUMas8iECvhEJFVMjD6TapbPEXOYZXDhxYQJjFjo49GnAb69geWRZ6a/M8OpG3HxjUbw wrOPB9hzoohx3hDSKKKBab4rxVoYMyEVfIRcOzXpPVfoJ+E+Ns9DJ+aL+FGGqexiPBi4L5JrEH+N olR8nou90iy3Nx4sPEq/5dYY0ujbk0L6xcdDOw/6QZWA36C01cK+XtUzIIbOpFrdgfanrLhOnpRF mAu09PHVeDTGKCCJjyNODPyME7C1FjOMCJ8BIoHJLCI5C7+AZTc0z6jdPJ87zAPGKn9AyYUIrR3s QlNzpAsHu5RMd9VuuYat3F64U5SgWIawmQjncvmHtOp8/UmVYiEFdZ1swgTNZam/H8zDM78ru2lu rQo4tc0xnQ2dy9Yg3LeBh+0GvuzVwF17szBoupmJIRMypeCb4B/vxkiFb1cZqdgJGzNSh1uHFTWL 0b313IU5nO7hj77ZeBM356bDzR0hvcJObcvdhZ225yRwyqkMVxBvlDQ2TiKdBF+Y0mZCtHkiCiLz ECNgImOpJwIiAuLlLMFoLtVLXWbfg1AOTzBaKsvd+p8FURQj/rsAdju/GH++wMi4wfBydHmJkSo/ mZafEBHAVCnRo3Rwb2Cc2lgndwsDRGkyckr1SBm51QOt8EkysZk/2o8AOtomO0W0J/DFPAhnuYR7 a+cUok6wNspX11uMzh822k9HtP5sxYUGNpA1dXgDbsedzSTO7TwAq3cLWNtXEpLh1WAM+8NlJEqE aTL4yuZO5uA2beGvM4OoGL0AqYDtkShIBfsD7j39u4GuS/fe4ssOSBu0VwGyBFsNyglZQXRCehVP JaTyAVMBB6rS7IX6eJwdGYr//MUUjRSJe3Pd/FCyk+vaEPJKdtZItQ7guVWgLH7fyfS0z2Q5EwiX mAPe+z+lHCSJfSWdW9sslEvxG2khnn2eqf/jiaMto9oy+T3wYWXLYsGmp1FHgSXDhUom7XH3nay4 70NgUW2pHnkKuGtHnq1wLWMJZ3Spjml77BvYPTpsBUs4a8jjIZ0K81v+LwSt2cd68TMo4XBIeB/J 30ekzomWYCyrNQEtJLZIe9hCyzapV89lzPYi19WORa4KwgWeczaR/6voYVFsKeEX4h2iRxVLSkKq PgKzj/sIzLyGJp1REf4ivaCOVJ2vdUy4NCfXSbB8ky/cWSofnD+cVEekrEdW79JUMapPvSv3dk+r pmc6/KC0fiithqb5lbrbn2yPdOq6DqUet+1AONmUaGoz56x9b3fYWn2jgNrt077qob1U4+xtgDdT wt4KyQm0aR6InqfXC/RKP0iTFZyrrWkHXQWwAr4jaE72dl2iI0S26LpITqWg1dlb3O8diT0e8tfY wwWaBf24tbLZpaL3vLVSNdQSuvpHc8resi6Trt3y4foS2u2/AAAA//8DAFBLAwQUAAYACAAAACEA np1qi+UBAAB3BgAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC0lUuP2yAUhfeV+h8s74kBv3CUZJrJo4o0aUdK2kU3EcbXE1QbLEMyk1b9 7yWapiMv68pLBBy+c7kcJncvdeWdoTVSq6lPRtj3QAldSPU09b/s14j5nrFcFbzSCqb+BYx/N3v/ bvLY6gZaK8F4TkKZqX+0thkHgRFHqLkZuWnlZkrd1ty6YfsU6LKUApZanGpQNqAYJ4E4Gatr1PyV 81/1xmfbV7LQ4kpnvu4vjcOdTf6IX7yytrKY+j+X8WK5jHGM6CpbIILJPcrCLEWYYUzv6WKdzVe/ fK+5Lqa+p3jtrG93m8fDA8+hOpQR5TyMKGIpTlBEGUN5QQiCPGdxlsWYMnFYKZ5XULjzz3ZcNc/G trN9e4JJ8DaeBDe2/6QM+1LupIVNFzKlZcZYXiKWlARFhJcoIzxHtEhFgQkp8igdxETU18TnZwVt p9BK5lx9Nx9qKVptdGlHQteDQMe9Kw92yS10sCkmDLmWIuGeknFIxjQexUlCCA2/DUKf9KX/5N5E B/0juDvg1SCUaV/KedNUUnDr0q0Du721hTf/cWrB26jXnHLrPJcdFsR1yyBeXKD2zJMXC6qA4rDd rfeHLdij7r7b+cklqfMqBuHObtw7UEZaeZb28i8NELz9GLPfAAAA//8DAFBLAwQUAAYACAAAACEA YNCjap8BAADMBAAAJwAAAHhsL3ByaW50ZXJTZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJpbuxT S07cQBB9nkFREikiB2CVPaNJmEBYGtsgI/9ke4AFGzPTIq003ZY/ypCIc3GRLOECrHKD8HqEollE REqyyIJuuerVp19Vue1TnKJGA41NzGCIamxhRC0wxwU9mnr0MzaiT9JqGLHLWRs+u8H3oXeNgQMH dy/N8zn1Ok5oDyiHtCKyddyC5/5+OQ8UVg/4vCD4wXUQFpNVdj9Mpm+wcL4NN3B7cHzzWOVXdpaV BIvtPMsZ/0HPTxT//xtYvf/fdbtgchGXhzbvNT46XzHGO0zgc7t4D4//0y4+4O0STYhtdJMeGw+I fMqA9ha26dmlHDN7B1dkDHXdd3tSw52WKfKg8KMIUy0b0VqUVbVoCvlFIArKMsiRNlLoruqk0cjS vMzdsIRnlGliMxeIjTbIRWtUv0zxs3B7PIbf10oscBTkZei5EQ7NWTKtXaV8M+svSNh6RnfyvDd9 qy7ZXCzmsiova4FMVeyOFVTVCaQJiq6qldTnSIwWlimr2nZmi6f7+yCn+bynKv0pCxOk+s+/hQ0e PZr48a/u6h4AAP//AwBQSwMEFAAGAAgAAAAhAJK2kG9HAQAAZQIAABEACAFkb2NQcm9wcy9jb3Jl LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySUUvDMBSF3wX/Q8l7m6ad Y4S2gyl7ciJYUXwLyd0W1qQliXb796btrB3zwcfcc/LlnEuy5VFVwRcYK2udIxLFKADNayH1Lkev 5TpcoMA6pgWrag05OoFFy+L2JuMN5bWBZ1M3YJwEG3iStpQ3Odo711CMLd+DYjbyDu3FbW0Uc/5o drhh/MB2gJM4nmMFjgnmGO6AYTMS0Rkp+IhsPk3VAwTHUIEC7SwmEcG/XgdG2T8v9MrEqaQ7Nb7T Oe6ULfggju6jlaOxbduoTfsYPj/B75vHl75qKHW3Kw6oyASn3ABztSmeJD8EK6YPNsOTcbfCilm3 8dveShCr04XzWvXMvsIABhH4UHSo8KO8pfcP5RoVSUwWYTwPSVqSBU0TOrv76B6/uN+FHAbqHOEf xISUSUxnCU2mxB9AkeGrj1F8AwAA//8DAFBLAwQUAAYACAAAACEAYUkJEIkBAAARAwAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckkFv2zAM he8D+h8M3Rs53VAMgaxiSFf0sGEBkrZnTaZjobIkiKyR7NePttHU2XrqjeR7ePpESd0cOl/0kNHF UInlohQFBBtrF/aVeNjdXX4VBZIJtfExQCWOgOJGX3xSmxwTZHKABUcErERLlFZSom2hM7hgObDS xNwZ4jbvZWwaZ+E22pcOAsmrsryWcCAINdSX6RQopsRVTx8NraMd+PBxd0wMrNW3lLyzhviW+qez OWJsqPh+sOCVnIuK6bZgX7Kjoy6VnLdqa42HNQfrxngEJd8G6h7MsLSNcRm16mnVg6WYC3R/eG1X ovhtEAacSvQmOxOIsQbb1Iy1T0hZP8X8jC0AoZJsmIZjOffOa/dFL0cDF+fGIWACYeEccefIA/5q NibTO8TLOfHIMPFOONuBbzpzzjdemU/6J3sdu2TCkYVT9cOFZ3xIu3hrCF7XeT5U29ZkqPkFTus+ DdQ9bzL7IWTdmrCH+tXzvzA8/uP0w/XyelF+LvldZzMl3/6y/gsAAP//AwBQSwMEFAAGAAgAAAAh AHq7YPooAQAAzgMAABAAAAB4bC9jYWxjQ2hhaW4ueG1sdJNRToQwEIbfTbxDM+9uscTVNcAmkFoP oAdooC4kUAglRm9vNXaQqbyQ8PFlOvNPyc4fQ8/ezey60eZwe0iAGVuPTWcvOby+PN08AHOLto3u R2ty+DQOzsX1VVbrvq5a3VnmK1iXQ7ss0yPnrm7NoN1hnIz1X97GedCLf50v3E2z0Y1rjVmGnosk OfLBF4Aiq9mcQ5UKYJ1vAlj//eS//Hnl/piVV6k3f/zVDIQR049FzECIKU7UREJNn8y2pgiEmveR GQg1j5EZCDXvIjOQrVkKWlMhoSbtU4n/+yxx0pC82pm9jPJUO3mWKd2RQkL6jPaukFAz3Cjsc+cu lYLmqZBsa8qVb26pxMrhLBn1KaMZZZSPjLKVuAWs/HenHP/E4gsAAP//AwBQSwECLQAUAAYACAAA ACEArDl47eQBAABRCgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQATXr5lAgEAAN8CAAALAAAAAAAAAAAAAAAAAB0EAABfcmVscy8ucmVsc1BLAQIt ABQABgAIAAAAIQCSB5TsBAEAAD8DAAAaAAAAAAAAAAAAAAAAAFAHAAB4bC9fcmVscy93b3JrYm9v ay54bWwucmVsc1BLAQItABQABgAIAAAAIQBJ7eRwQQMAAK0HAAAPAAAAAAAAAAAAAAAAAJQJAAB4 bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAHi8u8OwAAAAZAgAAFAAAAAAAAAAAAAAAAAAC DQAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA6r9mRkQNAACnNAAAGAAAAAAA AAAAAAAAAAAgDgAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhABj5gogc AwAAeAgAAA0AAAAAAAAAAAAAAAAAmhsAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAwRcQ vk4HAADGIAAAEwAAAAAAAAAAAAAAAADhHgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAI AAAAIQA5MbWR2wAAANABAAAjAAAAAAAAAAAAAAAAAGAmAAB4bC93b3Jrc2hlZXRzL19yZWxzL3No ZWV0MS54bWwucmVsc1BLAQItABQABgAIAAAAIQCBxV69ygAAADUCAAAjAAAAAAAAAAAAAAAAAHwn AAB4bC9kcmF3aW5ncy9fcmVscy9kcmF3aW5nMS54bWwucmVsc1BLAQItABQABgAIAAAAIQCAG9yB 0gAAAI8BAAAfAAAAAAAAAAAAAAAAAIcoAAB4bC9jaGFydHMvX3JlbHMvY2hhcnQxLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhABHKeiHTAAAAjwEAAB8AAAAAAAAAAAAAAAAAlikAAHhsL2NoYXJ0cy9f cmVscy9jaGFydDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAoXjI99MAAACPAQAAHwAAAAAAAAAA AAAAAACmKgAAeGwvY2hhcnRzL19yZWxzL2NoYXJ0My54bWwucmVsc1BLAQItABQABgAIAAAAIQCe vHWlnQQAANomAAAUAAAAAAAAAAAAAAAAALYrAAB4bC9jaGFydHMvc3R5bGUzLnhtbFBLAQItABQA BgAIAAAAIQAcFKeo/QAAAG4DAAAVAAAAAAAAAAAAAAAAAIUwAAB4bC9jaGFydHMvY29sb3JzMy54 bWxQSwECLQAUAAYACAAAACEAHBSnqP0AAABuAwAAFQAAAAAAAAAAAAAAAAC1MQAAeGwvY2hhcnRz L2NvbG9yczIueG1sUEsBAi0AFAAGAAgAAAAhABwUp6j9AAAAbgMAABUAAAAAAAAAAAAAAAAA5TIA AHhsL2NoYXJ0cy9jb2xvcnMxLnhtbFBLAQItABQABgAIAAAAIQCevHWlnQQAANomAAAUAAAAAAAA AAAAAAAAABU0AAB4bC9jaGFydHMvc3R5bGUxLnhtbFBLAQItABQABgAIAAAAIQBghvzg5wgAADsv AAAUAAAAAAAAAAAAAAAAAOQ4AAB4bC9jaGFydHMvY2hhcnQxLnhtbFBLAQItABQABgAIAAAAIQDS i8FA4wIAALYMAAAYAAAAAAAAAAAAAAAAAP1BAAB4bC9kcmF3aW5ncy9kcmF3aW5nMS54bWxQSwEC LQAUAAYACAAAACEALEuMQP8LAACwWwAAFAAAAAAAAAAAAAAAAAAWRQAAeGwvY2hhcnRzL2NoYXJ0 My54bWxQSwECLQAUAAYACAAAACEA3u7/xRQMAADbWwAAFAAAAAAAAAAAAAAAAABHUQAAeGwvY2hh cnRzL2NoYXJ0Mi54bWxQSwECLQAUAAYACAAAACEAnrx1pZ0EAADaJgAAFAAAAAAAAAAAAAAAAACN XQAAeGwvY2hhcnRzL3N0eWxlMi54bWxQSwECLQAUAAYACAAAACEAnp1qi+UBAAB3BgAAEwAAAAAA AAAAAAAAAABcYgAAZG9jUHJvcHMvY3VzdG9tLnhtbFBLAQItABQABgAIAAAAIQBg0KNqnwEAAMwE AAAnAAAAAAAAAAAAAAAAAHplAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5i aW5QSwECLQAUAAYACAAAACEAkraQb0cBAABlAgAAEQAAAAAAAAAAAAAAAABeZwAAZG9jUHJvcHMv Y29yZS54bWxQSwECLQAUAAYACAAAACEAYUkJEIkBAAARAwAAEAAAAAAAAAAAAAAAAADcaQAAZG9j UHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQB6u2D6KAEAAM4DAAAQAAAAAAAAAAAAAAAAAJts AAB4bC9jYWxjQ2hhaW4ueG1sUEsFBgAAAAAcABwAeAcAAPFtAAAAAA== --_006_DM5PR2101MB0901FCB1094A124818A0B1FEB3760DM5PR2101MB0901_-- From nobody Thu Jun 21 14:14:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A01130DD5 for ; Thu, 21 Jun 2018 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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=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 hBfzQJrIE02m for ; Thu, 21 Jun 2018 14:14:52 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 85B8012785F for ; Thu, 21 Jun 2018 14:14:52 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 16-v6so34277itl.5 for ; Thu, 21 Jun 2018 14:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=FNMR5CWdcrB0rPh/EYDW9ZlzL4FMmPm9HY4W9PNqcZM=; b=G441IQtKyldII5K3SSH13XyU3WCcsqvHdhDt2q1aOYBzPb+6XVgkiZaSUqd2ITYThM JLaDg/wg6uzmBaBqs9A1DQ6fh2DXSOvw7z5JQCrRT6Xj7JY8bODCVC+zxEM6LLIWUYzV rGGVT10JyuAJqSKweRaHcZst6G3vGPO+dK8Tu3f1nx3S3JVYUH7VZQiM7Txdm3TLOjmK kJN+V2PVQZk+Tf9PgCy2ZddLj94Y14PDJeG2FAbfXFyiaxNbh64Oteg8Chb1eEcpYw5n 7DFXMDQAiOiQW/XiRNDsjxH9kMoWjZ0lZe7NJ014ZlSaSxT1D695t3JgXA4mogDAuF2I ij3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=FNMR5CWdcrB0rPh/EYDW9ZlzL4FMmPm9HY4W9PNqcZM=; b=QAPHy0/iMSND24dPOwwYAKn1fIg2eKd83eJp1M1DfiQciXPRozeOmN7JrLhpLnr4uw usQDV5c0O7eqz/yCc5autDlgAuIHu2l+gz7h82NpgIfjItF3KCuu9NG0TyQuP0DDI4c2 U88pRB7j5/bLlJ+Zck8MFvtiY6R95FfxN93tliUVe9SGtU7IcOBS/G2Z+Qk0XUMfkknB SCw/ijY07cQWGahmsn8lUo6e7Dq0fVA7bgHnppz7IIOy5d+XYiaUrqbUAgwXx8rA8re/ K+dfgp8q7rtmsVd2Mbxvb9nV5jyiuRcfrsaIVUlHbcGKVAMUr7q/CeMaTUH6tTskZzDX FqyA== X-Gm-Message-State: APt69E3WRme8Lr8sACqCCGOfB535UOS/48zmnbg02+Ib1Gju2TKxwbLN xSctE9/xPK3CCL8G/BDLrBnu2ca48WKT1dRuljE= X-Google-Smtp-Source: ADUXVKJacUf4dJ+zyllBBiWTV0uk7DNUvcD8lHIFoMA3J8TWwBBWLZp0JUEJAkGXUsP7NAWIE/o8Q48zr63Fh0cZ2mA= X-Received: by 2002:a24:ce86:: with SMTP id v128-v6mr6656892itg.39.1529615691899; Thu, 21 Jun 2018 14:14:51 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Jun 2018 17:14:49 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 21 Jun 2018 17:14:49 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Eric Rescorla Cc: Jana Iyengar , IETF QUIC WG , "Deval, Manasi" , Marten Seemann , Martin Thomson , Ian Swett , Kazuho Oku , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="000000000000f56c2c056f2d676d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 21:14:56 -0000 --000000000000f56c2c056f2d676d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Missed that mail. My concern was mostly that you when several people raises concerns about a protocol design principle being changed, you need to argue why such a change is viable rather than just - need to check EOB anyway. You code goes some way to address that. I didn=E2=80=99t go through it in d= etail (I=E2=80=99m beyond my code line limit for today) but there could can be pr= oblems such as: ACK frame with length prefix says it does not exceed end of buffer. Parser reads all data and confirms this fact, so frame is accepted. What it might miss is that the length points after the end of the parse block leaving undetermined data hanging. Not saying this actually happens, but that is a concern. Personally, I actually like a length prefix, and generally don=E2=80=99t se= e a problem with it. But I=E2=80=99d prefer if it was a global principle then r= ather than mixing those concepts. When this is done in a generic fashion, and end pointer can be passed everywhere, and as soon as something does fit cleanly, abort the connection. The MQTT packet framing uses a length prefix uniformly: http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/ Mikkel On 19 June 2018 at 21.12.13, Eric Rescorla (ekr@rtfm.com) wrote: Not Manasi, but I don't understand (e). Here's the relevant section of the Minq decoder. --000000000000f56c2c056f2d676d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Missed that mail.

My concern was mostly t= hat you when several people raises concerns about a protocol design princip= le being changed, you need to argue why such a change is viable rather than= just - need to check EOB anyway.

You code goes some way to address that. I didn=E2=80=99t go = through it in detail (I=E2=80=99m beyond my code line limit for today) but = there could can be problems such as:

ACK frame with length prefix says it does not exceed end of= buffer. Parser reads all data and confirms this fact, so frame is accepted= . What it might miss is that the length points after the end of the parse b= lock leaving undetermined data hanging. Not saying this actually happens, b= ut that is a concern.

Personally, I actually like a length prefix, and generally don=E2=80=99t s= ee a problem with it. But I=E2=80=99d prefer if it was a global principle t= hen rather than mixing those concepts. When this is done in a generic fashi= on, and end pointer can be passed everywhere, and as soon as something does= fit cleanly, abort the connection.




--
Kazuho Oku
The MQTT packet framing uses a length prefix uniformly:


M= ikkel


On 19 June 2018 at 21= .12.13, Eric Rescorla (ekr@rtfm.com) wr= ote:


Not Manasi, but I don't understand (e).

Here's the relevant section of the Minq = decoder.
--000000000000f56c2c056f2d676d-- From nobody Thu Jun 21 16:06:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2D124D68 for ; Thu, 21 Jun 2018 16:06:46 -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 RQjQhMtKP_CQ for ; Thu, 21 Jun 2018 16:06:44 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 20A9A120049 for ; Thu, 21 Jun 2018 16:06:44 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id j135-v6so394706itj.1 for ; Thu, 21 Jun 2018 16:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iBkALlpO7u2PqswytduR1JJQGcZwKT2mCzhoijImdC8=; b=tffL7ylzeq/HHIrG1d6cfxeTlciZoVc7prAQD3wgVz2g0LLQUjxeIMCVb/3Whj45jk WPTzR9rEBreuTf3X5hupF4YUc9yxYpxbqnDBLAg6TQsp8vyd9VAPAbOdlzT/TS/HWrLn zqXJIciCnMX2ZTl+m/Ggi+LfiAhYezYTnsPF5dXVBZcyyNMQvDsDepxXiSeCZLrvd3qd +UdDXVcw/unuJQZdRrWgQwz4HMlkBeY56SrxBGuzLxXtZp3zufRtkdhH1fL/bM7386Mp QAsak6h8/IJP1R5NXQhWy7NKiTYeYo/ad/b3ue6KmloZtmQ1BLvb9yFOiXOrq0/wKA4Q /lQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iBkALlpO7u2PqswytduR1JJQGcZwKT2mCzhoijImdC8=; b=lx35pOk9RRaY7wPV/3VVwwFg1WCBalMSQtvhw23i/Kuk2Fc91XDDyVfk+UMYQMsB46 wrVHYN8K25qmSp10dJCpMyoh704SizF9E6P7EdQlDd7W/05G69FcS3t688mHtPt0+T/o MgH1NH3j435wbezxX7IqgT8/IFypw08Tuil9YHBYv822NmRCR7FMx8zTmG7HvVRkf1h+ VgHJXMxmYQ0pRDgqxTcopEDEtKUkYkhrcWk24KQhDDNWcwwM2yn0eIpaG1km/72a1PFI MNFmrgCuhA7Tgo39m+5HCq01qudv7stmOwsBp66e3qtVD5T+M9X3qd9lKzkDaRLk9eVv ry/A== X-Gm-Message-State: APt69E3qq8kVI0SG5kiQjTqem0tii5CWj3Q6EEXQcRrbDDx7SUaTV/8Q aZxs1w3yHyeH0KqVF892o0c8E2JWKodfe3l61DM= X-Google-Smtp-Source: ADUXVKJ8odluivVpKn63DLM+/pUr2qh0e2Xlabc3LmWXj/88nfK0RNrbUfE8jKcJCs0g1yHS7QPpEO8rCy0ClYZ7+pc= X-Received: by 2002:a24:5594:: with SMTP id e142-v6mr6777838itb.46.1529622403327; Thu, 21 Jun 2018 16:06:43 -0700 (PDT) MIME-Version: 1.0 References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B27A@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B27A@bgb01xud1012> From: Jana Iyengar Date: Thu, 21 Jun 2018 16:06:31 -0700 Message-ID: Subject: Re: Path forward with stream headers To: Lucas Pardue Cc: Roberto Peon , Martin Thomson , QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="000000000000fdb03a056f2ef7a8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 23:06:47 -0000 --000000000000fdb03a056f2ef7a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lucas, It's a matter of training... the tools can certainly help, but my point is that there is value in specific stream IDs being known identifiers, rather than opaque identifiers. I find self-descriptiveness to be valuable. I'm also not yet convinced that we need extensibility in this particular manner. Are there examples of things we anticipate needing this extensibility for, that we wouldn't want a version rev for? - jana On Thu, Jun 21, 2018 at 1:14 PM Lucas Pardue wrote= : > Hi Jana, > > I appreciate the debuggability concerns, can this just be solved by > tooling? Is the issue with trying to look at application debug logs in > realtime as applications receive QUIC packets? > > Wireshark for HTTP/2 already acts statefully when it decrypts sessions an= d > dissects HPACK, would it be terribly difficult for it to read this first > byte and represent the stream type in a convenient way? > > Note that the proposal is just for unidirectional streams - > client-initiated bidi streams are normal request/response on incrementing > stream IDs, that's all that needs to be looked for in a lot of traffic > scenarios. > > I'm probably far less experienced with debugging GQUIC traces but in my > experience cross referencing frames from Stream 3 to the response stream > was always a bit clunky, especially for push promise. See the attached > screenshot of a very old wireshark dissect of GQUIC (NB Alexis La Goutte > quickly fixed the bug with decoding the Header Block Fragment shown in th= at > image, thanks!). > > Lucas > ------------------------------ > *From:* QUIC [quic-bounces@ietf.org] on behalf of Jana Iyengar [ > jri.ietf@gmail.com] > *Sent:* 21 June 2018 20:37 > *To:* Roberto Peon > *Cc:* Martin Thomson; QUIC WG; Mike Bishop > *Subject:* Re: Path forward with stream headers > > Mike's point that the HTTP headers need to be read before reading data > from a stream out of order makes it clear that the first bytes are alread= y > HoL blocking in this current mapping. Given the current mapping, while I'= m > sympathetic to Roberto's argument that there are use cases where an > application might want to read data out of order from a stream, I don't > see additional HoL blocking because of this byte. > > That said, I like the self-descriptiveness of the stream ID. Even for > debugging purposes, it's a matter of training yourself to understand what > stream IDs mean what type of stream, but once that's done, it's always tr= ue > for QUICv1. Having looked at a large number of GQUIC traces, I can say th= at > being able to tell at a glance what a particular stream ID across traces = is > very useful (In GQUIC, stream 1 is crypto, stream 3 is headers, and > stream 5 is the first request stream from the client). With a type byte, > debuggability is worse, since you now must see the first byte and remembe= r > what stream ID maps to what for the rest of the connection, and you need = to > do this for every connection you're looking at. > > Given my experience, I would prefer having stream IDs that are self > descriptive. > > I understand the desire to keep this flexible for future tweaks of > HTTP/QUIC without a version rev, but it is a degree of freedom that we ca= n > surely plan to exercise for things we cannot anticipate right now. I'm no= t > yet convinced that adding this additional extensibility mechanism is > necessary right now. > > > On Wed, Jun 20, 2018 at 3:05 PM Roberto Peon wrote: > >> Yep, you're right, because we're not having HEADERS vs DATA frames as a >> QUIC-layer thing, we're screwed. >> >> -=3DR >> >> =EF=BB=BFOn 6/20/18, 2:48 PM, "Mike Bishop" wrote= : >> >> But you don't know where the body is until you've seen the header. >> Otherwise, you're not certain that what you're seeing *is* body, rather >> than something in a different frame that happens to look like your >> self-description. >> >> -----Original Message----- >> From: Roberto Peon [mailto:fenix@fb.com] >> Sent: Wednesday, June 20, 2018 2:03 PM >> To: Martin Thomson > > >> Cc: Mike Bishop ; QUIC WG >> Subject: Re: Path forward with stream headers >> >> You're assuming the data isn't self-descriptive in the body. >> -=3DR >> >> On 6/19/18, 5:29 PM, "Martin Thomson" > > wrote: >> >> On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon >> wrote: >> > However, if one must receive the first packet of each stream, >> additional HoL blocking (which prevents playback/interpretation) is indu= ced. >> >> This is the bit I'm pushing back on. The first byte isn't >> privileged. >> There's a push ID, a HEADERS frame, and the start of the first >> DATA >> frame before you can start into random access. Without that, yo= u >> can't know what you are reading. I fail to see how one addition= al >> octet is a problem here. >> >> >> >> >> --000000000000fdb03a056f2ef7a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lucas,

It's a matter of training= ... the tools can certainly help, but my point is that there is value in sp= ecific stream IDs being known identifiers, rather than opaque identifiers. = I find self-descriptiveness to be valuable.=C2=A0

= I'm also not yet convinced that we need extensibility in this particula= r manner. Are there examples of things we anticipate needing this extensibi= lity for, that we wouldn't want a version rev for?

- jana

= On Thu, Jun 21, 2018 at 1:14 PM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
Hi Jana,

I appreciate the debuggability concerns, can this just be solved by to= oling? Is the issue with trying to look at application debug logs in realti= me as applications receive QUIC packets?

Wireshark for HTTP/2 already acts statefully when it decrypts sessions= and dissects HPACK, would it be terribly difficult for it to read this fir= st byte and represent the stream type in a convenient way?

Note that the proposal is just for unidirectional streams - client-ini= tiated bidi streams are normal request/response on incrementing stream IDs,= that's all that needs to be looked for in a lot of traffic scenarios.<= br>

I'm probably far less experienced with debugging GQUIC traces but = in my experience cross referencing frames from Stream 3 to the response str= eam was always a bit clunky, especially for push promise. See the attached = screenshot of a very old wireshark dissect of GQUIC (NB Alexis La Goutte quickly fixed the bug with decoding the Head= er Block Fragment shown in that image, thanks!).

Lucas
From: QUIC [quic-bounces@ietf.org]= on behalf of Jana Iyengar [jri.ietf@gmail.com]
Sent: 21 June 2018 20:37
To: Roberto Peon
Cc: Martin Thomson; QUIC WG; Mike Bishop
Subject: Re: Path forward with stream headers

Mike's point that the HTTP headers need to be read bef= ore reading data from a stream out of order makes it clear that the first b= ytes are already HoL blocking in this current mapping. Given the current ma= pping, while=C2=A0I'm sympathetic to Roberto's argument that there are use cases where an ap= plication might want to read data out of order from a stream,=C2=A0I= don't see additional HoL blocking because of this byte.

That said, I like the self-descriptiveness of the stream ID. Even for = debugging purposes, it's a matter of training yourself to understand wh= at stream IDs mean what type of stream, but once that's done, it's = always true for QUICv1. Having looked at a large number of GQUIC traces, I can say that being able to tell at a glance what= a particular stream ID across traces is very useful (In GQUIC, stream 1 i= s crypto, stream 3 is headers, and stream 5 is the first request stream from the client).=C2=A0=C2=A0<= span style=3D"background-color:rgb(255,255,255);float:none;display:inline">= With a type byte, debuggability is worse, since you now must see the first = byte and remember what stream ID maps to what for the rest of the connection, and you need to do this for every connecti= on you're looking at.

Given my experience, I would prefer having stream IDs that are self descrip= tive.

I understand the desire to keep this flexible for future tweaks of HTTP/QUI= C without a version rev, but it is a degree of freedom that we can surely p= lan to exercise for things we cannot anticipate right now. I'm not yet = convinced that adding this additional extensibility mechanism is necessary right now.


On Wed, Jun 20, 2018 at 3:05 PM Roberto Peon <feni= x@fb.com> wrote:
Yep, you're right, because we're not having HEADERS vs DATA frames = as a QUIC-layer thing, we're screwed.

-=3DR

=EF=BB=BFOn 6/20/18, 2:48 PM, "Mike Bishop" <mbisho= p@evequefou.be> wrote:

=C2=A0 =C2=A0 But you don't know where the body is until you've see= n the header.=C2=A0 Otherwise, you're not certain that what you're = seeing *is* body, rather than something in a different frame that happens t= o look like your self-description.

=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: Roberto Peon [mailto:fenix@fb.com]
=C2=A0 =C2=A0 Sent: Wednesday, June 20, 2018 2:03 PM
=C2=A0 =C2=A0 To: Martin Thomson <martin.thomson@gmail.c= om>
=C2=A0 =C2=A0 Cc: Mike Bishop <mbishop@evequefou.be>; = QUIC WG <quic@ietf.org>
=C2=A0 =C2=A0 Subject: Re: Path forward with stream headers

=C2=A0 =C2=A0 You're assuming the data isn't self-descriptive in th= e body.
=C2=A0 =C2=A0 -=3DR

=C2=A0 =C2=A0 On 6/19/18, 5:29 PM, "Martin Thomson" <martin.thomson@gmail..com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon &= lt;fenix@fb.com> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > However, if one must receive the first pac= ket of each stream, additional HoL blocking (which prevents playback/interp= retation) is induced.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the bit I'm pushing back on.=C2=A0 = The first byte isn't privileged.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There's a push ID, a HEADERS frame, and the= start of the first DATA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 frame before you can start into random access.= =C2=A0 Without that, you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 can't know what you are reading.=C2=A0 I fa= il to see how one additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 octet is a problem here.




--000000000000fdb03a056f2ef7a8-- From nobody Thu Jun 21 16:09:01 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF7126CB6 for ; Thu, 21 Jun 2018 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIFRV7bEdurc for ; Thu, 21 Jun 2018 16:08:54 -0700 (PDT) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 33754120049 for ; Thu, 21 Jun 2018 16:08:54 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 16:08:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.51,253,1526367600"; d="scan'208,217"; a="68990313" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga002.jf.intel.com with ESMTP; 21 Jun 2018 16:08:53 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX107.amr.corp.intel.com ([169.254.1.167]) with mapi id 14.03.0319.002; Thu, 21 Jun 2018 16:08:53 -0700 From: "Deval, Manasi" To: 'Marten Seemann' CC: Ian Swett , Kazuho Oku , "Eric Rescorla" , Jana Iyengar , "Praveen Balasubramanian" , IETF QUIC WG , "Martin Thomson" Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7X+IAADpdCoAAAtMWAABL8DbA= Date: Thu, 21 Jun 2018 23:08:51 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTI1YzU5NjAtNmQ0My00MTNlLTlmMzEtZDA1ODZiY2MxMjc0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZStcL2k0U1ZwZERWRjFqaDRsR2hybTJUNkkwSlwvUEhhSDBDUSs5TGZrRXB3VitFUDFoWUtXdnQ1a29JdjM2TUh2In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B843873ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 23:09:00 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B843873ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmZWVsIHRoYXQgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgZXZlcnkgdmFsdWUgdmFsaWQgaXMg c29tZXdoYXQgYWNhZGVtaWMuIFRoZSBsZW5ndGggdmFsdWUgcHJvdmlkZXMgbXVjaCBtb3JlIHZh bHVlIHRoYW4gdGhlIGJsb2NrIGNvdW50IGFuZCB0aGUgZmFjdCB0aGF0IGNlcnRhaW4gdmFsdWVz IGNhbiBuZXZlciBiZSBhY2hpZXZlZCBpcyBhbiBpbmhlcmVudCBwcm9wZXJ0eSBvZiB0aGUgbGVu Z3RoLg0KDQpPbmUgaW50ZXJlc3Rpbmcgb2JzZXJ2YXRpb24gaXMgdGhhdCB0aGlzIHByb3BlcnR5 IGlzIG5vdCBsaW1pdGVkIHRvIGxlbmd0aC4gT25lIGNhbiBldmVuIG1ha2UgYSBzaW1pbGFyIGFy Z3VtZW50IGFib3V0IEFDSyBibG9jayBjb3VudC4gVGhlIG1heGltdW0gbnVtYmVyIG9mIEFDSyBi bG9ja3MgdGhhdCBjYW4gYmUgZGVmaW5lZCB3aWxsIG5vdCBhbHdheXMgaGF2ZSBhIG1lYW5pbmdm dWwgdmFsdWUuIEluIG91dCBleGFtcGxlcywgMCwxLDIsMyBhcmUgYWxsIHZhbGlkLiBJZiBJIHNl dCB0aGUgdmFsdWUgb2YgQUNLIGJsb2NrIGNvdW50IHRvIGhhdmUgbG93ZXIgdHdvIGJpdHMgdG8g YmUgMTEsIHRoZSBtYXhpbXVtIHZhbHVlIGlzIG9mIEFDSyBibG9ja3MgaXMg4oCTIDQ2MTE2ODYw MTg0MjczODc5MDMuIFRoaXMgaXMgdGhlIHNhbWUgdmFsdWUgb2YgbGFyZ2VzdCBhY2tub3dsZWRn ZWQgc28gaWYgdGhlIEFDSyBibG9jayBjb3VudCB3YXMgc2V0IHRvIHRoaXMgdmFsdWUsIGl0IHdv dWxkIHN0aWxsIGJlIG1lYW5pbmdsZXNzLg0KDQpUaGFua3MsDQpNYW5hc2kNCg0KDQoNCg0KRnJv bTogTWFydGVuIFNlZW1hbm4gW21haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggNjo0NCBQTQ0KVG86IERldmFsLCBNYW5hc2kgPG1hbmFz aS5kZXZhbEBpbnRlbC5jb20+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsg S2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47IEVyaWMgUmVzY29ybGEgPGVrckBydGZt LmNvbT47IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPjsgUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDog UmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0K DQpIaSBNYW5hc2ksDQoNCj4gVGhlIHJpc2sgb2YgZGlzYWdyZWVtZW50IGJldHdlZW4gYWNrIGJs b2NrcyBhbmQgYWNrIGJsb2NrIGNvdW50IGlzIHNhbWUgYXMgdGhlIHJpc2sgb2YgZGlzYWdyZWVt ZW50IGJldHdlZW4gYWNrIGJsb2NrcyBhbmQgYWNrIGxlbmd0aC4gRWl0aGVyIHdheSB0aGlzIG5l ZWRzIHRvIGJlIGNvdW50ZWQgdXAgd2hpbGUgY3JlYXRpbmcgdGhlIEFDSyBhbmQgY291bnRlZCBk b3duIHdoaWxlIHBhcnNpbmcgaXQuIFRoZSBwb3NzaWJpbGl0eSBvZiBlcnJvciBpcyB0aGUgc2Ft ZS4gR2V0dGluZyB0aGUgYWNrIGJsb2NrIGNvdW50IHdyb25nIGlzIGFzIHByb2JsZW1hdGljIGFz IGdldHRpbmcgdGhlIGFjayBsZW5ndGggd3JvbmcuIERvIHlvdSBhZ3JlZT8NCg0KSSBkaXNhZ3Jl ZS4gTGV0J3MgdGFrZSBhbiBleGFtcGxlIG9mIGFuIEFDSyBmcmFtZSB3aXRoIG9uZSBBQ0sgcmFu Z2UsIHRoYXQgbmVlZHMgYSAyIGJ5dGUgdmFyaW50IHRvIHJlcHJlc2VudCB0aGUgRmlyc3QgQUNL IEJsb2NrIGFuZCBhbm90aGVyIDIgYnl0ZSB2YXJpbnQgdG8gcmVwcmVzZW50IHRoZSBHYXAuDQpX aXRoIHlvdXIgcHJvcG9zYWw6DQoNCiAgMS4gIFRoZSB2YWx1ZXMgMCBhbmQgMSBhcmUgaW52YWxp ZCwgc2luY2UgdGhlIGxlbmd0aCBmaWVsZHMgaXRzZWxmIGlzIGluY2x1ZGVkIGluIHRoZSBsZW5n dGguDQogIDIuICBUaGUgdmFsdWVzIDIsIDMsIC4uLiwgKDIgKyBsZW4oTGFyZ2VzdEFja25vd2xl ZGdlZCkgKyBsZW4oQWNrRGVsYXkpKSAtIDEgYXJlIGludmFsaWQsIHNpbmNlIHRoZSBsZW5ndGgg bmVlZHMgdG8gaW5jbHVkZSB0aGUgTGFyZ2VzdCBBY2tub3dsZWRnZWQgYW5kIHRoZSBBY2sgRGVs YXkuDQogIDMuICBUaGUgdmFsdWUgMiArIGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSArIGxlbihB Y2tEZWxheSkgd291bGQgYmUgdGhlIGZpcnN0IHZhbGlkIHZhbHVlLCBhbmQgY29ycmVzcG9uZCB0 byBhbiBBQ0sgZnJhbWUgd2l0aCBubyBibG9ja3MuDQogIDQuICBUaGUgdmFsdWUgMiArIGxlbihM YXJnZXN0QWNrbm93bGVkZ2VkKSArIGxlbihBY2tEZWxheSkgKyAxIGlzIGludmFsaWQsIHNpbmNl IGl0IHdvdWxkIGN1dCB0aGUgdmFyaW50IGZvciB0aGUgRmlyc3QgQUNLIEJsb2NrDQogIDUuICBU aGUgdmFsdWUgMiArIGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSArIGxlbihBY2tEZWxheSkgKyAy IGlzIGludmFsaWQsIHNpbmNlIGl0IHdvdWxkIGN1dCB0aGUgZnJhbWUgYWZ0ZXIgdGhlIEZpcnN0 IEFDSyBCbG9jayAoYnV0IGV2ZXJ5IGJsb2NrIG11c3QgYmUgZm9sbG93ZWQgYnkgYSBnYXAgbGVu Z3RoKQ0KICA2LiAgVGhlIHZhbHVlIDIgKyBsZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkgKyBsZW4o QWNrRGVsYXkpICsgMyBpcyBpbnZhbGlkLCBzaW5jZSBpdCB3b3VsZCBjdXQgdGhlIHZhcmludCBm b3IgdGhlIEdhcA0KICA3LiAgRmluYWxseSwgdGhlIHZhbHVlIDIgKyBsZW4oTGFyZ2VzdEFja25v d2xlZGdlZCkgKyBsZW4oQWNrRGVsYXkpICsgNCBpcyB2YWxpZA0KVGhlcmUgYXJlICphIGxvdCog b2YgaW52YWxpZCB2YWx1ZXMgdGhhdCB5b3UgY2FuIGVuY29kZSBpbnRvIHRoZSBBQ0sgbGVuZ3Ro IGZpZWxkLiBNb3JlIGltcG9ydGFudGx5LCAqbm9uZSogb2YgdGhlc2UgZXJyb3IgY2FzZXMgZXhp c3RzIHdpdGggdGhlIGN1cnJlbnQgZnJhbWUgZm9ybWF0Lg0KVGhlICpvbmx5KiBlcnJvciBjYXNl IHRoYXQgY2FuIG9jY3VyIHdpdGggb3VyIGN1cnJlbnQgZm9ybWF0IGlzIHRoYXQgdGhlIHBhY2tl dCBpcyB0b28gc2hvcnQgZm9yIHRoZSBudW1iZXIgb2YgQUNLIGJsb2NrcyB0aGF0IGFyZSBzdXBw b3NlZCB0byBjb250YWluZWQgaW4gdGhlIGZyYW1lLiBUaGlzIGNhbiBvY2N1ciB3aXRoIHlvdXIg cHJvcG9zYWwgYXMgd2VsbCAoaW4gYWRkaXRpb24gdG8gdGhlIGVycm9yIGNhc2VzIGxpc3RlZCBh Ym92ZSkuDQoNCk15IGNvbmNlcm4gaXMgbm90IHRoYXQgaXQncyBpbXBvc3NpYmxlIG9yIGV2ZW4g cGFydGljdWxhcmx5IGhhcmQgdG8gY2F0Y2ggdGhlc2UgZXJyb3JzLCBidXQgSSBkaXNsaWtlIHRo ZSBwcm9wZXJ0eSB0aGF0IHNvbWUgKGluIGZhY3QsIG1vc3QpIGVuY29kYWJsZSB2YWx1ZXMgYXJl IGludmFsaWQuDQoNCkJlc3QsDQpNYXJ0ZW4NCg0KDQpPbiBXZWQsIEp1biAyMCwgMjAxOCBhdCAz OjIxIEFNIERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFz aS5kZXZhbEBpbnRlbC5jb20+PiB3cm90ZToNCkhpIElhbiwNCg0KSGVyZSBpcyBhbm90aGVyIGF0 dGVtcHQgdG8gc29sdmUgdGhlIG9iamVjdGlvbnMgeW91IHJhaXNlZDoNCg0KPkknbSBub3QgYSBm YW4gb2YgdGhpcyBwcm9wb3NhbCwgYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRv IGRyb3AgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCBiZWNhdXNlIHdpdGggdGhlIEVDTiBwcm9w b3NhbCBpdCBiZWNvbWVzIGltcHJhY3RpY2FsbHkgY29tcGxleCB0byBwYXJzZS4NCklzIHRoZXJl IGEgcmVhc29uIHRoZSBwcm9wb3NhbCBmcm9tIENocmlzdGlhbiBkb2VzIG5vdCBzb2x2ZSB0aGlz IHByb2JsZW0/DQoNCj5JZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tz LCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMgbGFyZ2VyLCBidXQgSSBkb24ndCB0aGluayB0aGUgZXh0 cmEgc2l6ZSBmaWVsZCBpcyB1c2VmdWwgZm9yIG1vc3QgaW1wbGVtZW50YXRpb25zLiAgQWxzbywg aXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxlbmd0aCwg d2hpY2ggYWRkIGNvbXBsZXhpdHkgYW5kIHRoZSBwb3NzaWJpbGl0eSBvZiB3cml0aW5nIGVycm9y LXByb25lIGNvZGUuICBUaGUgaWRlYSBvZiBzb21lb25lIG9mZmxvYWRpbmcgYWNrIHByb2Nlc3Np bmcgYW5kIHRoZW4gcHJvY2VlZGluZyB0byB0cnVzdCB0aGUgbGVuZ3RoIHNlZW1zIGxpa2Ugc29t ZW9uZSBjb3VsZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuDQpU aGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgYmxvY2sg Y291bnQgaXMgc2FtZSBhcyB0aGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxv Y2tzIGFuZCBhY2sgbGVuZ3RoLiBFaXRoZXIgd2F5IHRoaXMgbmVlZHMgdG8gYmUgY291bnRlZCB1 cCB3aGlsZSBjcmVhdGluZyB0aGUgQUNLIGFuZCBjb3VudGVkIGRvd24gd2hpbGUgcGFyc2luZyBp dC4gVGhlIHBvc3NpYmlsaXR5IG9mIGVycm9yIGlzIHRoZSBzYW1lLiBHZXR0aW5nIHRoZSBhY2sg YmxvY2sgY291bnQgd3JvbmcgaXMgYXMgcHJvYmxlbWF0aWMgYXMgZ2V0dGluZyB0aGUgYWNrIGxl bmd0aCB3cm9uZy4gRG8geW91IGFncmVlPw0KDQo+TXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVh ZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yayB0aGFuIGl0J3Mgd29y dGguICBTdXJlIHlvdSBjYW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0aCBvbmUgY29ubmVjdGlvbiwg YnV0IHRoYXQgc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3Jr bG9hZHMgSSd2ZSBzZWVuLiAgVHlwaWNhbGx5IHRoZSBleHRyYSBjb3N0IG9mIG11bHRpdGhyZWFk aW5nIG91dHdlaWdocyBpdHMgdmFsdWUuDQpUaGUgdmFsdWUgaXMgdHdvIGZvbGQg4oCTIHByZS1w cm9jZXNzaW5nIGFuZCBtdWx0aS10aHJlYWRpbmcuIElmIHdlIHByZS1wcm9jZXNzIHRoZSByZWNl aXZlZCBwYWNrZXRzIHN1Y2ggdGhhdCBBQ0tzIGFuZCBzdHJlYW1zIGNhbiBiZSBjb2FsZXNjZWQs IHRoZSByZWNlaXZlIHNpZGUgY2FuIGluZGljYXRlIGEgbGFyZ2UgY2h1bmsgb2YgaW5mb3JtYXRp b24gdGhvdWdoIHRoZSBrZXJuZWwsIHJlZHVjaW5nIHRoZSBjb3N0IG9mIHN5c3RlbSBjYWxsIGFu ZCBwcm90b2NvbCBvdmVyaGVhZC4gVGhpcyBpcyB0aGUgc2FtZSBjb25jZXB0IGFzIFVEUCBzZWdt ZW50YXRpb24gdGFrZW4gYSBzdGVwIGZ1cnRoZXIgb24gcmVjZWl2ZSBzaWRlLiBBZnRlciB0aGlz IGNodW5rIGlzIGluZGljYXRlZCBpbnRvIHRoZSBRVUlDIHByb3RvY29sLCB0aGUgcHJvdG9jb2wg bWF5IHByb2Nlc3Mgc3RyZWFtIGFuZCBBQ0sgaW4gcGFyYWxsZWwuIFdoaWxlIGZvbGtzIG1heSBv ciBtYXkgbm90IHV0aWxpemUgdGhpcywgdGhlcmUgaXMgYW4gYWR2YW50YWdlIGhlcmUuDQoNClRo YW5rcywNCk1hbmFzaQ0KDQoNCkZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+XQ0KU2VudDogVHVlc2RheSwgSnVuZSAx OSwgMjAxOCAxMToyNiBBTQ0KVG86IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5j b208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+Pg0KQ2M6IE1hcnRlbiBTZWVtYW5uIDxt YXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+Pjsg S2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNv bT4+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBK YW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21haWwuY29t Pj47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpw cmF2YkBtaWNyb3NvZnQuY29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29t PG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KDQpTdWJqZWN0OiBSZTogUHJvcG9z YWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoDQoNCkknbSBzdGls bCBub3QgaW50ZXJlc3RlZCBpbiB0aGlzIGNoYW5nZSwgZm9yIHRoZSByZWFzb25zIEkgc3RhdGVk IGFib3ZlLg0KDQpPbiBUdWUsIEp1biAxOSwgMjAxOCBhdCAyOjIxIFBNIERldmFsLCBNYW5hc2kg PG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+PiB3 cm90ZToNCkhpIEFsbCwNCg0KRG8gd2UgaGF2ZSBhZ3JlZW1lbnQgaGVyZSB0byBjcmVhdGUgYSBu ZXcgUFI/DQoNClRoYW5rcywNCk1hbmFzaQ0KDQpGcm9tOiBEZXZhbCwgTWFuYXNpDQpTZW50OiBT dW5kYXksIEp1bmUgMTcsIDIwMTggMjoyNSBQTQ0KVG86IE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5z ZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+PjsgS2F6dWhv IE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpD YzogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv OjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNv bTxtYWlsdG86anJpLmlldGZAZ21haWwuY29tPj47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxw cmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj47IElFVEYgUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBNYXJ0aW4gVGhvbXNv biA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20+Pg0KU3ViamVjdDogUkU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdp dGggQUNLIGxlbmd0aA0KDQpIaSBBbGwsDQoNCkkgaGF2ZSBtYWRlIGEgbGlzdCBvZiBvYmplY3Rp b25zIHRvIHRoZSBwcm9wb3NhbCBhbmQgdGhlIHNvbHV0aW9ucyB0byB0aG9zZSBvYmplY3Rpb25z IGRpc2N1c3NlZCBvbiB0aGlzIHRocmVhZC4NCg0KDQphLiAgICAgIENvLWV4aXN0ZW5jZSBvZiBs ZW5ndGggZmllbGQgd2l0aCBFQ04gZmllbGQgYW5kIEFDSyBibG9ja3MuDQoNCg0KDQpDaHJpc3Rp YW4gc3VnZ2VzdGVkIHRvIG1vdmUgdGhlIEVDTiBmaWVsZHMgdG8gcHJlY2VkZSB0aGUgQUNLIGJs b2Nrcy4gVGhpcyBpcyBhbiBlbGVnYW50IHNvbHV0aW9uLiBQYXJzaW5nIGVudGlyZSBsaXN0IG9m IEFDSyBibG9ja3MgdG8gcmV2aWV3IEVDTiBiaXRzIHdvdWxkIGhhdmUgYmVlbiBhbm5veWluZywg ZXZlbiB0aG91Z2ggaXQgY2FuIHdvcmsuDQoNCg0KDQpiLiAgICAgIFRoZXJlIGFyZSB0d28gY2Fz ZXMgdG8gYmUgcGFyc2VkIOKAkyBlbnRpcmUgQUNLIGFuZCBwYXJzZSBBQ0sgdG8gaWRlbnRpZnkg bGVuZ3RoLiBUaGVyZSBhcmUgc29tZSByZXNlcnZhdGlvbnMgd2hlbiBBQ0sgcGFyc2luZyBnZXRz IGhhcmRlciBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGVudGlyZSBoZWFkZXIgbmVlZHMgdG8gYmUg cGFyc2VkLg0KDQoNCg0KQWdyZWVtZW50IGZyb20gc2V2ZXJhbCBmb2xrcyBoZXJlLiBJbiB0aGUg b3JpZ2luYWwgQUNLIGRlZmluZWQgaW4gZHJhZnQgMTIgb2YgdGhlIHNsaWRlLCBvbmUgd291bGQg Y291bnQgZG93biBudW1iZXIgb2YgQUNLIGJsb2NrcyB0byBnZXQgdG8gdGhlIGVuZCBvZiB0aGUg cGFja2V0LiBJbiB0aGUgcHJvcG9zYWwgSSBtYWRlLCBvbmUgd291bGQgY291bnQgZG93biB0aGUg bGVuZ3RoIHRvIGlkZW50aWZ5IHRoZSBlbmQgb2YgdGhlIHBhY2tldC4gVGhlIGxvZ2ljIGlzIHZl cnkgc2ltaWxhciBpbiBjeWNsZSBjb3VudCBhbmQgY29tcGxleGl0eS4gU2V2ZXJhbCBmb2xrcyBh bHNvIGNvbW1lbnRlZCB0byB0aGlzIGVmZmVjdC4NCg0KDQoNCmMuICAgICAgTXVsdGktdGhyZWFk ZWQgcGFja2V0IHByb2Nlc3NpbmcNCg0KDQoNCkkgd291bGQgZXhwZWN0IHRoYXQgdGhlcmUgYXJl IDEwcyBvZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1c2UgYXQgYW55IHRpbWUgZm9yIGEgc2Vy dmVyIHdpdGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRpLXRocmVhZGluZyB0byBoYW5kbGUgZWFj aCBvZiB0aGVzZSBmbG93cyAvIGNvbm5lY3Rpb25zIGluIHBhcmFsbGVsIGlzIG5lY2Vzc2l0eSB0 byBiZSBhYmxlIHRvIHN1cHBvcnQgbGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIG9uIGEgaGln aCBzcGVlZCBsaW5rLiBUeCBzZWdtZW50YXRpb24sIFJ4IGNvYWxlc2NpbmcgYXJlIHdlbGwga25v d24gc3RyYXRlZ2llcyB0byByZWR1Y2UgdGhlIHByb2Nlc3NpbmcgY29zdC4gSW4gaW5pdGlhbCBz dGFnZXMsIGNvZGUgaXMgb2Z0ZW4gd3JpdHRlbiBhcyBhIHNpbmdsZS10aHJlYWRlZCBhbmQgdGhl biByZS1mYWN0b3JlZCB0byBwYXJhbGxlbGl6ZSBjeWNsZSBpbnRlbnNpdmUgb3BlcmF0aW9ucy4g SW4gb3JkZXIgdG8gYWxsb3cgdGhpcyBwcm90b2NvbCB0byBzY2FsZSBpbiBmdXR1cmUsIEkgd291 bGQgc3VnZ2VzdCB3ZSBkbyBub3QgcHJlY2x1ZGUgdGhpcyBjYXNlLg0KDQoNCg0KZC4gICAgICBJ bmNyZWFzZSBpbiBBQ0sgc2l6ZSBieSAxIGJ5dGUuDQoNCg0KDQpJIGRvIG5vdCBzZWUgdGhpcyBh cyBhIHNlcmlvdXMgaXNzdWUgYnV0IGlmIGZvbGtzIGJ1dCB3ZSBjYW4gY29uc2lkZXIgbWFraW5n IHRoaXMgYSB2YXJpbnQsIGlmIG90aGVycyBoYXZlIHN0cm9uZyBmZWVsaW5ncyBhYm91dCBpdC4g SXTigJlzIGEgdHJhZGUtb2ZmIDogMiByZWFkcyB0byBzYXZlIDEgYnl0ZS4NCg0KDQoNCmUuICAg ICAgRXZlcnkgZW5jb2RhYmxlIHZhbHVlIHNob3VsZCBiZSB2YWxpZA0KDQpOb3QgZXZlcnkgbGVu Z3RoIHdpbGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVuZ3Rocy4gVGhpcyBzYW1l IGlzc3VlIGFpbHMgdGhlIOKAmHBheWxvYWQgbGVuZ3Ro4oCZIGluIFFVSUMgaGVhZGVyLiBOb3Qg b25seSBkb2VzIHRoZSBpc3N1ZSBleGlzdCBmb3Igc21hbGwgdmFsdWVzLCBpdCBhbHNvIGFwcGxp ZXMgdG8gbGFyZ2UgdmFsdWVzIHNpbmNlIGRhdGEgc3RyZWFtIHdpbGwgYmUgc2VudCBhZnRlciBj cnlwdG8gbmVnb3RpYXRpb24uICBFLmcuICAtIGhvdyBkb2VzIG9uZSBjcmFmdCBhIHBheWxvYWQg d2l0aCA2MiBiaXQgcGF5bG9hZCBsZW5ndGggaW4gYSBsYXJnZSBoZWFkZXI/DQoNCg0KDQoNCg0K VGhhbmtzLA0KDQpNYW5hc2kNCg0KDQoNCkZyb206IE1hcnRlbiBTZWVtYW5uIFttYWlsdG86bWFy dGVuc2VlbWFubkBnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIEp1bmUgMTcsIDIwMTggNjo1OSBB TQ0KVG86IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBn bWFpbC5jb20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPG1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgSmFuYSBJeWVu Z2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbT4+OyBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWlj cm9zb2Z0LmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86 bWFydGluLnRob21zb25AZ21haWwuY29tPj47IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBp bnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+Pg0KU3ViamVjdDogUmU6IFBy b3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KDQpNYXli ZSBpdCdzIHNwZWNpZmljIHRvIEdvLCBidXQgSSdtIHVzaW5nIGEgc2luZ2xlIGlvLlJlYWRlciBm b3IgdGhlIHdob2xlIHBhY2tldCwgc28gYXMgbG9uZyBhcyB0aGUgcGFja2V0IHBheWxvYWQgaXMg bG9uZyBlbm91Z2gsIHRoZSB2YXJpbnQgcGFyc2luZyB3aWxsIG5vdCBmYWlsLg0KSSBkb24ndCB0 aGluayB0aGF0IHNwZWNpZmljcyBvZiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVyIGhlcmUg dGhvdWdoLCBhbmQgSSdtIHN1cmUgYm90aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25hYmx5 IGltcGxlbWVudGVkIGluIEMgYXMgd2VsbCBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdtIG9wcG9z ZWQgdG8gTWFuYXNpJ3MgcHJvcG9zYWwgYXJlIHRoYXQgaXQgbW92ZXMgdXMgYXdheSBmcm9tIHRo ZSBwcmluY2lwbGUgdGhhdCBvbmx5IHJlYXNvbmFibGUgdmFsdWVzIHNob3VsZCBiZSBlbmNvZGFi bGUsIGFuZCB0aGF0IGl0IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lLCBmb3Ig dGhlIHF1ZXN0aW9uYWJsZSBiZW5lZml0IG9mIGJlaW5nIGFibGUgdG8gcGFyYWxsZWxpc2UgdGhl IGZyYW1lIHBhcnNlci4NCg0KT24gU3VuLCBKdW4gMTcsIDIwMTggYXQgODo0OCBQTSBLYXp1aG8g T2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4gd3Jv dGU6DQoyMDE4LTA2LTE3IDIyOjM2IEdNVCswOTowMCBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2Vl bWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj46DQo+IEF0IGxl YXN0IGZvciBteSBpbXBsZW1lbnRhdGlvbiwgcGFyc2luZyBkb2Vzbid0IGJlY29tZSBlYXNpZXIs IGl0IGJlY29tZXMNCj4gbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50 LXBhcnNlciBhbHdheXMgY29uc3VtZXMgYXMgbWFueQ0KPiBieXRlcyBhcyB0aGUgdmFyaW50IHJl cXVpcmVzLCBzbyBhZnRlciBwYXJzaW5nIGEgdmFyaW50LCBJJ2QgaGF2ZSB0bw0KPiBpbnRyb2R1 Y2UgYW4gYWRkaXRpb25hbCBjaGVjayB0aGF0IHRoaXMgZGlkbid0IG92ZXJmbG93IHRoZSBBQ0sg bGVuZ3RoIChlLmcuDQo+IGNvbnNpZGVyIHRoYXQgSSBwYXJzZWQgdGhlIEFDSyBmcmFtZSBzbyBm YXIgdGhhdCBvbmx5IDIgYnl0ZXMgYXJlIHJlbWFpbmluZw0KPiBhY2NvcmRpbmcgdG8gQUNLIGxl bmd0aCBmaWVsZCwgYnV0IHRoZSBuZXh0IHZhcmludCBpcyA0IGJ5dGVzIGxvbmcpLg0KDQpJc24n dCB5b3VyIHZhcmludCBwYXJzZXIgY2hlY2tpbmcgdGhhdCBpdCBoYXMgbm90IChvciB3aWxsIG5v dCkgcnVuDQphY3Jvc3MgdGhlIGVuZCBvZiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IEFD SyBibG9jayBpdCBwYXJzZXM/DQpJJ2QgYXNzdW1lIHRoYXQgeW91IHdvdWxkIGJlIGRvaW5nIHRo YXQsIGJlY2F1c2UgSSB0aGluayB0aGF0IGlzDQpuZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92 ZXJydW4uDQoNCldoYXQgSSBhbSBzYXlpbmcgdGhhdCB0aGF0IGNoZWNrIGNvdWxkIGJlIGNvbnZl cnRlZCB0byBhIG92ZXJydW4gY2hlY2sNCmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgImZyYW1lIHBh eWxvYWQiLCBhbmQgdGhhdCBjaGVja2luZyB0aGUNCnJlbWFpbmluZyBibG9jayBjb3VudCBiZWNv bWVzIHVubmVjZXNzYXJ5LCBpbiBjYXNlIHdlIHJlcGxhY2UgQUNLDQpCbG9jayBDb3VudCB3aXRo IEFDSyBGcmFtZSBMZW5ndGguDQoNCj4NCj4gSW4gZ2VuZXJhbCwgd2UndmUgYmVlbiBtb3Zpbmcg dGhlIHdpcmUgaW1hZ2UgdG93YXJkcyBtYWtpbmcgZXZlcnkgZW5jb2RhYmxlDQo+IHZhbHVlIHZh bGlkLiBUaGlzIHByb3Bvc2FsIG1vdmVzIHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBsZToNCj4g KiBzb21lIHNtYWxsIHZhbHVlcyBhcmUgYWx3YXlzIGludmFsaWQgKHRoZSBsZW5ndGggY2FuIG5l dmVyIGJlIGJldHdlZW4gMA0KPiBhbmQgMykNCj4gKiBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFs dWVzIGFyZSBpbnZhbGlkIChpZiB0aGUgYm91bmRhcnkgZmFsbHMgaW5zaWRlIGENCj4gdmFyaW50 LCBhcyBkZXNjcmliZWQgYWJvdmUpDQo+IEJvdGggdGhlc2UgY2FzZXMgY2FuJ3Qgb2NjdXIgd2l0 aCB0aGUgY3VycmVudCBBQ0sgZnJhbWUgZm9ybWF0Lg0KPg0KPiBPbiBTdW4sIEp1biAxNywgMjAx OCBhdCA3OjU0IFBNIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVo b29rdUBnbWFpbC5jb20+PiB3cm90ZToNCj4+DQo+PiAyMDE4LTA2LTE3IDg6MzQgR01UKzA5OjAw IElhbiBTd2V0dA0KPj4gPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj46DQo+PiA+IEknbSBub3QgYSBmYW4gb2Yg dGhpcyBwcm9wb3NhbCwgYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRvDQo+PiA+ IGRyb3ANCj4+ID4gdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCBiZWNhdXNlIHdpdGggdGhlIEVD TiBwcm9wb3NhbCBpdCBiZWNvbWVzDQo+PiA+IGltcHJhY3RpY2FsbHkgY29tcGxleCB0byBwYXJz ZS4NCj4+DQo+PiBGb3IgdGhlIEVDTiBwcm9wb3NhbCwgYXMgQ2hyaXN0aWFuIGhhcyBzdWdnZXN0 ZWQsIHdlIGNhbiBtb3ZlIHRoZSBFQ04NCj4+IGNvdW50ZXJzIGJlZm9yZSB0aGUgQUNLIGJsb2Nr cy4gVGhlbiwgaXQgd291bGQgbm90IGJlIGNvbXBsZXggdG8NCj4+IHBhcnNlLg0KPj4NCj4+IEFu ZCBteSB2aWV3IGlzIHRoYXQgcGFyc2luZyBiZWNvbWVzIGVhc2llciBpZiB3ZSByZXBsYWNlIEFD SyBCbG9jaw0KPj4gQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLg0KPj4NCj4+IE5vdywgd2l0 aCBBQ0sgQmxvY2sgQ291bnQsIHdlIG5lZWQgdG8gY2hlY2sgdGhlIHJlbWFpbmluZyBudW1iZXIg b2YNCj4+IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0IHBheWxv YWQgZm9yIGV2ZXJ5IGJsb2NrDQo+PiB0aGF0IHdlIHBhcnNlLiBGYWlsaW5nIHRvIGNoZWNrIGVp dGhlciBsZWFkcyB0byBhIGJ1ZyBvciBhIHNlY3VyaXR5DQo+PiBpc3N1ZS4NCj4+DQo+PiBJZiB3 ZSBzd2l0Y2ggdG8gQUNLIEZyYW1lIExlbmd0aCwgd2UgbmVlZCB0byBvbmx5IGNoZWNrIHRoZSBy ZW1haW5pbmcNCj4+IHNwYWNlIGluIHRoZSBmcmFtZS4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgdGhp cyBpcyB0aGUgYmlnZ2VzdCBiZW5lZml0IG9mIHJlcGxhY2luZyBBQ0sgQmxvY2sgQ291bnQNCj4+ IHdpdGggQUNLIEZyYW1lIExlbmd0aC4gT1RPSCB0aGUgZG93bnNpZGUgaXMgdGhhdCB5b3UgbmVl ZCBleHRyYSBvbmUgdG8NCj4+IHR3byBiaXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBn YXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVsb3cgNjUsDQo+PiB0d28gaWYgdGhleSBhcmUgZXhwZWN0 ZWQgdG8gYmUgYWJvdmUgdGhhdCkgZm9yIGVuY29kaW5nIEFDSyBGcmFtZQ0KPj4gTGVuZ3RoIGNv bXBhcmVkIHRvIEFDSyBCbG9jayBDb3VudC4NCj4+DQo+Pg0KPj4NCj4+IEhhdmluZyBzYWlkIHRo YXQsIEkgaG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUgaXQncw0K Pj4gbGVuZ3RoIGJlaW5nIGVuY29kZWQgKGVpdGhlciBleHBsaWNpdGx5IG9yIGVpdGhlciBhcyBh IHNpZ25hbCB0aGF0DQo+PiBzYXlzICJ0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQiKS4gQ29uc2lk ZXIgc29tZXRoaW5nIGxpa2UgYmVsb3c6DQo+Pg0KPj4gfDB8IGZyYW1lLXR5cGUgKDcpIHwgZnJh bWUtcGF5bG9hZC1sZW5ndGggKGkpIHwgZnJhbWUtcGF5bG9hZCAoKikgfA0KPj4gIG9yDQo+PiB8 MXwgZnJhbWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8DQo+Pg0KPj4gV2hlbiBNU0Ig b2YgdGhlIGZpcnN0IG9jdGV0IHNldCB0byB6ZXJvLCB0aGUgbGVuZ3RoIG9mIHRoZSBmcmFtZQ0K Pj4gcGF5bG9hZCBpcyBkZXNpZ25hdGVkIGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBm b2xsb3dzIHRoZSBmcmFtZQ0KPj4gdHlwZS4NCj4+IFdoZW4gTVNCIG9mIHRoZSBmaXJzdCBvY3Rl dCBzZXQgdG8gb25lLCB0aGUgbGVuZ3RoIG9mIHRoZSBmcmFtZQ0KPj4gcGF5bG9hZCBzcGFucyB0 byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuDQo+Pg0KPj4gSW4gdGhpcyBlbmNvZGluZywgd2UgY2Fu IGFsd2F5cyBvbWl0IHRoZSBMZW5ndGggZmllbGQgb2YgYSBTVFJFQU0NCj4+IGZyYW1lLiBTbyB0 aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQg aW4NCj4+IHByYWN0aWNlLg0KPj4NCj4+IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0 aGUgQUNLIEJsb2NrIENvdW50IGZpZWxkLiBBbmQgdGhlDQo+PiBvdmVyaGVhZCB3aWxsIGJlIG9u ZSB0byB0d28gYml0cyBpZiB0aGUgQUNLIGZyYW1lIGlzIHNlbnQgaW4gdGhlDQo+PiBtaWRkbGUg b2YgdGhlIHBhY2tldCAodGhlcmVieSB1c2luZyB0aGUgZW5jb2Rpbmcgd2l0aCBleHBsaWNpdCBm cmFtZQ0KPj4gcGF5bG9hZCBsZW5ndGgpLCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlm IEFDSyBpcyB0aGUgbGFzdCBmcmFtZQ0KPj4gb2YgdGhlIHBhY2tldC4NCj4+DQo+PiBXZSBhcmUg bGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3RoZXIg dHlwZXMNCj4+IG9mIGZyYW1lcywgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgd291bGQgYmUgYW4g aXNzdWUgY29uc2lkZXJpbmcgdGhhdA0KPj4gdGhleSB3aWxsIGJlIGZhciBzZWxkb20gc2VlbiBj b21wYXJlZCB0byBTVFJFQU1zIGFuZCBBQ0tzLg0KPj4NCj4+IFRvIHN1bW1hcml6ZSwgbXkgYW50 aWNpcGF0aW9uIGlzIHRoYXQgd2UgY2FuIG1ha2UgYWxsIHRoZSBmcmFtZXMNCj4+IHNlbGYtY29u dGFpbmVkIChpLmUuIHRoZSBsZW5ndGggY2FuIGJlIGRldGVybWluZWQgd2l0aG91dCB0aGUNCj4+ IGtub3dsZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVy aGVhZCwgaWYgd2UNCj4+IGFncmVlIG9uIG1ha2luZyB0aGUgZnJhbWUgdHlwZSBzcGFjZSAxIGJp dCBzbWFsbGVyLg0KPj4NCj4+IEZpbmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcg YSBzZWxmLWNvbnRhaW5lZCBlbmNvZGluZyBvZg0KPj4gZnJhbWVzIGlzIHRoYXQgd2Ugd291bGQg aGF2ZSB0aGUgYWJpbGl0eSB0byBpbnRyb2R1Y2UgbmV3IG9wdGlvbmFsDQo+PiBmcmFtZXMgd2l0 aG91dCBuZWdvdGlhdGlvbi4gQnkgbWFraW5nIHRoZSBmcmFtZXMgc2VsZi1jb250YWluZWQsIFFV SUMNCj4+IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZy YW1lcyB0aGF0IHRoZXkgZG8NCj4+IG5vdCB1bmRlcnN0YW5kLg0KPj4NCj4+IEJlaW5nIGFibGUg dG8gc2VuZCBRVUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dA0KPj4gbmVn b3RpYXRpbmcgdXNpbmcgVHJhbnNwb3J0IFBhcmFtZXRlcnMgd2lsbCBiZSBhIHdpbiBpbiBib3Ro IHRlcm1zIG9mDQo+PiBzZWN1cml0eSAoYmVjYXVzZSBjbGllbnRzJyBUUCBpcyBzZW50IGluIGNs ZWFyKSBhbmQgZmxleGliaWxpdHkNCj4+IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2libGUgdG8g c2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJlDQo+PiBvdXQgd2hldGhlciB0aGUg cGVlciBzdXBwb3J0cyB0aGF0IGV4dGVuc2lvbikuDQo+Pg0KPj4gPiBJZiB3ZSBkb24ndCByZW1v dmUgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMNCj4+ID4g bGFyZ2VyLA0KPj4gPiBidXQgSSBkb24ndCB0aGluayB0aGUgZXh0cmEgc2l6ZSBmaWVsZCBpcyB1 c2VmdWwgZm9yIG1vc3QNCj4+ID4gaW1wbGVtZW50YXRpb25zLg0KPj4gPiBBbHNvLCBpdCBtZWFu cyB0aGUgbGVuZ3RoIGNhbiBkaXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBh ZGQNCj4+ID4gY29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3It cHJvbmUgY29kZS4gIFRoZSBpZGVhIG9mDQo+PiA+IHNvbWVvbmUgb2ZmbG9hZGluZyBhY2sgcHJv Y2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZQ0KPj4gPiBsZW5ndGgNCj4+ ID4gc2VlbXMgbGlrZSBzb21lb25lIGNvdWxkIGdldCB3cm9uZyBhbmQgY2F1c2Ugc29tZSBjb25j ZXJuaW5nIGlzc3Vlcy4NCj4+ID4NCj4+ID4gTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVk IHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yaw0KPj4gPiB0aGFuDQo+PiA+ IGl0J3Mgd29ydGguICBTdXJlIHlvdSBjYW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0aCBvbmUgY29u bmVjdGlvbiwgYnV0DQo+PiA+IHRoYXQNCj4+ID4gc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9i bGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLg0KPj4gPiBUeXBpY2FsbHkNCj4+ ID4gdGhlIGV4dHJhIGNvc3Qgb2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4N Cj4+ID4NCj4+ID4gVG8gYmUgY2xlYXIsIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBhd2Z1bCBp ZGVhLCBidXQgSSBhbHNvIGRvbid0IHNlZQ0KPj4gPiB0aGUNCj4+ID4gdmFsdWUgYW5kIGl0IGFk ZHMgY29tcGxleGl0eS4gIEkgcmVhZCBNYW5hc2kncyBlbWFpbCwgYnV0IEkgZG9uJ3QgdGhpbmsN Cj4+ID4gSQ0KPj4gPiB1bmRlcnN0YW5kIHdoeSBhbnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0 aWNlLg0KPj4gPg0KPj4gPiBPbiBTYXQsIEp1biAxNiwgMjAxOCBhdCA0OjEzIFBNIEVyaWMgUmVz Y29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQo+PiA+Pg0K Pj4gPj4gT24gRnJpLCBKdW4gMTUsIDIwMTggYXQgNjo0NiBQTSwgTWFydGVuIFNlZW1hbm4NCj4+ ID4+IDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5j b20+Pg0KPj4gPj4gd3JvdGU6DQo+PiA+Pj4NCj4+ID4+PiBUaGlzIHByb3Bvc2FsIGluY3JlYXNl cyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lIGJ5IDEgYnl0ZSBpbiB0aGUNCj4+ID4+PiBjb21t b24NCj4+ID4+PiBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJhbmdlcyksIHNpbmNlIHRoZSBBQ0sg bGVuZ3RoIGZpZWxkIGhlcmUgYWx3YXlzDQo+PiA+Pj4gY29uc3VtZXMgMiBieXRlcywgd2hlcmVh cyB0aGUgQUNLIEJsb2NrIENvdW50IGlzIGEgdmFyaWFibGUtbGVuZ3RoDQo+PiA+Pj4gaW50ZWdl ci4NCj4+ID4+PiBDb25zaWRlcmluZyBob3cgbXVjaCB3b3JrIHdlIHB1dCBpbnRvIG1pbmltaXNp bmcgdGhlIHNpemUgb2YgdGhlDQo+PiA+Pj4gZnJhbWVzLA0KPj4gPj4+IHRoaXMgZmVlbHMgbGlr ZSBhIHN0ZXAgaW4gdGhlIHdyb25nIGRpcmVjdGlvbi4uDQo+PiA+Pj4NCj4+ID4+PiBSZWdhcmRp bmcgdGhlIHByb2Nlc3NpbmcgY29zdCwgSSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4g QUNLDQo+PiA+Pj4gZnJhbWUNCj4+ID4+PiByZXF1aXJlcyBsb29waW5nIG92ZXIgYW5kIG1ha2lu ZyBjaGFuZ2VzIHRvIGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdA0KPj4gPj4+IGtlZXBzDQo+PiA+Pj4g dHJhY2sgb2Ygc2VudCBwYWNrZXRzLiBUaGlzIGlzIG11Y2ggbW9yZSBleHBlbnNpdmUgdGhhbiBz aW1wbHkgcGFyc2luZw0KPj4gPj4+IGENCj4+ID4+PiBidW5jaCBvZiB2YXJpbnRzIGluIHRoZSBB Q0sgZnJhbWUuIEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgYQ0KPj4gPj4+IG11bHRpLXRocmVhZGVk DQo+PiA+Pj4gcGFja2V0IHBhcnNlciB3b3VsZCBvZmZlciBhbnkgcmVhbC13b3JsZCBwZXJmb3Jt YW5jZSBiZW5lZml0cy4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gSSBkb24ndCB3YW50IHRvIG92ZXJz dGF0ZSB0aGUgYmVuZWZpdCBoZXJlLCBidXQgbXkgcG9pbnQgaXNuJ3QgdGhhdA0KPj4gPj4gcGFy c2luZyBpcyBleHBlbnNpdmUgYnV0IHRoYXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBhIG11bHRpdGhy ZWFkZWQNCj4+ID4+IHBhY2tldA0KPj4gPj4gcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQncyBu aWNlIHRvIGhhdmUgYSBzaW1wbGVyIGRhdGEgc3RydWN0dXJlICh0aGUNCj4+ID4+IHVucGFyc2Vk IEFDSyBibG9jaykgdG8gaGFuZCB0byB0aGUgQUNLIHByb2Nlc3NpbmcgdGhyZWFkLg0KPj4gPj4N Cj4+ID4+IC1Fa3INCj4+ID4+DQo+PiA+Pg0KPj4gPj4+DQo+PiA+Pj4gT24gU2F0LCBKdW4gMTYs IDIwMTggYXQgNjoxOSBBTSBNYXJ0aW4gVGhvbXNvbg0KPj4gPj4+IDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQo+PiA+Pj4gd3JvdGU6 DQo+PiA+Pj4+DQo+PiA+Pj4+IFdoZW4gd2UgZGlzY3Vzc2VkIHRoaXMgYmVmb3JlLCBzb21lIHBl b3BsZSBvYnNlcnZlZCB0aGF0IHRoaXMgY3JlYXRlcw0KPj4gPj4+PiBhIG5lZWQgdG8gZW5jb2Rl IGluIHR3byBwYXNzZXMuICBUaGF0J3MgdGhlIHRyYWRlLW9mZiBoZXJlLiAgKE5vdA0KPj4gPj4+ PiBleHByZXNzaW5nIGFuIG9waW5pb24uKQ0KPj4gPj4+PiBPbiBGcmksIEp1biAxNSwgMjAxOCBh dCAzOjUxIFBNIEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0 ZkBnbWFpbC5jb20+Pg0KPj4gPj4+PiB3cm90ZToNCj4+ID4+Pj4gPg0KPj4gPj4+PiA+IEkgZG9u J3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHRoaXMuIEknbSBjZXJ0YWlubHkgbm90IG9wcG9z ZWQgdG8NCj4+ID4+Pj4gPiBpdC4NCj4+ID4+Pj4gPiBEb2VzIGFueW9uZSBoYXZlIGEgc3Ryb25n IG9wcG9zaXRpb24/DQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiBPbiBGcmksIEp1biAxNSwgMjAxOCBh dCAzOjEwIFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQo+PiA+Pj4+ID4gPHByYXZiQG1pY3Jv c29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+ID4+Pj4gPj4N Cj4+ID4+Pj4gPj4gSSBhZ3JlZSBhcyB3ZWxsIHNpbmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBl ciBwYWNrZXQgcHJvY2Vzc2luZw0KPj4gPj4+PiA+PiBvdmVyaGVhZC4gQUNLcyBhcmUgZ29pbmcg dG8gYmUgdGhlIHNlY29uZCBtb3N0IGNvbW1vbiBmcmFtZSB0eXBlDQo+PiA+Pj4+ID4+IHNvIG5v DQo+PiA+Pj4+ID4+IG9iamVjdGlvbnMgdG8gc3BlY2lhbCBjYXNpbmcuDQo+PiA+Pj4+ID4+DQo+ PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IEZyb206IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBFcmljDQo+PiA+Pj4+ID4+IFJlc2NvcmxhDQo+PiA+Pj4+ID4+IFNlbnQ6IEZyaWRheSwg SnVuZSAxNSwgMjAxOCA5OjExIEFNDQo+PiA+Pj4+ID4+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5h c2kuZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4+ID4+ Pj4gPj4gQ2M6IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0 ZkBnbWFpbC5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4+DQo+PiA+Pj4+ID4+IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9j ayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4g Pj4NCj4+ID4+Pj4gPj4gSSBhZ3JlZSB3aXRoIE1hbmFzaSBoZXJlLiBUaGlzIGNoYW5nZSB3b3Vs ZCBhbGxvdyBhY2sgZnJhbWUNCj4+ID4+Pj4gPj4gcGFyc2luZw0KPj4gPj4+PiA+PiB0byBiZSBt b3JlIHNlbGYtY29udGFpbmVkLCB3aGljaCBpcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBwYXJzZXIN Cj4+ID4+Pj4gPj4gYW5kIGFsc28NCj4+ID4+Pj4gPj4gcG90ZW50aWFsbHkgZm9yIHBhcmFsbGVs aXNtIChiZWNhdXNlIHlvdSBjYW4gcXVpY2tseSBmaW5kIHRoZQ0KPj4gPj4+PiA+PiBmcmFtZSBh bmQgdGhlbg0KPj4gPj4+PiA+PiBwcm9jZXNzIGl0IGluIHBhcmFsbGVsKS4NCj4+ID4+Pj4gPj4N Cj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gLUVrcg0KPj4gPj4+PiA+Pg0KPj4g Pj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBP biBNb24sIEp1biAxMSwgMjAxOCBhdCA1OjIyIFBNLCBEZXZhbCwgTWFuYXNpDQo+PiA+Pj4+ID4+ IDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4g d3JvdGU6DQo+PiA+Pj4+ID4+DQo+PiA+Pj4+ID4+IEluIGdlbmVyYWwsIHZhcmludHMgcmVxdWly ZSBzb21lIHNwZWNpZmljIGxvZ2ljIGZvciBwYXJzaW5nLiBUbw0KPj4gPj4+PiA+PiBza2lwDQo+ PiA+Pj4+ID4+IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkgc2luZ2xlIHZh cmludC4gQXMgdGhlIGNvZGUNCj4+ID4+Pj4gPj4gc2VlcyBTdHJlYW0NCj4+ID4+Pj4gPj4gYW5k IEFDSyBoZWFkZXJzIG1vc3QgZnJlcXVlbnRseSwgdGhhdCBpcyBteSBmb2N1cy4gIFRoZSBTdHJl YW0NCj4+ID4+Pj4gPj4gZnJhbWUgaGFzIGENCj4+ID4+Pj4gPj4gbGVuZ3RoIGluIGl0cyB0aGly ZCBmaWVsZC4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4g QUNLIHBhcnNpbmcsIGhvd2V2ZXIsIG5lZWRzIDYgKyAyKm51bV9ibG9ja3MgcmVhZHMgdG8gaWRl bnRpZnkNCj4+ID4+Pj4gPj4gbGVuZ3RoLiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKA mGxhcmdlc3QgYWNrbm93bGVkZ2Vk4oCZLCDigJhBQ0sNCj4+ID4+Pj4gPj4gZGVsYXnigJkgYW5k DQo+PiA+Pj4+ID4+IOKAmEFDSyBibG9jayBjb3VudOKAmS4gVGhlIHBhaW4gcG9pbnQgaXMgdGhl IHRvdGFsIG51bWJlciBvZiBjeWNsZXMNCj4+ID4+Pj4gPj4gcGFyc2UgYW4NCj4+ID4+Pj4gPj4g QUNLLiBJZiBJIGFtIHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBw YWNrZXRzDQo+PiA+Pj4+ID4+IGhhdmUgYQ0KPj4gPj4+PiA+PiBwaWdneWJhY2tlZCBBQ0ssIHRo ZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQgYm90dGxlbmVjay4NCj4+ID4+Pj4gPj4N Cj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gVGhhbmtzLA0KPj4gPj4+PiA+Pg0K Pj4gPj4+PiA+PiBNYW5hc2kNCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4g RnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEphbmENCj4+ID4+Pj4gPj4gSXllbmdhcg0KPj4g Pj4+PiA+PiBTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTQ0KPj4gPj4+PiA+PiBU bzogRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRl dmFsQGludGVsLmNvbT4+OyBRVUlDIFdHDQo+PiA+Pj4+ID4+IDxxdWljQGlldGYub3JnPG1haWx0 bzpxdWljQGlldGYub3JnPj4NCj4+ID4+Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJl cGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4gPj4+PiA+Pg0KPj4gPj4+ PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiBZb3UncmUgcmlnaHQgdGhhdCB3ZSBubyBsb25n ZXIgaGF2ZSB0aGUgYWJpbGl0eSB0byBza2lwIGFuIEFDSw0KPj4gPj4+PiA+PiBmcmFtZSwNCj4+ ID4+Pj4gPj4gYW5kIHRoaXMgY3JlcHQgaW4gd2hlbiB3ZSBtb3ZlZCB0byB2YXJpbnRzLg0KPj4g Pj4+PiA+Pg0KPj4gPj4+PiA+PiBJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5l cmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1lcyBub3QNCj4+ID4+Pj4gPj4ganVzdCBBQ0tzLCBzaW5j ZSBpZHMsIHBhY2tldCBudW1iZXJzLCBhbmQgbnVtYmVycyBpbiBhbGwgZnJhbWVzDQo+PiA+Pj4+ ID4+IGFyZSBub3cgYWxsDQo+PiA+Pj4+ID4+IHZhcmludHMuIFRvIHNraXAgYW55IGZyYW1lLCB5 b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkcw0KPj4gPj4+PiA+PiBpbiB0aG9z ZQ0KPj4gPj4+PiA+PiBmcmFtZXMuIElmIHlvdSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNr aXAgdmFyaW50cywgdGhlbg0KPj4gPj4+PiA+PiBza2lwcGluZyB0aGUgYWNrDQo+PiA+Pj4+ID4+ IGJsb2NrIHNlY3Rpb24gaXMgbWVyZWx5IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1f YmxvY2srMSkNCj4+ID4+Pj4gPj4gdGltZXMuIERvDQo+PiA+Pj4+ID4+IHlvdSBzZWUgc3BlY2lm aWMgdmFsdWUgaW4gc2tpcHBpbmcgQUNLIGZyYW1lcyBvdmVyIHRoZSBvdGhlcg0KPj4gPj4+PiA+ PiBjb250cm9sIGZyYW1lcz8NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ ID4+Pj4gPj4NCj4+ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQg ODo0MyBBTSBEbWl0cmkgVGlraG9ub3YNCj4+ID4+Pj4gPj4gPGR0aWtob25vdkBsaXRlc3BlZWR0 ZWNoLi5jb208bWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb20+PiB3cm90ZToNCj4+ ID4+Pj4gPj4NCj4+ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgMDM6MzM6MzVQTSAr MDAwMCwgRGV2YWwsIE1hbmFzaSB3cm90ZToNCj4+ID4+Pj4gPj4gPiAtICAgICAgICBNb3Zpbmcg dGhlIEFDSyBsZW5ndGggdG8gdGhlIGZyb250IG9mIHRoZSBBQ0sgYWxsb3dzDQo+PiA+Pj4+ID4+ ID4gdGhlDQo+PiA+Pj4+ID4+ID4gICAgICAgICAgZmxleGliaWxpdHkgb2YgZWl0aGVyIHJlYWRp bmcgdGhlIGVudGlyZSBBQ0sgb3IgcmVhZGluZw0KPj4gPj4+PiA+PiA+IHRoZQ0KPj4gPj4+PiA+ PiA+ICAgICAgICAgIGZpcnN0IDE2IGJpdHMgYW5kIHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4g VGhpcyBpcyBhDQo+PiA+Pj4+ID4+ID4gdXNlZnVsDQo+PiA+Pj4+ID4+ID4gICAgICAgICAgZmVh dHVyZSBmb3IgdGhlIGNhc2Ugd2hlcmUgQUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQgaW50bw0KPj4g Pj4+PiA+PiA+ICAgICAgICAgIG11bHRpcGxlIGxheWVycy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9j ZXNzb3IgdGhpcyBpcyBydW4NCj4+ID4+Pj4gPj4gPiBvbiwNCj4+ID4+Pj4gPj4gPiAgICAgICAg ICB0aGVyZSBhcmUgZGlmZmVyZW50IGFkdmFudGFnZXMgLQ0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+ PiBKdXN0IGEgbm90ZS4gIEluIG15IGV4cGVyaWVuY2UsIHRoZSBjb3N0IG9mIHBhcnNpbmcgYW4g QUNLIGZyYW1lDQo+PiA+Pj4+ID4+IGlzDQo+PiA+Pj4+ID4+IG5lZ2xpZ2libGUgY29tcGFyZWQg dG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQNCj4+ID4+Pj4gPj4g aXMsDQo+PiA+Pj4+ID4+IHBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlz Y2FyZCBuZXdseSBBQ0tlZCBwYWNrZXRzLg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+PiAgIC0gRG1p dHJpLg0KPj4gPj4+PiA+Pg0KPj4gPj4+PiA+Pg0KPj4gPj4+Pg0KPj4gPj4NCj4+ID4NCj4+DQo+ Pg0KPj4NCj4+IC0tDQo+PiBLYXp1aG8gT2t1DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0K --_000_1F436ED13A22A246A59CA374CBC543998B843873ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1 OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgsIGxp Lm0tNDE3MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4 MTc4MzUzbXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tNDE3MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0 Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaA0KCXttc28t c3R5bGUtbmFtZTptXy00MTcxNDY4OTE0OTU1NDQ5NDc4bV8tNzU5NjM0Mjk4MTA5MzEyODg1Nm00 MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS00MTcxNDY4OTE0OTU1NDQ5NDc4bS03NTk2MzQyOTgx MDkzMTI4ODU2bTQxNTI2OTg2MDYxNTgxNzgzNTNtc29wbGFpbnRleHQsIGxpLm0tNDE3MTQ2ODkx NDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUzbXNvcGxh aW50ZXh0LCBkaXYubS00MTcxNDY4OTE0OTU1NDQ5NDc4bS03NTk2MzQyOTgxMDkzMTI4ODU2bTQx NTI2OTg2MDYxNTgxNzgzNTNtc29wbGFpbnRleHQNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNDE3MTQ2 ODkxNDk1NTQ0OTQ3OG1fLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21z b3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyODY2Njk5MDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjEyMDU2MTIzMzQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTAwNzkwMjAzNzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNjU5OTgwMzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDcwQzAiPkkgZmVlbCB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBoYXZlIGV2ZXJ5 IHZhbHVlIHZhbGlkIGlzIHNvbWV3aGF0IGFjYWRlbWljLiBUaGUgbGVuZ3RoIHZhbHVlIHByb3Zp ZGVzIG11Y2ggbW9yZSB2YWx1ZSB0aGFuIHRoZSBibG9jayBjb3VudCBhbmQgdGhlIGZhY3QgdGhh dCBjZXJ0YWluDQogdmFsdWVzIGNhbiBuZXZlciBiZSBhY2hpZXZlZCBpcyBhbiBpbmhlcmVudCBw cm9wZXJ0eSBvZiB0aGUgbGVuZ3RoLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPk9uZSBpbnRlcmVzdGluZyBvYnNlcnZhdGlvbiBpcyB0aGF0IHRoaXMgcHJvcGVy dHkgaXMgbm90IGxpbWl0ZWQgdG8gbGVuZ3RoLiBPbmUgY2FuIGV2ZW4gbWFrZSBhIHNpbWlsYXIg YXJndW1lbnQgYWJvdXQgQUNLIGJsb2NrIGNvdW50LiBUaGUgbWF4aW11bSBudW1iZXIgb2YNCiBB Q0sgYmxvY2tzIHRoYXQgY2FuIGJlIGRlZmluZWQgd2lsbCBub3QgYWx3YXlzIGhhdmUgYSBtZWFu aW5nZnVsIHZhbHVlLiBJbiBvdXQgZXhhbXBsZXMsIDAsMSwyLDMgYXJlIGFsbCB2YWxpZC4gSWYg SSBzZXQgdGhlIHZhbHVlIG9mIEFDSyBibG9jayBjb3VudCB0byBoYXZlIGxvd2VyIHR3byBiaXRz IHRvIGJlIDExLCB0aGUgbWF4aW11bSB2YWx1ZSBpcyBvZiBBQ0sgYmxvY2tzIGlzIOKAkyA0NjEx Njg2MDE4NDI3Mzg3OTAzLiBUaGlzIGlzIHRoZQ0KIHNhbWUgdmFsdWUgb2YgbGFyZ2VzdCBhY2tu b3dsZWRnZWQgc28gaWYgdGhlIEFDSyBibG9jayBjb3VudCB3YXMgc2V0IHRvIHRoaXMgdmFsdWUs IGl0IHdvdWxkIHN0aWxsIGJlIG1lYW5pbmdsZXNzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDA3MEMwIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPk1hbmFzaTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcnRlbiBTZWVtYW5u IFttYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgSnVuZSAxOSwgMjAxOCA2OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBEZXZhbCwgTWFuYXNp ICZsdDttYW5hc2kuZGV2YWxAaW50ZWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0 ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0OzsgS2F6dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdt YWlsLmNvbSZndDs7IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7IEphbmEgSXll bmdhciAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g Jmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291 bnQgd2l0aCBBQ0sgbGVuZ3RoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgTWFuYXNpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDtUaGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxv Y2tzIGFuZCBhY2sgYmxvY2sgY291bnQgaXMgc2FtZSBhcyB0aGUgcmlzayBvZiBkaXNhZ3JlZW1l bnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgbGVuZ3RoLiBFaXRoZXIgd2F5IHRoaXMgbmVl ZHMgdG8gYmUgY291bnRlZCB1cCB3aGlsZSBjcmVhdGluZyB0aGUgQUNLIGFuZCBjb3VudGVkIGRv d24gd2hpbGUgcGFyc2luZyBpdC4gVGhlDQogcG9zc2liaWxpdHkgb2YgZXJyb3IgaXMgdGhlIHNh bWUuIEdldHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9uZyBpcyBhcyBwcm9ibGVtYXRpYyBh cyBnZXR0aW5nIHRoZSBhY2sgbGVuZ3RoIHdyb25nLiBEbyB5b3UgYWdyZWU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZGlzYWdyZWUuIExldCdzIHRha2UgYW4gZXhhbXBsZSBvZiBhbiBBQ0sgZnJhbWUgd2l0aCBv bmUgQUNLIHJhbmdlLCB0aGF0IG5lZWRzIGEgMiBieXRlIHZhcmludCB0byByZXByZXNlbnQgdGhl IEZpcnN0IEFDSyBCbG9jayBhbmQgYW5vdGhlciAyIGJ5dGUgdmFyaW50IHRvIHJlcHJlc2VudCB0 aGUgR2FwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2l0aCB5b3VyIHByb3Bvc2FsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9s IHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSB2YWx1ZXMg MCBhbmQgMSBhcmUgaW52YWxpZCwgc2luY2UgdGhlIGxlbmd0aCBmaWVsZHMgaXRzZWxmIGlzIGlu Y2x1ZGVkIGluIHRoZSBsZW5ndGguPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5UaGUgdmFsdWVzIDIsIDMsIC4uLiwgKDIgJiM0MzsgbGVuKExhcmdlc3RBY2tu b3dsZWRnZWQpICYjNDM7Jm5ic3A7bGVuKEFja0RlbGF5KSkgLSAxIGFyZSBpbnZhbGlkLCBzaW5j ZSB0aGUgbGVuZ3RoIG5lZWRzIHRvIGluY2x1ZGUgdGhlIExhcmdlc3QgQWNrbm93bGVkZ2VkIGFu ZCB0aGUgQWNrIERlbGF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+VGhlIHZhbHVlJm5ic3A7PC9zcGFuPjIgJiM0MzsgbGVuKExhcmdlc3RBY2tub3dsZWRn ZWQpICYjNDM7Jm5ic3A7bGVuKEFja0RlbGF5KSB3b3VsZCBiZSB0aGUgZmlyc3QgdmFsaWQgdmFs dWUsIGFuZCBjb3JyZXNwb25kIHRvIGFuIEFDSyBmcmFtZSB3aXRoIG5vIGJsb2Nrcy48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ DQpUaGUgdmFsdWUgMiAmIzQzOyBsZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkgJiM0MzsmbmJzcDts ZW4oQWNrRGVsYXkpJm5ic3A7JiM0MzsgMSBpcyBpbnZhbGlkLCBzaW5jZSBpdCB3b3VsZCBjdXQg dGhlIHZhcmludCBmb3IgdGhlIEZpcnN0IEFDSyBCbG9jazxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSB2YWx1ZSAyICYj NDM7IGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSAmIzQzOyZuYnNwO2xlbihBY2tEZWxheSkmbmJz cDsmIzQzOyAyIGlzIGludmFsaWQsIHNpbmNlIGl0IHdvdWxkIGN1dCB0aGUgZnJhbWUgYWZ0ZXIg dGhlIEZpcnN0IEFDSyBCbG9jayAoYnV0IGV2ZXJ5IGJsb2NrIG11c3QgYmUgZm9sbG93ZWQgYnkg YSBnYXAgbGVuZ3RoKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSB2YWx1ZSAyICYjNDM7IGxlbihMYXJnZXN0QWNrbm93 bGVkZ2VkKSAmIzQzOyZuYnNwO2xlbihBY2tEZWxheSkmbmJzcDsmIzQzOyAzIGlzIGludmFsaWQs IHNpbmNlIGl0IHdvdWxkIGN1dCB0aGUgdmFyaW50IGZvciB0aGUgR2FwPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KRmluYWxs eSwgdGhlIHZhbHVlIDIgJiM0MzsgbGVuKExhcmdlc3RBY2tub3dsZWRnZWQpICYjNDM7Jm5ic3A7 bGVuKEFja0RlbGF5KSZuYnNwOyYjNDM7IDQmbmJzcDtpcyB2YWxpZDxvOnA+PC9vOnA+PC9saT48 L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5UaGVyZSBhcmUgKmEgbG90KiBvZiBpbnZhbGlkIHZhbHVlcyB0aGF0IHlvdSBjYW4g ZW5jb2RlIGludG8gdGhlIEFDSyBsZW5ndGggZmllbGQuIE1vcmUgaW1wb3J0YW50bHksICpub25l KiBvZiB0aGVzZSBlcnJvciBjYXNlcyBleGlzdHMgd2l0aCB0aGUgY3VycmVudCBmcmFtZSBmb3Jt YXQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSAqb25seSogZXJy b3IgY2FzZSB0aGF0IGNhbiBvY2N1ciB3aXRoIG91ciBjdXJyZW50IGZvcm1hdCBpcyB0aGF0IHRo ZSBwYWNrZXQgaXMgdG9vIHNob3J0IGZvciB0aGUgbnVtYmVyIG9mIEFDSyBibG9ja3MgdGhhdCBh cmUgc3VwcG9zZWQgdG8gY29udGFpbmVkIGluIHRoZSBmcmFtZS4gVGhpcyBjYW4gb2NjdXIgd2l0 aCB5b3VyIHByb3Bvc2FsIGFzIHdlbGwNCiAoaW4gYWRkaXRpb24gdG8gdGhlIGVycm9yIGNhc2Vz IGxpc3RlZCBhYm92ZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5NeSBjb25jZXJuIGlzIG5vdCB0aGF0IGl0J3MgaW1wb3NzaWJsZSBvciBldmVuIHBhcnRpY3Vs YXJseSBoYXJkIHRvIGNhdGNoIHRoZXNlIGVycm9ycywgYnV0IEkgZGlzbGlrZSB0aGUgcHJvcGVy dHkgdGhhdCBzb21lIChpbiBmYWN0LCBtb3N0KSBlbmNvZGFibGUgdmFsdWVzIGFyZSBpbnZhbGlk Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJlc3QsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPk1hcnRlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biAyMCwgMjAxOCBhdCAz OjIxIEFNIERldmFsLCBNYW5hc2kgJmx0OzxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50 ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXNpLmRldmFsQGludGVsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+SGkgSWFuLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkhlcmUgaXMgYW5vdGhlciBhdHRlbXB0IHRv IHNvbHZlIHRoZSBvYmplY3Rpb25zIHlvdSByYWlzZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+Jmd0 O0knbSBub3QgYSBmYW4gb2YgdGhpcyBwcm9wb3NhbCwgYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGlt cHJhY3RpY2FsIHRvIGRyb3AgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLA0KIGJlY2F1c2Ugd2l0 aCB0aGUgRUNOIHByb3Bvc2FsIGl0IGJlY29tZXMgaW1wcmFjdGljYWxseSBjb21wbGV4IHRvIHBh cnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPklz IHRoZXJlIGEgcmVhc29uIHRoZSBwcm9wb3NhbCBmcm9tIENocmlzdGlhbiBkb2VzIG5vdCBzb2x2 ZSB0aGlzIHByb2JsZW0/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij4mZ3Q7SWYgd2UgZG9uJ3QgcmVt b3ZlIHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgdGhlbiB0aGUgYWNrIGZyYW1lIGlzIGxhcmdl ciwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIGV4dHJhDQogc2l6ZSBmaWVsZCBpcyB1c2VmdWwgZm9y IG1vc3QgaW1wbGVtZW50YXRpb25zLiZuYnNwOyBBbHNvLCBpdCBtZWFucyB0aGUgbGVuZ3RoIGNh biBkaXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBhZGQgY29tcGxleGl0eSBh bmQgdGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29kZS4mbmJzcDsgVGhl IGlkZWEgb2Ygc29tZW9uZSBvZmZsb2FkaW5nIGFjayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2Nl ZWRpbmcgdG8gdHJ1c3QNCiB0aGUgbGVuZ3RoIHNlZW1zIGxpa2Ugc29tZW9uZSBjb3VsZCBnZXQg d3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+VGhlIHJpc2sgb2YgZGlzYWdyZWVtZW50 IGJldHdlZW4gYWNrIGJsb2NrcyBhbmQgYWNrIGJsb2NrIGNvdW50IGlzIHNhbWUgYXMgdGhlIHJp c2sgb2YgZGlzYWdyZWVtZW50DQogYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgbGVuZ3RoLiBF aXRoZXIgd2F5IHRoaXMgbmVlZHMgdG8gYmUgY291bnRlZCB1cCB3aGlsZSBjcmVhdGluZyB0aGUg QUNLIGFuZCBjb3VudGVkIGRvd24gd2hpbGUgcGFyc2luZyBpdC4gVGhlIHBvc3NpYmlsaXR5IG9m IGVycm9yIGlzIHRoZSBzYW1lLiBHZXR0aW5nIHRoZSBhY2sgYmxvY2sgY291bnQgd3JvbmcgaXMg YXMgcHJvYmxlbWF0aWMgYXMgZ2V0dGluZyB0aGUgYWNrIGxlbmd0aCB3cm9uZy4gRG8NCiB5b3Ug YWdyZWU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+Jmd0O015IGV4cGVyaWVuY2UgaXMgbXVsdGl0aHJl YWRlZCBwYWNrZXQgcHJvY2Vzc2luZyBpcyBtb3JlIGNvc3QgYW5kIHdvcmsgdGhhbiBpdCdzIHdv cnRoLiZuYnNwOyBTdXJlIHlvdQ0KIGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9uZSBjb25u ZWN0aW9uLCBidXQgdGhhdCBzZWVtcyBsaWtlIGFuIGFjYWRlbWljIHByb2JsZW0sIG5vdCBvbmUg Zm9yIHdvcmtsb2FkcyBJJ3ZlIHNlZW4uJm5ic3A7IFR5cGljYWxseSB0aGUgZXh0cmEgY29zdCBv ZiBtdWx0aXRocmVhZGluZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRoZSB2YWx1ZSBpcyB0d28gZm9sZCDigJMg cHJlLXByb2Nlc3NpbmcgYW5kIG11bHRpLXRocmVhZGluZy4gSWYgd2UgcHJlLXByb2Nlc3MgdGhl IHJlY2VpdmVkIHBhY2tldHMNCiBzdWNoIHRoYXQgQUNLcyBhbmQgc3RyZWFtcyBjYW4gYmUgY29h bGVzY2VkLCB0aGUgcmVjZWl2ZSBzaWRlIGNhbiBpbmRpY2F0ZSBhIGxhcmdlIGNodW5rIG9mIGlu Zm9ybWF0aW9uIHRob3VnaA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkU3NUI2Ij50 aGUga2VybmVsLCByZWR1Y2luZyB0aGUgY29zdCBvZiBzeXN0ZW0gY2FsbCBhbmQgcHJvdG9jb2wg b3ZlcmhlYWQuIFRoaXMgaXMgdGhlIHNhbWUgY29uY2VwdCBhcyBVRFAgc2VnbWVudGF0aW9uIHRh a2VuIGEgc3RlcCBmdXJ0aGVyIG9uIHJlY2VpdmUgc2lkZS4gQWZ0ZXIgdGhpcyBjaHVuayBpcyBp bmRpY2F0ZWQNCiBpbnRvIHRoZSBRVUlDIHByb3RvY29sLCB0aGUgcHJvdG9jb2wgbWF5IHByb2Nl c3Mgc3RyZWFtIGFuZCBBQ0sgaW4gcGFyYWxsZWwuIFdoaWxlIGZvbGtzIG1heSBvciBtYXkgbm90 IHV0aWxpemUgdGhpcywgdGhlcmUgaXMgYW4gYWR2YW50YWdlIGhlcmUuICZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRTc1QjYiPlRoYW5rcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMkU3NUI2Ij5NYW5hc2k8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IElhbiBTd2V0dCBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgSnVuZSAxOSwgMjAxOCAxMToyNiBBTTxicj4NCjxiPlRvOjwvYj4gRGV2YWwsIE1hbmFzaSAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRlbiBTZWVtYW5uICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBLYXp1aG8NCiBPa3UgJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 OyBFcmljIFJlc2NvcmxhICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZWtyQHJ0Zm0uY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQogSmFuYSBJeWVuZ2FyICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+anJpLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuDQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cHJhdmJA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cHJhdmJAbWlj cm9zb2Z0LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBJRVRGIFFVSUMgV0cg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+cXVpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Ow0KIE1hcnRpbiBUaG9tc29uICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFy dGluLnRob21zb25AZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSdtIHN0aWxsIG5vdCBpbnRlcmVzdGVkIGluIHRoaXMgY2hhbmdlLCBmb3Ig dGhlIHJlYXNvbnMgSSBzdGF0ZWQgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKdW4gMTksIDIwMTggYXQgMjoyMSBQTSBEZXZh bCwgTWFuYXNpICZsdDs8YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5EbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRvIGNyZWF0ZSBh IG5ldyBQUj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNDE3MTQ2ODkxNDk1NTQ0OTQ3 OF9tXy03NTk2MzQyOTgxMDkzMSI+PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+DQogRGV2YWwsIE1hbmFzaSA8YnI+DQo8Yj5TZW50OjwvYj4g U3VuZGF5LCBKdW5lIDE3LCAyMDE4IDI6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRlbiBTZWVt YW5uICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBLYXp1aG8NCiBPa3UgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTwvc3Bhbj48YSBo cmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBFcmljIFJlc2NvcmxhICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZWty QHJ0Zm0uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEphbmEgSXllbmdhciAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmpyaS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7Ow0KIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPnByYXZiQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OzsgSUVURiBRVUlDDQogV0cgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cXVpY0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQcm9wb3NhbCB0byByZXBs YWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPkhpIEFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMw Ij5JIGhhdmUgbWFkZSBhIGxpc3Qgb2Ygb2JqZWN0aW9ucyB0byB0aGUgcHJvcG9zYWwgYW5kIHRo ZSBzb2x1dGlvbnMgdG8gdGhvc2Ugb2JqZWN0aW9ucyBkaXNjdXNzZWQgb24NCiB0aGlzIHRocmVh ZC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tNDE3MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4 NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw NzBDMCI+YS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDA3MEMw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+Q28tZXhpc3RlbmNlIG9mIGxlbmd0aCBmaWVsZCB3aXRoIEVDTiBmaWVs ZCBhbmQgQUNLIGJsb2Nrcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQx NzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1 M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0Nzht LTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkNocmlzdGlhbiBzdWdnZXN0ZWQgdG8g bW92ZSB0aGUgRUNOIGZpZWxkcyB0byBwcmVjZWRlIHRoZSBBQ0sgYmxvY2tzLiBUaGlzIGlzIGFu IGVsZWdhbnQgc29sdXRpb24uIFBhcnNpbmcgZW50aXJlIGxpc3Qgb2YgQUNLIGJsb2NrcyB0byBy ZXZpZXcgRUNOIGJpdHMgd291bGQgaGF2ZSBiZWVuIGFubm95aW5nLCBldmVuDQogdGhvdWdoIGl0 IGNhbiB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5 NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3Rw YXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5 ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPmIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRoZXJlIGFyZSB0d28gY2FzZXMgdG8g YmUgcGFyc2VkIOKAkyBlbnRpcmUgQUNLIGFuZCBwYXJzZSBBQ0sgdG8gaWRlbnRpZnkgbGVuZ3Ro LiBUaGVyZSBhcmUgc29tZSByZXNlcnZhdGlvbnMgd2hlbiBBQ0sgcGFyc2luZyBnZXRzIGhhcmRl ciBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGVudGlyZSBoZWFkZXINCiBuZWVkcyB0byBiZSBwYXJz ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNDE3MTQ2ODkxNDk1NTQ0OTQ3 OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFw aCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tNDE3MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEy ODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+QWdyZWVtZW50IGZyb20gc2V2ZXJhbCBmb2xrcyBoZXJlLiBJbiB0 aGUgb3JpZ2luYWwgQUNLIGRlZmluZWQgaW4gZHJhZnQgMTIgb2YgdGhlIHNsaWRlLCBvbmUgd291 bGQgY291bnQgZG93biBudW1iZXIgb2YgQUNLIGJsb2NrcyB0byBnZXQgdG8gdGhlIGVuZCBvZiB0 aGUgcGFja2V0LiBJbiB0aGUgcHJvcG9zYWwNCiBJIG1hZGUsIG9uZSB3b3VsZCBjb3VudCBkb3du IHRoZSBsZW5ndGggdG8gaWRlbnRpZnkgdGhlIGVuZCBvZiB0aGUgcGFja2V0LiBUaGUgbG9naWMg aXMgdmVyeSBzaW1pbGFyIGluIGN5Y2xlIGNvdW50IGFuZCBjb21wbGV4aXR5LiBTZXZlcmFsIGZv bGtzIGFsc28gY29tbWVudGVkIHRvIHRoaXMgZWZmZWN0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tNDE3MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00 MTUyNjk4NjA2MTU4MTc4MzUzbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNDE3 MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUz bXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Yy48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBD MCI+TXVsdGktdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZt NDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQx NzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1 M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkkgd291 bGQgZXhwZWN0IHRoYXQgdGhlcmUgYXJlIDEwcyBvZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1 c2UgYXQgYW55IHRpbWUgZm9yIGEgc2VydmVyIHdpdGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRp LXRocmVhZGluZyB0byBoYW5kbGUgZWFjaCBvZiB0aGVzZSBmbG93cyAvIGNvbm5lY3Rpb25zIGlu IHBhcmFsbGVsDQogaXMgbmVjZXNzaXR5IHRvIGJlIGFibGUgdG8gc3VwcG9ydCBsYXJnZSBudW1i ZXIgb2YgY29ubmVjdGlvbnMgb24gYSBoaWdoIHNwZWVkIGxpbmsuIFR4IHNlZ21lbnRhdGlvbiwg UnggY29hbGVzY2luZyBhcmUgd2VsbCBrbm93biBzdHJhdGVnaWVzIHRvIHJlZHVjZSB0aGUgcHJv Y2Vzc2luZyBjb3N0LiBJbiBpbml0aWFsIHN0YWdlcywgY29kZSBpcyBvZnRlbiB3cml0dGVuIGFz IGEgc2luZ2xlLXRocmVhZGVkIGFuZCB0aGVuIHJlLWZhY3RvcmVkDQogdG8gcGFyYWxsZWxpemUg Y3ljbGUgaW50ZW5zaXZlIG9wZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93IHRoaXMgcHJvdG9j b2wgdG8gc2NhbGUgaW4gZnV0dXJlLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgZG8gbm90IHByZWNsdWRl IHRoaXMgY2FzZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5 MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xp c3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYz NDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPmQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkluY3JlYXNlIGluIEFDSyBzaXpl IGJ5IDEgYnl0ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS00MTcxNDY4OTE0 OTU1NDQ5NDc4bS03NTk2MzQyOTgxMDkzMTI4ODU2bTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0 cGFyYWdyYXBoIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS00MTcxNDY4OTE0OTU1NDQ5NDc4bS03NTk2MzQy OTgxMDkzMTI4ODU2bTQxNTI2OTg2MDYxNTgxNzgzNTNtc29saXN0cGFyYWdyYXBoIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5JIGRvIG5vdCBzZWUgdGhpcyBhcyBhIHNlcmlvdXMg aXNzdWUgYnV0IGlmIGZvbGtzIGJ1dCB3ZSBjYW4gY29uc2lkZXIgbWFraW5nIHRoaXMgYSB2YXJp bnQsIGlmIG90aGVycyBoYXZlIHN0cm9uZyBmZWVsaW5ncyBhYm91dCBpdC4gSXTigJlzIGEgdHJh ZGUtb2ZmIDogMiByZWFkcyB0byBzYXZlIDEgYnl0ZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1 MjY5ODYwNjE1ODE3ODM1M21zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0 Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAw NzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPkV2ZXJ5IGVuY29kYWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS00MTcxNDY4OTE0OTU1NDQ5NDc4bS03NTk2 MzQyOTgxMDkzMTI4ODU2bTQxNTI2OTg2MDYxNTgxNzgzNTNtc29wbGFpbnRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5Ob3QgZXZlcnkg bGVuZ3RoIHdpbGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVuZ3Rocy4gVGhpcyBz YW1lIGlzc3VlIGFpbHMgdGhlIOKAmHBheWxvYWQgbGVuZ3Ro4oCZIGluIFFVSUMgaGVhZGVyLiBO b3Qgb25seSBkb2VzIHRoZSBpc3N1ZSBleGlzdCBmb3Igc21hbGwgdmFsdWVzLCBpdCBhbHNvIGFw cGxpZXMgdG8gbGFyZ2UgdmFsdWVzIHNpbmNlIGRhdGEgc3RyZWFtIHdpbGwgYmUgc2VudA0KIGFm dGVyIGNyeXB0byBuZWdvdGlhdGlvbi4mbmJzcDsgRS5nLiAmbmJzcDstIGhvdyBkb2VzIG9uZSBj cmFmdCBhIHBheWxvYWQgd2l0aCA2MiBiaXQgcGF5bG9hZCBsZW5ndGggaW4gYSBsYXJnZSBoZWFk ZXI/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNDE3MTQ2ODkxNDk1NTQ0OTQ3 OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUzbXNvcGxhaW50ZXh0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibS00MTcxNDY4OTE0OTU1NDQ5NDc4bS03NTk2MzQyOTgxMDkzMTI4ODU2bTQx NTI2OTg2MDYxNTgxNzgzNTNtc29wbGFpbnRleHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5 NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMxMjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb3BsYWlu dGV4dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQxNzE0Njg5MTQ5NTU0NDk0NzhtLTc1OTYzNDI5ODEwOTMx Mjg4NTZtNDE1MjY5ODYwNjE1ODE3ODM1M21zb3BsYWludGV4dCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+TWFuYXNpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNDE3 MTQ2ODkxNDk1NTQ0OTQ3OG0tNzU5NjM0Mjk4MTA5MzEyODg1Nm00MTUyNjk4NjA2MTU4MTc4MzUz bXNvcGxhaW50ZXh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IE1hcnRlbiBTZWVtYW5uIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1h bm5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYWlsdG86bWFy dGVuc2VlbWFubkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFN1bmRheSwgSnVuZSAxNywgMjAxOCA2OjU5IEFNPGJyPg0KPGI+VG86PC9i PiBLYXp1aG8gT2t1ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmthenVob29rdUBnbWFpbC5jb208 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0 ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWFuc3dldHQ9NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQog RXJpYyBSZXNjb3JsYSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmVrckBydGZtLmNvbTwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86anJpLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5q cmkuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5wcmF2YkBtaWNyb3Nv ZnQuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IElFVEYgUVVJQw0KIFdHICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPnF1aWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OzsgTWFydGluIFRob21zb24gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBEZXZh bCwgTWFuYXNpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1hbmFzaS5kZXZhbEBpbnRlbC5j b208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1heWJlIGl0J3Mgc3BlY2lm aWMgdG8gR28sIGJ1dCBJJ20gdXNpbmcgYSBzaW5nbGUgaW8uUmVhZGVyIGZvciB0aGUgd2hvbGUg cGFja2V0LCBzbyBhcyBsb25nIGFzIHRoZSBwYWNrZXQgcGF5bG9hZCBpcyBsb25nIGVub3VnaCwg dGhlIHZhcmludCBwYXJzaW5nIHdpbGwgbm90IGZhaWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHRoaW5rIHRoYXQgc3BlY2lmaWNzIG9mIHBy b2dyYW1taW5nIGxhbmd1YWdlcyBtYXR0ZXIgaGVyZSB0aG91Z2gsIGFuZCBJJ20gc3VyZSBib3Ro IGZyYW1lIGZvcm1hdHMgY2FuIGJlIHJlYXNvbmFibHkgaW1wbGVtZW50ZWQgaW4gQyBhcyB3ZWxs IGFzIGluIEdvLiBUaGUgcmVhc29ucyBJJ20gb3Bwb3NlZA0KIHRvIE1hbmFzaSdzIHByb3Bvc2Fs IGFyZSB0aGF0IGl0IG1vdmVzIHVzIGF3YXkgZnJvbSB0aGUgcHJpbmNpcGxlIHRoYXQgb25seSBy ZWFzb25hYmxlIHZhbHVlcyBzaG91bGQgYmUgZW5jb2RhYmxlLCBhbmQgdGhhdCBpdCBpbmNyZWFz ZXMgdGhlIHNpemUgb2YgdGhlIEFDSyBmcmFtZSwgZm9yIHRoZSBxdWVzdGlvbmFibGUgYmVuZWZp dCBvZiBiZWluZyBhYmxlIHRvIHBhcmFsbGVsaXNlIHRoZSBmcmFtZSBwYXJzZXIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4s IEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzpr YXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAx OC0wNi0xNyAyMjozNiBHTVQmIzQzOzA5OjAwIE1hcnRlbiBTZWVtYW5uICZsdDs8YSBocmVmPSJt YWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0ZW5zZWVt YW5uQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsgQXQgbGVhc3QgZm9yIG15IGltcGxlbWVu dGF0aW9uLCBwYXJzaW5nIGRvZXNuJ3QgYmVjb21lIGVhc2llciwgaXQgYmVjb21lczxicj4NCiZn dDsgbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50LXBhcnNlciBhbHdh eXMgY29uc3VtZXMgYXMgbWFueTxicj4NCiZndDsgYnl0ZXMgYXMgdGhlIHZhcmludCByZXF1aXJl cywgc28gYWZ0ZXIgcGFyc2luZyBhIHZhcmludCwgSSdkIGhhdmUgdG88YnI+DQomZ3Q7IGludHJv ZHVjZSBhbiBhZGRpdGlvbmFsIGNoZWNrIHRoYXQgdGhpcyBkaWRuJ3Qgb3ZlcmZsb3cgdGhlIEFD SyBsZW5ndGggKGUuZy48YnI+DQomZ3Q7IGNvbnNpZGVyIHRoYXQgSSBwYXJzZWQgdGhlIEFDSyBm cmFtZSBzbyBmYXIgdGhhdCBvbmx5IDIgYnl0ZXMgYXJlIHJlbWFpbmluZzxicj4NCiZndDsgYWNj b3JkaW5nIHRvIEFDSyBsZW5ndGggZmllbGQsIGJ1dCB0aGUgbmV4dCB2YXJpbnQgaXMgNCBieXRl cyBsb25nKS48YnI+DQo8YnI+DQpJc24ndCB5b3VyIHZhcmludCBwYXJzZXIgY2hlY2tpbmcgdGhh dCBpdCBoYXMgbm90IChvciB3aWxsIG5vdCkgcnVuPGJyPg0KYWNyb3NzIHRoZSBlbmQgb2YgdGhl IHBhY2tldCBwYXlsb2FkIGZvciBldmVyeSBBQ0sgYmxvY2sgaXQgcGFyc2VzPzxicj4NCkknZCBh c3N1bWUgdGhhdCB5b3Ugd291bGQgYmUgZG9pbmcgdGhhdCwgYmVjYXVzZSBJIHRoaW5rIHRoYXQg aXM8YnI+DQpuZWNlc3NhcnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4uPGJyPg0KPGJyPg0KV2hh dCBJIGFtIHNheWluZyB0aGF0IHRoYXQgY2hlY2sgY291bGQgYmUgY29udmVydGVkIHRvIGEgb3Zl cnJ1biBjaGVjazxicj4NCmFnYWluc3QgdGhlIGVuZCBvZiB0aGUgJnF1b3Q7ZnJhbWUgcGF5bG9h ZCZxdW90OywgYW5kIHRoYXQgY2hlY2tpbmcgdGhlPGJyPg0KcmVtYWluaW5nIGJsb2NrIGNvdW50 IGJlY29tZXMgdW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0s8YnI+DQpCbG9jayBD b3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4g Z2VuZXJhbCwgd2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdpcmUgaW1hZ2UgdG93YXJkcyBtYWtpbmcg ZXZlcnkgZW5jb2RhYmxlPGJyPg0KJmd0OyB2YWx1ZSB2YWxpZC4gVGhpcyBwcm9wb3NhbCBtb3Zl cyB1cyBhd2F5IGZyb20gdGhhdCBwcmluY2lwbGU6PGJyPg0KJmd0OyAqIHNvbWUgc21hbGwgdmFs dWVzIGFyZSBhbHdheXMgaW52YWxpZCAodGhlIGxlbmd0aCBjYW4gbmV2ZXIgYmUgYmV0d2VlbiAw PGJyPg0KJmd0OyBhbmQgMyk8YnI+DQomZ3Q7ICogYSBsb3Qgb2YgaW50ZXJtZWRpYXRlIHZhbHVl cyBhcmUgaW52YWxpZCAoaWYgdGhlIGJvdW5kYXJ5IGZhbGxzIGluc2lkZSBhPGJyPg0KJmd0OyB2 YXJpbnQsIGFzIGRlc2NyaWJlZCBhYm92ZSk8YnI+DQomZ3Q7IEJvdGggdGhlc2UgY2FzZXMgY2Fu J3Qgb2NjdXIgd2l0aCB0aGUgY3VycmVudCBBQ0sgZnJhbWUgZm9ybWF0Ljxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uIFN1biwgSnVuIDE3LCAyMDE4IGF0IDc6NTQgUE0gS2F6dWhvIE9rdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9v a3VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAy MDE4LTA2LTE3IDg6MzQgR01UJiM0MzswOTowMCBJYW4gU3dldHQ8YnI+DQomZ3Q7Jmd0OyAmbHQ7 aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7Ojxicj4NCiZn dDsmZ3Q7ICZndDsgSSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBiZWNhdXNlIEkgdGhp bmsgaXQgaXMgaW1wcmFjdGljYWwgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGRyb3A8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04g cHJvcG9zYWwgaXQgYmVjb21lczxicj4NCiZndDsmZ3Q7ICZndDsgaW1wcmFjdGljYWxseSBjb21w bGV4IHRvIHBhcnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRm9yIHRoZSBFQ04gcHJv cG9zYWwsIGFzIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkLCB3ZSBjYW4gbW92ZSB0aGUgRUNOPGJy Pg0KJmd0OyZndDsgY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sgYmxvY2tzLiBUaGVuLCBpdCB3b3Vs ZCBub3QgYmUgY29tcGxleCB0bzxicj4NCiZndDsmZ3Q7IHBhcnNlLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgQW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMgZWFzaWVyIGlm IHdlIHJlcGxhY2UgQUNLIEJsb2NrPGJyPg0KJmd0OyZndDsgQ291bnQgd2l0aCBBQ0sgRnJhbWUg TGVuZ3RoLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTm93LCB3aXRoIEFDSyBCbG9jayBD b3VudCwgd2UgbmVlZCB0byBjaGVjayB0aGUgcmVtYWluaW5nIG51bWJlciBvZjxicj4NCiZndDsm Z3Q7IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0IHBheWxvYWQg Zm9yIGV2ZXJ5IGJsb2NrPGJyPg0KJmd0OyZndDsgdGhhdCB3ZSBwYXJzZS4gRmFpbGluZyB0byBj aGVjayBlaXRoZXIgbGVhZHMgdG8gYSBidWcgb3IgYSBzZWN1cml0eTxicj4NCiZndDsmZ3Q7IGlz c3VlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYgd2Ugc3dpdGNoIHRvIEFDSyBGcmFt ZSBMZW5ndGgsIHdlIG5lZWQgdG8gb25seSBjaGVjayB0aGUgcmVtYWluaW5nPGJyPg0KJmd0OyZn dDsgc3BhY2UgaW4gdGhlIGZyYW1lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGlu ayB0aGF0IHRoaXMgaXMgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiByZXBsYWNpbmcgQUNLIEJsb2Nr IENvdW50PGJyPg0KJmd0OyZndDsgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9IIHRoZSBkb3du c2lkZSBpcyB0aGF0IHlvdSBuZWVkIGV4dHJhIG9uZSB0bzxicj4NCiZndDsmZ3Q7IHR3byBiaXRz IChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVsb3cg NjUsPGJyPg0KJmd0OyZndDsgdHdvIGlmIHRoZXkgYXJlIGV4cGVjdGVkIHRvIGJlIGFib3ZlIHRo YXQpIGZvciBlbmNvZGluZyBBQ0sgRnJhbWU8YnI+DQomZ3Q7Jmd0OyBMZW5ndGggY29tcGFyZWQg dG8gQUNLIEJsb2NrIENvdW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlm IGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUgaXQnczxicj4NCiZndDsmZ3Q7IGxlbmd0aCBiZWlu ZyBlbmNvZGVkIChlaXRoZXIgZXhwbGljaXRseSBvciBlaXRoZXIgYXMgYSBzaWduYWwgdGhhdDxi cj4NCiZndDsmZ3Q7IHNheXMgJnF1b3Q7dG8gdGhlIGVuZCBvZiB0aGUgcGFja2V0JnF1b3Q7KS4g Q29uc2lkZXIgc29tZXRoaW5nIGxpa2UgYmVsb3c6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyB8MHwgZnJhbWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkLWxlbmd0aCAoaSkgfCBmcmFtZS1w YXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDsmbmJzcDsgb3I8YnI+DQomZ3Q7Jmd0OyB8MXwgZnJh bWUtdHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBXaGVuIE1TQiBvZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHplcm8sIHRoZSBsZW5ndGgg b2YgdGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBpcyBkZXNpZ25hdGVkIGJ5IHRoZSB2 YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZTxicj4NCiZndDsmZ3Q7IHR5 cGUuPGJyPg0KJmd0OyZndDsgV2hlbiBNU0Igb2YgdGhlIGZpcnN0IG9jdGV0IHNldCB0byBvbmUs IHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBzcGFucyB0byB0 aGUgZW5kIG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbiB0aGlz IGVuY29kaW5nLCB3ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0aCBmaWVsZCBvZiBhIFNUUkVB TTxicj4NCiZndDsmZ3Q7IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVh bSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW48YnI+DQomZ3Q7Jmd0OyBwcmFjdGljZS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0 aGUgQUNLIEJsb2NrIENvdW50IGZpZWxkLiBBbmQgdGhlPGJyPg0KJmd0OyZndDsgb3ZlcmhlYWQg d2lsbCBiZSBvbmUgdG8gdHdvIGJpdHMgaWYgdGhlIEFDSyBmcmFtZSBpcyBzZW50IGluIHRoZTxi cj4NCiZndDsmZ3Q7IG1pZGRsZSBvZiB0aGUgcGFja2V0ICh0aGVyZWJ5IHVzaW5nIHRoZSBlbmNv ZGluZyB3aXRoIGV4cGxpY2l0IGZyYW1lPGJyPg0KJmd0OyZndDsgcGF5bG9hZCBsZW5ndGgpLCBv ciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFzdCBmcmFtZTxicj4N CiZndDsmZ3Q7IG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBh cmUgbGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3Ro ZXIgdHlwZXM8YnI+DQomZ3Q7Jmd0OyBvZiBmcmFtZXMsIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0 IHdvdWxkIGJlIGFuIGlzc3VlIGNvbnNpZGVyaW5nIHRoYXQ8YnI+DQomZ3Q7Jmd0OyB0aGV5IHdp bGwgYmUgZmFyIHNlbGRvbSBzZWVuIGNvbXBhcmVkIHRvIFNUUkVBTXMgYW5kIEFDS3MuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUbyBzdW1tYXJpemUsIG15IGFudGljaXBhdGlvbiBpcyB0 aGF0IHdlIGNhbiBtYWtlIGFsbCB0aGUgZnJhbWVzPGJyPg0KJmd0OyZndDsgc2VsZi1jb250YWlu ZWQgKGkuZS4gdGhlIGxlbmd0aCBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHRoZTxicj4NCiZn dDsmZ3Q7IGtub3dsZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFu eSBvdmVyaGVhZCwgaWYgd2U8YnI+DQomZ3Q7Jmd0OyBhZ3JlZSBvbiBtYWtpbmcgdGhlIGZyYW1l IHR5cGUgc3BhY2UgMSBiaXQgc21hbGxlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZp bmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRhaW5lZCBlbmNv ZGluZyBvZjxicj4NCiZndDsmZ3Q7IGZyYW1lcyBpcyB0aGF0IHdlIHdvdWxkIGhhdmUgdGhlIGFi aWxpdHkgdG8gaW50cm9kdWNlIG5ldyBvcHRpb25hbDxicj4NCiZndDsmZ3Q7IGZyYW1lcyB3aXRo b3V0IG5lZ290aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRhaW5lZCwgUVVJ Qzxicj4NCiZndDsmZ3Q7IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3Jp bmcgdGhlIGZyYW1lcyB0aGF0IHRoZXkgZG88YnI+DQomZ3Q7Jmd0OyBub3QgdW5kZXJzdGFuZC48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlaW5nIGFibGUgdG8gc2VuZCBRVUlDIGZyYW1l cyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dDxicj4NCiZndDsmZ3Q7IG5lZ290aWF0aW5n IHVzaW5nIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIHdpbGwgYmUgYSB3aW4gaW4gYm90aCB0ZXJtcyBv Zjxicj4NCiZndDsmZ3Q7IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMnIFRQIGlzIHNlbnQgaW4g Y2xlYXIpIGFuZCBmbGV4aWJpbGl0eTxicj4NCiZndDsmZ3Q7IChiZWNhdXNlIHdlIHdpbGwgYmUg cG9zc2libGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJlPGJyPg0KJmd0 OyZndDsgb3V0IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydHMgdGhhdCBleHRlbnNpb24pLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJl ciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IGxhcmdlciw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBz aXplIGZpZWxkIGlzIHVzZWZ1bCBmb3IgbW9zdDxicj4NCiZndDsmZ3Q7ICZndDsgaW1wbGVtZW50 YXRpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsgQWxzbywgaXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4g ZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxlbmd0aCwgd2hpY2ggYWRkPGJyPg0KJmd0OyZndDsg Jmd0OyBjb21wbGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3JpdGluZyBlcnJvci1wcm9u ZSBjb2RlLiZuYnNwOyBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7ICZndDsgc29tZW9uZSBvZmZs b2FkaW5nIGFjayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcgdG8gdHJ1c3QgdGhlPGJy Pg0KJmd0OyZndDsgJmd0OyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHNlZW1zIGxpa2Ugc29t ZW9uZSBjb3VsZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuPGJy Pg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgTXkgZXhwZXJpZW5jZSBpcyBtdWx0 aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yazxicj4NCiZn dDsmZ3Q7ICZndDsgdGhhbjxicj4NCiZndDsmZ3Q7ICZndDsgaXQncyB3b3J0aC4mbmJzcDsgU3Vy ZSB5b3UgY2FuJ3QgZmlsbCBhIDEwMEcgTklDIHdpdGggb25lIGNvbm5lY3Rpb24sIGJ1dDxicj4N CiZndDsmZ3Q7ICZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsgc2VlbXMgbGlrZSBhbiBhY2Fk ZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLjxicj4NCiZndDsm Z3Q7ICZndDsgVHlwaWNhbGx5PGJyPg0KJmd0OyZndDsgJmd0OyB0aGUgZXh0cmEgY29zdCBvZiBt dWx0aXRocmVhZGluZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IFRvIGJlIGNsZWFyLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYW4gYXdm dWwgaWRlYSwgYnV0IEkgYWxzbyBkb24ndCBzZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4N CiZndDsmZ3Q7ICZndDsgdmFsdWUgYW5kIGl0IGFkZHMgY29tcGxleGl0eS4mbmJzcDsgSSByZWFk IE1hbmFzaSdzIGVtYWlsLCBidXQgSSBkb24ndCB0aGluazxicj4NCiZndDsmZ3Q7ICZndDsgSTxi cj4NCiZndDsmZ3Q7ICZndDsgdW5kZXJzdGFuZCB3aHkgYW55IG9mIHRob3NlIG1hdHRlciBpbiBw cmFjdGljZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBPbiBTYXQsIEp1 biAxNiwgMjAxOCBhdCA0OjEzIFBNIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE9uIEZyaSwgSnVu IDE1LCAyMDE4IGF0IDY6NDYgUE0sIE1hcnRlbiBTZWVtYW5uPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgVGhpcyBwcm9wb3NhbCBpbmNyZWFzZXMgdGhlIHNpemUgb2YgdGhlIEFDSyBmcmFt ZSBieSAxIGJ5dGUgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNvbW1vbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJhbmdlcyksIHNp bmNlIHRoZSBBQ0sgbGVuZ3RoIGZpZWxkIGhlcmUgYWx3YXlzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IGNvbnN1bWVzIDIgYnl0ZXMsIHdoZXJlYXMgdGhlIEFDSyBCbG9jayBDb3VudCBpcyBh IHZhcmlhYmxlLWxlbmd0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbnRlZ2VyLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBDb25zaWRlcmluZyBob3cgbXVjaCB3b3JrIHdlIHB1dCBp bnRvIG1pbmltaXNpbmcgdGhlIHNpemUgb2YgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IGZyYW1lcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhpcyBmZWVscyBsaWtlIGEgc3Rl cCBpbiB0aGUgd3JvbmcgZGlyZWN0aW9uLi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgUmVnYXJkaW5nIHRoZSBwcm9jZXNzaW5nIGNvc3QsIEkg YWdyZWUgd2l0aCBEbWl0cmkuIEhhbmRsaW5nIGFuIEFDSzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBmcmFtZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlcyBsb29waW5nIG92 ZXIgYW5kIG1ha2luZyBjaGFuZ2VzIHRvIGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBrZWVwczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB0cmFjayBv ZiBzZW50IHBhY2tldHMuIFRoaXMgaXMgbXVjaCBtb3JlIGV4cGVuc2l2ZSB0aGFuIHNpbXBseSBw YXJzaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgYnVuY2ggb2YgdmFyaW50cyBpbiB0aGUgQUNLIGZyYW1lLiBJdCBzZWVtcyB1bmxpa2Vs eSB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbXVsdGktdGhyZWFkZWQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcGFja2V0IHBhcnNlciB3b3VsZCBvZmZlciBhbnkgcmVhbC13 b3JsZCBwZXJmb3JtYW5jZSBiZW5lZml0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSSBkb24ndCB3YW50IHRvIG92 ZXJzdGF0ZSB0aGUgYmVuZWZpdCBoZXJlLCBidXQgbXkgcG9pbnQgaXNuJ3QgdGhhdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHBhcnNpbmcgaXMgZXhwZW5zaXZlIGJ1dCB0aGF0IGlmIHlvdSB3YW50 IHRvIGhhdmUgYSBtdWx0aXRocmVhZGVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcGFja2V0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgcHJvY2Vzc2luZyBzeXN0ZW0sIHRoZW4gaXQncyBuaWNlIHRv IGhhdmUgYSBzaW1wbGVyIGRhdGEgc3RydWN0dXJlICh0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB1bnBhcnNlZCBBQ0sgYmxvY2spIHRvIGhhbmQgdG8gdGhlIEFDSyBwcm9jZXNzaW5nIHRocmVh ZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IC1Fa3I8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIFNhdCwgSnVuIDE2LCAy MDE4IGF0IDY6MTkgQU0gTWFydGluIFRob21zb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBXaGVuIHdlIGRpc2N1c3NlZCB0aGlzIGJlZm9yZSwgc29tZSBw ZW9wbGUgb2JzZXJ2ZWQgdGhhdCB0aGlzIGNyZWF0ZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGEgbmVlZCB0byBlbmNvZGUgaW4gdHdvIHBhc3Nlcy4mbmJzcDsgVGhhdCdzIHRoZSB0 cmFkZS1vZmYgaGVyZS4mbmJzcDsgKE5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg ZXhwcmVzc2luZyBhbiBvcGluaW9uLik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9u IEZyaSwgSnVuIDE1LCAyMDE4IGF0IDM6NTEgUE0gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJt YWlsdG86anJpLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpLmlldGZAZ21haWwu Y29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyBJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLiBJJ20gY2VydGFp bmx5IG5vdCBvcHBvc2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IGl0 Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBEb2VzIGFueW9uZSBoYXZlIGEg c3Ryb25nIG9wcG9zaXRpb24/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0 IDM6MTAgUE0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IEkgYWdyZWUgYXMgd2VsbCBzaW5jZSB0aGlzIGNhbiBoZWxwIHJlZHVjZSBw ZXIgcGFja2V0IHByb2Nlc3Npbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IG92ZXJoZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9u IGZyYW1lIHR5cGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNvIG5v PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvYmplY3Rpb25zIHRvIHNw ZWNpYWwgY2FzaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgRnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgRXJpYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgUmVzY29ybGE8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVu ZSAxNSwgMjAxOCA5OjExIEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBUbzogRGV2YWwsIE1hbmFzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRl bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9hPiZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IENjOiBKYW5hIEl5ZW5nYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmku aWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byBy ZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEkgYWdyZWUgd2l0aCBNYW5hc2kgaGVyZS4gVGhp cyBjaGFuZ2Ugd291bGQgYWxsb3cgYWNrIGZyYW1lPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBwYXJzaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB0byBiZSBtb3JlIHNlbGYtY29udGFpbmVkLCB3aGljaCBpcyBhbiBhZHZhbnRhZ2UgZm9y IHRoZSBwYXJzZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCBh bHNvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwb3RlbnRpYWxseSBm b3IgcGFyYWxsZWxpc20gKGJlY2F1c2UgeW91IGNhbiBxdWlja2x5IGZpbmQgdGhlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSBhbmQgdGhlbjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcHJvY2VzcyBpdCBpbiBwYXJhbGxlbCkuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtRWtyPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDU6MjIgUE0sIERldmFsLCBNYW5hc2k8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFu YXNpLmRldmFsQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmFzaS5kZXZhbEBpbnRlbC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJbiBnZW5lcmFsLCB2YXJp bnRzIHJlcXVpcmUgc29tZSBzcGVjaWZpYyBsb2dpYyBmb3IgcGFyc2luZy4gVG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNraXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkg c2luZ2xlIHZhcmludC4gQXMgdGhlIGNvZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IHNlZXMgU3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBhbmQgQUNLIGhlYWRlcnMgbW9zdCBmcmVxdWVudGx5LCB0aGF0IGlzIG15IGZvY3VzLiZu YnNwOyBUaGUgU3RyZWFtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBm cmFtZSBoYXMgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGVuZ3Ro IGluIGl0cyB0aGlyZCBmaWVsZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IEFDSyBwYXJzaW5nLCBob3dldmVyLCBuZWVkcyA2ICYjNDM7IDIqbnVtX2Jsb2Nr cyByZWFkcyB0byBpZGVudGlmeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgbGVuZ3RoLiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9yIOKAmGxhcmdlc3QgYWNrbm93 bGVkZ2Vk4oCZLCDigJhBQ0s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IGRlbGF54oCZIGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg4oCY QUNLIGJsb2NrIGNvdW504oCZLiBUaGUgcGFpbiBwb2ludCBpcyB0aGUgdG90YWwgbnVtYmVyIG9m IGN5Y2xlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcGFyc2UgYW48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEFDSy4gSWYgSSBhbSBwcm9j ZXNzaW5nIDEwTSBwcHMsIHdoZXJlIDEwJSAtIDMwJSBvZiB0aGUgcGFja2V0czxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaGF2ZSBhPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVz IGEgc2lnbmlmaWNhbnQgYm90dGxlbmVjay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNYW5hc2k8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBRVUlDIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKYW5hPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJeWVuZ2FyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBTZW50OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgVG86IERldmFsLCBNYW5hc2kgJmx0OzxhIGhy ZWY9Im1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXNp LmRldmFsQGludGVsLmNvbTwvYT4mZ3Q7OyBRVUlDIFdHPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9j ayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IFlvdSdyZSByaWdodCB0aGF0IHdlIG5vIGxvbmdlciBoYXZlIHRoZSBhYmls aXR5IHRvIHNraXAgYW4gQUNLPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBmcmFtZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCB0aGlz IGNyZXB0IGluIHdoZW4gd2UgbW92ZWQgdG8gdmFyaW50cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0 IGZyYW1lcyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGp1c3Qg QUNLcywgc2luY2UgaWRzLCBwYWNrZXQgbnVtYmVycywgYW5kIG51bWJlcnMgaW4gYWxsIGZyYW1l czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgYXJlIG5vdyBhbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHZhcmludHMuIFRvIHNraXAgYW55 IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50IGZpZWxkczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgaW4gdGhvc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lcy4gSWYgeW91IGhhdmUgbG9naWMgdG8gcHJvY2Vz cyBhbmQgc2tpcCB2YXJpbnRzLCB0aGVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBza2lwcGluZyB0aGUgYWNrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBibG9jayBzZWN0aW9uIGlzIG1lcmVseSByZXBlYXRpbmcgdGhpcyBvcGVyYXRpb24g KDIqbnVtX2Jsb2NrJiM0MzsxKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgdGltZXMuIERvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB5b3Ug c2VlIHNwZWNpZmljIHZhbHVlIGluIHNraXBwaW5nIEFDSyBmcmFtZXMgb3ZlciB0aGUgb3RoZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wgZnJhbWVzPzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRyaSBUaWtob25v djxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC4uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHRpa2hv bm92QGxpdGVzcGVlZHRlY2guLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDAzOjMzOjM1UE0gJiM0MzswMDAwLCBEZXZhbCwg TWFuYXNpIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1vdmluZyB0aGUgQUNLIGxlbmd0aCB0byB0 aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmbGV4aWJpbGl0eSBvZiBl aXRoZXIgcmVhZGluZyB0aGUgZW50aXJlIEFDSyBvciByZWFkaW5nPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZmly c3QgMTYgYml0cyBhbmQgc2tpcHBpbmcgb3ZlciB0aGUgbGVuZ3RoLiBUaGlzIGlzIGE8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgdXNlZnVsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBmZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sgcHJvY2Vzc2luZyBpcyBz cGxpdCBpbnRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtdWx0aXBsZSBsYXllcnMuIERlcGVuZGlu ZyBvbiB0aGUgcHJvY2Vzc29yIHRoaXMgaXMgcnVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IG9uLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgYXJlIGRp ZmZlcmVudCBhZHZhbnRhZ2VzIC08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdXN0IGEgbm90ZS4m bmJzcDsgSW4gbXkgZXhwZXJpZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWdsaWdpYmxlIGNvbXBhcmVkIHRvIHRoZSBjb3N0 IG9mIHByb2Nlc3NpbmcgYW4gQUNLIGZyYW1lOiB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IHBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBuZXdseSBB Q0tlZCBwYWNrZXRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOy0gRG1pdHJp Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsg S2F6dWhvIE9rdTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3U8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1F436ED13A22A246A59CA374CBC543998B843873ORSMSX111amrcor_-- From nobody Thu Jun 21 16:25:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5B12777C for ; Thu, 21 Jun 2018 16:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 DiETpvZAOc5c for ; Thu, 21 Jun 2018 16:25:21 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 BFE5E127332 for ; Thu, 21 Jun 2018 16:25:21 -0700 (PDT) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 16:25:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,253,1526367600"; d="png'150?scan'150,208,217,150";a="48959443" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga007.fm.intel.com with ESMTP; 21 Jun 2018 16:25:20 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 21 Jun 2018 16:25:20 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX114.amr.corp.intel.com ([169.254.8.118]) with mapi id 14.03.0319.002; Thu, 21 Jun 2018 16:25:20 -0700 From: "Deval, Manasi" To: Nick Banks , "quic@ietf.org" Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAFy+Sw Date: Thu, 21 Jun 2018 23:25:19 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B843999@ORSMSX111.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWRhZjY2YzgtYTY2YS00YWRlLWI4ZTYtMzA1NjE3YjhmZmY4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYmdHb1gwZFwvN1VHaDdQVXBDS1VyTllXT09RUTBoVUVpOUltMDRGK0JMcGthMmJtTWxjTCs5ZHB4T3RjN24rTTUifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/related; boundary="_004_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 23:25:27 -0000 --_004_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_ Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_" --_000_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 10% increase on server may be quite significant on a client machine. Th= is may be an issue for mobile devices. Manasi From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Nick Banks Sent: Thursday, June 21, 2018 1:48 PM To: quic@ietf.org Subject: Packet Number Encryption Performance Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): [cid:image001.png@01D4097C.184A6370] Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick --_000_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 10% increase on se= rver may be quite significant on a client machine. This may be an issue for= mobile devices.

 

Manasi

 

 

From: QUI= C [mailto:quic-bounces@ietf.org] On Behalf Of Nick Banks
Sent: Thursday, June 21, 2018 1:48 PM
To: quic@ietf.org
Subject: Packet Number Encryption Performance

 

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.=

 

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

 

 

Time (ms)<= /span>

Rate (Mbps)

Bytes

NO PNE

PNE=

PNE Overhead

No PNE

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 

--_000_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_-- --_004_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=29298; creation-date="Thu, 21 Jun 2018 23:25:19 GMT"; modification-date="Thu, 21 Jun 2018 23:25:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --_004_1F436ED13A22A246A59CA374CBC543998B843999ORSMSX111amrcor_-- From nobody Thu Jun 21 16:36:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7DC127AC2 for ; Thu, 21 Jun 2018 16:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8tt3LzWYuTs for ; Thu, 21 Jun 2018 16:36:50 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37ADF12785F for ; Thu, 21 Jun 2018 16:36:50 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5LNafLO018770; Fri, 22 Jun 2018 00:36:41 +0100 (BST) Received: from BGB01XI1004.national.core.bbc.co.uk (10.184.50.54) by BGB01XI1011.national.core.bbc.co.uk (10.161.14.15) with Microsoft SMTP Server (TLS) id 14.3.389.1; Fri, 22 Jun 2018 00:36:41 +0100 Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1004.national.core.bbc.co.uk ([10.184.50.54]) with mapi id 14.03.0389.001; Fri, 22 Jun 2018 00:36:40 +0100 From: Lucas Pardue To: Jana Iyengar CC: Roberto Peon , Martin Thomson , QUIC WG , Mike Bishop Subject: RE: Path forward with stream headers Thread-Topic: Path forward with stream headers Thread-Index: AdQIENSUAUHFuhsDSVSI2JhFySDeG///nSCA//9xobCAAQ6RgIAACWUAgAACQQCAAVjHgIAADIsAgAAE3YCAAWkFgIAAGsopgAAfmICAABdTNg== Date: Thu, 21 Jun 2018 23:36:39 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B2C8@bgb01xud1012> References: <0CEEAD26-8CCD-4506-AB9B-941701A3962C@fb.com> <65C79755-0D0E-4786-9494-731CA380DBC8@fb.com> <9C41B8AC-515A-40D3-8162-285F26DD2642@fb.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B27A@bgb01xud1012>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-23922.003 X-TM-AS-Result: No-25.809700-8.000000-10 X-TMASE-MatchedRID: b/1IsOqez6d2eNZNqWU3H8qXjImgj58bju+GX08gELDmQx8ZECP6e/ea 4uH4Y9hvox3eLPiNwxUI/uAZhBR3ZR1YpEPWJiyzF0vYDRID+crRahuPwaQ1WrII+BcngqQ8n68 M3lJ/4rmPOUYXFMZ53nSxb76ag5Nay6nXBt6I/Bov2E0OPZsHB/a/bRHEsPI3wPIW/nmxDKgvu1 lVcZKEoEe2hPXfXQDtOrdW+lppsNbOWt5JgsaVVUKcYi5Qw/RVYpovC7zX5q/qLnOUXH9QdMMpI ZACY/bBomGAuAptZl1FxlKPbeVUqM/37CIrJSBATVa+L3Zgqc7LBdK2mpaYlqvM+zzl/BSTSFpI Z3L5rR8Nw+DYi2ZSrllVlNW6LdwVAbDZOrlndJi3UCG/IQp2PqX1XMd/SqvuCZch4INkhioKDpy 6oiUnx3JS4f6hWI8wKOJdFzEcmJu2L7ZGrRpjDce31VQ+6yRGf7rvXBvEkWm/DsA7dUYjzkxQVO cxxUOlfN/TUSJWLWl0fTzLMWE5Ci+IAeTRb8cP4NAJeq9IDSwb1/7MUw/GuqEQSMuSdJfAb9mYr gm1c2PrdNCmvWF8mG2Qt0yaekNi2mQ59oV+WcBU/2M0RAfTitZKsq3DGpalgBeiq2bjyEks6zDB dwhLRxeD6oFh+3IFFxX5hsTzsUB16NuLD9SbQnQIOMndeKgE4b+uxQ/rA9ZScXQMxepe+2y5oRP T/gnF9Nhvm1lZioV6Icng2y1Lgp/yorkJXkCFvHKClHGjjr1U+YqtAU+F2RKAWnKBwBf/UgqMah PZV4ji8zVgXoAltj2Xsf5MVCB18gATfdkjbTzdB/CxWTRRu/558CedkGIvIXptJJqT2TE= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--25.809700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-23922.003 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 23:36:55 -0000 T25lIGJyb2FkIGV4YW1wbGUgSSB0aGluayBtZW50aW9uZWQgc29tZXdoZXJlIG9uY2UgcmVsYXRl ZCB0byBIVFRQIGV4dGVuc2lvbiBmcmFtZXMuIEluIEgyLCBmcmFtZXMgbm90IGFzc29jaWF0ZWQg d2l0aCByZXF1ZXN0L3Jlc3BvbnNlIGFyZSB1c3VhbGx5IGR1bXBlZCBvbiB0aGUgY29udHJvbCBz dHJlYW0uIExhcmdlLCB1bnJlbGF0ZWQgZnJhbWVzIGNvdWxkIEhvTCBibG9jayB0aGF0IHN0cmVh bS4NCg0KSFRUUC9RVUlDIGNvdWxkIGFsbG93IHN1Y2ggZnJhbWVzIHRvIGJlIHNlbnQgb24gdW5p ZGlyZWN0aW9uYWwgc3RyZWFtcyAoIGJ1dCBub3QgY3VycmVudGx5IGJlY2F1c2Ugc2VydmVyIHB1 c2ggZ29iYmxlZCB1cCBhIGhhbGYgb2YgdGhhdCBzcGFjZSkuDQoNCkx1Y2FzDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW2pyaS5p ZXRmQGdtYWlsLmNvbV0NClNlbnQ6IDIyIEp1bmUgMjAxOCAwMDowNg0KVG86IEx1Y2FzIFBhcmR1 ZQ0KQ2M6IFJvYmVydG8gUGVvbjsgTWFydGluIFRob21zb247IFFVSUMgV0c7IE1pa2UgQmlzaG9w DQpTdWJqZWN0OiBSZTogUGF0aCBmb3J3YXJkIHdpdGggc3RyZWFtIGhlYWRlcnMNCg0KSGkgTHVj YXMsDQoNCkl0J3MgYSBtYXR0ZXIgb2YgdHJhaW5pbmcuLi4gdGhlIHRvb2xzIGNhbiBjZXJ0YWlu bHkgaGVscCwgYnV0IG15IHBvaW50IGlzIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4gc3BlY2lmaWMg c3RyZWFtIElEcyBiZWluZyBrbm93biBpZGVudGlmaWVycywgcmF0aGVyIHRoYW4gb3BhcXVlIGlk ZW50aWZpZXJzLiBJIGZpbmQgc2VsZi1kZXNjcmlwdGl2ZW5lc3MgdG8gYmUgdmFsdWFibGUuDQoN CkknbSBhbHNvIG5vdCB5ZXQgY29udmluY2VkIHRoYXQgd2UgbmVlZCBleHRlbnNpYmlsaXR5IGlu IHRoaXMgcGFydGljdWxhciBtYW5uZXIuIEFyZSB0aGVyZSBleGFtcGxlcyBvZiB0aGluZ3Mgd2Ug YW50aWNpcGF0ZSBuZWVkaW5nIHRoaXMgZXh0ZW5zaWJpbGl0eSBmb3IsIHRoYXQgd2Ugd291bGRu J3Qgd2FudCBhIHZlcnNpb24gcmV2IGZvcj8NCg0KLSBqYW5hDQoNCk9uIFRodSwgSnVuIDIxLCAy MDE4IGF0IDE6MTQgUE0gTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPG1haWx0 bzpMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPj4gd3JvdGU6DQpIaSBKYW5hLA0KDQpJIGFwcHJlY2lh dGUgdGhlIGRlYnVnZ2FiaWxpdHkgY29uY2VybnMsIGNhbiB0aGlzIGp1c3QgYmUgc29sdmVkIGJ5 IHRvb2xpbmc/IElzIHRoZSBpc3N1ZSB3aXRoIHRyeWluZyB0byBsb29rIGF0IGFwcGxpY2F0aW9u IGRlYnVnIGxvZ3MgaW4gcmVhbHRpbWUgYXMgYXBwbGljYXRpb25zIHJlY2VpdmUgUVVJQyBwYWNr ZXRzPw0KDQpXaXJlc2hhcmsgZm9yIEhUVFAvMiBhbHJlYWR5IGFjdHMgc3RhdGVmdWxseSB3aGVu IGl0IGRlY3J5cHRzIHNlc3Npb25zIGFuZCBkaXNzZWN0cyBIUEFDSywgd291bGQgaXQgYmUgdGVy cmlibHkgZGlmZmljdWx0IGZvciBpdCB0byByZWFkIHRoaXMgZmlyc3QgYnl0ZSBhbmQgcmVwcmVz ZW50IHRoZSBzdHJlYW0gdHlwZSBpbiBhIGNvbnZlbmllbnQgd2F5Pw0KDQpOb3RlIHRoYXQgdGhl IHByb3Bvc2FsIGlzIGp1c3QgZm9yIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgLSBjbGllbnQtaW5p dGlhdGVkIGJpZGkgc3RyZWFtcyBhcmUgbm9ybWFsIHJlcXVlc3QvcmVzcG9uc2Ugb24gaW5jcmVt ZW50aW5nIHN0cmVhbSBJRHMsIHRoYXQncyBhbGwgdGhhdCBuZWVkcyB0byBiZSBsb29rZWQgZm9y IGluIGEgbG90IG9mIHRyYWZmaWMgc2NlbmFyaW9zLg0KDQpJJ20gcHJvYmFibHkgZmFyIGxlc3Mg ZXhwZXJpZW5jZWQgd2l0aCBkZWJ1Z2dpbmcgR1FVSUMgdHJhY2VzIGJ1dCBpbiBteSBleHBlcmll bmNlIGNyb3NzIHJlZmVyZW5jaW5nIGZyYW1lcyBmcm9tIFN0cmVhbSAzIHRvIHRoZSByZXNwb25z ZSBzdHJlYW0gd2FzIGFsd2F5cyBhIGJpdCBjbHVua3ksIGVzcGVjaWFsbHkgZm9yIHB1c2ggcHJv bWlzZS4gU2VlIHRoZSBhdHRhY2hlZCBzY3JlZW5zaG90IG9mIGEgdmVyeSBvbGQgd2lyZXNoYXJr IGRpc3NlY3Qgb2YgR1FVSUMgKE5CIEFsZXhpcyBMYSBHb3V0dGUgcXVpY2tseSBmaXhlZCB0aGUg YnVnIHdpdGggZGVjb2RpbmcgdGhlIEhlYWRlciBCbG9jayBGcmFnbWVudCBzaG93biBpbiB0aGF0 IGltYWdlLCB0aGFua3MhKS4NCg0KTHVjYXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBRVUlDIFtxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBKYW5hIEl5ZW5nYXIgW2pyaS5pZXRmQGdtYWlsLmNv bTxtYWlsdG86anJpLmlldGZAZ21haWwuY29tPl0NClNlbnQ6IDIxIEp1bmUgMjAxOCAyMDozNw0K VG86IFJvYmVydG8gUGVvbg0KQ2M6IE1hcnRpbiBUaG9tc29uOyBRVUlDIFdHOyBNaWtlIEJpc2hv cA0KU3ViamVjdDogUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFkZXJzDQoNCk1pa2Un cyBwb2ludCB0aGF0IHRoZSBIVFRQIGhlYWRlcnMgbmVlZCB0byBiZSByZWFkIGJlZm9yZSByZWFk aW5nIGRhdGEgZnJvbSBhIHN0cmVhbSBvdXQgb2Ygb3JkZXIgbWFrZXMgaXQgY2xlYXIgdGhhdCB0 aGUgZmlyc3QgYnl0ZXMgYXJlIGFscmVhZHkgSG9MIGJsb2NraW5nIGluIHRoaXMgY3VycmVudCBt YXBwaW5nLiBHaXZlbiB0aGUgY3VycmVudCBtYXBwaW5nLCB3aGlsZSBJJ20gc3ltcGF0aGV0aWMg dG8gUm9iZXJ0bydzIGFyZ3VtZW50IHRoYXQgdGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBhbiBh cHBsaWNhdGlvbiBtaWdodCB3YW50IHRvIHJlYWQgZGF0YSBvdXQgb2Ygb3JkZXIgZnJvbSBhIHN0 cmVhbSwgSSBkb24ndCBzZWUgYWRkaXRpb25hbCBIb0wgYmxvY2tpbmcgYmVjYXVzZSBvZiB0aGlz IGJ5dGUuDQoNClRoYXQgc2FpZCwgSSBsaWtlIHRoZSBzZWxmLWRlc2NyaXB0aXZlbmVzcyBvZiB0 aGUgc3RyZWFtIElELiBFdmVuIGZvciBkZWJ1Z2dpbmcgcHVycG9zZXMsIGl0J3MgYSBtYXR0ZXIg b2YgdHJhaW5pbmcgeW91cnNlbGYgdG8gdW5kZXJzdGFuZCB3aGF0IHN0cmVhbSBJRHMgbWVhbiB3 aGF0IHR5cGUgb2Ygc3RyZWFtLCBidXQgb25jZSB0aGF0J3MgZG9uZSwgaXQncyBhbHdheXMgdHJ1 ZSBmb3IgUVVJQ3YxLiBIYXZpbmcgbG9va2VkIGF0IGEgbGFyZ2UgbnVtYmVyIG9mIEdRVUlDIHRy YWNlcywgSSBjYW4gc2F5IHRoYXQgYmVpbmcgYWJsZSB0byB0ZWxsIGF0IGEgZ2xhbmNlIHdoYXQg YSBwYXJ0aWN1bGFyIHN0cmVhbSBJRCBhY3Jvc3MgdHJhY2VzIGlzIHZlcnkgdXNlZnVsIChJbiBH UVVJQywgc3RyZWFtIDEgaXMgY3J5cHRvLCBzdHJlYW0gMyBpcyBoZWFkZXJzLCBhbmQgc3RyZWFt IDUgaXMgdGhlIGZpcnN0IHJlcXVlc3Qgc3RyZWFtIGZyb20gdGhlIGNsaWVudCkuICBXaXRoIGEg dHlwZSBieXRlLCBkZWJ1Z2dhYmlsaXR5IGlzIHdvcnNlLCBzaW5jZSB5b3Ugbm93IG11c3Qgc2Vl IHRoZSBmaXJzdCBieXRlIGFuZCByZW1lbWJlciB3aGF0IHN0cmVhbSBJRCBtYXBzIHRvIHdoYXQg Zm9yIHRoZSByZXN0IG9mIHRoZSBjb25uZWN0aW9uLCBhbmQgeW91IG5lZWQgdG8gZG8gdGhpcyBm b3IgZXZlcnkgY29ubmVjdGlvbiB5b3UncmUgbG9va2luZyBhdC4NCg0KR2l2ZW4gbXkgZXhwZXJp ZW5jZSwgSSB3b3VsZCBwcmVmZXIgaGF2aW5nIHN0cmVhbSBJRHMgdGhhdCBhcmUgc2VsZiBkZXNj cmlwdGl2ZS4NCg0KSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8ga2VlcCB0aGlzIGZsZXhpYmxl IGZvciBmdXR1cmUgdHdlYWtzIG9mIEhUVFAvUVVJQyB3aXRob3V0IGEgdmVyc2lvbiByZXYsIGJ1 dCBpdCBpcyBhIGRlZ3JlZSBvZiBmcmVlZG9tIHRoYXQgd2UgY2FuIHN1cmVseSBwbGFuIHRvIGV4 ZXJjaXNlIGZvciB0aGluZ3Mgd2UgY2Fubm90IGFudGljaXBhdGUgcmlnaHQgbm93LiBJJ20gbm90 IHlldCBjb252aW5jZWQgdGhhdCBhZGRpbmcgdGhpcyBhZGRpdGlvbmFsIGV4dGVuc2liaWxpdHkg bWVjaGFuaXNtIGlzIG5lY2Vzc2FyeSByaWdodCBub3cuDQoNCg0KT24gV2VkLCBKdW4gMjAsIDIw MTggYXQgMzowNSBQTSBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIu Y29tPj4gd3JvdGU6DQpZZXAsIHlvdSdyZSByaWdodCwgYmVjYXVzZSB3ZSdyZSBub3QgaGF2aW5n IEhFQURFUlMgdnMgREFUQSBmcmFtZXMgYXMgYSBRVUlDLWxheWVyIHRoaW5nLCB3ZSdyZSBzY3Jl d2VkLg0KDQotPVINCg0K77u/T24gNi8yMC8xOCwgMjo0OCBQTSwgIk1pa2UgQmlzaG9wIiA8bWJp c2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQoN CiAgICBCdXQgeW91IGRvbid0IGtub3cgd2hlcmUgdGhlIGJvZHkgaXMgdW50aWwgeW91J3ZlIHNl ZW4gdGhlIGhlYWRlci4gIE90aGVyd2lzZSwgeW91J3JlIG5vdCBjZXJ0YWluIHRoYXQgd2hhdCB5 b3UncmUgc2VlaW5nICppcyogYm9keSwgcmF0aGVyIHRoYW4gc29tZXRoaW5nIGluIGEgZGlmZmVy ZW50IGZyYW1lIHRoYXQgaGFwcGVucyB0byBsb29rIGxpa2UgeW91ciBzZWxmLWRlc2NyaXB0aW9u Lg0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBSb2JlcnRvIFBl b24gW21haWx0bzpmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT5dDQogICAgU2VudDog V2VkbmVzZGF5LCBKdW5lIDIwLCAyMDE4IDI6MDMgUE0NCiAgICBUbzogTWFydGluIFRob21zb24g PG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuLmNv bT4+DQogICAgQ2M6IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJp c2hvcEBldmVxdWVmb3UuYmU+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0Bp ZXRmLm9yZz4+DQogICAgU3ViamVjdDogUmU6IFBhdGggZm9yd2FyZCB3aXRoIHN0cmVhbSBoZWFk ZXJzDQoNCiAgICBZb3UncmUgYXNzdW1pbmcgdGhlIGRhdGEgaXNuJ3Qgc2VsZi1kZXNjcmlwdGl2 ZSBpbiB0aGUgYm9keS4NCiAgICAtPVINCg0KICAgIE9uIDYvMTkvMTgsIDU6MjkgUE0sICJNYXJ0 aW4gVGhvbXNvbiIgPG1hcnRpbi50aG9tc29uQGdtYWlsLi5jb208bWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQogICAgICAgIE9uIFdlZCwgSnVuIDIwLCAyMDE4IGF0 IDEwOjIxIEFNIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+ PiB3cm90ZToNCiAgICAgICAgPiBIb3dldmVyLCBpZiBvbmUgbXVzdCByZWNlaXZlIHRoZSBmaXJz dCBwYWNrZXQgb2YgZWFjaCBzdHJlYW0sIGFkZGl0aW9uYWwgSG9MIGJsb2NraW5nICh3aGljaCBw cmV2ZW50cyBwbGF5YmFjay9pbnRlcnByZXRhdGlvbikgaXMgaW5kdWNlZC4NCg0KICAgICAgICBU aGlzIGlzIHRoZSBiaXQgSSdtIHB1c2hpbmcgYmFjayBvbi4gIFRoZSBmaXJzdCBieXRlIGlzbid0 IHByaXZpbGVnZWQuDQogICAgICAgIFRoZXJlJ3MgYSBwdXNoIElELCBhIEhFQURFUlMgZnJhbWUs IGFuZCB0aGUgc3RhcnQgb2YgdGhlIGZpcnN0IERBVEENCiAgICAgICAgZnJhbWUgYmVmb3JlIHlv dSBjYW4gc3RhcnQgaW50byByYW5kb20gYWNjZXNzLiAgV2l0aG91dCB0aGF0LCB5b3UNCiAgICAg ICAgY2FuJ3Qga25vdyB3aGF0IHlvdSBhcmUgcmVhZGluZy4gIEkgZmFpbCB0byBzZWUgaG93IG9u ZSBhZGRpdGlvbmFsDQogICAgICAgIG9jdGV0IGlzIGEgcHJvYmxlbSBoZXJlLg0KDQoNCg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpU aGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZA0KbWF5 IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJC QyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGlu DQplcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwg Y29weSBvciBkaXNjbG9zZSB0aGUNCmluZm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiBy ZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5Lg0KUGxlYXNl IG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFpbHMNCnNlbnQgb3IgcmVjZWl2ZWQuDQpG dXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0bw0KdGhpcy4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Thu Jun 21 17:56:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B65212F1AC for ; Thu, 21 Jun 2018 17:56:00 -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_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Beg4FxQo06mM for ; Thu, 21 Jun 2018 17:55:57 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 86DAD1294D0 for ; Thu, 21 Jun 2018 17:55:57 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id a195-v6so667716itd.3 for ; Thu, 21 Jun 2018 17:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EeVblIsSgk6vLB+TUwUDTad6e00SMyQRIIQtfY2eyf8=; b=LCUTahBM6dYx+JKykScn8FYsrDzY/SEXQhiztHNAFDH9gRE+tnBcNWGLYd9Fd1ZnED QPr6VEqnpAjLKaHywjKHknOqFnUp9eqpCuFpOKdItDsSh9RSZ736Bv1Nb8NIAhUjvGz8 mX5UAOWskdJJNf9FvlqUZq/vMppg44xm2NI4RTUg1u4etkOjhUxPKi8WPSMMkIAizDnQ L9z8LwF7XpCVGXr3y4q26UVL4mZrg0Q26RtsZso87CaYNSZqN9Ki+Pp5CXsSec4BsGh5 M6H/4iIIoZzy0D/31ZKM3PgR831d4r1Yvnu1PXOXbJC9DTZOnlGvbU/qZLb2DsRuVkkP WrxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EeVblIsSgk6vLB+TUwUDTad6e00SMyQRIIQtfY2eyf8=; b=TjnIBUd0deVi0XyoS/AjJIrfekwjU4XIunbYxi8KtuA2ZIzXi7WHS318k72aXh/2y+ 65w0ePPbHiRV+m7QQG3LPiGLIL33uQ6aDsevQ0qZO5M8Ox1PTlP4u1yryjkBdZ2djmBj SNGibHQjmFA3e73eAUcKlrYgAoY//z7p/RpAM5em7/EbXr7V74nAvGS4atYEecIkzsnM yoEOMlsf3f8W0S5v3Wt+YyBT3b3/MrdYuMAkWcoqC/qrNW4WeuW19SdPpJk9yynjYlMq jSvvGf7dCcDWWtocDfjqDjAYf8T/gL0UMJUIwUCb6phcySQ4gjyfRgrQp6HZiD/0hQdW YFEQ== X-Gm-Message-State: APt69E1Ppc9euerlbOgvPnVo4xuTAa/6T9B1IDwBaI85SKBHWMpznBLa s2vH2xdHnbPZ9hq0yRrkgYo+7Zi6lsQIxX9/bdw= X-Google-Smtp-Source: ADUXVKICfnFCGxP9mMflVNrsYiiSaSkP/d+/TMuBSC9p+enTXYBBHdCrK9B8FfNzSADoP7+qvEePCZJeMd5SuxuwKbw= X-Received: by 2002:a24:1643:: with SMTP id a64-v6mr7458877ita.101.1529628956188; Thu, 21 Jun 2018 17:55:56 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B843999@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B843999@ORSMSX111.amr.corp.intel.com> From: Jana Iyengar Date: Thu, 21 Jun 2018 17:55:44 -0700 Message-ID: Subject: Re: Packet Number Encryption Performance To: "Deval, Manasi" Cc: nibanks=40microsoft.com@dmarc.ietf.org, QUIC WG Content-Type: multipart/related; boundary="0000000000009295d1056f307eae" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 00:56:01 -0000 --0000000000009295d1056f307eae Content-Type: multipart/alternative; boundary="0000000000009295cf056f307ead" --0000000000009295cf056f307ead Content-Type: text/plain; charset="UTF-8" Thanks for sharing these numbers, Nick! A few questions: 1. It's quite possibly I'm missing something basic, but: Assuming the same number of packets (10M in your experiments), why do smaller packets result in lower rates? Shouldn't encrypting the same number of smaller packets result in a higher rate? 2. PNE seems to add about 700-800ms of latency, which understandably decreases as % overhead as the packet size increases. But the difference in rates seems to increase as the packet size increases, which is exactly counter-intuitive. How do you compute rate? 3. What's the PN size used? On Thu, Jun 21, 2018 at 4:25 PM Deval, Manasi wrote: > The 10% increase on server may be quite significant on a client machine. > This may be an issue for mobile devices. > > > > Manasi > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Nick Banks > *Sent:* Thursday, June 21, 2018 1:48 PM > *To:* quic@ietf.org > *Subject:* Packet Number Encryption Performance > > > > Hello QUIC WG, > > > > I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided > to get some performance numbers to see what the overhead of PNE was. I > figured the rest of the WG might be interested. > > > > My test just encrypts the same buffer (size dependent on the test case) > 10,000,000 times and measured the time it took. The test then did the same > thing, but also encrypted the packet number as well. I ran all that 10 > times in total. I then collected the best times for each category to > produce the following graphs and tables (full excel doc attached): > > > > > > *Time (ms)* > > *Rate (Mbps)* > > *Bytes* > > *NO PNE* > > *PNE* > > *PNE Overhead* > > *No PNE* > > *PNE* > > *4* > > 2284.671 > > 3027.657 > > 33% > > 140.064 > > 105.692 > > *16* > > 2102.402 > > 2828.204 > > 35% > > 608.827 > > 452.584 > > *64* > > 2198.883 > > 2907.577 > > 32% > > 2328.45 > > 1760.92 > > *256* > > 2758.3 > > 3490.28 > > 27% > > 7424.86 > > 5867.72 > > *600* > > 4669.283 > > 5424.539 > > 16% > > 10280 > > 8848.68 > > *1000* > > 6130.139 > > 6907.805 > > 13% > > 13050.3 > > 11581.1 > > *1200* > > 6458.679 > > 7229.672 > > 12% > > 14863.7 > > 13278.6 > > *1450* > > 7876.312 > > 8670.16 > > 10% > > 14727.7 > > 13379.2 > > > > I used a server grade lab machine I had at my disposal, running the latest > Windows 10 Server DataCenter build. Again, these numbers are for crypto > only. No QUIC or UDP is included. > > > > Thanks, > > - Nick > > > --0000000000009295cf056f307ead Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for sharing these numbers, Nick! A few questions:1. It's quite possibly I'm missing something basic, but: Assumin= g the same number of packets (10M in your experiments), why do=C2=A0smaller= packets result in lower rates? Shouldn't encrypting the same number of= smaller packets result in a higher rate?
2. PNE seems to add= about 700-800ms of latency, which understandably decreases as % overhead a= s the packet size increases. But the difference in rates seems to increase = as the packet size increases, which is exactly counter-intuitive. How do yo= u compute rate?
3. What's the PN size used?


On Thu, Jun 21, 2018 at 4:25 PM Deval, Ma= nasi <manasi.deval@intel.com> wrote:

The 10% increase on se= rver may be quite significant on a client machine. This may be an issue for= mobile devices.

=C2=A0

Manasi

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Nick Banks
Sent: Thursday, June 21, 2018 1:48 PM
To: quic@ietf.org=
Subject: Packet Number Encryption Performance

=C2=A0

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

<= u>

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0

--0000000000009295cf056f307ead-- --0000000000009295d1056f307eae Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <16424f4ee444cff311> X-Attachment-Id: 16424f4ee444cff311 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --0000000000009295d1056f307eae Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <> X-Attachment-Id: iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --0000000000009295d1056f307eae-- From nobody Thu Jun 21 18:21:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFBA130DFC for ; Thu, 21 Jun 2018 18:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk_NxbF8E8ek for ; Thu, 21 Jun 2018 18:21:38 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on070a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::70a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FABF130DEF for ; Thu, 21 Jun 2018 18:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GfX1p6LFWpn3hdXOsmhr4S1vcxE4C0yiiCClPv5XBfc=; b=LcQDiQrGc2Sfkuij5f1ZRErA9xYwd/Q2w8+LHlrMZULTg8CuY1y+Wqgn6LaYH5H3GIG9X7EP12KJcYLmwh+DH5vr4BX2XGPEYtwyGthnPtA3OTA3NcxTkjs+ccCPBOXDbm2bNsNqcH9AJtYSR/Z2IR1Wy0J5RXZLXNlPEzN4/z4= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0869.namprd21.prod.outlook.com (10.167.110.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.8; Fri, 22 Jun 2018 01:21:37 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Fri, 22 Jun 2018 01:21:37 +0000 From: Nick Banks To: Jana Iyengar , "Deval, Manasi" CC: QUIC WG Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAFy+SwAAM+xwAAAKfxMQ== Date: Fri, 22 Jun 2018 01:21:36 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B843999@ORSMSX111.amr.corp.intel.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0869; 7:+QGioOw1D8gAcqV68pVTAhfKXMGSZfWNTNLfby1CBAEsB3ZM+61TZvX9R6ACQp4YfaMyKPuMHmQERjgmL5yZ61FsAFxIA5q33O1jZIph/NIcABak0bYqzNRk0otQfOKqykTlXROxSuIISxA5ZSjQYgP3TOAJTQLxeJ2N+jiHhHjzZwuyMIAMcKTEPyFlJbYIc8dbzzeyx8/0wVF//IFbLWLDLOwUtT5hDRtl3XtT6AL3RyOVIhXXOFOeSQvQ0ouW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 69ce27d7-1226-42ac-7850-08d5d7de7fe4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989110)(4534165)(4627221)(201703031133081)(201702281549075)(8990100)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB0869; x-ms-traffictypediagnostic: DM5PR2101MB0869: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0869; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0869; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(39380400002)(199004)(189003)(105586002)(55016002)(4326008)(97736004)(316002)(5070765005)(33656002)(110136005)(8936002)(3480700004)(99286004)(8676002)(106356001)(7736002)(81166006)(81156014)(39060400002)(66066001)(25786009)(229853002)(102836004)(53546011)(6506007)(68736007)(7696005)(733005)(76176011)(186003)(6436002)(26005)(6246003)(446003)(53936002)(2906002)(9686003)(561924002)(11346002)(476003)(3660700001)(486006)(3280700002)(236005)(5660300001)(22452003)(5890100001)(86362001)(8990500004)(86612001)(2900100001)(478600001)(54556002)(74316002)(10290500003)(54896002)(3846002)(14454004)(10090500001)(6116002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0869; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DdmW6d+NctosF+obyN2GunaUQqidyY5dL8BSlfh544TWXzgvtvP0bBq++0sCNcEWO928dMSy7pACQ+vCtGzh++eduv8Nj7ktX8UHljdb38TKVo6xetUKbjVljK+cZppUSG8/7mLrd7L7IwBasBanizOqrND9FwNICRgwMP0v0w4E8ehi19c0FHIqUt8oF32vl2Luo4xwtk2Z+RuG7zYjkUjE+lZfkrThyF300NRMf6WKmdWf9JMjqZL6qq15TcqslWl5IhtinULrYWwmK3rbq8qW23aM0WT6fC2Kas5NmKYjRMqtcApsycFHu0pWLRgH spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901B5F4B01EE7A81CC9E52AB3750DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69ce27d7-1226-42ac-7850-08d5d7de7fe4 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 01:21:36.9783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0869 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 01:21:52 -0000 --_000_DM5PR2101MB0901B5F4B01EE7A81CC9E52AB3750DM5PR2101MB0901_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I used a 4 byte packet number. I computed rate simply by dividing the total= number of bits encrypted (10M * 8 * size) by the total time to encrypt. It= =92s all in the Excel doc. As to why the rate increases with size of the packet, that is because the p= er byte overhead is being reduced both in terms of function call overhead a= nd crypto cpu cycles. Finally, why the PNE cost seems to change, I don=92t = know. Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ________________________________ From: Jana Iyengar Sent: Thursday, June 21, 2018 5:55:44 PM To: Deval, Manasi Cc: Nick Banks; QUIC WG Subject: Re: Packet Number Encryption Performance Thanks for sharing these numbers, Nick! A few questions: 1. It's quite possibly I'm missing something basic, but: Assuming the same = number of packets (10M in your experiments), why do smaller packets result = in lower rates? Shouldn't encrypting the same number of smaller packets res= ult in a higher rate? 2. PNE seems to add about 700-800ms of latency, which understandably decrea= ses as % overhead as the packet size increases. But the difference in rates= seems to increase as the packet size increases, which is exactly counter-i= ntuitive. How do you compute rate? 3. What's the PN size used? On Thu, Jun 21, 2018 at 4:25 PM Deval, Manasi > wrote: The 10% increase on server may be quite significant on a client machine. Th= is may be an issue for mobile devices. Manasi From: QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Nick Banks Sent: Thursday, June 21, 2018 1:48 PM To: quic@ietf.org Subject: Packet Number Encryption Performance Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): [cid:image001.png@01D4097C.184A6370] Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick --_000_DM5PR2101MB0901B5F4B01EE7A81CC9E52AB3750DM5PR2101MB0901_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I used a 4 byte packet number. I computed rate simpl= y by dividing the total number of bits encrypted (10M * 8 * size) by the to= tal time to encrypt. It=92s all in the Excel doc.

 

As to why the rate increases with size of the packet= , that is because the per byte overhead is being reduced both in terms of f= unction call overhead and crypto cpu cycles. Finally, why the PNE cost seem= s to change, I don=92t know.

 

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

 

From: Jana Iyengar <jri.= ietf@gmail.com>
Sent: Thursday, June 21, 2018 5:55:44 PM
To: Deval, Manasi
Cc: Nick Banks; QUIC WG
Subject: Re: Packet Number Encryption Performance
 
Thanks for sharing these numbers, Nick! A few questions:
1. It's quite possibly I'm missing something basic, but: Assuming the = same number of packets (10M in your experiments), why do smaller packe= ts result in lower rates? Shouldn't encrypting the same number of smaller p= ackets result in a higher rate?
2. PNE seems to add about 700-800ms of latency, which understandably d= ecreases as % overhead as the packet size increases. But the difference in = rates seems to increase as the packet size increases, which is exactly coun= ter-intuitive. How do you compute rate?
3. What's the = PN size used?


On Thu, Jun 21, 2018 at 4:25 PM Deval, Manasi <manasi.deval@intel.com> wrote:

The 10% increase on se= rver may be quite significant on a client machine. This may be an issue for= mobile devices.

 

Manasi

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Nick Banks
Sent: Thursday, June 21, 2018 1:48 PM
To: quic@ietf.org=
Subject: Packet Number Encryption Performance

 

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

 

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

 

<= u>

 

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 

--_000_DM5PR2101MB0901B5F4B01EE7A81CC9E52AB3750DM5PR2101MB0901_-- From nobody Thu Jun 21 18:47:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29D5130DC8 for ; Thu, 21 Jun 2018 18:47:02 -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_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MPHpJI6NJjU9 for ; Thu, 21 Jun 2018 18:46:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 EBBB0130DC6 for ; Thu, 21 Jun 2018 18:46:58 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id k16-v6so2000574ioa.8 for ; Thu, 21 Jun 2018 18:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eZdZ8XzAQmIZc7y9FZZhQl5rGftvaEwD8SKALNQnM9k=; b=epi/CW8RFPEjE/Z10qWbmpL8nqIoY8DcKcGjyP40zJTTHRowBVapHHfOfHoJIQs0Ss huMjoDLdr7Mm882Yuw14+k/KBXTnnbjqJeGKTEpsy4CuCYL/bx2+OKPkPRaf4JyNaFOG S794gdOIkSoW+xUo2QzSWXmYWiNT4uSeKRRQ2tJ92s2ASt9upB/MTlUmQyEWq3kUs5s4 9U8PDw711cbaq3BdD+56HmFImRUzu3VYIroFxyYQzWYGRAgTSSazK3dhB4o7lN/fip9i DS7NSiNjI0YS+24BphajqurGTGVFljzqMRFQJvFavEExhel+eLY1VmTmG7afdxn4Kgjy uPkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eZdZ8XzAQmIZc7y9FZZhQl5rGftvaEwD8SKALNQnM9k=; b=G470E/Iymh63ZxhwfKazdZ/bj6r0MK5ggV6LoY9VWYQBnAAmOFNwIO6+nJyWTUj5St LbdkCVrJJBBj0rUzY2I9mqLzBL/UGO9JAdQwl/o3bjQ8nqjKO/kVOHIxtf+LtVatjRf7 JRssR680ubnCIximNGpdZHavYFeef0OgbFsD4Upi5J/U91PZxozEPtBPrjogPNT/vTsq A2Unxd2r0xT8NFkS+Y+7mbNMPcUL8N84p+g6bY4tVESXa+PHDTb9aegYHMu9OKelMrst +MgvXp89ucsXVrYvKHP31UWT8Mxy9Z9XWqSI6MAX6koZ7h3OW4GEvxiuqb+IzkYA3iBD yNIQ== X-Gm-Message-State: APt69E0WkECJ4+U/4Skc7CQ1AK1c3Da6tktFr4Z0OfDfHZxYILlMFM7O Dq0IcUuSIzAbEy9HgvPeCU2cNn/+r/dTyAyisS0= X-Google-Smtp-Source: ADUXVKLfZYrpkb5WdEP2GsSzLzHrQ3VHVYKT8IKCrNm2d4tiiZ5NxVRjb3FJMver7qhEm+/An6Bx6QfkAcy+7BKsS34= X-Received: by 2002:a6b:d106:: with SMTP id l6-v6mr13066155iob.8.1529632018183; Thu, 21 Jun 2018 18:46:58 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B843999@ORSMSX111.amr.corp.intel.com> In-Reply-To: From: Jana Iyengar Date: Thu, 21 Jun 2018 18:46:46 -0700 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: "Deval, Manasi" , QUIC WG Content-Type: multipart/alternative; boundary="00000000000014be71056f313578" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 01:47:03 -0000 --00000000000014be71056f313578 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 21, 2018 at 6:21 PM Nick Banks wrote: > I used a 4 byte packet number. I computed rate simply by dividing the > total number of bits encrypted (10M * 8 * size) by the total time to > encrypt. It=E2=80=99s all in the Excel doc. > That can't be right -- how do you get a 4-byte packet size then? The rate computation helps. Thank you. Basically the % overhead is correct; the graph looks like the difference increases because the range of the Y is quite large (2 orders of magnitude). A log scale is slightly better. But plotting the PNE overhead normalizes the range, and is probably visually clearer. As to why the rate increases with size of the packet, that is because the > per byte overhead is being reduced both in terms of function call overhea= d > and crypto cpu cycles. Finally, why the PNE cost seems to change, I don= =E2=80=99t > know. > The PNE cost doesn't seem to change much, the relative cost does as your % overhead numbers show. A thought: if you're encrypting the same buffer 10M times, are you basically escaping read/write costs, since I presume both buffers are always is in the cache. This might give us a skewed picture... if it's not too much work, can you change a byte in the data and increment/decrement the PN between runs, so that the encryption itself happens on new data on each run? The cost does seem high, but this is relative to the cost of crypto itself as part of total transmission cost. I expect PNE to be visible even when looking at total transmission cost, but I expect it to be much lower than the 10% that shows up in your microbenchmark. Thanks again for sharing these results! > > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > *From:* Jana Iyengar > *Sent:* Thursday, June 21, 2018 5:55:44 PM > *To:* Deval, Manasi > *Cc:* Nick Banks; QUIC WG > *Subject:* Re: Packet Number Encryption Performance > > Thanks for sharing these numbers, Nick! A few questions: > 1. It's quite possibly I'm missing something basic, but: Assuming the sam= e > number of packets (10M in your experiments), why do smaller packets resul= t > in lower rates? Shouldn't encrypting the same number of smaller packets > result in a higher rate? > 2. PNE seems to add about 700-800ms of latency, which understandably > decreases as % overhead as the packet size increases. But the difference = in > rates seems to increase as the packet size increases, which is exactly > counter-intuitive. How do you compute rate? > 3. What's the PN size used? > > > On Thu, Jun 21, 2018 at 4:25 PM Deval, Manasi > wrote: > >> The 10% increase on server may be quite significant on a client machine. >> This may be an issue for mobile devices. >> >> >> >> Manasi >> >> >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Nick Banks >> *Sent:* Thursday, June 21, 2018 1:48 PM >> *To:* quic@ietf.org >> *Subject:* Packet Number Encryption Performance >> >> >> >> Hello QUIC WG, >> >> >> >> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided >> to get some performance numbers to see what the overhead of PNE was. I >> figured the rest of the WG might be interested. >> >> >> >> My test just encrypts the same buffer (size dependent on the test case) >> 10,000,000 times and measured the time it took. The test then did the sa= me >> thing, but also encrypted the packet number as well. I ran all that 10 >> times in total. I then collected the best times for each category to >> produce the following graphs and tables (full excel doc attached): >> >> >> >> >> >> *Time (ms)* >> >> *Rate (Mbps)* >> >> *Bytes* >> >> *NO PNE* >> >> *PNE* >> >> *PNE Overhead* >> >> *No PNE* >> >> *PNE* >> >> *4* >> >> 2284.671 >> >> 3027.657 >> >> 33% >> >> 140.064 >> >> 105.692 >> >> *16* >> >> 2102.402 >> >> 2828.204 >> >> 35% >> >> 608.827 >> >> 452.584 >> >> *64* >> >> 2198.883 >> >> 2907.577 >> >> 32% >> >> 2328.45 >> >> 1760.92 >> >> *256* >> >> 2758.3 >> >> 3490.28 >> >> 27% >> >> 7424.86 >> >> 5867.72 >> >> *600* >> >> 4669.283 >> >> 5424.539 >> >> 16% >> >> 10280 >> >> 8848.68 >> >> *1000* >> >> 6130.139 >> >> 6907.805 >> >> 13% >> >> 13050.3 >> >> 11581.1 >> >> *1200* >> >> 6458.679 >> >> 7229.672 >> >> 12% >> >> 14863.7 >> >> 13278.6 >> >> *1450* >> >> 7876.312 >> >> 8670.16 >> >> 10% >> >> 14727.7 >> >> 13379.2 >> >> >> >> I used a server grade lab machine I had at my disposal, running the >> latest Windows 10 Server DataCenter build. Again, these numbers are for >> crypto only. No QUIC or UDP is included. >> >> >> >> Thanks, >> >> - Nick >> >> >> > --00000000000014be71056f313578 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 21= , 2018 at 6:21 PM Nick Banks <n= ibanks@microsoft.com> wrote:

I used a 4 byte packet number. I computed rate simpl= y by dividing the total number of bits encrypted (10M * 8 * size) by the to= tal time to encrypt. It=E2=80=99s all in the Excel doc.


That can't be right -- how do you get a 4-= byte packet size then?
The rate computation helps. Thank you.

Bas= ically the % overhead is correct; the graph looks like the difference incre= ases because the range of the Y is quite large (2 orders of magnitude). A l= og scale is slightly better. But plotting the PNE overhead normalizes the r= ange, and is probably visually clearer.

As to why the rate increases with size of the packet= , that is because the per byte overhead is being reduced both in terms of f= unction call overhead and crypto cpu cycles. Finally, why the PNE cost seem= s to change, I don=E2=80=99t know.


The PNE cost doesn't seem to change much, the relative cost doe= s as your % overhead numbers show.

A thought: if y= ou're encrypting the same buffer 10M times, are you basically escaping = read/write costs, since I presume both buffers are always is in the cache. = This might give us a skewed picture... if it's not too much work, can y= ou change a byte in the data and increment/decrement the PN between runs, s= o that the encryption itself happens on new data on each run?

=
The cost does seem high, but this is relative to the cost of crypto it= self as part of total transmission cost. I expect PNE to be visible even wh= en looking at total transmission cost, but I expect it to be much lower tha= n the 10% that shows up in your microbenchmark.

Thanks again for sha= ring these results!
=C2=A0

=C2=A0=

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: = Jana Iyengar <jr= i.ietf@gmail.com>
Sent: Thursday, June 21, 2018 5:55:44 PM
To: Deval, Manasi
Cc: Nick Banks; QUIC WG
Subject: Re: Packet Number Encryption Performance
=C2=A0
Thanks for sharing these numbers, Nick! A few questions:
1. It's quite possibly I'm missing something basic, but: Assum= ing the same number of packets (10M in your experiments), why do=C2=A0small= er packets result in lower rates? Shouldn't encrypting the same number = of smaller packets result in a higher rate?
2. PNE seems to add about 700-800ms of latency, which understandably d= ecreases as % overhead as the packet size increases. But the difference in = rates seems to increase as the packet size increases, which is exactly coun= ter-intuitive. How do you compute rate?
3. What's = the PN size used?


On Thu, Jun 21, 2018 at 4:25 PM Deval, Manasi <manasi.deval@intel.com= > wrote:

The 10% increase on se= rver may be quite significant on a client machine. This may be an issue for= mobile devices.

=C2=A0

Manasi

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Nick Banks
Sent: Thursday, June 21, 2018 1:48 PM
To: quic@ietf.org=
Subject: Packet Number Encryption Performance

=C2=A0

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0

--00000000000014be71056f313578-- From nobody Thu Jun 21 18:48:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54AB130DC9 for ; Thu, 21 Jun 2018 18:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 gVayfog8BCN7 for ; Thu, 21 Jun 2018 18:48:18 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 EF001130DC6 for ; Thu, 21 Jun 2018 18:48:17 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r19-v6so1859849ywc.10 for ; Thu, 21 Jun 2018 18:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=at2TzkJCIXPRpBPSvRcmRija1LtyRc0+K5PoKDCS3iY=; b=XjwmGzb+WKfGXCFxgcQ6PwKfOU2mqjAA34nE+QFgA8y/ZgrasjKCmmH4KUrHqPDXRX yooqHvCoyBhYQ6fXIjuOyzl/rdw1P6GklXC9IXUo1UpWRB+TzltQE2uQhxL87cMsUKmm mH6fBe1rM3EDlBvFc1bPuIK2YhJmIpIIa6wnjZlLFkpohLSH3kVWMN+5NOCjfefN4kny SzI+LwZ6d7EMKKXxp26YqfCrKsvsW+WZbcdzUT9OW39uEbkktwaF3jCa2jXz9K6NudhE UXHLcQApN3SgDJwtofxv83nJ6F6985Q4Xdmwjn58mqqojhgMN3diVkimLNFN9XNRyhS9 1GxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=at2TzkJCIXPRpBPSvRcmRija1LtyRc0+K5PoKDCS3iY=; b=U96rjAlGSjkmj85rv6xKOUnWXUZckkidGRX8auZ2HtIeTLRZQNFPOXTvuWNaPBB2aL XLFGe0vbpynGq2k4YEuTVpIEIbI7n1BgnTFTKap/CvzpEk3ak7z4qNh5jRs6JMM7kxQN 66myFC+FhYtTLCFdbPpwdyRCX7Xi2Lv9fL4hdboaaRNMNyl2u8n0SqMLO8uH8Iwr/SkP YGcKKg/UyKc0V6Ehr1onG2gtfQgeGFw+FCTdYGKJhCiCpVKdYI42bRQ1gQKE5QlDp0Hk DYvNX95a1lGWTY4Wz/Z8WaJG686GhVTwh+T3k/6feuQEQK2vPz+/rjMxtBfDuHUKASIJ n2Xw== X-Gm-Message-State: APt69E21ZwHEG9hl6B4dU831uCdq8uQZ+fCTXxXAejZb3WKUD/onmPKW 5FgKyHpQBuCnAFL3PmRizNtwBX98I14db6RV+nseog== X-Google-Smtp-Source: ADUXVKIBRbJy8BDsZCBMLsJlN5A5Bd962MC2LQUzANbrj0nge9cfHcvVDjVTDEYjowXe0LQbuvvpK7X67c+NE9gQhpM= X-Received: by 2002:a81:b3c2:: with SMTP id r185-v6mr12969195ywh.283.1529632096555; Thu, 21 Jun 2018 18:48:16 -0700 (PDT) MIME-Version: 1.0 References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> From: Ian Swett Date: Thu, 21 Jun 2018 21:48:04 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" Cc: Marten Seemann , Kazuho Oku , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000c17d94056f3139c3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 01:48:25 -0000 --000000000000c17d94056f3139c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 21, 2018 at 7:08 PM Deval, Manasi wrote: > I feel that the requirement to have every value valid is somewhat > academic. The length value provides much more value than the block count > This is a key point we disagree on. I see no value in a length field. I believe it having value is predicated on the idea that multi-core QUIC packet processing is a good idea? I fear efforts to multithread processing of a single QUIC packet are not only a waste of time, but also a potential source of correctness issues. In my experience, the CPU cost of sending is much higher than receiving, so I have a really difficult time imagining multi-core receive being worthwhile. and the fact that certain values can never be achieved is an inherent > property of the length. > > > > One interesting observation is that this property is not limited to > length. One can even make a similar argument about ACK block count. The > maximum number of ACK blocks that can be defined will not always have a > meaningful value. In out examples, 0,1,2,3 are all valid. If I set the > value of ACK block count to have lower two bits to be 11, the maximum val= ue > is of ACK blocks is =E2=80=93 4611686018427387903. This is the same value= of > largest acknowledged so if the ACK block count was set to this value, it > would still be meaningless. > > > > Thanks, > > Manasi > > > > > > > > *From:* Marten Seemann [mailto:martenseemann@gmail.com] > *Sent:* Tuesday, June 19, 2018 6:44 PM > *To:* Deval, Manasi > *Cc:* Ian Swett ; Kazuho Oku ; > Eric Rescorla ; Jana Iyengar ; Praveen > Balasubramanian ; IETF QUIC WG ; > Martin Thomson > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > Hi Manasi, > > > > > The risk of disagreement between ack blocks and ack block count is same > as the risk of disagreement between ack blocks and ack length. Either way > this needs to be counted up while creating the ACK and counted down while > parsing it. The possibility of error is the same. Getting the ack block > count wrong is as problematic as getting the ack length wrong. Do you agr= ee? > > > > I disagree. Let's take an example of an ACK frame with one ACK range, tha= t > needs a 2 byte varint to represent the First ACK Block and another 2 byte > varint to represent the Gap. > > With your proposal: > > 1. The values 0 and 1 are invalid, since the length fields itself is > included in the length. > 2. The values 2, 3, ..., (2 + len(LargestAcknowledged) > + len(AckDelay)) - 1 are invalid, since the length needs to include th= e > Largest Acknowledged and the Ack Delay. > 3. The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the > first valid value, and correspond to an ACK frame with no blocks. > 4. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is > invalid, since it would cut the varint for the First ACK Block > 5. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is > invalid, since it would cut the frame after the First ACK Block (but e= very > block must be followed by a gap length) > 6. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is > invalid, since it would cut the varint for the Gap > 7. Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + > 4 is valid > > There are *a lot* of invalid values that you can encode into the ACK > length field. More importantly, *none* of these error cases exists with t= he > current frame format. > > The *only* error case that can occur with our current format is that the > packet is too short for the number of ACK blocks that are supposed to > contained in the frame. This can occur with your proposal as well (in > addition to the error cases listed above). > > > > My concern is not that it's impossible or even particularly hard to catch > these errors, but I dislike the property that some (in fact, most) > encodable values are invalid. > > > > Best, > > Marten > > > > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > wrote: > > Hi Ian, > > > > Here is another attempt to solve the objections you raised: > > > > >I'm not a fan of this proposal, because I think it is impractical to dro= p > the number of ack blocks, because with the ECN proposal it becomes > impractically complex to parse. > > Is there a reason the proposal from Christian does not solve this problem= ? > > > > >If we don't remove the number of ack blocks, then the ack frame is > larger, but I don't think the extra size field is useful for most > implementations. Also, it means the length can disagree with the actual > length, which add complexity and the possibility of writing error-prone > code. The idea of someone offloading ack processing and then proceeding = to > trust the length seems like someone could get wrong and cause some > concerning issues. > > The risk of disagreement between ack blocks and ack block count is same a= s > the risk of disagreement between ack blocks and ack length. Either way th= is > needs to be counted up while creating the ACK and counted down while > parsing it. The possibility of error is the same. Getting the ack block > count wrong is as problematic as getting the ack length wrong. Do you agr= ee? > > > > >My experience is multithreaded packet processing is more cost and work > than it's worth. Sure you can't fill a 100G NIC with one connection, but > that seems like an academic problem, not one for workloads I've seen. > Typically the extra cost of multithreading outweighs its value. > > The value is two fold =E2=80=93 pre-processing and multi-threading. If we > pre-process the received packets such that ACKs and streams can be > coalesced, the receive side can indicate a large chunk of information > though the kernel, reducing the cost of system call and protocol > overhead. This is the same concept as UDP segmentation taken a step furth= er > on receive side. After this chunk is indicated into the QUIC protocol, th= e > protocol may process stream and ACK in parallel. While folks may or may n= ot > utilize this, there is an advantage here. > > > > Thanks, > > Manasi > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, June 19, 2018 11:26 AM > *To:* Deval, Manasi > *Cc:* Marten Seemann ; Kazuho Oku < > kazuhooku@gmail.com>; Eric Rescorla ; Jana Iyengar < > jri.ietf@gmail.com>; Praveen Balasubramanian ; IETF > QUIC WG ; Martin Thomson > > > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > I'm still not interested in this change, for the reasons I stated above. > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > wrote: > > Hi All, > > > > Do we have agreement here to create a new PR? > > > > Thanks, > > Manasi > > > > *From:* Deval, Manasi > *Sent:* Sunday, June 17, 2018 2:25 PM > *To:* Marten Seemann ; Kazuho Oku < > kazuhooku@gmail.com> > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* RE: Proposal to replace ACK block count with ACK length > > > > Hi All, > > > > I have made a list of objections to the proposal and the solutions to > those objections discussed on this thread. > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > Christian suggested to move the ECN fields to precede the ACK blocks. Thi= s > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits would have been annoying, even though it can work. > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse A= CK to > identify length. There are some reservations when ACK parsing gets harder > for the case where the entire header needs to be parsed. > > > > Agreement from several folks here. In the original ACK defined in draft 1= 2 > of the slide, one would count down number of ACK blocks to get to the end > of the packet. In the proposal I made, one would count down the length to > identify the end of the packet. The logic is very similar in cycle count > and complexity. Several folks also commented to this effect. > > > > c. Multi-threaded packet processing > > > > I would expect that there are 10s of 1000s of connections in use at any > time for a server with a high speed link. Multi-threading to handle each = of > these flows / connections in parallel is necessity to be able to support > large number of connections on a high speed link. Tx segmentation, Rx > coalescing are well known strategies to reduce the processing cost. In > initial stages, code is often written as a single-threaded and then > re-factored to parallelize cycle intensive operations. In order to allow > this protocol to scale in future, I would suggest we do not preclude this > case. > > > > d. Increase in ACK size by 1 byte. > > > > I do not see this as a serious issue but if folks but we can consider > making this a varint, if others have strong feelings about it. It=E2=80= =99s a > trade-off : 2 reads to save 1 byte. > > > > e. Every encodable value should be valid > > Not every length will be valid. This is inherent to lengths. This same > issue ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue > exist for small values, it also applies to large values since data stream > will be sent after crypto negotiation. E.g. - how does one craft a > payload with 62 bit payload length in a large header? > > > > > > Thanks, > > Manasi > > > > > > *From:* Marten Seemann [mailto:martenseemann@gmail.com > ] > *Sent:* Sunday, June 17, 2018 6:59 AM > *To:* Kazuho Oku > *Cc:* Ian Swett ; Eric Rescorla < > ekr@rtfm.com>; Jana Iyengar ; Praveen Balasubramanian > ; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com>; Deval, Manasi > *Subject:* Re: Proposal to replace ACK block count with ACK length > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the whole > packet, so as long as the packet payload is long enough, the varint parsi= ng > will not fail. > > I don't think that specifics of programming languages matter here though, > and I'm sure both frame formats can be reasonably implemented in C as wel= l > as in Go. The reasons I'm opposed to Manasi's proposal are that it moves = us > away from the principle that only reasonable values should be encodable, > and that it increases the size of the ACK frame, for the questionable > benefit of being able to parallelise the frame parser. > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > > At least for my implementation, parsing doesn't become easier, it becom= es > > more complex with this proposal. My varint-parser always consumes as ma= ny > > bytes as the varint requires, so after parsing a varint, I'd have to > > introduce an additional check that this didn't overflow the ACK length > (e.g. > > consider that I parsed the ACK frame so far that only 2 bytes are > remaining > > according to ACK length field, but the next varint is 4 bytes long). > > Isn't your varint parser checking that it has not (or will not) run > across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun. > > What I am saying that that check could be converted to a overrun check > against the end of the "frame payload", and that checking the > remaining block count becomes unnecessary, in case we replace ACK > Block Count with ACK Frame Length. > > > > > In general, we've been moving the wire image towards making every > encodable > > value valid. This proposal moves us away from that principle: > > * some small values are always invalid (the length can never be between= 0 > > and 3) > > * a lot of intermediate values are invalid (if the boundary falls insid= e > a > > varint, as described above) > > Both these cases can't occur with the current ACK frame format. > > > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: > >> > >> 2018-06-17 8:34 GMT+09:00 Ian Swett > >> : > >> > I'm not a fan of this proposal, because I think it is impractical to > >> > drop > >> > the number of ack blocks, because with the ECN proposal it becomes > >> > impractically complex to parse. > >> > >> For the ECN proposal, as Christian has suggested, we can move the ECN > >> counters before the ACK blocks. Then, it would not be complex to > >> parse. > >> > >> And my view is that parsing becomes easier if we replace ACK Block > >> Count with ACK Frame Length. > >> > >> Now, with ACK Block Count, we need to check the remaining number of > >> blocks and the remaining space in the packet payload for every block > >> that we parse. Failing to check either leads to a bug or a security > >> issue. > >> > >> If we switch to ACK Frame Length, we need to only check the remaining > >> space in the frame. > >> > >> I think that this is the biggest benefit of replacing ACK Block Count > >> with ACK Frame Length. OTOH the downside is that you need extra one to > >> two bits (one if the size of block / gap is expected to be below 65, > >> two if they are expected to be above that) for encoding ACK Frame > >> Length compared to ACK Block Count. > >> > >> > >> > >> Having said that, I honestly wonder if all the frames could have it's > >> length being encoded (either explicitly or either as a signal that > >> says "to the end of the packet"). Consider something like below: > >> > >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >> or > >> |1| frame-type (7) | frame-payload (*) | > >> > >> When MSB of the first octet set to zero, the length of the frame > >> payload is designated by the varint that immediately follows the frame > >> type. > >> When MSB of the first octet set to one, the length of the frame > >> payload spans to the end of the packet. > >> > >> In this encoding, we can always omit the Length field of a STREAM > >> frame. So the overhead for carrying stream data will be indifferent in > >> practice. > >> > >> For the ACK frame, we can omit the ACK Block Count field. And the > >> overhead will be one to two bits if the ACK frame is sent in the > >> middle of the packet (thereby using the encoding with explicit frame > >> payload length), or one octet or more shorter if ACK is the last frame > >> of the packet. > >> > >> We are likely to see increase of overhead for most of the other types > >> of frames, but I do not think that would be an issue considering that > >> they will be far seldom seen compared to STREAMs and ACKs. > >> > >> To summarize, my anticipation is that we can make all the frames > >> self-contained (i.e. the length can be determined without the > >> knowledge of how each frame is encoded) without any overhead, if we > >> agree on making the frame type space 1 bit smaller. > >> > >> Finally, the biggest benefit of using a self-contained encoding of > >> frames is that we would have the ability to introduce new optional > >> frames without negotiation. By making the frames self-contained, QUIC > >> endpoints will have the freedom of ignoring the frames that they do > >> not understand. > >> > >> Being able to send QUIC frames defined in extensions without > >> negotiating using Transport Parameters will be a win in both terms of > >> security (because clients' TP is sent in clear) and flexibility > >> (because we will be possible to send the extensions before we figure > >> out whether the peer supports that extension). > >> > >> > If we don't remove the number of ack blocks, then the ack frame is > >> > larger, > >> > but I don't think the extra size field is useful for most > >> > implementations. > >> > Also, it means the length can disagree with the actual length, which > add > >> > complexity and the possibility of writing error-prone code. The ide= a > of > >> > someone offloading ack processing and then proceeding to trust the > >> > length > >> > seems like someone could get wrong and cause some concerning issues. > >> > > >> > My experience is multithreaded packet processing is more cost and wo= rk > >> > than > >> > it's worth. Sure you can't fill a 100G NIC with one connection, but > >> > that > >> > seems like an academic problem, not one for workloads I've seen. > >> > Typically > >> > the extra cost of multithreading outweighs its value. > >> > > >> > To be clear, I don't think this is an awful idea, but I also don't s= ee > >> > the > >> > value and it adds complexity. I read Manasi's email, but I don't > think > >> > I > >> > understand why any of those matter in practice. > >> > > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >> >> > >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >> >> > >> >> wrote: > >> >>> > >> >>> This proposal increases the size of the ACK frame by 1 byte in the > >> >>> common > >> >>> case (less than 63 ACK ranges), since the ACK length field here > always > >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length > >> >>> integer. > >> >>> Considering how much work we put into minimising the size of the > >> >>> frames, > >> >>> this feels like a step in the wrong direction.. > >> >>> > >> >>> Regarding the processing cost, I agree with Dmitri. Handling an AC= K > >> >>> frame > >> >>> requires looping over and making changes to a data structure that > >> >>> keeps > >> >>> track of sent packets. This is much more expensive than simply > parsing > >> >>> a > >> >>> bunch of varints in the ACK frame. It seems unlikely that a > >> >>> multi-threaded > >> >>> packet parser would offer any real-world performance benefits. > >> >> > >> >> > >> >> I don't want to overstate the benefit here, but my point isn't that > >> >> parsing is expensive but that if you want to have a multithreaded > >> >> packet > >> >> processing system, then it's nice to have a simpler data structure > (the > >> >> unparsed ACK block) to hand to the ACK processing thread. > >> >> > >> >> -Ekr > >> >> > >> >> > >> >>> > >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> When we discussed this before, some people observed that this > creates > >> >>>> a need to encode in two passes. That's the trade-off here. (Not > >> >>>> expressing an opinion.) > >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >> >>>> wrote: > >> >>>> > > >> >>>> > I don't have a strong opinion on this. I'm certainly not oppose= d > to > >> >>>> > it. > >> >>>> > Does anyone have a strong opposition? > >> >>>> > > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> I agree as well since this can help reduce per packet processi= ng > >> >>>> >> overhead. ACKs are going to be the second most common frame ty= pe > >> >>>> >> so no > >> >>>> >> objections to special casing. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >> >>>> >> Rescorla > >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >> >>>> >> To: Deval, Manasi > >> >>>> >> Cc: Jana Iyengar ; QUIC WG > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> I agree with Manasi here. This change would allow ack frame > >> >>>> >> parsing > >> >>>> >> to be more self-contained, which is an advantage for the parse= r > >> >>>> >> and also > >> >>>> >> potentially for parallelism (because you can quickly find the > >> >>>> >> frame and then > >> >>>> >> process it in parallel). > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> -Ekr > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> In general, varints require some specific logic for parsing. T= o > >> >>>> >> skip > >> >>>> >> over any header, I have to read every single varint. As the co= de > >> >>>> >> sees Stream > >> >>>> >> and ACK headers most frequently, that is my focus. The Stream > >> >>>> >> frame has a > >> >>>> >> length in its third field. > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify > >> >>>> >> length. There are two reads each for =E2=80=98largest acknowle= dged=E2=80=99, > =E2=80=98ACK > >> >>>> >> delay=E2=80=99 and > >> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total= number of cycles > >> >>>> >> parse an > >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packet= s > >> >>>> >> have a > >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck= . > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> > >> >>>> >> Manasi > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >> >>>> >> Iyengar > >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >> >>>> >> To: Deval, Manasi ; QUIC WG > >> >>>> >> > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK leng= th > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> You're right that we no longer have the ability to skip an ACK > >> >>>> >> frame, > >> >>>> >> and this crept in when we moved to varints. > >> >>>> >> > >> >>>> >> I believe your problem though is generally true of most frames > not > >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frame= s > >> >>>> >> are now all > >> >>>> >> varints. To skip any frame, you'll need to parse the varint > fields > >> >>>> >> in those > >> >>>> >> frames. If you have logic to process and skip varints, then > >> >>>> >> skipping the ack > >> >>>> >> block section is merely repeating this operation (2*num_block+= 1) > >> >>>> >> times. Do > >> >>>> >> you see specific value in skipping ACK frames over the other > >> >>>> >> control frames? > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >> >>>> >> wrote: > >> >>>> >> > >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > >> >>>> >> > - Moving the ACK length to the front of the ACK allow= s > >> >>>> >> > the > >> >>>> >> > flexibility of either reading the entire ACK or > reading > >> >>>> >> > the > >> >>>> >> > first 16 bits and skipping over the length. This is= a > >> >>>> >> > useful > >> >>>> >> > feature for the case where ACK processing is split > into > >> >>>> >> > multiple layers. Depending on the processor this is > run > >> >>>> >> > on, > >> >>>> >> > there are different advantages - > >> >>>> >> > >> >>>> >> Just a note. In my experience, the cost of parsing an ACK fra= me > >> >>>> >> is > >> >>>> >> negligible compared to the cost of processing an ACK frame: th= at > >> >>>> >> is, > >> >>>> >> poking at various memory locations to discard newly ACKed > packets. > >> >>>> >> > >> >>>> >> - Dmitri. > >> >>>> >> > >> >>>> >> > >> >>>> > >> >> > >> > > >> > >> > >> > >> -- > >> Kazuho Oku > > > > -- > Kazuho Oku > > --000000000000c17d94056f3139c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 21= , 2018 at 7:08 PM Deval, Manasi <manasi.deval@intel.com> wrote:

I feel that the requirement to have e= very value valid is somewhat academic. The length value provides much more = value than the block count


This is a key point we disagree on.=C2=A0 I see no value in a lengt= h field.=C2=A0 I believe it having value is predicated on the idea that mul= ti-core QUIC packet processing is a good idea?=C2=A0 I fear efforts to mult= ithread processing of a single QUIC packet are not only a waste of time, bu= t also a potential source of correctness issues.

I= n my experience, the CPU cost of sending is much higher than receiving, so = I have a really difficult time imagining multi-core receive being worthwhil= e.

and the fact that certain values can never be achieved is an inherent property of the length.

=C2=A0

One interesting observation is that t= his property is not limited to length. One can even make a similar argument= about ACK block count. The maximum number of ACK blocks that can be defined will not always have a meaningful value. In= out examples, 0,1,2,3 are all valid. If I set the value of ACK block count= to have lower two bits to be 11, the maximum value is of ACK blocks is =E2= =80=93 4611686018427387903. This is the same value of largest acknowledged so if the ACK block count was set to th= is value, it would still be meaningless.

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: Marten Seemann [mailto:martenseemann@gmail.com]
Sent: Tuesday, June 19, 2018 6:44 PM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Ian Swett <ianswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>; Eric Rescorla= <ekr@rtfm.com>= ; Jana Iyengar <= jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUI= C WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

=C2=A0

Hi Manasi,

=C2=A0

>=C2=A0The risk of disagreement between ack block= s and ack block count is same as the risk of disagreement between ack block= s and ack length. Either way this needs to be counted up while creating the= ACK and counted down while parsing it. The possibility of error is the same. Getting the ack block count wrong is as = problematic as getting the ack length wrong. Do you agree?

=C2=A0

I disagree. Let's take an example of an ACK fram= e with one ACK range, that needs a 2 byte varint to represent the First ACK= Block and another 2 byte varint to represent the Gap.

With your proposal:

  1. The values 0 and 1 are invalid, since the = length fields itself is included in the length.
    2. The values 2, 3, ..., (2 + len(LargestAckn= owledged) +=C2=A0len(AckDelay)) - 1 are invalid, since the length needs to = include the Largest Acknowledged and the Ack Delay.
  2. The value=C2=A02 + len(LargestAckno= wledged) +=C2=A0len(AckDelay) would be the first valid value, and correspon= d to an ACK frame with no blocks.
  3. The value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 1 is inv= alid, since it would cut the varint for the First ACK Block
  4. The value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 2 is inv= alid, since it would cut the frame after the First ACK Block (but every blo= ck must be followed by a gap length)
  5. The value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+ 3 is inv= alid, since it would cut the varint for the Gap
  6. Finally, the value 2 + len(LargestAcknowledged) +=C2=A0len(AckDelay)=C2=A0+= 4=C2=A0is valid

There are *a lot* o= f invalid values that you can encode into the ACK length field. More import= antly, *none* of these error cases exists with the current frame format.=C2= =A0

The *only* error ca= se that can occur with our current format is that the packet is too short f= or the number of ACK blocks that are supposed to contained in the frame. Th= is can occur with your proposal as well (in addition to the error cases listed above).

=C2=A0

My concern is not t= hat it's impossible or even particularly hard to catch these errors, bu= t I dislike the property that some (in fact, most) encodable values are inv= alid.

=C2=A0

Best,=

Marten

=C2=A0

=C2=A0

On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi Ian,

=C2=A0

Here is another attempt to solve the = objections you raised:

=C2=A0

>I'm not a fan of this proposa= l, because I think it is impractical to drop the number of ack blocks, because with the ECN proposal it becomes impractically complex to parse.

Is there a reason the proposal from C= hristian does not solve this problem?

=C2=A0

>If we don't remove the number= of ack blocks, then the ack frame is larger, but I don't think the ext= ra size field is useful for most implementations.=C2=A0 Also, it means the le= ngth can disagree with the actual length, which add complexity and the poss= ibility of writing error-prone code.=C2=A0 The idea of someone offloading a= ck processing and then proceeding to trust the length seems like someone could get wrong and cause some concerning is= sues.

The risk of disagreement between ack = blocks and ack block count is same as the risk of disagreement between ack blocks and ack length. Either way this needs to be counted up = while creating the ACK and counted down while parsing it. The possibility o= f error is the same. Getting the ack block count wrong is as problematic as= getting the ack length wrong. Do you agree?

=C2=A0

>My experience is multithreaded pa= cket processing is more cost and work than it's worth.=C2=A0 Sure you can't fill a 100G NIC with one connection, but that seems like an acad= emic problem, not one for workloads I've seen.=C2=A0 Typically the extr= a cost of multithreading outweighs its value.

The value is two fold =E2=80=93 pre-p= rocessing and multi-threading. If we pre-process the received packets such that ACKs and streams can be coalesced, the receive side can indicate= a large chunk of information though the kernel, reducing the cost of system call and prot= ocol overhead. This is the same concept as UDP segmentation taken a step fu= rther on receive side. After this chunk is indicated into the QUIC protocol, the protocol may process stream and ACK in paralle= l. While folks may or may not utilize this, there is an advantage here. =C2= =A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, June 19, 2018 11:26 AM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <k= azuhooku@gmail.com>; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb= @microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>


Subject: Re: Proposal to replace ACK block count with ACK length

=C2=A0

I'm still not interested in this change, for the= reasons I stated above.

=C2=A0

On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi All,

=C2=A0

Do we have agreement here to create a= new PR?

=C2=A0

Thanks,

Manasi

=C2=A0

From: Deval, Manasi
Sent: Sunday, June 17, 2018 2:25 PM
To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <k= azuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org&g= t;; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@iet= f.org>; Martin Thomson <martin.thomson@gmail.com&g= t;
Subject: RE: Proposal to replace ACK block count with ACK length

=C2=A0

Hi All,

=C2=A0

I have made a list of objections to t= he proposal and the solutions to those objections discussed on this thread.

=C2=A0

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Co-existence of length field with ECN field and ACK b= locks.

=C2=A0

Christian suggested to move the ECN fields to precede the AC= K blocks. This is an elegant solution. Parsing entire list of ACK blocks to= review ECN bits would have been annoying, even though it can work.

=C2=A0

b.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two cases to be parsed =E2=80=93 entire ACK= and parse ACK to identify length. There are some reservations when ACK par= sing gets harder for the case where the entire header needs to be parsed.

=C2=A0

Agreement from several folks here. In the original ACK defin= ed in draft 12 of the slide, one would count down number of ACK blocks to g= et to the end of the packet. In the proposal I made, one would count down the length to identify the end of the packet.= The logic is very similar in cycle count and complexity. Several folks als= o commented to this effect.

=C2=A0

c.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Multi-threaded packet processing

=C2=A0

I would expect that there are 10s of 1000s of connections in= use at any time for a server with a high speed link. Multi-threading to ha= ndle each of these flows / connections in parallel is necessity to be able to support large number of connections on a high s= peed link. Tx segmentation, Rx coalescing are well known strategies to redu= ce the processing cost. In initial stages, code is often written as a singl= e-threaded and then re-factored to parallelize cycle intensive operations. In order to allow this protocol= to scale in future, I would suggest we do not preclude this case.

=C2=A0

d.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Increase in ACK size by 1 byte.<= /p>

=C2=A0

I do not see this as a serious issue but if folks but we can= consider making this a varint, if others have strong feelings about it. It= =E2=80=99s a trade-off : 2 reads to save 1 byte.

=C2=A0

e.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every encodable value should be valid<= /span>

Not every length will be valid. This is inher= ent to lengths. This same issue ails the =E2=80=98payload length=E2=80=99 i= n QUIC header. Not only does the issue exist for small values, it also appl= ies to large values since data stream will be sent after crypto negotiation.=C2=A0 E.g. =C2=A0- how does one craft a payload = with 62 bit payload length in a large header?

=C2=A0

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: Marten Seemann [mailto:martenseemann= @gmail.com]
Sent: Sunday, June 17, 2018 6:59 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@iet= f.org>; Martin Thomson <martin.thomson@gmail.com&g= t;; Deval, Manasi <manasi.deval@intel.com>
Subject: Re: Proposal to replace ACK block count with ACK length

=C2=A0

Maybe it's specific to Go, but I'm using a s= ingle io.Reader for the whole packet, so as long as the packet payload is l= ong enough, the varint parsing will not fail.

I don't think that specifics of programming lang= uages matter here though, and I'm sure both frame formats can be reason= ably implemented in C as well as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us away from the principle that= only reasonable values should be encodable, and that it increases the size= of the ACK frame, for the questionable benefit of being able to parallelis= e the frame parser.

=C2=A0

On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com= > wrote:

2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.= com>:
> At least for my implementation, parsing doesn't become easier, it = becomes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have = to
> introduce an additional check that this didn't overflow the ACK le= ngth (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every = encodable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format. >
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is imp= ractical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>=C2=A0 or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibilit= y
>> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack= frame is
>> > larger,
>> > but I don't think the extra size field is useful for most=
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.= =C2=A0 The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with= one connection, but
>> > that
>> > seems like an academic problem, not one for workloads I'v= e seen.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I a= lso don't see
>> > the
>> > value and it adds complexity.=C2=A0 I read Manasi's email= , but I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my po= int isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler d= ata structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.=C2=A0 That's = the trade-off here.=C2=A0 (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I= 'm certainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.=C2=A0 The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*num_bl= ocks reads to identify
>> >>>> >> length. There are two reads each for =E2= =80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>> >>>> >> delay=E2=80=99 and
>> >>>> >> =E2=80=98ACK block count=E2=80=99. The p= ain point is the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have = the ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll n= eed to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wrote: >> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000= , Deval, Manasi wrote:
>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f= eature for the case where ACK processing is split into
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.=C2=A0 In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku

--000000000000c17d94056f3139c3-- From nobody Thu Jun 21 19:20:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA005130DD2 for ; Thu, 21 Jun 2018 19:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPt-bKS_24d3 for ; Thu, 21 Jun 2018 19:20:24 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0121.outbound.protection.outlook.com [104.47.33.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F52B130DD5 for ; Thu, 21 Jun 2018 19:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FM83svx0IEn/XGHQ/gxAPuM8Piq6W5ca+vCDV7yPStI=; b=KNUX+wwpe0QD5mGTU5yOWyOf5uEBmWfAdBdaL+W6Ak2IWkCheIRREL1aVTWjw1/He8OHoXLa15E2b6N7AEzOo0+NRSxjNdYQxV7XLGrJ8mc/CwU1VQ+o+8ZGuF+UbJq02l2ue2FklZloBZ7i8sQ/v2RfEY5yCOhypNmMkLReAMc= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0807.namprd21.prod.outlook.com (10.167.110.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.1; Fri, 22 Jun 2018 02:20:19 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Fri, 22 Jun 2018 02:20:19 +0000 From: Nick Banks To: Ian Swett , "Deval, Manasi" CC: Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , Marten Seemann , IETF QUIC WG , Martin Thomson , Kazuho Oku Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFON0uAAA2Oe4AABJAbAAC4BBWAAAAXlWAADdw6gAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAD4/6gABeMHaAAAAl2oAABAimgAALQ2CAAF8rsoAABY+CAAAA8bAu Date: Fri, 22 Jun 2018 02:20:19 +0000 Message-ID: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0807; 7:XRd/XYEPt6LawQ8KsmH3hT4AgbSEnpRM5eVnHktCZfN7abPXge6mpmBTz7fcypu81yqTJW+/3aYrSEBuFEwGv8HJTJrvFFBg/CHATEGWjfBOv1qEPvmvFda/6vOA6/09tTAVPZppc/HtaElA8zLsDWV7pJBgzxCRqvsWdxoPIOpHIZN1YaKQhocOt1fED8CULzFffdebeB28Oux9yv+UDFGBLn9MMkv+Q1iJMKfp08dumvTJsVo4lKi5fhPKMVZP x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ddfef7e0-874d-4739-f30a-08d5d7e6b376 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989111)(4534165)(4627221)(201703031133081)(201702281549075)(8990101)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB0807; x-ms-traffictypediagnostic: DM5PR2101MB0807: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(85827821059158)(788757137089)(211936372134217)(153496737603132)(228905959029699)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0807; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0807; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(366004)(346002)(376002)(199004)(189003)(53754006)(51444003)(78114003)(6246003)(25786009)(11346002)(486006)(8990500004)(561944003)(186003)(2900100001)(33656002)(476003)(446003)(229853002)(26005)(6506007)(102836004)(53546011)(59450400001)(5660300001)(76176011)(7736002)(6436002)(10090500001)(53936002)(7696005)(53946003)(74316002)(81166006)(3846002)(8676002)(8936002)(39060400002)(81156014)(6116002)(4326008)(105586002)(66066001)(68736007)(14454004)(478600001)(97736004)(106356001)(86362001)(86612001)(54896002)(3660700001)(99286004)(2906002)(55016002)(5250100002)(236005)(93886005)(316002)(3280700002)(9686003)(22452003)(54906003)(110136005)(10290500003)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0807; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 65rs4cjr1CLsZxcmOG2b5NDJwzuFHb8i7AJ1eD57bj9i2FyoZh1eOyY6SiYmQymPGIh/qlGsYY6Yyw3eL93GYQBLghsNEW9M1tiAM5DUfNOLLoJV3uFJngzyqU8DdhQbn/nLg1Y8LK6vST5t75BSy53GXiBsYx6TAG1tjWvgmHutS62v8hLUozKYophL8KSWTJ1Et9kbNJltwDxLIOAi2+ziJozUR0bxTQxine4KPNKy1eVyIJOEeuBBsECCYRkJxeGgGzYuQwOYF8TxBNx13NQjRKo2mF8M2H6dI0glsK2esRxB8NpZ9cgA+rBPvYsYzbQF9uJePekVAhKMhUDAXg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB090196A0B48DB53D84B99C5AB3750DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ddfef7e0-874d-4739-f30a-08d5d7e6b376 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 02:20:19.3818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0807 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 02:20:32 -0000 --_000_DM5PR2101MB090196A0B48DB53D84B99C5AB3750DM5PR2101MB0901_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that changing this for the sake of multi-threaded usage isn=92t wor= th it, but I do think the change has merit for the goal of improving the ef= ficiency of parsing through all the frames quickly. The hardware can use th= is to help find the correct frames in packets to coalesce together. The cod= e shouldn=92t have to pay the penalty of walking every ack block if it=92s = not interested in the information there. Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ________________________________ From: QUIC on behalf of Ian Swett Sent: Thursday, June 21, 2018 6:48:04 PM To: Deval, Manasi Cc: Eric Rescorla; Jana Iyengar; Praveen Balasubramanian; Marten Seemann; I= ETF QUIC WG; Martin Thomson; Kazuho Oku Subject: Re: Proposal to replace ACK block count with ACK length On Thu, Jun 21, 2018 at 7:08 PM Deval, Manasi > wrote: I feel that the requirement to have every value valid is somewhat academic.= The length value provides much more value than the block count This is a key point we disagree on. I see no value in a length field. I b= elieve it having value is predicated on the idea that multi-core QUIC packe= t processing is a good idea? I fear efforts to multithread processing of a= single QUIC packet are not only a waste of time, but also a potential sour= ce of correctness issues. In my experience, the CPU cost of sending is much higher than receiving, so= I have a really difficult time imagining multi-core receive being worthwhi= le. and the fact that certain values can never be achieved is an inherent prope= rty of the length. One interesting observation is that this property is not limited to length.= One can even make a similar argument about ACK block count. The maximum nu= mber of ACK blocks that can be defined will not always have a meaningful va= lue. In out examples, 0,1,2,3 are all valid. If I set the value of ACK bloc= k count to have lower two bits to be 11, the maximum value is of ACK blocks= is =96 4611686018427387903. This is the same value of largest acknowledged= so if the ACK block count was set to this value, it would still be meaning= less. Thanks, Manasi From: Marten Seemann [mailto:martenseemann@gmail.com] Sent: Tuesday, June 19, 2018 6:44 PM To: Deval, Manasi > Cc: Ian Swett >; Kazuho Oku= >; Eric Rescorla >; Jana Iyengar >; Praveen Balasubramanian >; IETF QUIC WG >; Martin T= homson > Subject: Re: Proposal to replace ACK block count with ACK length Hi Manasi, > The risk of disagreement between ack blocks and ack block count is same a= s the risk of disagreement between ack blocks and ack length. Either way th= is needs to be counted up while creating the ACK and counted down while par= sing it. The possibility of error is the same. Getting the ack block count = wrong is as problematic as getting the ack length wrong. Do you agree? I disagree. Let's take an example of an ACK frame with one ACK range, that = needs a 2 byte varint to represent the First ACK Block and another 2 byte v= arint to represent the Gap. With your proposal: 1. The values 0 and 1 are invalid, since the length fields itself is inc= luded in the length. 2. The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) = - 1 are invalid, since the length needs to include the Largest Acknowledged= and the Ack Delay. 3. The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the f= irst valid value, and correspond to an ACK frame with no blocks. 4. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid= , since it would cut the varint for the First ACK Block 5. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid= , since it would cut the frame after the First ACK Block (but every block m= ust be followed by a gap length) 6. The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid= , since it would cut the varint for the Gap 7. Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 i= s valid There are *a lot* of invalid values that you can encode into the ACK length= field. More importantly, *none* of these error cases exists with the curre= nt frame format. The *only* error case that can occur with our current format is that the pa= cket is too short for the number of ACK blocks that are supposed to contain= ed in the frame. This can occur with your proposal as well (in addition to = the error cases listed above). My concern is not that it's impossible or even particularly hard to catch t= hese errors, but I dislike the property that some (in fact, most) encodable= values are invalid. Best, Marten On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > wrote: Hi Ian, Here is another attempt to solve the objections you raised: >I'm not a fan of this proposal, because I think it is impractical to drop = the number of ack blocks, because with the ECN proposal it becomes impracti= cally complex to parse. Is there a reason the proposal from Christian does not solve this problem? >If we don't remove the number of ack blocks, then the ack frame is larger,= but I don't think the extra size field is useful for most implementations.= Also, it means the length can disagree with the actual length, which add = complexity and the possibility of writing error-prone code. The idea of so= meone offloading ack processing and then proceeding to trust the length see= ms like someone could get wrong and cause some concerning issues. The risk of disagreement between ack blocks and ack block count is same as = the risk of disagreement between ack blocks and ack length. Either way this= needs to be counted up while creating the ACK and counted down while parsi= ng it. The possibility of error is the same. Getting the ack block count wr= ong is as problematic as getting the ack length wrong. Do you agree? >My experience is multithreaded packet processing is more cost and work tha= n it's worth. Sure you can't fill a 100G NIC with one connection, but that= seems like an academic problem, not one for workloads I've seen. Typicall= y the extra cost of multithreading outweighs its value. The value is two fold =96 pre-processing and multi-threading. If we pre-pro= cess the received packets such that ACKs and streams can be coalesced, the = receive side can indicate a large chunk of information though the kernel, r= educing the cost of system call and protocol overhead. This is the same con= cept as UDP segmentation taken a step further on receive side. After this c= hunk is indicated into the QUIC protocol, the protocol may process stream a= nd ACK in parallel. While folks may or may not utilize this, there is an ad= vantage here. Thanks, Manasi From: Ian Swett [mailto:ianswett@google.com] Sent: Tuesday, June 19, 2018 11:26 AM To: Deval, Manasi > Cc: Marten Seemann = >; Kazuho Oku >; Eric Resco= rla >; Jana Iyengar >; Praveen Balasubramanian >; IETF QUIC WG >; Martin Thomson > Subject: Re: Proposal to replace ACK block count with ACK length I'm still not interested in this change, for the reasons I stated above. On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > wrote: Hi All, Do we have agreement here to create a new PR? Thanks, Manasi From: Deval, Manasi Sent: Sunday, June 17, 2018 2:25 PM To: Marten Seemann = >; Kazuho Oku > Cc: Ian Swett >; Eric Rescorla >; Jana Iy= engar >; Praveen Balasubraman= ian >; IETF QUIC WG >; Martin Thomson > Subject: RE: Proposal to replace ACK block count with ACK length Hi All, I have made a list of objections to the proposal and the solutions to those= objections discussed on this thread. a. Co-existence of length field with ECN field and ACK blocks. Christian suggested to move the ECN fields to precede the ACK blocks. This = is an elegant solution. Parsing entire list of ACK blocks to review ECN bit= s would have been annoying, even though it can work. b. There are two cases to be parsed =96 entire ACK and parse ACK to id= entify length. There are some reservations when ACK parsing gets harder for= the case where the entire header needs to be parsed. Agreement from several folks here. In the original ACK defined in draft 12 = of the slide, one would count down number of ACK blocks to get to the end o= f the packet. In the proposal I made, one would count down the length to id= entify the end of the packet. The logic is very similar in cycle count and = complexity. Several folks also commented to this effect. c. Multi-threaded packet processing I would expect that there are 10s of 1000s of connections in use at any tim= e for a server with a high speed link. Multi-threading to handle each of th= ese flows / connections in parallel is necessity to be able to support larg= e number of connections on a high speed link. Tx segmentation, Rx coalescin= g are well known strategies to reduce the processing cost. In initial stage= s, code is often written as a single-threaded and then re-factored to paral= lelize cycle intensive operations. In order to allow this protocol to scale= in future, I would suggest we do not preclude this case. d. Increase in ACK size by 1 byte. I do not see this as a serious issue but if folks but we can consider makin= g this a varint, if others have strong feelings about it. It=92s a trade-of= f : 2 reads to save 1 byte. e. Every encodable value should be valid Not every length will be valid. This is inherent to lengths. This same issu= e ails the =91payload length=92 in QUIC header. Not only does the issue exi= st for small values, it also applies to large values since data stream will= be sent after crypto negotiation. E.g. - how does one craft a payload wi= th 62 bit payload length in a large header? Thanks, Manasi From: Marten Seemann [mailto:martenseemann@gmail.com] Sent: Sunday, June 17, 2018 6:59 AM To: Kazuho Oku > Cc: Ian Swett >; Eric Rescorla >; Jana Iyengar >; Praveen B= alasubramanian >; IETF QUIC= WG >; Martin Thomson >; Deval, Manasi > Subject: Re: Proposal to replace ACK block count with ACK length Maybe it's specific to Go, but I'm using a single io.Reader for the whole p= acket, so as long as the packet payload is long enough, the varint parsing = will not fail. I don't think that specifics of programming languages matter here though, a= nd I'm sure both frame formats can be reasonably implemented in C as well a= s in Go. The reasons I'm opposed to Manasi's proposal are that it moves us = away from the principle that only reasonable values should be encodable, an= d that it increases the size of the ACK frame, for the questionable benefit= of being able to parallelise the frame parser. On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku > wrote: 2018-06-17 22:36 GMT+09:00 Marten Seemann >: > At least for my implementation, parsing doesn't become easier, it becomes > more complex with this proposal. My varint-parser always consumes as many > bytes as the varint requires, so after parsing a varint, I'd have to > introduce an additional check that this didn't overflow the ACK length (e= .g. > consider that I parsed the ACK frame so far that only 2 bytes are remaini= ng > according to ACK length field, but the next varint is 4 bytes long). Isn't your varint parser checking that it has not (or will not) run across the end of the packet payload for every ACK block it parses? I'd assume that you would be doing that, because I think that is necessary to avoid buffer overrun. What I am saying that that check could be converted to a overrun check against the end of the "frame payload", and that checking the remaining block count becomes unnecessary, in case we replace ACK Block Count with ACK Frame Length. > > In general, we've been moving the wire image towards making every encodab= le > value valid. This proposal moves us away from that principle: > * some small values are always invalid (the length can never be between 0 > and 3) > * a lot of intermediate values are invalid (if the boundary falls inside = a > varint, as described above) > Both these cases can't occur with the current ACK frame format. > > On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku > wrote: >> >> 2018-06-17 8:34 GMT+09:00 Ian Swett >> >: >> > I'm not a fan of this proposal, because I think it is impractical to >> > drop >> > the number of ack blocks, because with the ECN proposal it becomes >> > impractically complex to parse. >> >> For the ECN proposal, as Christian has suggested, we can move the ECN >> counters before the ACK blocks. Then, it would not be complex to >> parse. >> >> And my view is that parsing becomes easier if we replace ACK Block >> Count with ACK Frame Length. >> >> Now, with ACK Block Count, we need to check the remaining number of >> blocks and the remaining space in the packet payload for every block >> that we parse. Failing to check either leads to a bug or a security >> issue. >> >> If we switch to ACK Frame Length, we need to only check the remaining >> space in the frame. >> >> I think that this is the biggest benefit of replacing ACK Block Count >> with ACK Frame Length. OTOH the downside is that you need extra one to >> two bits (one if the size of block / gap is expected to be below 65, >> two if they are expected to be above that) for encoding ACK Frame >> Length compared to ACK Block Count. >> >> >> >> Having said that, I honestly wonder if all the frames could have it's >> length being encoded (either explicitly or either as a signal that >> says "to the end of the packet"). Consider something like below: >> >> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | >> or >> |1| frame-type (7) | frame-payload (*) | >> >> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the frame >> type. >> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet. >> >> In this encoding, we can always omit the Length field of a STREAM >> frame. So the overhead for carrying stream data will be indifferent in >> practice. >> >> For the ACK frame, we can omit the ACK Block Count field. And the >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit frame >> payload length), or one octet or more shorter if ACK is the last frame >> of the packet. >> >> We are likely to see increase of overhead for most of the other types >> of frames, but I do not think that would be an issue considering that >> they will be far seldom seen compared to STREAMs and ACKs. >> >> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the >> knowledge of how each frame is encoded) without any overhead, if we >> agree on making the frame type space 1 bit smaller. >> >> Finally, the biggest benefit of using a self-contained encoding of >> frames is that we would have the ability to introduce new optional >> frames without negotiation. By making the frames self-contained, QUIC >> endpoints will have the freedom of ignoring the frames that they do >> not understand. >> >> Being able to send QUIC frames defined in extensions without >> negotiating using Transport Parameters will be a win in both terms of >> security (because clients' TP is sent in clear) and flexibility >> (because we will be possible to send the extensions before we figure >> out whether the peer supports that extension). >> >> > If we don't remove the number of ack blocks, then the ack frame is >> > larger, >> > but I don't think the extra size field is useful for most >> > implementations. >> > Also, it means the length can disagree with the actual length, which a= dd >> > complexity and the possibility of writing error-prone code. The idea = of >> > someone offloading ack processing and then proceeding to trust the >> > length >> > seems like someone could get wrong and cause some concerning issues. >> > >> > My experience is multithreaded packet processing is more cost and work >> > than >> > it's worth. Sure you can't fill a 100G NIC with one connection, but >> > that >> > seems like an academic problem, not one for workloads I've seen. >> > Typically >> > the extra cost of multithreading outweighs its value. >> > >> > To be clear, I don't think this is an awful idea, but I also don't see >> > the >> > value and it adds complexity. I read Manasi's email, but I don't thin= k >> > I >> > understand why any of those matter in practice. >> > >> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla > wrote: >> >> >> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >> >> > >> >> wrote: >> >>> >> >>> This proposal increases the size of the ACK frame by 1 byte in the >> >>> common >> >>> case (less than 63 ACK ranges), since the ACK length field here alwa= ys >> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length >> >>> integer. >> >>> Considering how much work we put into minimising the size of the >> >>> frames, >> >>> this feels like a step in the wrong direction.. >> >>> >> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK >> >>> frame >> >>> requires looping over and making changes to a data structure that >> >>> keeps >> >>> track of sent packets. This is much more expensive than simply parsi= ng >> >>> a >> >>> bunch of varints in the ACK frame. It seems unlikely that a >> >>> multi-threaded >> >>> packet parser would offer any real-world performance benefits. >> >> >> >> >> >> I don't want to overstate the benefit here, but my point isn't that >> >> parsing is expensive but that if you want to have a multithreaded >> >> packet >> >> processing system, then it's nice to have a simpler data structure (t= he >> >> unparsed ACK block) to hand to the ACK processing thread. >> >> >> >> -Ekr >> >> >> >> >> >>> >> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >> >>> > >> >>> wrote: >> >>>> >> >>>> When we discussed this before, some people observed that this creat= es >> >>>> a need to encode in two passes. That's the trade-off here. (Not >> >>>> expressing an opinion.) >> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >> >>>> wrote: >> >>>> > >> >>>> > I don't have a strong opinion on this. I'm certainly not opposed = to >> >>>> > it. >> >>>> > Does anyone have a strong opposition? >> >>>> > >> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >> >>>> > > wrote: >> >>>> >> >> >>>> >> I agree as well since this can help reduce per packet processing >> >>>> >> overhead. ACKs are going to be the second most common frame type >> >>>> >> so no >> >>>> >> objections to special casing. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric >> >>>> >> Rescorla >> >>>> >> Sent: Friday, June 15, 2018 9:11 AM >> >>>> >> To: Deval, Manasi > >> >>>> >> Cc: Jana Iyengar >= ; QUIC WG > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> I agree with Manasi here. This change would allow ack frame >> >>>> >> parsing >> >>>> >> to be more self-contained, which is an advantage for the parser >> >>>> >> and also >> >>>> >> potentially for parallelism (because you can quickly find the >> >>>> >> frame and then >> >>>> >> process it in parallel). >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> -Ekr >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >> >>>> >> > wrote: >> >>>> >> >> >>>> >> In general, varints require some specific logic for parsing. To >> >>>> >> skip >> >>>> >> over any header, I have to read every single varint. As the code >> >>>> >> sees Stream >> >>>> >> and ACK headers most frequently, that is my focus. The Stream >> >>>> >> frame has a >> >>>> >> length in its third field. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify >> >>>> >> length. There are two reads each for =91largest acknowledged=92,= =91ACK >> >>>> >> delay=92 and >> >>>> >> =91ACK block count=92. The pain point is the total number of cyc= les >> >>>> >> parse an >> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets >> >>>> >> have a >> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> Thanks, >> >>>> >> >> >>>> >> Manasi >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana >> >>>> >> Iyengar >> >>>> >> Sent: Monday, June 11, 2018 3:11 PM >> >>>> >> To: Deval, Manasi >; QUIC WG >> >>>> >> > >> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> You're right that we no longer have the ability to skip an ACK >> >>>> >> frame, >> >>>> >> and this crept in when we moved to varints. >> >>>> >> >> >>>> >> I believe your problem though is generally true of most frames n= ot >> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames >> >>>> >> are now all >> >>>> >> varints. To skip any frame, you'll need to parse the varint fiel= ds >> >>>> >> in those >> >>>> >> frames. If you have logic to process and skip varints, then >> >>>> >> skipping the ack >> >>>> >> block section is merely repeating this operation (2*num_block+1) >> >>>> >> times. Do >> >>>> >> you see specific value in skipping ACK frames over the other >> >>>> >> control frames? >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >> >>>> >> > wrote: >> >>>> >> >> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >> >>>> >> > - Moving the ACK length to the front of the ACK allows >> >>>> >> > the >> >>>> >> > flexibility of either reading the entire ACK or readi= ng >> >>>> >> > the >> >>>> >> > first 16 bits and skipping over the length. This is a >> >>>> >> > useful >> >>>> >> > feature for the case where ACK processing is split in= to >> >>>> >> > multiple layers. Depending on the processor this is r= un >> >>>> >> > on, >> >>>> >> > there are different advantages - >> >>>> >> >> >>>> >> Just a note. In my experience, the cost of parsing an ACK frame >> >>>> >> is >> >>>> >> negligible compared to the cost of processing an ACK frame: that >> >>>> >> is, >> >>>> >> poking at various memory locations to discard newly ACKed packet= s. >> >>>> >> >> >>>> >> - Dmitri. >> >>>> >> >> >>>> >> >> >>>> >> >> >> > >> >> >> >> -- >> Kazuho Oku -- Kazuho Oku --_000_DM5PR2101MB090196A0B48DB53D84B99C5AB3750DM5PR2101MB0901_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I agree that changing this for the sake of multi-thr= eaded usage isn=92t worth it, but I do think the change has merit for the g= oal of improving the efficiency of parsing through all the frames quickly. = The hardware can use this to help find the correct frames in packets to coalesce together. The code shouldn=92t h= ave to pay the penalty of walking every ack block if it=92s not interested = in the information there.

 

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

 

From: QUIC <quic-bounces= @ietf.org> on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf= .org>
Sent: Thursday, June 21, 2018 6:48:04 PM
To: Deval, Manasi
Cc: Eric Rescorla; Jana Iyengar; Praveen Balasubramanian; Marten See= mann; IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: Proposal to replace ACK block count with ACK length
 
On Thu, Jun 21, 2018 at 7:08 PM Deval, Manasi <manasi.deval@intel.com> wrote:

I feel that the requirement to have e= very value valid is somewhat academic. The length value provides much more = value than the block count


This is a key point we disagree on.  I see no value in a length f= ield.  I believe it having value is predicated on the idea that multi-= core QUIC packet processing is a good idea?  I fear efforts to multith= read processing of a single QUIC packet are not only a waste of time, but also a potential source of correctness issues.

In my experience, the CPU cost of sending is much higher than receivin= g, so I have a really difficult time imagining multi-core receive being wor= thwhile.

and the fact that certain values can = never be achieved is an inherent property of the length.

 

One interesting observation is that t= his property is not limited to length. One can even make a similar argument= about ACK block count. The maximum number of ACK blocks that can be defined will not always have a meaningful value. In= out examples, 0,1,2,3 are all valid. If I set the value of ACK block count= to have lower two bits to be 11, the maximum value is of ACK blocks is =96= 4611686018427387903. This is the same value of largest acknowledged so if the ACK block count was set to th= is value, it would still be meaningless.

 

Thanks,

Manasi

 

 

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d"> 

From: Marten Seemann [mailto:martenseemann@gmail.com]
Sent: Tuesday, June 19, 2018 6:44 PM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Ian Swett <ianswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>; Eric Rescorla= <ekr@rtfm.com>= ; Jana Iyengar <j= ri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC= WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Proposal to replace ACK block count with ACK length<= /u>

 

Hi Manasi,

 

> The risk of disagreement between ack block= s and ack block count is same as the risk of disagreement between ack block= s and ack length. Either way this needs to be counted up while creating the= ACK and counted down while parsing it. The possibility of error is the same. Getting the ack block count wrong is as = problematic as getting the ack length wrong. Do you agree?

 

I disagree. Let's take an example of an ACK frame wi= th one ACK range, that needs a 2 byte varint to represent the First ACK Blo= ck and another 2 byte varint to represent the Gap.

With your proposal:

  1. The values 0 and 1= are invalid, since the length fields itself is included in the length.
  2. The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(= AckDelay)) - 1 are invalid, since the length needs to include the Largest A= cknowledged and the Ack Delay.
  3. The value 2 + len(Lar= gestAcknowledged) + len(AckDelay) would be the first valid value, = and correspond to an ACK frame with no blocks.
  4. The value 2 + len(LargestAcknowledged) + len(Ac= kDelay) + 1 is invalid, since it would cut the varint for the Firs= t ACK Block
  5. The value 2 + len= (LargestAcknowledged) + len(AckDelay) + 2 is invalid, sin= ce it would cut the frame after the First ACK Block (but every block must b= e followed by a gap length)
  6. The v= alue 2 + len(LargestAcknowledged) + len(AckDelay) + 3= is invalid, since it would cut the varint for the Gap
    7. Finally, the value 2 + len(LargestAcknowledged) &= #43; len(AckDelay) + 4 is valid

There are *a lot* o= f invalid values that you can encode into the ACK length field. More import= antly, *none* of these error cases exists with the current frame format.&nb= sp;

The *only* error ca= se that can occur with our current format is that the packet is too short f= or the number of ACK blocks that are supposed to contained in the frame. Th= is can occur with your proposal as well (in addition to the error cases listed above).

 

My concern is not t= hat it's impossible or even particularly hard to catch these errors, but I = dislike the property that some (in fact, most) encodable values are invalid= .

 

Best,=

Marten

 

 

On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi Ian,

 

Here is another attempt to solve the = objections you raised:

 

>I'm not a fan of this proposal, b= ecause I think it is impractical to drop the number of ack blocks, because = with the ECN proposal it becomes impractically complex to parse.

Is there a reason the proposal from C= hristian does not solve this problem?

 

>If we don't remove the number of = ack blocks, then the ack frame is larger, but I don't think the extra size = field is useful for most implementations.  Also, it means the length can disagree with the actual length, which add complex= ity and the possibility of writing error-prone code.  The idea of some= one offloading ack processing and then proceeding to trust the length seems= like someone could get wrong and cause some concerning issues.

The risk of disagreement between ack = blocks and ack block count is same as the risk of disagreement between ack = blocks and ack length. Either way this needs to be counted up while creating the ACK and counted down while parsing it. Th= e possibility of error is the same. Getting the ack block count wrong is as= problematic as getting the ack length wrong. Do you agree?

 

>My experience is multithreaded pa= cket processing is more cost and work than it's worth.  Sure you can't= fill a 100G NIC with one connection, but that seems like an academic problem, not one for workloads I've seen.  Typically the = extra cost of multithreading outweighs its value.

The value is two fold =96 pre-process= ing and multi-threading. If we pre-process the received packets such that A= CKs and streams can be coalesced, the receive side can indicate a large chunk of information though the= kernel, reducing the cost of system call and protocol overhead. This is th= e same concept as UDP segmentation taken a step further on receive side. After this chunk is indicated into the QUIC proto= col, the protocol may process stream and ACK in parallel. While folks may o= r may not utilize this, there is an advantage here.  =

 

Thanks,

Manasi

 

 

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, June 19, 2018 11:26 AM
To: Deval, Manasi <manasi.deval@intel.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <k= azuhooku@gmail.com>; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb= @microsoft.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>


Subject: Re: Proposal to replace ACK block count with ACK length

 

I'm still not interested in this change, for the rea= sons I stated above.

 

On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@inte= l.com> wrote:

Hi All,

 

Do we have agreement here to create a= new PR?

 

Thanks,

Manasi

 

From: Deval, Manasi
Sent: Sunday, June 17, 2018 2:25 PM
To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku <k= azuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org&g= t;; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@iet= f.org>; Martin Thomson <martin.thomson@gmail.com&g= t;
Subject: RE: Proposal to replace ACK block count with ACK length

 

Hi All,

 

I have made a list of objections to t= he proposal and the solutions to those objections discussed on this thread.

 

a. = ;     Co-existence of length field with ECN field and ACK b= locks.

 

Christian suggested to move the ECN fields to precede the AC= K blocks. This is an elegant solution. Parsing entire list of ACK blocks to= review ECN bits would have been annoying, even though it can work.

 

b. = ;     There are two cases to be parsed =96 entire ACK and p= arse ACK to identify length. There are some reservations when ACK parsing g= ets harder for the case where the entire header needs to be parsed.

 

Agreement from several folks here. In the original ACK defin= ed in draft 12 of the slide, one would count down number of ACK blocks to g= et to the end of the packet. In the proposal I made, one would count down the length to identify the end of the packet.= The logic is very similar in cycle count and complexity. Several folks als= o commented to this effect.

 

c. = ;     Multi-threaded packet processing

 

I would expect that there are 10s of 1000s of connections in= use at any time for a server with a high speed link. Multi-threading to ha= ndle each of these flows / connections in parallel is necessity to be able to support large number of connections on a high s= peed link. Tx segmentation, Rx coalescing are well known strategies to redu= ce the processing cost. In initial stages, code is often written as a singl= e-threaded and then re-factored to parallelize cycle intensive operations. In order to allow this protocol= to scale in future, I would suggest we do not preclude this case.

 

d. = ;     Increase in ACK size by 1 byte.<= /p>

 

I do not see this as a serious issue but if folks but we can= consider making this a varint, if others have strong feelings about it. It= =92s a trade-off : 2 reads to save 1 byte.

 

e.      Every encodable value should be valid<= /span>

Not every length will be valid. This is inher= ent to lengths. This same issue ails the =91payload length=92 in QUIC heade= r. Not only does the issue exist for small values, it also applies to large= values since data stream will be sent after crypto negotiation.  E.g.  - how does one craft a payload = with 62 bit payload length in a large header?

 

 

Thanks,

Manasi

 

 

From: Marten Seemann [mailto:martenseemann= @gmail.com]
Sent: Sunday, June 17, 2018 6:59 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@iet= f.org>; Martin Thomson <martin.thomson@gmail.com&g= t;; Deval, Manasi <manasi.deval@intel.com>
Subject: Re: Proposal to replace ACK block count with ACK length

 

Maybe it's specific to Go, but I'm using a single io= .Reader for the whole packet, so as long as the packet payload is long enou= gh, the varint parsing will not fail.

I don't think that specifics of programming language= s matter here though, and I'm sure both frame formats can be reasonably imp= lemented in C as well as in Go. The reasons I'm opposed to Manasi's proposa= l are that it moves us away from the principle that only reasonable values should be encodable, and that it inc= reases the size of the ACK frame, for the questionable benefit of being abl= e to parallelise the frame parser.

 

On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com= > wrote:

2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gm= ail.com>:
> At least for my implementation, parsing doesn't become easier, it beco= mes
> more complex with this proposal. My varint-parser always consumes as m= any
> bytes as the varint requires, so after parsing a varint, I'd have to > introduce an additional check that this didn't overflow the ACK length= (e.g.
> consider that I parsed the ACK frame so far that only 2 bytes are rema= ining
> according to ACK length field, but the next varint is 4 bytes long).
Isn't your varint parser checking that it has not (or will not) run
across the end of the packet payload for every ACK block it parses?
I'd assume that you would be doing that, because I think that is
necessary to avoid buffer overrun.

What I am saying that that check could be converted to a overrun check
against the end of the "frame payload", and that checking the
remaining block count becomes unnecessary, in case we replace ACK
Block Count with ACK Frame Length.

>
> In general, we've been moving the wire image towards making every enco= dable
> value valid. This proposal moves us away from that principle:
> * some small values are always invalid (the length can never be betwee= n 0
> and 3)
> * a lot of intermediate values are invalid (if the boundary falls insi= de a
> varint, as described above)
> Both these cases can't occur with the current ACK frame format.
>
> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>> <ianswett=3D40google.com@dmarc.ietf.org>:
>> > I'm not a fan of this proposal, because I think it is impract= ical to
>> > drop
>> > the number of ack blocks, because with the ECN proposal it be= comes
>> > impractically complex to parse.
>>
>> For the ECN proposal, as Christian has suggested, we can move the = ECN
>> counters before the ACK blocks. Then, it would not be complex to >> parse.
>>
>> And my view is that parsing becomes easier if we replace ACK Block=
>> Count with ACK Frame Length.
>>
>> Now, with ACK Block Count, we need to check the remaining number o= f
>> blocks and the remaining space in the packet payload for every blo= ck
>> that we parse. Failing to check either leads to a bug or a securit= y
>> issue.
>>
>> If we switch to ACK Frame Length, we need to only check the remain= ing
>> space in the frame.
>>
>> I think that this is the biggest benefit of replacing ACK Block Co= unt
>> with ACK Frame Length. OTOH the downside is that you need extra on= e to
>> two bits (one if the size of block / gap is expected to be below 6= 5,
>> two if they are expected to be above that) for encoding ACK Frame<= br> >> Length compared to ACK Block Count.
>>
>>
>>
>> Having said that, I honestly wonder if all the frames could have i= t's
>> length being encoded (either explicitly or either as a signal that=
>> says "to the end of the packet"). Consider something lik= e below:
>>
>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = |
>>  or
>> |1| frame-type (7) | frame-payload (*) |
>>
>> When MSB of the first octet set to zero, the length of the frame >> payload is designated by the varint that immediately follows the f= rame
>> type.
>> When MSB of the first octet set to one, the length of the frame >> payload spans to the end of the packet.
>>
>> In this encoding, we can always omit the Length field of a STREAM<= br> >> frame. So the overhead for carrying stream data will be indifferen= t in
>> practice.
>>
>> For the ACK frame, we can omit the ACK Block Count field. And the<= br> >> overhead will be one to two bits if the ACK frame is sent in the >> middle of the packet (thereby using the encoding with explicit fra= me
>> payload length), or one octet or more shorter if ACK is the last f= rame
>> of the packet.
>>
>> We are likely to see increase of overhead for most of the other ty= pes
>> of frames, but I do not think that would be an issue considering t= hat
>> they will be far seldom seen compared to STREAMs and ACKs.
>>
>> To summarize, my anticipation is that we can make all the frames >> self-contained (i.e. the length can be determined without the
>> knowledge of how each frame is encoded) without any overhead, if w= e
>> agree on making the frame type space 1 bit smaller.
>>
>> Finally, the biggest benefit of using a self-contained encoding of=
>> frames is that we would have the ability to introduce new optional=
>> frames without negotiation. By making the frames self-contained, Q= UIC
>> endpoints will have the freedom of ignoring the frames that they d= o
>> not understand.
>>
>> Being able to send QUIC frames defined in extensions without
>> negotiating using Transport Parameters will be a win in both terms= of
>> security (because clients' TP is sent in clear) and flexibility >> (because we will be possible to send the extensions before we figu= re
>> out whether the peer supports that extension).
>>
>> > If we don't remove the number of ack blocks, then the ack fra= me is
>> > larger,
>> > but I don't think the extra size field is useful for most
>> > implementations.
>> > Also, it means the length can disagree with the actual length= , which add
>> > complexity and the possibility of writing error-prone code.&n= bsp; The idea of
>> > someone offloading ack processing and then proceeding to trus= t the
>> > length
>> > seems like someone could get wrong and cause some concerning = issues.
>> >
>> > My experience is multithreaded packet processing is more cost= and work
>> > than
>> > it's worth.  Sure you can't fill a 100G NIC with one con= nection, but
>> > that
>> > seems like an academic problem, not one for workloads I've se= en.
>> > Typically
>> > the extra cost of multithreading outweighs its value.
>> >
>> > To be clear, I don't think this is an awful idea, but I also = don't see
>> > the
>> > value and it adds complexity.  I read Manasi's email, bu= t I don't think
>> > I
>> > understand why any of those matter in practice.
>> >
>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >>
>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>> >> <martenseemann@gmail.com>
>> >> wrote:
>> >>>
>> >>> This proposal increases the size of the ACK frame by = 1 byte in the
>> >>> common
>> >>> case (less than 63 ACK ranges), since the ACK length = field here always
>> >>> consumes 2 bytes, whereas the ACK Block Count is a va= riable-length
>> >>> integer.
>> >>> Considering how much work we put into minimising the = size of the
>> >>> frames,
>> >>> this feels like a step in the wrong direction..
>> >>>
>> >>> Regarding the processing cost, I agree with Dmitri. H= andling an ACK
>> >>> frame
>> >>> requires looping over and making changes to a data st= ructure that
>> >>> keeps
>> >>> track of sent packets. This is much more expensive th= an simply parsing
>> >>> a
>> >>> bunch of varints in the ACK frame. It seems unlikely = that a
>> >>> multi-threaded
>> >>> packet parser would offer any real-world performance = benefits.
>> >>
>> >>
>> >> I don't want to overstate the benefit here, but my point = isn't that
>> >> parsing is expensive but that if you want to have a multi= threaded
>> >> packet
>> >> processing system, then it's nice to have a simpler data = structure (the
>> >> unparsed ACK block) to hand to the ACK processing thread.=
>> >>
>> >> -Ekr
>> >>
>> >>
>> >>>
>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>> >>> <martin.thomson@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> When we discussed this before, some people observ= ed that this creates
>> >>>> a need to encode in two passes.  That's the = trade-off here.  (Not
>> >>>> expressing an opinion.)
>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <= jri.ietf@gmail.com<= /a>>
>> >>>> wrote:
>> >>>> >
>> >>>> > I don't have a strong opinion on this. I'm c= ertainly not opposed to
>> >>>> > it.
>> >>>> > Does anyone have a strong opposition?
>> >>>> >
>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Bala= subramanian
>> >>>> > <pravb@microsoft.com> wrote:
>> >>>> >>
>> >>>> >> I agree as well since this can help redu= ce per packet processing
>> >>>> >> overhead. ACKs are going to be the secon= d most common frame type
>> >>>> >> so no
>> >>>> >> objections to special casing.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Eric
>> >>>> >> Rescorla
>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com> >> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG &l= t;quic@ietf.org><= br> >> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> I agree with Manasi here. This change wo= uld allow ack frame
>> >>>> >> parsing
>> >>>> >> to be more self-contained, which is an a= dvantage for the parser
>> >>>> >> and also
>> >>>> >> potentially for parallelism (because you= can quickly find the
>> >>>> >> frame and then
>> >>>> >> process it in parallel).
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> -Ekr
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, = Manasi
>> >>>> >> <manasi.deval@intel.com> wrote:
>> >>>> >>
>> >>>> >> In general, varints require some specifi= c logic for parsing. To
>> >>>> >> skip
>> >>>> >> over any header, I have to read every si= ngle varint. As the code
>> >>>> >> sees Stream
>> >>>> >> and ACK headers most frequently, that is= my focus.  The Stream
>> >>>> >> frame has a
>> >>>> >> length in its third field.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> ACK parsing, however, needs 6 + 2*nu= m_blocks reads to identify
>> >>>> >> length. There are two reads each for =91= largest acknowledged=92, =91ACK
>> >>>> >> delay=92 and
>> >>>> >> =91ACK block count=92. The pain point is= the total number of cycles
>> >>>> >> parse an
>> >>>> >> ACK. If I am processing 10M pps, where 1= 0% - 30% of the packets
>> >>>> >> have a
>> >>>> >> piggybacked ACK, these cycles becomes a = significant bottleneck.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> Manasi
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Jana
>> >>>> >> Iyengar
>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; Q= UIC WG
>> >>>> >> <quic@ietf.org>
>> >>>> >> Subject: Re: Proposal to replace ACK blo= ck count with ACK length
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> You're right that we no longer have the = ability to skip an ACK
>> >>>> >> frame,
>> >>>> >> and this crept in when we moved to varin= ts.
>> >>>> >>
>> >>>> >> I believe your problem though is general= ly true of most frames not
>> >>>> >> just ACKs, since ids, packet numbers, an= d numbers in all frames
>> >>>> >> are now all
>> >>>> >> varints. To skip any frame, you'll need = to parse the varint fields
>> >>>> >> in those
>> >>>> >> frames. If you have logic to process and= skip varints, then
>> >>>> >> skipping the ack
>> >>>> >> block section is merely repeating this o= peration (2*num_block+1)
>> >>>> >> times. Do
>> >>>> >> you see specific value in skipping ACK f= rames over the other
>> >>>> >> control frames?
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri T= ikhonov
>> >>>> >> <dtikhonov@litespeedtech..com> wrote: >> >>>> >>
>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM += 0000, Deval, Manasi wrote:
>> >>>> >> > -        Moving= the ACK length to the front of the ACK allows
>> >>>> >> > the
>> >>>> >> >          f= lexibility of either reading the entire ACK or reading
>> >>>> >> > the
>> >>>> >> >          f= irst 16 bits and skipping over the length. This is a
>> >>>> >> > useful
>> >>>> >> >          f= eature for the case where ACK processing is split into
>> >>>> >> >          m= ultiple layers. Depending on the processor this is run
>> >>>> >> > on,
>> >>>> >> >          t= here are different advantages -
>> >>>> >>
>> >>>> >> Just a note.  In my experience, the= cost of parsing an ACK frame
>> >>>> >> is
>> >>>> >> negligible compared to the cost of proce= ssing an ACK frame: that
>> >>>> >> is,
>> >>>> >> poking at various memory locations to di= scard newly ACKed packets.
>> >>>> >>
>> >>>> >>   - Dmitri.
>> >>>> >>
>> >>>> >>
>> >>>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku

--_000_DM5PR2101MB090196A0B48DB53D84B99C5AB3750DM5PR2101MB0901_-- From nobody Thu Jun 21 19:21:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2E9130DD6 for ; Thu, 21 Jun 2018 19:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 XsHza3w0II8G for ; Thu, 21 Jun 2018 19:21:19 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 47724130DC6 for ; Thu, 21 Jun 2018 19:21:19 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id 30-v6so2658863pld.13 for ; Thu, 21 Jun 2018 19:21:19 -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=AHyD6dUBLAisaavgqTkvsqUovifKau8kJecm/V1wuRA=; b=h9hjwsQTOHJcIYyStGOHed2h6N/euy/M04hkLDTndzwm02BH3v7hGNtxDGJrj8odFw WoV9cBp/PheYODVPGY/7PFMBgASNnuU2RttzvTbZP/3k7ZCfdTAP+VlxH/l7m05WoLJM gHKVHpQxedJBStp8u5ltDLiZNgQbIZKy5aW9xHntIKcPdjIjmTkZ5BCy3keTUuggtT9j hxka1ejbq0R1LAh7JUJR9t6NByXb8S4hSMjdHuCPvjDsDQnMb4o74Wgzv45M8BNXHfUf nFreoovi/zfJFmgZjLgJ3muH0+wW+gpRdAqccbRqBWLBL+LBJbvlwjDSA4WcH5sak9RT i7jA== 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=AHyD6dUBLAisaavgqTkvsqUovifKau8kJecm/V1wuRA=; b=kn3Xe0u/X8AEnvVv6Do38KD3kn8TdMKmBNVBwa99TgqIoKo1m/79hWI7yUD3SNaM9R pQLsnVuif2cHM11bhh1aC0JrioW3ha961w4yJjUG4n2iEcXTOs8Svdb2JX16VS4FZlnS v+2RH6LwFghmI/2TkHddoaNFwPKZlgNqxwSRVk7u7V0gTjBxL6Dy3zOM1oIwNgXWFHpN SZXdKPEtjJk92xb6D/V8ULs09bJLuNijJjTcs/2PaJyjLAAE3menlYoEBQEUPzCGkzFw LX0ORueHdgvFnjYVMT28BzCwS54MTXMKvo5u2vn6omgONl3WM9tJgfgnOlY7JvtEDsFK 8GwQ== X-Gm-Message-State: APt69E1kdsMde0d6zpa0/ED3Pm/W0cIP5L2Qs4XV35HOn1UWdl6cSmrd aCBveV71LjkK6eT7zlH+RcSg9EPAzE2p0GJY+9YX2Q== X-Google-Smtp-Source: ADUXVKI4YWPk+zAWyeHfvSft+M1USFNDCjFKVgUyAgbDwUB7JBUmeuubVO/e2Am0yEPdAGmR5BHifG3tSMIG2J/L/ek= X-Received: by 2002:a17:902:7089:: with SMTP id z9-v6mr30849909plk.231.1529634078640; Thu, 21 Jun 2018 19:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Thu, 21 Jun 2018 19:21:17 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 22 Jun 2018 11:21:17 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/related; boundary="000000000000e4f1cf056f31afca" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 02:21:22 -0000 --000000000000e4f1cf056f31afca Content-Type: multipart/alternative; boundary="000000000000e4f1ce056f31afc9" --000000000000e4f1ce056f31afc9 Content-Type: text/plain; charset="UTF-8" Hi Nick, Thank you for bringing the numbers to the list. I have just run a small benchmark using Quicly, and I see comparable numbers. To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial packet of 1,280 octets. I expect that we will see similar numbers on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look at the total number of CPU cycles spent by a QUIC stack as a whole. Looking at the profile, the overhead consists of three operations that each consumes comparable CPU cycles: core AES operation (using AES-NI), CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks. I would assume that we can cut down the overhead to somewhere between 2% to 4%, but it might be hard to go down to somewhere near 1%, because we cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization). I do not think that 2% to 4% of additional overhead to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is something that we might want to decrease. I am glad to be able to learn that now. 2018-06-22 5:48 GMT+09:00 Nick Banks : > Hello QUIC WG, > > > > I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided > to get some performance numbers to see what the overhead of PNE was. I > figured the rest of the WG might be interested. > > > > My test just encrypts the same buffer (size dependent on the test case) > 10,000,000 times and measured the time it took. The test then did the same > thing, but also encrypted the packet number as well. I ran all that 10 > times in total. I then collected the best times for each category to > produce the following graphs and tables (full excel doc attached): > > > > > > *Time (ms)* > > *Rate (Mbps)* > > *Bytes* > > *NO PNE* > > *PNE* > > *PNE Overhead* > > *No PNE* > > *PNE* > > *4* > > 2284.671 > > 3027.657 > > 33% > > 140.064 > > 105.692 > > *16* > > 2102.402 > > 2828.204 > > 35% > > 608.827 > > 452.584 > > *64* > > 2198.883 > > 2907.577 > > 32% > > 2328.45 > > 1760.92 > > *256* > > 2758.3 > > 3490.28 > > 27% > > 7424.86 > > 5867.72 > > *600* > > 4669.283 > > 5424.539 > > 16% > > 10280 > > 8848.68 > > *1000* > > 6130.139 > > 6907.805 > > 13% > > 13050.3 > > 11581.1 > > *1200* > > 6458.679 > > 7229.672 > > 12% > > 14863.7 > > 13278.6 > > *1450* > > 7876.312 > > 8670.16 > > 10% > > 14727.7 > > 13379.2 > > > > I used a server grade lab machine I had at my disposal, running the latest > Windows 10 Server DataCenter build. Again, these numbers are for crypto > only. No QUIC or UDP is included. > > > > Thanks, > > - Nick > > > -- Kazuho Oku --000000000000e4f1ce056f31afc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick,

Thank you for bringing the num= bers to the list.

I have just run a small benchmar= k using Quicly, and I see comparable numbers.

To b= e precise, I see 10.0% increase of CPU cycles when encrypting a Initial pac= ket of 1,280 octets. I expect that we will see similar numbers on other QUI= C stacks that also use picotls (with OpenSSL as a backend). Note that the n= umber is only comparing the cost of encryption, the overhead ratio will be = much smaller if we look at the total number of CPU cycles spent by a QUIC s= tack as a whole.

Looking at the profile, the overh= ead consists of three operations that each consumes comparable CPU cycles: = core AES operation (using AES-NI), CTR operation overhead, CTR initializati= on. Note that picotls at the moment provides access to CTR crypto beneath t= he AEAD interface, which is to be used by the QUIC stacks.
I would assume that we can cut down the overhead to somewhere = between 2% to 4%, but it might be hard to go down to somewhere near 1%, bec= ause we cannot parallelize the AES operation of PNE with that of AEAD (see = https://github.com/openssl/openssl/blob/Open= SSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L24-L39 about the impact of p= arallelization).

I do not think that 2% to 4% of a= dditional overhead to the crypto is an issue for QUIC/HTTP, but current ove= rhead of 10% is something that we might want to decrease. I am glad to be a= ble to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>:=

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0




--
Kazuho Oku
--000000000000e4f1ce056f31afc9-- --000000000000e4f1cf056f31afca Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ec6ef0925dec7165_0.0.1 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --000000000000e4f1cf056f31afca-- From nobody Thu Jun 21 19:54:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9A130DD7 for ; Thu, 21 Jun 2018 19:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkf3R7KpYNGd for ; Thu, 21 Jun 2018 19:54:34 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE94130DD6 for ; Thu, 21 Jun 2018 19:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zpLd0AOQyimMIOLqLQst3qTCbUjMv1thrgP5jfQDIOY=; b=fbTmXlsueQTvl770VmruuRO1sxIkWqksdAgyOpTePzcmr/iVbwquwuO5LtO+BkEmMFqpOvalJU0V9Y3BO4bXYOjsvJq3KupCwvA0sM4TTs15BCY+1Op/i5+6hoEUO+TavODJNzHv20fa/iJmJU/SiLUn9/Ovu5unCZfkNJDO7EE= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1063.namprd21.prod.outlook.com (52.132.128.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.3; Fri, 22 Jun 2018 02:54:31 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Fri, 22 Jun 2018 02:54:31 +0000 From: Nick Banks To: Kazuho Oku CC: "quic@ietf.org" Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOU= Date: Fri, 22 Jun 2018 02:54:31 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1063; 7:E0bVpU2kPiUdRasQotZGvNiphBbRX+3W3zi4srudZSBj2e1nkx2f1SP2DzsheWzzwYL0HXkoCR3AWFSMWIBmOlMHysYXF1zvJQqTnUvtkOHvEAspaauKDuQlNTDZgKao5NB5rNlWm76Nfg5fpWL57Cw20EPE/ibOTI1bCxk5fUrokIchso8jwQJ/8KW3oEJIM5e9ew5n/MQWQ8RbjXDTJv0Y088AmH1SGlrMD/4jC6Atqn6zSJgPJhqPS0YbgMN3 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0ce9540c-c299-4e62-adc0-08d5d7eb7a91 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989111)(4534165)(4627221)(201703031133081)(201702281549075)(8990101)(5600026)(711020)(48565401081)(2017052603328)(49563074)(7193020); SRVR:DM5PR2101MB1063; x-ms-traffictypediagnostic: DM5PR2101MB1063: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(189930954265078)(85827821059158)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1063; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1063; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(396003)(346002)(39380400002)(39860400002)(366004)(189003)(199004)(25786009)(6116002)(86362001)(7736002)(2900100001)(3660700001)(3480700004)(3846002)(105586002)(33656002)(86612001)(99936001)(561924002)(22452003)(106356001)(76176011)(2906002)(966005)(6246003)(81156014)(478600001)(81166006)(4326008)(5250100002)(39060400002)(10290500003)(5890100001)(8676002)(8936002)(68736007)(3280700002)(9886003)(14454004)(446003)(6436002)(97736004)(733005)(55016002)(236005)(54556002)(606006)(53936002)(10090500001)(102836004)(6916009)(11346002)(1411001)(316002)(9686003)(486006)(74316002)(8990500004)(7696005)(66066001)(229853002)(59450400001)(6506007)(99286004)(345774005)(6306002)(5660300001)(54896002)(26005)(186003)(53546011)(476003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1063; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /zReEfPo5cTqF2kIcnVkCWnZ6NCDXeqc8yaeXGarkhQTItI5Ch6UuGYVxclEPcl9o9kgQlx8m8tpsET+cv+TIqxER7BoZxcYUKtd5GZBEtc1eE90paZMxI3IaDRglwRY/PHQ5ZsE6xzZTFmfECN1j126gvNG/Rx4KzPubQcasngid1HOcg4DP5Avr2at3snriqRaRMoir2eZJ5TFcFDcMj+I9CINKs8p1PuYzwJDRrJhOAdJ1Nx731gKBGqfKe9/dHUn407iU1Z693ikJtKgmKPE4zs4mT6ROireaAHijIbS9sp4gOqtzt12mFe+f82P spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ce9540c-c299-4e62-adc0-08d5d7eb7a91 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 02:54:31.5296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1063 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 02:54:38 -0000 --_004_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_ Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_" --_000_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kazuho, Thanks for sharing your numbers as well! I'm bit confused where you say you= can reduce the 10% overhead to 2% to 4%. How do you plan on doing that? Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ________________________________ From: Kazuho Oku Sent: Thursday, June 21, 2018 7:21:17 PM To: Nick Banks Cc: quic@ietf.org Subject: Re: Packet Number Encryption Performance Hi Nick, Thank you for bringing the numbers to the list. I have just run a small benchmark using Quicly, and I see comparable number= s. To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial= packet of 1,280 octets. I expect that we will see similar numbers on other= QUIC stacks that also use picotls (with OpenSSL as a backend). Note that t= he number is only comparing the cost of encryption, the overhead ratio will= be much smaller if we look at the total number of CPU cycles spent by a QU= IC stack as a whole. Looking at the profile, the overhead consists of three operations that each= consumes comparable CPU cycles: core AES operation (using AES-NI), CTR ope= ration overhead, CTR initialization. Note that picotls at the moment provid= es access to CTR crypto beneath the AEAD interface, which is to be used by = the QUIC stacks. I would assume that we can cut down the overhead to somewhere between 2% to= 4%, but it might be hard to go down to somewhere near 1%, because we canno= t parallelize the AES operation of PNE with that of AEAD (see https://githu= b.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L2= 4-L39 about the impact of parallelization). I do not think that 2% to 4% of additional overhead to the crypto is an iss= ue for QUIC/HTTP, but current overhead of 10% is something that we might wa= nt to decrease. I am glad to be able to learn that now. 2018-06-22 5:48 GMT+09:00 Nick Banks >: Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): [cid:image003.png@01D40966.7655B6B0] Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick -- Kazuho Oku --_000_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kazuho,

 

Thanks for sharing your numbers as well! I'm bit con= fused where you say you can reduce the 10% overhead to 2% to 4%. How do you= plan on doing that?

 

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

 

From: Kazuho Oku <kazuho= oku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@ietf.org
Subject: Re: Packet Number Encryption Performance
 
Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable n= umbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a In= itial packet of 1,280 octets. I expect that we will see similar numbers on = other QUIC stacks that also use picotls (with OpenSSL as a backend). Note t= hat the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look= at the total number of CPU cycles spent by a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that= each consumes comparable CPU cycles: core AES operation (using AES-NI), CT= R operation overhead, CTR initialization. Note that picotls at the moment p= rovides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between = 2% to 4%, but it might be hard to go down to somewhere near 1%, because we = cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization).

I do not think that 2% to 4% of additional overhead to the crypto is a= n issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>:<= br>

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

 

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

 

 

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 




--
Kazuho Ok= u
--_000_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_-- --_004_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=29298; creation-date="Fri, 22 Jun 2018 02:21:24 GMT"; modification-date="Fri, 22 Jun 2018 02:21:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --_004_DM5PR2101MB0901C834F1FDFEC6D0D50781B3750DM5PR2101MB0901_-- From nobody Thu Jun 21 20:22:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7EF130DDE for ; Thu, 21 Jun 2018 20:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RUT4l4sIcedm for ; Thu, 21 Jun 2018 20:22: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 7E16D130DDC for ; Thu, 21 Jun 2018 20:22:42 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id i7-v6so2325484pgp.2 for ; Thu, 21 Jun 2018 20:22:42 -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=GRHJrLmGwu9eBjFeDTuPL5kiHmGlUubafcvE1zj1TGA=; b=OKTnR1fJTPCFf59Tu28wCIpTbwqcZlk+9st3ZD5ss8uS8geA1FQUBQF+spqIesJwOr oDiLyDzJUM17wg7tnRdpzXJKntHvngpIHZ1QEgZO63WY0SaBtcSo3z/DZwz8AJHeZu2W q+Ka8lMHswnSJfwrQdkzTCI+jurS7aqc0NwJ6QXCHLRoDbMTsMaf3j3LnmQRDAJD8zPD VDohJu/XOH+oL6My5HzDqIQ+UtUWxplx5QAvRKsxZGgA5C//On1tbf0R99CE5PVEW1xu l0AJfxfa7hBCl0OfZuFYhaPRf/0Wdqto7pfnV/KYGg56EaCAdPU/kZ0BEUPr7GbdB46n BJcA== 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=GRHJrLmGwu9eBjFeDTuPL5kiHmGlUubafcvE1zj1TGA=; b=fIdFDFcK2E7+xTAUbqKX1HYS9xZ6aSflGwSPvQK4pHw8jRg4GX7V7ibM2iOx7RWvXk 60+ttrZ4Mei4TqGGEnm/+pbPUiJdzakQJJcWvt0i6lfGHRmK7Qr/uHfEKaK8H2oVmSxY Emseu2ySKykVR9G6iOw0utoBS3Q1Ue+CGyuNXzzh3zxIN5sxca+wBUsn3NO9Dxt84LIx rjlJDUF+Hy+WBoRJEmfkfP4+sHokvZ0pj50FCxeKBbdnDeDxwgWAXz+6CTBpz9Oxoexg hTcCs6Qv3qS6d0z7rVYTLgLKPXOA5o8kiufLj3Gw5F5+pAIuQdXtBszNKXzND40n+MDP zqyg== X-Gm-Message-State: APt69E2qVas580ePWFgO8z2xvgw/3eAqKa95hRwV6/vICFtR0nAGn3UD XczqB4NaXwqPHwIEpMcRC+eAR+ZZurDMWcxjS2U= X-Google-Smtp-Source: ADUXVKKq9QffbqaL4F3WFqMwOEgd/QjYYR9+76kdcIcViFugmWkJ7YgPNog6PjD34QcYHlR1MzT7Pzc+odeYKClPiyI= X-Received: by 2002:a63:b305:: with SMTP id i5-v6mr24842833pgf.370.1529637761810; Thu, 21 Jun 2018 20:22:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Thu, 21 Jun 2018 20:22:39 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 22 Jun 2018 12:22:39 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/related; boundary="0000000000006db708056f328b9a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 03:22:45 -0000 --0000000000006db708056f328b9a Content-Type: multipart/alternative; boundary="0000000000006db705056f328b99" --0000000000006db705056f328b99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-06-22 11:54 GMT+09:00 Nick Banks : > Hi Kazuho, > > > > Thanks for sharing your numbers as well! I'm bit confused where you say > you can reduce the 10% overhead to 2% to 4%. How do you plan on doing tha= t? > As stated in my previous mail, the 10% of overhead consists of three parts, each consuming comparable number of CPU cycles. The two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB operation cost. It should be able to remove the costly abstraction layer. It should also be possible to remove the overhead of CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the only difference between CTR and ECB). That cost should be something that should be possible to be nullified. Considering these aspects, and by looking at the numbers on the OpenSSL source code (as well as considering the overhead of GCM), my expectation goes to 2% to 4%. > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > *From:* Kazuho Oku > *Sent:* Thursday, June 21, 2018 7:21:17 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Packet Number Encryption Performance > > Hi Nick, > > Thank you for bringing the numbers to the list. > > I have just run a small benchmark using Quicly, and I see comparable > numbers. > > To be precise, I see 10.0% increase of CPU cycles when encrypting a > Initial packet of 1,280 octets. I expect that we will see similar numbers > on other QUIC stacks that also use picotls (with OpenSSL as a backend). > Note that the number is only comparing the cost of encryption, the overhe= ad > ratio will be much smaller if we look at the total number of CPU cycles > spent by a QUIC stack as a whole. > > Looking at the profile, the overhead consists of three operations that > each consumes comparable CPU cycles: core AES operation (using AES-NI), C= TR > operation overhead, CTR initialization. Note that picotls at the moment > provides access to CTR crypto beneath the AEAD interface, which is to be > used by the QUIC stacks. > > I would assume that we can cut down the overhead to somewhere between 2% > to 4%, but it might be hard to go down to somewhere near 1%, because we > cannot parallelize the AES operation of PNE with that of AEAD (see > https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/ > crypto/aes/asm/aesni-x86_64.pl#L24-L39 > > about the impact of parallelization). > > I do not think that 2% to 4% of additional overhead to the crypto is an > issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht > want to decrease. I am glad to be able to learn that now. > > > 2018-06-22 5:48 GMT+09:00 Nick Banks dmarc.ietf.org>: > >> Hello QUIC WG, >> >> >> >> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided >> to get some performance numbers to see what the overhead of PNE was. I >> figured the rest of the WG might be interested. >> >> >> >> My test just encrypts the same buffer (size dependent on the test case) >> 10,000,000 times and measured the time it took. The test then did the sa= me >> thing, but also encrypted the packet number as well. I ran all that 10 >> times in total. I then collected the best times for each category to >> produce the following graphs and tables (full excel doc attached): >> >> >> >> >> >> *Time (ms)* >> >> *Rate (Mbps)* >> >> *Bytes* >> >> *NO PNE* >> >> *PNE* >> >> *PNE Overhead* >> >> *No PNE* >> >> *PNE* >> >> *4* >> >> 2284.671 >> >> 3027.657 >> >> 33% >> >> 140.064 >> >> 105.692 >> >> *16* >> >> 2102.402 >> >> 2828.204 >> >> 35% >> >> 608.827 >> >> 452.584 >> >> *64* >> >> 2198.883 >> >> 2907.577 >> >> 32% >> >> 2328.45 >> >> 1760.92 >> >> *256* >> >> 2758.3 >> >> 3490.28 >> >> 27% >> >> 7424.86 >> >> 5867.72 >> >> *600* >> >> 4669.283 >> >> 5424.539 >> >> 16% >> >> 10280 >> >> 8848.68 >> >> *1000* >> >> 6130.139 >> >> 6907.805 >> >> 13% >> >> 13050.3 >> >> 11581.1 >> >> *1200* >> >> 6458.679 >> >> 7229.672 >> >> 12% >> >> 14863.7 >> >> 13278.6 >> >> *1450* >> >> 7876.312 >> >> 8670.16 >> >> 10% >> >> 14727.7 >> >> 13379.2 >> >> >> >> I used a server grade lab machine I had at my disposal, running the >> latest Windows 10 Server DataCenter build. Again, these numbers are for >> crypto only. No QUIC or UDP is included. >> >> >> >> Thanks, >> >> - Nick >> >> >> > > > > -- > Kazuho Oku > --=20 Kazuho Oku --0000000000006db705056f328b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&g= t;:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?


As= stated in my previous mail, the 10% of overhead consists of three parts, e= ach consuming comparable number of CPU cycles. The two among the three is r= elated to the abstraction layer and how CTR is implemented, while the other= one is the core AES-ECB operation cost.

It should= be able to remove the costly abstraction layer.

I= t should also be possible to remove the overhead of CTR, since in PNE, we n= eed to XOR at most 4 octets (applying XOR is the only difference between CT= R and ECB). That cost should be something that should be possible to be nul= lified.

Considering these aspects, and by looking = at the numbers on the OpenSSL source code (as well as considering the overh= ead of GCM), my expectation goes to 2% to 4%.

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: = Kazuho Oku <kaz= uhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@ietf.org=
Subject: Re: Packet Number Encryption Performance
=C2=A0
Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable n= umbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a In= itial packet of 1,280 octets. I expect that we will see similar numbers on = other QUIC stacks that also use picotls (with OpenSSL as a backend). Note t= hat the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look= at the total number of CPU cycles spent by a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that= each consumes comparable CPU cycles: core AES operation (using AES-NI), CT= R operation overhead, CTR initialization. Note that picotls at the moment p= rovides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between = 2% to 4%, but it might be hard to go down to somewhere near 1%, because we = cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

I do not think that 2% to 4% of additional overhead to the crypto is a= n issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0




--
Kazuho Oku



--
Kazuho Oku
--0000000000006db705056f328b99-- --0000000000006db708056f328b9a Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 876ba58c1de1a059_0.1 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --0000000000006db708056f328b9a-- From nobody Thu Jun 21 20:45:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C673C130DDE for ; Thu, 21 Jun 2018 20:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 RXk5s5ICzF8M for ; Thu, 21 Jun 2018 20:45:19 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 1AE54128CF3 for ; Thu, 21 Jun 2018 20:45:19 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id c41-v6so2757674plj.10 for ; Thu, 21 Jun 2018 20:45:19 -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=R88zNOlx+Q+VFDV2aWDZ4yLpuj5+QpqY7mmOFS+Mq8g=; b=gRb5gDo0Isrk2iSyBGkx7cA/QiDlGru4UX1vVokW99fNKQVUTPWbAoLdetT+UHS8Cj +/yp29URFvOSngNOw6NquuUAhMhW5upkSwUwXL01gjX+yTAP6TIBRX7Fw/CE/STzjdrz P98APX2iLMQ1op+7gpQob0A99h7N/0Yre9uaShsvpzoMuRYLkjxBSgALEp/cZMboTQlv EsbjA+TIhHCnKuw4XINxyE/the+C4mRI6ny7G+fN6fFetN+u2Qjf9aBMZXB/zwjlzanh QkFTh7xqCRiB+KaYFaK4YMCLzoKkZpmNJs7Rf6l8aVFtW3ac/0Tb36rY723kqFbuD45i xYNw== 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=R88zNOlx+Q+VFDV2aWDZ4yLpuj5+QpqY7mmOFS+Mq8g=; b=WRLTinD18+tBwuonMHfK1NET/S0DxGDSlw5uMyEJHGhFMM6JblU51rRrQ2TX9MSvqS BNkJEdgTYg/cdufAslog/2MetAHxABcEMyE9hBGeu3X58hBZb6yQKZmgROIFaDTCRSje RvG0V8pFMkrloBB48+99wT1HNWpVvxpSAmQmwaMSOaIR2MA41cpdsJxkbGsMHRHyMOv3 4AURzbCuAudmYxoLJIHQifd/m8nvIyGs6POBejN2j3ePXYOnEbNYcqsM0B/6KMy8vcQr kw7sgLuP6hfa7W4VC8i4pxUluq9hcW9qV4nMLQ3dzmxBcYExeh0blumpEFF+/+rE4LhR ExHA== X-Gm-Message-State: APt69E1iRLm5CvRyqt/GGldB4S/jDqVVTjI9OJQfWcB0i6Yc93g263+n BUlKQMHeMdz9eup2OOlEB5pUxNzcHKSidJIJczI= X-Google-Smtp-Source: ADUXVKKmDEDAISiQOcFFTJcoWB8gLoXOxnePThvspVv2Aw8Eg+iW0+6CP9C7vTaAg0D1Cnq6GOr+04s2XEKe2UD5ujI= X-Received: by 2002:a17:902:b08a:: with SMTP id p10-v6mr18017881plr.0.1529639118500; Thu, 21 Jun 2018 20:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Thu, 21 Jun 2018 20:45:17 -0700 (PDT) In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> From: Kazuho Oku Date: Fri, 22 Jun 2018 12:45:17 +0900 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: "Deval, Manasi" Cc: Marten Seemann , Ian Swett , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 03:45:22 -0000 2018-06-22 8:08 GMT+09:00 Deval, Manasi : > I feel that the requirement to have every value valid is somewhat academi= c. I think that Marten is correct in pointing out that making the ACK frame self-containing (by having a field that represents the number of octets being consumed by the frame) would be an exception from the design pattern we have. Look at STREAM frame. The field is not self-contained. Instead, it has a Length field for the Stream Data, which is a leaf. The same goes for NEW_CONNECTION_ID frame (that has the length field for Connection ID field (which is also a leaf)), CONNECTION_CLOSE (length field for Reason Phase). I agree with Marten, Mikkel (and possibly others as well) that having consistency is important. Therefore, I agree with Mikkel that we should consider making every frame self-contained or keeping every frame as-is (i.e. not self-contained). FWIW, as described in the latter half of https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it is possible to make every frame self-contained *and* also make ACK frames smaller than the current draft. Making every frame self-contained gives us the possibility to send new extension frames without negotiation. I do not think that I would push for making every frame self-contained by myself (because I do not think it meets the high bar to have a change at such a late moment of standardization), but as stated, my preference goes to seeing every frame made self-contained or none of them made as such. > The length value provides much more value than the block count and the fa= ct > that certain values can never be achieved is an inherent property of the > length. > > > > One interesting observation is that this property is not limited to lengt= h. > One can even make a similar argument about ACK block count. The maximum > number of ACK blocks that can be defined will not always have a meaningfu= l > value. In out examples, 0,1,2,3 are all valid. If I set the value of ACK > block count to have lower two bits to be 11, the maximum value is of ACK > blocks is =E2=80=93 4611686018427387903. This is the same value of larges= t > acknowledged so if the ACK block count was set to this value, it would st= ill > be meaningless. > > > > Thanks, > > Manasi > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > Sent: Tuesday, June 19, 2018 6:44 PM > To: Deval, Manasi > Cc: Ian Swett ; Kazuho Oku ; Er= ic > Rescorla ; Jana Iyengar ; Praveen > Balasubramanian ; IETF QUIC WG ; Mart= in > Thomson > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > Hi Manasi, > > > >> The risk of disagreement between ack blocks and ack block count is same = as >> the risk of disagreement between ack blocks and ack length. Either way t= his >> needs to be counted up while creating the ACK and counted down while par= sing >> it. The possibility of error is the same. Getting the ack block count wr= ong >> is as problematic as getting the ack length wrong. Do you agree? > > > > I disagree. Let's take an example of an ACK frame with one ACK range, tha= t > needs a 2 byte varint to represent the First ACK Block and another 2 byte > varint to represent the Gap. > > With your proposal: > > The values 0 and 1 are invalid, since the length fields itself is include= d > in the length. > The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 = are > invalid, since the length needs to include the Largest Acknowledged and t= he > Ack Delay. > The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first > valid value, and correspond to an ACK frame with no blocks. > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, si= nce > it would cut the varint for the First ACK Block > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, si= nce > it would cut the frame after the First ACK Block (but every block must be > followed by a gap length) > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, si= nce > it would cut the varint for the Gap > Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is va= lid > > There are *a lot* of invalid values that you can encode into the ACK leng= th > field. More importantly, *none* of these error cases exists with the curr= ent > frame format. > > The *only* error case that can occur with our current format is that the > packet is too short for the number of ACK blocks that are supposed to > contained in the frame. This can occur with your proposal as well (in > addition to the error cases listed above). > > > > My concern is not that it's impossible or even particularly hard to catch > these errors, but I dislike the property that some (in fact, most) encoda= ble > values are invalid. > > > > Best, > > Marten > > > > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > wrote: > > Hi Ian, > > > > Here is another attempt to solve the objections you raised: > > > >>I'm not a fan of this proposal, because I think it is impractical to drop >> the number of ack blocks, because with the ECN proposal it becomes >> impractically complex to parse. > > Is there a reason the proposal from Christian does not solve this problem= ? > > > >>If we don't remove the number of ack blocks, then the ack frame is larger= , >> but I don't think the extra size field is useful for most implementation= s. >> Also, it means the length can disagree with the actual length, which add >> complexity and the possibility of writing error-prone code. The idea of >> someone offloading ack processing and then proceeding to trust the lengt= h >> seems like someone could get wrong and cause some concerning issues. > > The risk of disagreement between ack blocks and ack block count is same a= s > the risk of disagreement between ack blocks and ack length. Either way th= is > needs to be counted up while creating the ACK and counted down while pars= ing > it. The possibility of error is the same. Getting the ack block count wro= ng > is as problematic as getting the ack length wrong. Do you agree? > > > >>My experience is multithreaded packet processing is more cost and work th= an >> it's worth. Sure you can't fill a 100G NIC with one connection, but tha= t >> seems like an academic problem, not one for workloads I've seen. Typica= lly >> the extra cost of multithreading outweighs its value. > > The value is two fold =E2=80=93 pre-processing and multi-threading. If we > pre-process the received packets such that ACKs and streams can be > coalesced, the receive side can indicate a large chunk of information tho= ugh > the kernel, reducing the cost of system call and protocol overhead. This = is > the same concept as UDP segmentation taken a step further on receive side= . > After this chunk is indicated into the QUIC protocol, the protocol may > process stream and ACK in parallel. While folks may or may not utilize th= is, > there is an advantage here. > > > > Thanks, > > Manasi > > > > > > From: Ian Swett [mailto:ianswett@google.com] > Sent: Tuesday, June 19, 2018 11:26 AM > To: Deval, Manasi > Cc: Marten Seemann ; Kazuho Oku > ; Eric Rescorla ; Jana Iyengar > ; Praveen Balasubramanian ; IETF > QUIC WG ; Martin Thomson > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > I'm still not interested in this change, for the reasons I stated above. > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > wrote: > > Hi All, > > > > Do we have agreement here to create a new PR? > > > > Thanks, > > Manasi > > > > From: Deval, Manasi > Sent: Sunday, June 17, 2018 2:25 PM > To: Marten Seemann ; Kazuho Oku > > Cc: Ian Swett ; Eric Rescorla > ; Jana Iyengar ; Praveen Balasubramania= n > ; IETF QUIC WG ; Martin Thomson > > Subject: RE: Proposal to replace ACK block count with ACK length > > > > Hi All, > > > > I have made a list of objections to the proposal and the solutions to tho= se > objections discussed on this thread. > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > Christian suggested to move the ECN fields to precede the ACK blocks. Thi= s > is an elegant solution. Parsing entire list of ACK blocks to review ECN b= its > would have been annoying, even though it can work. > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse A= CK to > identify length. There are some reservations when ACK parsing gets harder > for the case where the entire header needs to be parsed. > > > > Agreement from several folks here. In the original ACK defined in draft 1= 2 > of the slide, one would count down number of ACK blocks to get to the end= of > the packet. In the proposal I made, one would count down the length to > identify the end of the packet. The logic is very similar in cycle count = and > complexity. Several folks also commented to this effect. > > > > c. Multi-threaded packet processing > > > > I would expect that there are 10s of 1000s of connections in use at any t= ime > for a server with a high speed link. Multi-threading to handle each of th= ese > flows / connections in parallel is necessity to be able to support large > number of connections on a high speed link. Tx segmentation, Rx coalescin= g > are well known strategies to reduce the processing cost. In initial stage= s, > code is often written as a single-threaded and then re-factored to > parallelize cycle intensive operations. In order to allow this protocol t= o > scale in future, I would suggest we do not preclude this case. > > > > d. Increase in ACK size by 1 byte. > > > > I do not see this as a serious issue but if folks but we can consider mak= ing > this a varint, if others have strong feelings about it. It=E2=80=99s a tr= ade-off : 2 > reads to save 1 byte. > > > > e. Every encodable value should be valid > > Not every length will be valid. This is inherent to lengths. This same is= sue > ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does t= he issue exist for > small values, it also applies to large values since data stream will be s= ent > after crypto negotiation. E.g. - how does one craft a payload with 62 b= it > payload length in a large header? > > > > > > Thanks, > > Manasi > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > Sent: Sunday, June 17, 2018 6:59 AM > To: Kazuho Oku > Cc: Ian Swett ; Eric Rescorla > ; Jana Iyengar ; Praveen Balasubramania= n > ; IETF QUIC WG ; Martin Thomson > ; Deval, Manasi > Subject: Re: Proposal to replace ACK block count with ACK length > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the whole > packet, so as long as the packet payload is long enough, the varint parsi= ng > will not fail. > > I don't think that specifics of programming languages matter here though, > and I'm sure both frame formats can be reasonably implemented in C as wel= l > as in Go. The reasons I'm opposed to Manasi's proposal are that it moves = us > away from the principle that only reasonable values should be encodable, = and > that it increases the size of the ACK frame, for the questionable benefit= of > being able to parallelise the frame parser. > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : >> At least for my implementation, parsing doesn't become easier, it become= s >> more complex with this proposal. My varint-parser always consumes as man= y >> bytes as the varint requires, so after parsing a varint, I'd have to >> introduce an additional check that this didn't overflow the ACK length >> (e.g. >> consider that I parsed the ACK frame so far that only 2 bytes are >> remaining >> according to ACK length field, but the next varint is 4 bytes long). > > Isn't your varint parser checking that it has not (or will not) run > across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun. > > What I am saying that that check could be converted to a overrun check > against the end of the "frame payload", and that checking the > remaining block count becomes unnecessary, in case we replace ACK > Block Count with ACK Frame Length. > >> >> In general, we've been moving the wire image towards making every >> encodable >> value valid. This proposal moves us away from that principle: >> * some small values are always invalid (the length can never be between = 0 >> and 3) >> * a lot of intermediate values are invalid (if the boundary falls inside= a >> varint, as described above) >> Both these cases can't occur with the current ACK frame format. >> >> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote: >>> >>> 2018-06-17 8:34 GMT+09:00 Ian Swett >>> : >>> > I'm not a fan of this proposal, because I think it is impractical to >>> > drop >>> > the number of ack blocks, because with the ECN proposal it becomes >>> > impractically complex to parse. >>> >>> For the ECN proposal, as Christian has suggested, we can move the ECN >>> counters before the ACK blocks. Then, it would not be complex to >>> parse. >>> >>> And my view is that parsing becomes easier if we replace ACK Block >>> Count with ACK Frame Length. >>> >>> Now, with ACK Block Count, we need to check the remaining number of >>> blocks and the remaining space in the packet payload for every block >>> that we parse. Failing to check either leads to a bug or a security >>> issue. >>> >>> If we switch to ACK Frame Length, we need to only check the remaining >>> space in the frame. >>> >>> I think that this is the biggest benefit of replacing ACK Block Count >>> with ACK Frame Length. OTOH the downside is that you need extra one to >>> two bits (one if the size of block / gap is expected to be below 65, >>> two if they are expected to be above that) for encoding ACK Frame >>> Length compared to ACK Block Count. >>> >>> >>> >>> Having said that, I honestly wonder if all the frames could have it's >>> length being encoded (either explicitly or either as a signal that >>> says "to the end of the packet"). Consider something like below: >>> >>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | >>> or >>> |1| frame-type (7) | frame-payload (*) | >>> >>> When MSB of the first octet set to zero, the length of the frame >>> payload is designated by the varint that immediately follows the frame >>> type. >>> When MSB of the first octet set to one, the length of the frame >>> payload spans to the end of the packet. >>> >>> In this encoding, we can always omit the Length field of a STREAM >>> frame. So the overhead for carrying stream data will be indifferent in >>> practice. >>> >>> For the ACK frame, we can omit the ACK Block Count field. And the >>> overhead will be one to two bits if the ACK frame is sent in the >>> middle of the packet (thereby using the encoding with explicit frame >>> payload length), or one octet or more shorter if ACK is the last frame >>> of the packet. >>> >>> We are likely to see increase of overhead for most of the other types >>> of frames, but I do not think that would be an issue considering that >>> they will be far seldom seen compared to STREAMs and ACKs. >>> >>> To summarize, my anticipation is that we can make all the frames >>> self-contained (i.e. the length can be determined without the >>> knowledge of how each frame is encoded) without any overhead, if we >>> agree on making the frame type space 1 bit smaller. >>> >>> Finally, the biggest benefit of using a self-contained encoding of >>> frames is that we would have the ability to introduce new optional >>> frames without negotiation. By making the frames self-contained, QUIC >>> endpoints will have the freedom of ignoring the frames that they do >>> not understand. >>> >>> Being able to send QUIC frames defined in extensions without >>> negotiating using Transport Parameters will be a win in both terms of >>> security (because clients' TP is sent in clear) and flexibility >>> (because we will be possible to send the extensions before we figure >>> out whether the peer supports that extension). >>> >>> > If we don't remove the number of ack blocks, then the ack frame is >>> > larger, >>> > but I don't think the extra size field is useful for most >>> > implementations. >>> > Also, it means the length can disagree with the actual length, which >>> > add >>> > complexity and the possibility of writing error-prone code. The idea >>> > of >>> > someone offloading ack processing and then proceeding to trust the >>> > length >>> > seems like someone could get wrong and cause some concerning issues. >>> > >>> > My experience is multithreaded packet processing is more cost and wor= k >>> > than >>> > it's worth. Sure you can't fill a 100G NIC with one connection, but >>> > that >>> > seems like an academic problem, not one for workloads I've seen. >>> > Typically >>> > the extra cost of multithreading outweighs its value. >>> > >>> > To be clear, I don't think this is an awful idea, but I also don't se= e >>> > the >>> > value and it adds complexity. I read Manasi's email, but I don't thi= nk >>> > I >>> > understand why any of those matter in practice. >>> > >>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: >>> >> >>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >>> >> >>> >> wrote: >>> >>> >>> >>> This proposal increases the size of the ACK frame by 1 byte in the >>> >>> common >>> >>> case (less than 63 ACK ranges), since the ACK length field here >>> >>> always >>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length >>> >>> integer. >>> >>> Considering how much work we put into minimising the size of the >>> >>> frames, >>> >>> this feels like a step in the wrong direction.. >>> >>> >>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK >>> >>> frame >>> >>> requires looping over and making changes to a data structure that >>> >>> keeps >>> >>> track of sent packets. This is much more expensive than simply >>> >>> parsing >>> >>> a >>> >>> bunch of varints in the ACK frame. It seems unlikely that a >>> >>> multi-threaded >>> >>> packet parser would offer any real-world performance benefits. >>> >> >>> >> >>> >> I don't want to overstate the benefit here, but my point isn't that >>> >> parsing is expensive but that if you want to have a multithreaded >>> >> packet >>> >> processing system, then it's nice to have a simpler data structure >>> >> (the >>> >> unparsed ACK block) to hand to the ACK processing thread. >>> >> >>> >> -Ekr >>> >> >>> >> >>> >>> >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >>> >>> >>> >>> wrote: >>> >>>> >>> >>>> When we discussed this before, some people observed that this >>> >>>> creates >>> >>>> a need to encode in two passes. That's the trade-off here. (Not >>> >>>> expressing an opinion.) >>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar >>> >>>> wrote: >>> >>>> > >>> >>>> > I don't have a strong opinion on this. I'm certainly not opposed >>> >>>> > to >>> >>>> > it. >>> >>>> > Does anyone have a strong opposition? >>> >>>> > >>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >>> >>>> > wrote: >>> >>>> >> >>> >>>> >> I agree as well since this can help reduce per packet processin= g >>> >>>> >> overhead. ACKs are going to be the second most common frame typ= e >>> >>>> >> so no >>> >>>> >> objections to special casing. >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric >>> >>>> >> Rescorla >>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM >>> >>>> >> To: Deval, Manasi >>> >>>> >> Cc: Jana Iyengar ; QUIC WG >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt= h >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> I agree with Manasi here. This change would allow ack frame >>> >>>> >> parsing >>> >>>> >> to be more self-contained, which is an advantage for the parser >>> >>>> >> and also >>> >>>> >> potentially for parallelism (because you can quickly find the >>> >>>> >> frame and then >>> >>>> >> process it in parallel). >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> -Ekr >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >>> >>>> >> wrote: >>> >>>> >> >>> >>>> >> In general, varints require some specific logic for parsing. To >>> >>>> >> skip >>> >>>> >> over any header, I have to read every single varint. As the cod= e >>> >>>> >> sees Stream >>> >>>> >> and ACK headers most frequently, that is my focus. The Stream >>> >>>> >> frame has a >>> >>>> >> length in its third field. >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify >>> >>>> >> length. There are two reads each for =E2=80=98largest acknowled= ged=E2=80=99, =E2=80=98ACK >>> >>>> >> delay=E2=80=99 and >>> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the total = number of cycles >>> >>>> >> parse an >>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets >>> >>>> >> have a >>> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck. >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> Thanks, >>> >>>> >> >>> >>>> >> Manasi >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana >>> >>>> >> Iyengar >>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM >>> >>>> >> To: Deval, Manasi ; QUIC WG >>> >>>> >> >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt= h >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> You're right that we no longer have the ability to skip an ACK >>> >>>> >> frame, >>> >>>> >> and this crept in when we moved to varints. >>> >>>> >> >>> >>>> >> I believe your problem though is generally true of most frames >>> >>>> >> not >>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames >>> >>>> >> are now all >>> >>>> >> varints. To skip any frame, you'll need to parse the varint >>> >>>> >> fields >>> >>>> >> in those >>> >>>> >> frames. If you have logic to process and skip varints, then >>> >>>> >> skipping the ack >>> >>>> >> block section is merely repeating this operation (2*num_block+1= ) >>> >>>> >> times. Do >>> >>>> >> you see specific value in skipping ACK frames over the other >>> >>>> >> control frames? >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >>> >>>> >> wrote: >>> >>>> >> >>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: >>> >>>> >> > - Moving the ACK length to the front of the ACK allows >>> >>>> >> > the >>> >>>> >> > flexibility of either reading the entire ACK or >>> >>>> >> > reading >>> >>>> >> > the >>> >>>> >> > first 16 bits and skipping over the length. This is = a >>> >>>> >> > useful >>> >>>> >> > feature for the case where ACK processing is split >>> >>>> >> > into >>> >>>> >> > multiple layers. Depending on the processor this is >>> >>>> >> > run >>> >>>> >> > on, >>> >>>> >> > there are different advantages - >>> >>>> >> >>> >>>> >> Just a note. In my experience, the cost of parsing an ACK fram= e >>> >>>> >> is >>> >>>> >> negligible compared to the cost of processing an ACK frame: tha= t >>> >>>> >> is, >>> >>>> >> poking at various memory locations to discard newly ACKed >>> >>>> >> packets. >>> >>>> >> >>> >>>> >> - Dmitri. >>> >>>> >> >>> >>>> >> >>> >>>> >>> >> >>> > >>> >>> >>> >>> -- >>> Kazuho Oku > > > > -- > Kazuho Oku --=20 Kazuho Oku From nobody Thu Jun 21 22:17:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA15130DE6 for ; Thu, 21 Jun 2018 22:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 w4OE14h-njXx for ; Thu, 21 Jun 2018 22:17:11 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 D2030130DDE for ; Thu, 21 Jun 2018 22:17:10 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l19-v6so5076553ioj.5 for ; Thu, 21 Jun 2018 22:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lR1ziqqPm5SU01/D/HMUpMUie2elAZ3qB9rJn1L8Rkc=; b=mqyj4rRuxQeOeEPJpAOQH83rw8zNsGA44AsVie/eRHCh5+CE3FjwgtgU3e1B5Rs+WJ eka7OVy9BRm6Cx6qx0CCsbSLXUkomgu54aH/HyYP6A64jIpYn3lKKfO/PKlWv0f7aDjv FeG7cpWD/idHfKy9olcwZ3+aIrJuafFoqhiLSQOKQVQjqHF6t6iZjYu980ODrBLWeHxv j78XHZ7vSUKm977xg+TTAyIiW23tyZ1lToTnCsw92tQl6ydqMplSgbqf+ZjSuulBpg8N fU0BSZv4LG5Cza5iZg3tDZ3c3CJpLF8CSK+IXpjuHw4Msd/7/Lxug2pZFTKkcx5Ah7h+ szCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lR1ziqqPm5SU01/D/HMUpMUie2elAZ3qB9rJn1L8Rkc=; b=eCC768HZj4Omkw5DvIybEcUYp2wiQwGLCyXjPPd0YN8pm0yfaXPr3ERzV7ZnFtgcUW PXHLevtLzPykVcI5D6BBbFmSOlxCGJkmZSpnd407awEe+uDs5wrK+hV4e6o6X8JglVCA WECNW1Igup6yMFMmYs+ulire79U2y8osrVPIYtibVVNfqxpMXtpbYBpBAlOzi1O0NOJk /f+arr38/vPLr/30F8nVu847Nsj/3JGGk3nl6b9t9kP1fm4+23hJKcxOGkQW4ce+xBsz Ucpot7zo8eNR7WWhxvRvRqCDckGlC9iVG11Dz2VJtQJaYPCJxuBM0Qt+VOtjLGKB77SU uPjA== X-Gm-Message-State: APt69E2VLnZDRBKXPv3Q3l9RADhiOaWzwze26knIuh0pfN18ZmXQan/+ DjhjwjJAklrbS6KJamm55R/UxD4c7aGdr0o2tOs= X-Google-Smtp-Source: AAOMgpeXjnXKSy33GKNP6bgopCTVuK4vxyEeGAXQFyizOE2Vq9/TO7HfmeqjcJ0QiVARxvs/hnIkLqtKP6tL85otQ88= X-Received: by 2002:a6b:b68a:: with SMTP id g132-v6mr94795iof.209.1529644629990; Thu, 21 Jun 2018 22:17:09 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Jun 2018 22:17:08 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 21 Jun 2018 22:17:08 -0700 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks , Kazuho Oku Cc: "quic@ietf.org" Content-Type: multipart/related; boundary="000000000000ce4e7f056f3424d8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 05:17:13 -0000 --000000000000ce4e7f056f3424d8 Content-Type: multipart/alternative; boundary="000000000000ce4e7d056f3424d7" --000000000000ce4e7d056f3424d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There might be an additional hidden overhead at large scale if staged PNE causes the packet to pulled in and out of L1 cache several times either send or receive side or by creating additional write buffer pressure by touching an inbound packet, notably on NUMA architectures. This effect can have more overhead than encryption itself if it happens. On 22 June 2018 at 05.22.56, Kazuho Oku (kazuhooku@gmail.com) wrote: 2018-06-22 11:54 GMT+09:00 Nick Banks : > Hi Kazuho, > > > > Thanks for sharing your numbers as well! I'm bit confused where you say > you can reduce the 10% overhead to 2% to 4%. How do you plan on doing tha= t? > As stated in my previous mail, the 10% of overhead consists of three parts, each consuming comparable number of CPU cycles. The two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB operation cost. It should be able to remove the costly abstraction layer. It should also be possible to remove the overhead of CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the only difference between CTR and ECB). That cost should be something that should be possible to be nullified. Considering these aspects, and by looking at the numbers on the OpenSSL source code (as well as considering the overhead of GCM), my expectation goes to 2% to 4%. > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > *From:* Kazuho Oku > *Sent:* Thursday, June 21, 2018 7:21:17 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Packet Number Encryption Performance > > Hi Nick, > > Thank you for bringing the numbers to the list. > > I have just run a small benchmark using Quicly, and I see comparable > numbers. > > To be precise, I see 10.0% increase of CPU cycles when encrypting a > Initial packet of 1,280 octets. I expect that we will see similar numbers > on other QUIC stacks that also use picotls (with OpenSSL as a backend). > Note that the number is only comparing the cost of encryption, the overhe= ad > ratio will be much smaller if we look at the total number of CPU cycles > spent by a QUIC stack as a whole. > > Looking at the profile, the overhead consists of three operations that > each consumes comparable CPU cycles: core AES operation (using AES-NI), C= TR > operation overhead, CTR initialization. Note that picotls at the moment > provides access to CTR crypto beneath the AEAD interface, which is to be > used by the QUIC stacks. > > I would assume that we can cut down the overhead to somewhere between 2% > to 4%, but it might be hard to go down to somewhere near 1%, because we > cannot parallelize the AES operation of PNE with that of AEAD (see > https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/ > crypto/aes/asm/aesni-x86_64.pl#L24-L39 > > about the impact of parallelization). > > I do not think that 2% to 4% of additional overhead to the crypto is an > issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht > want to decrease. I am glad to be able to learn that now. > > > 2018-06-22 5:48 GMT+09:00 Nick Banks dmarc.ietf.org>: > >> Hello QUIC WG, >> >> >> >> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided >> to get some performance numbers to see what the overhead of PNE was. I >> figured the rest of the WG might be interested. >> >> >> >> My test just encrypts the same buffer (size dependent on the test case) >> 10,000,000 times and measured the time it took. The test then did the sa= me >> thing, but also encrypted the packet number as well. I ran all that 10 >> times in total. I then collected the best times for each category to >> produce the following graphs and tables (full excel doc attached): >> >> >> >> >> >> *Time (ms)* >> >> *Rate (Mbps)* >> >> *Bytes* >> >> *NO PNE* >> >> *PNE* >> >> *PNE Overhead* >> >> *No PNE* >> >> *PNE* >> >> *4* >> >> 2284.671 >> >> 3027.657 >> >> 33% >> >> 140.064 >> >> 105.692 >> >> *16* >> >> 2102.402 >> >> 2828.204 >> >> 35% >> >> 608.827 >> >> 452.584 >> >> *64* >> >> 2198.883 >> >> 2907.577 >> >> 32% >> >> 2328.45 >> >> 1760.92 >> >> *256* >> >> 2758.3 >> >> 3490.28 >> >> 27% >> >> 7424.86 >> >> 5867.72 >> >> *600* >> >> 4669.283 >> >> 5424.539 >> >> 16% >> >> 10280 >> >> 8848.68 >> >> *1000* >> >> 6130.139 >> >> 6907.805 >> >> 13% >> >> 13050.3 >> >> 11581.1 >> >> *1200* >> >> 6458.679 >> >> 7229.672 >> >> 12% >> >> 14863.7 >> >> 13278.6 >> >> *1450* >> >> 7876.312 >> >> 8670.16 >> >> 10% >> >> 14727.7 >> >> 13379.2 >> >> >> >> I used a server grade lab machine I had at my disposal, running the >> latest Windows 10 Server DataCenter build. Again, these numbers are for >> crypto only. No QUIC or UDP is included. >> >> >> >> Thanks, >> >> - Nick >> >> >> > > > > -- > Kazuho Oku > -- Kazuho Oku --000000000000ce4e7d056f3424d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = There might be an ad= ditional hidden overhead at large scale if staged PNE causes the packet to = pulled in and out of L1 cache several times either send or receive side or = by creating additional write buffer pressure by touching an inbound packet,= notably on NUMA architectures. This effect can have more overhead than enc= ryption itself if it happens.

On 22 June = 2018 at 05.22.56, Kazuho Oku (kazuho= oku@gmail.com) wrote:

=


2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit confused where you say you can reduce the 10% overhead to 2% to 4%. How do you plan on doing that?


As stated in my previous mail, the 10% of overhead consists of three parts, each consuming comparable number of CPU cycles. The two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB operation cost.

It should be able to remove the costly abstraction layer.

It should also be possible to remove the overhead of CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the only difference between CTR and ECB). That cost should be something that should be possible to be nullified.

Considering these aspects, and by looking at the numbers on the OpenSSL source code (as well as considering the overhead of GCM), my expectation goes to 2% to 4%.

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: = Kazuho Oku <kaz= uhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@ietf.org=
Subject: Re: Packet Number Encryption Performance
=C2=A0
Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable numbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial packet of 1,280 octets. I expect that we will see similar numbers on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look at the total number of CPU cycles spent by a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that each consumes comparable CPU cycles: core AES operation (using AES-NI), CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between 2% to 4%, but it might be hard to go down to somewhere near 1%, because we cannot parallelize the AES operation of PNE with that of AEAD (see https://g= ithub.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesn= i-x86_64.pl#L24-L39 about the impact of parallelization).

I do not think that 2% to 4% of additional overhead to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is something that we might want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org&= gt;:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to get some performance numbers to see what the overhead of PNE was. I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependent on the test case) 10,000,000 times and measured the time it took. The test then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected the best times for each category to produce the following graphs and tables (full excel doc attached):

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)

Bytes

NO PNE

PNE

PNE Overhead

No PNE

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my disposal, running the latest Windows 10 Server DataCenter build. Again, these numbers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0




--
Kazuho Oku



--
Kazuho Oku
--000000000000ce4e7d056f3424d7-- --000000000000ce4e7f056f3424d8 Content-Type: application/octet-stream; name="image003.png@01D40966.7655B6B0" Content-Disposition: inline; filename="image003.png@01D40966.7655B6B0" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6324c2e649026c44_0.1.1 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --000000000000ce4e7f056f3424d8-- From nobody Thu Jun 21 22:57:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3077130DDE for ; Thu, 21 Jun 2018 22:57:50 -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, 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 1M_2XtovTSf3 for ; Thu, 21 Jun 2018 22:57:48 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFC130DEB for ; Thu, 21 Jun 2018 22:57:48 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w5M5vjjk004896; Fri, 22 Jun 2018 07:57:45 +0200 Date: Fri, 22 Jun 2018 07:57:45 +0200 From: Willy Tarreau To: Kazuho Oku Cc: Nick Banks , "quic@ietf.org" Subject: Re: Packet Number Encryption Performance Message-ID: <20180622055745.GA4889@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 05:57:51 -0000 Hi Kazuho, On Fri, Jun 22, 2018 at 12:22:39PM +0900, Kazuho Oku wrote: > As stated in my previous mail, the 10% of overhead consists of three parts, > each consuming comparable number of CPU cycles. The two among the three is > related to the abstraction layer and how CTR is implemented, while the > other one is the core AES-ECB operation cost. > > It should be able to remove the costly abstraction layer. > > It should also be possible to remove the overhead of CTR, since in PNE, we > need to XOR at most 4 octets (applying XOR is the only difference between > CTR and ECB). That cost should be something that should be possible to be > nullified. > > Considering these aspects, and by looking at the numbers on the OpenSSL > source code (as well as considering the overhead of GCM), my expectation > goes to 2% to 4%. Well, probably that we don't need the 10 full AES rounds and could have enough of 2 like some of the SHA3 proposals did, or even maybe just one. These ones take a few tens of CPU cycles on modern CPUs, possibly less, and are probably more than enough to prevent the linkability people are concerned with. Just my two cents. Willy From nobody Thu Jun 21 23:44:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503CF130DFD for ; Thu, 21 Jun 2018 23:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 dsJAElS0OfAn for ; Thu, 21 Jun 2018 23:44:48 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 F04EB130DF7 for ; Thu, 21 Jun 2018 23:44:47 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id a7-v6so2988579plp.3 for ; Thu, 21 Jun 2018 23:44:47 -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=Qa8P2WKiYtkD6jfLrdiFuPI76goWTc+dbXeO5JBMmeI=; b=SIDU68CJTbPpe2QyqLfCJb5eyZniDesIuhNNnIDek4uZDUKXfk9YVL4Cc8dIs/h+0Z cX7SxcUUZPsATX9IGl0kkuv0WNfSugNkktDprYwcaJc4UxOhtXNkdS9w6XsTOTyQBQYe hR4KslJ8FI2rVSvnMvXMMB9aQq+xikz57kjhnTgNqLl9RwXRLWkoZFT/vuOmyN+mK6ts osC22CFP4zKOfvWHSkl7PafBoTNtKcz/OQBEPewV8jUAIZrX3x6CqnPSqhPjOQMZlZyI /1MJNcEXproOCIECdqYqh0ayd6O9OpEFr5qZo0u1A4LIhOtNPpEI17Lc4pOvfR6DzM76 tNhA== 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=Qa8P2WKiYtkD6jfLrdiFuPI76goWTc+dbXeO5JBMmeI=; b=geyHhz4UWhFVE3/rdBMKbNmYjytByMLrJvSLQAIV4d0bGmlbtVyOLAPUSg52XoiYZG MQTXuNje18f/loaQrnPM6FgPu2Gqg4B7totFOJyyym50TlQA3ZNdrzoAMHjvJgWmEzwJ 1XABwzo4IfCYFJHqJQjW4LujccNZyv+TNyQBqUi1ygPmBURta1qDm0kaeG/JuKjSZ3MM JJrOb4+D1ERRJL9H2+3ZtjMOWUrecyESHlyqXNYMk48PKLzMCOd9VTN47BgL3QwuuU6u ped4ore63bR7grAOcX7FdZCO4GI1UI0aty31pf9EtFGVibnYeubbWqrtUIvYJGq6zXn4 BcSw== X-Gm-Message-State: APt69E0eOuoh7xKmuKRhe7knH/la2ismh9/bFC8pjZkv9C6HwX6kn7eH 1H3FftcHmdgQcj4ulqj+bN+Dl1QPDqcgJ7sxMSg= X-Google-Smtp-Source: ADUXVKIQS2Hfz8HorxAx+r71/jO3peEGZqYUb2km8WlBi+fk8qgjViJhWdGAvkr0VIb3C+HnrqXens0SoCjIwHgmEkI= X-Received: by 2002:a17:902:7089:: with SMTP id z9-v6mr334888plk.231.1529649887421; Thu, 21 Jun 2018 23:44:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Thu, 21 Jun 2018 23:44:46 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 22 Jun 2018 15:44:46 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/related; boundary="0000000000002bc632056f355e98" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 06:44:52 -0000 --0000000000002bc632056f355e98 Content-Type: multipart/alternative; boundary="0000000000002bc630056f355e97" --0000000000002bc630056f355e97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-06-22 12:22 GMT+09:00 Kazuho Oku : > > > 2018-06-22 11:54 GMT+09:00 Nick Banks : > >> Hi Kazuho, >> >> >> >> Thanks for sharing your numbers as well! I'm bit confused where you say >> you can reduce the 10% overhead to 2% to 4%. How do you plan on doing th= at? >> > > As stated in my previous mail, the 10% of overhead consists of three > parts, each consuming comparable number of CPU cycles. The two among the > three is related to the abstraction layer and how CTR is implemented, whi= le > the other one is the core AES-ECB operation cost. > > It should be able to remove the costly abstraction layer. > > It should also be possible to remove the overhead of CTR, since in PNE, w= e > need to XOR at most 4 octets (applying XOR is the only difference between > CTR and ECB). That cost should be something that should be possible to be > nullified. > > Considering these aspects, and by looking at the numbers on the OpenSSL > source code (as well as considering the overhead of GCM), my expectation > goes to 2% to 4%. > Just did some experiments and it seems that the expectation was correct. The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by doing the following: * remove the overhead of CTR abstraction (i.e. use the ECB backend and do XOR by ourselves) * remove the overhead of the abstraction layer (i.e. call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calling EVP_EncryptUpdate) Of course the changes are specific to OpenSSL, but I would expect that you can expect similar numbers assuming that you have access to an optimized AES implementation. > > >> >> Sent from my Windows 10 phone >> >> [HxS - 15254 - 16.0.10228.20075] >> >> >> ------------------------------ >> *From:* Kazuho Oku >> *Sent:* Thursday, June 21, 2018 7:21:17 PM >> *To:* Nick Banks >> *Cc:* quic@ietf.org >> *Subject:* Re: Packet Number Encryption Performance >> >> Hi Nick, >> >> Thank you for bringing the numbers to the list. >> >> I have just run a small benchmark using Quicly, and I see comparable >> numbers. >> >> To be precise, I see 10.0% increase of CPU cycles when encrypting a >> Initial packet of 1,280 octets. I expect that we will see similar number= s >> on other QUIC stacks that also use picotls (with OpenSSL as a backend). >> Note that the number is only comparing the cost of encryption, the overh= ead >> ratio will be much smaller if we look at the total number of CPU cycles >> spent by a QUIC stack as a whole. >> >> Looking at the profile, the overhead consists of three operations that >> each consumes comparable CPU cycles: core AES operation (using AES-NI), = CTR >> operation overhead, CTR initialization. Note that picotls at the moment >> provides access to CTR crypto beneath the AEAD interface, which is to be >> used by the QUIC stacks. >> >> I would assume that we can cut down the overhead to somewhere between 2% >> to 4%, but it might be hard to go down to somewhere near 1%, because we >> cannot parallelize the AES operation of PNE with that of AEAD (see >> https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypt >> o/aes/asm/aesni-x86_64.pl#L24-L39 >> >> about the impact of parallelization). >> >> I do not think that 2% to 4% of additional overhead to the crypto is an >> issue for QUIC/HTTP, but current overhead of 10% is something that we mi= ght >> want to decrease. I am glad to be able to learn that now. >> >> >> 2018-06-22 5:48 GMT+09:00 Nick Banks > .ietf.org>: >> >>> Hello QUIC WG, >>> >>> >>> >>> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decide= d >>> to get some performance numbers to see what the overhead of PNE was. I >>> figured the rest of the WG might be interested. >>> >>> >>> >>> My test just encrypts the same buffer (size dependent on the test case) >>> 10,000,000 times and measured the time it took. The test then did the s= ame >>> thing, but also encrypted the packet number as well. I ran all that 10 >>> times in total. I then collected the best times for each category to >>> produce the following graphs and tables (full excel doc attached): >>> >>> >>> >>> >>> >>> *Time (ms)* >>> >>> *Rate (Mbps)* >>> >>> *Bytes* >>> >>> *NO PNE* >>> >>> *PNE* >>> >>> *PNE Overhead* >>> >>> *No PNE* >>> >>> *PNE* >>> >>> *4* >>> >>> 2284.671 >>> >>> 3027.657 >>> >>> 33% >>> >>> 140.064 >>> >>> 105.692 >>> >>> *16* >>> >>> 2102.402 >>> >>> 2828.204 >>> >>> 35% >>> >>> 608.827 >>> >>> 452.584 >>> >>> *64* >>> >>> 2198.883 >>> >>> 2907.577 >>> >>> 32% >>> >>> 2328.45 >>> >>> 1760.92 >>> >>> *256* >>> >>> 2758.3 >>> >>> 3490.28 >>> >>> 27% >>> >>> 7424.86 >>> >>> 5867.72 >>> >>> *600* >>> >>> 4669.283 >>> >>> 5424.539 >>> >>> 16% >>> >>> 10280 >>> >>> 8848.68 >>> >>> *1000* >>> >>> 6130.139 >>> >>> 6907.805 >>> >>> 13% >>> >>> 13050.3 >>> >>> 11581.1 >>> >>> *1200* >>> >>> 6458.679 >>> >>> 7229.672 >>> >>> 12% >>> >>> 14863.7 >>> >>> 13278.6 >>> >>> *1450* >>> >>> 7876.312 >>> >>> 8670.16 >>> >>> 10% >>> >>> 14727.7 >>> >>> 13379.2 >>> >>> >>> >>> I used a server grade lab machine I had at my disposal, running the >>> latest Windows 10 Server DataCenter build. Again, these numbers are for >>> crypto only. No QUIC or UDP is included. >>> >>> >>> >>> Thanks, >>> >>> - Nick >>> >>> >>> >> >> >> >> -- >> Kazuho Oku >> > > > > -- > Kazuho Oku > --=20 Kazuho Oku --0000000000002bc630056f355e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:


2018-06-22 11= :54 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?


=
As stated in my previous mail, the 10% of overhead consists of three p= arts, each consuming comparable number of CPU cycles. The two among the thr= ee is related to the abstraction layer and how CTR is implemented, while th= e other one is the core AES-ECB operation cost.

It= should be able to remove the costly abstraction layer.

It should also be possible to remove the overhead of CTR, since in PN= E, we need to XOR at most 4 octets (applying XOR is the only difference bet= ween CTR and ECB). That cost should be something that should be possible to= be nullified.

Considering these aspects, and by l= ooking at the numbers on the OpenSSL source code (as well as considering th= e overhead of GCM), my expectation goes to 2% to 4%.

Just did some experiments and it seems th= at the expectation was correct.

The benchmarks tel= l me that the overhead goes down from 10.0% to 3.8%, by doing the following= :

* remove the overhead of CTR abstraction (i.e. u= se the ECB backend and do XOR by ourselves)
* remove the overhead= of the abstraction layer (i.e. call the method returned by EVP_CIPHER_meth= _get_do_cipher instead of calling EVP_EncryptUpdate)

Of course the changes are specific to OpenSSL, but I would expect that y= ou can expect similar numbers assuming that you have access to an optimized= AES implementation.
=C2=A0
<= div>

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@ietf.org=
Subject: Re: Packet Number Encryption Performance
=C2=A0
Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable n= umbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a In= itial packet of 1,280 octets. I expect that we will see similar numbers on = other QUIC stacks that also use picotls (with OpenSSL as a backend). Note t= hat the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look= at the total number of CPU cycles spent by a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that= each consumes comparable CPU cycles: core AES operation (using AES-NI), CT= R operation overhead, CTR initialization. Note that picotls at the moment p= rovides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between = 2% to 4%, but it might be hard to go down to somewhere near 1%, because we = cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

I do not think that 2% to 4% of additional overhead to the crypto is a= n issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

=

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0




--
Kazuho Oku



--
Kazuho Oku
--0000000000002bc630056f355e97-- --0000000000002bc632056f355e98 Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 876ba58c1de1a059_0.1 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --0000000000002bc632056f355e98-- From nobody Fri Jun 22 04:45:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82FC130E42 for ; Fri, 22 Jun 2018 04:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.52 X-Spam-Level: X-Spam-Status: No, score=-15.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 6CVxEX0ITNXB for ; Fri, 22 Jun 2018 04:45:33 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 F2A8B130E3D for ; Fri, 22 Jun 2018 04:45:32 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id n23-v6so2431145ybg.1 for ; Fri, 22 Jun 2018 04:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lzBpbuHtXPHdepr1/4yhD6deVWsxH29iAa+har7xM60=; b=ekmpvwg3JfD2OYSwZk+L3xlMjFLMVlDS/1vTYy8OB12CR92sFVI+xPh/yYMqeID+GW FdNi5UupdFbyhYX64HI/VOj0PoYXFgTsyaiKdY6Pp2tANXQ+QQfgZi9nuVybr6hdAdBr Z7qYlGoz04l3x6tY5PCa6f3HwxXkQYxIOKAj3zeZHiF1jCLB/NBQMq7rq9SnOjBwGpGa 64rPcZKXsgj65uBhqaBD5ykNRFWEKp+7DkOCgd4QLL4bkDce+4hN+CxSdWJrMMh3e3+i WMo8vJxiubZc+WM/G4Q4ph/sL/9AwcGYAn8KlGZt3QGoXxtsEIJOJF30GUs6HFr4R8If N4WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lzBpbuHtXPHdepr1/4yhD6deVWsxH29iAa+har7xM60=; b=Ai6s8q3+mZo55UQjtdmPyfSldZr1UxFSMxddu6eOCZ5mgPpV3CQBFXA6mSmulXTfuC 2zCbO0yKWfRS/Pc6Vyo0XzB8I1/m5i881+pCRRnmpxV5uNzbLge/FoczjTzS90HqB9Oe 9tGqY4DQfnrt41s81LHIK1BvdOZQ3g7C3YiKwlRqAGZeFoyVAJNffVydl8f3/qbechAz CfGWKRul3nNANeFszhQOgaUo5O7EPaxNvvIHawZNSZvCJ6f3wBAXSmxYS3IGhD2LqB/b c4onTj98KT27DNMDfHSsayOg+uV0iAzSYpN0SrlckqoYxM9v9CcCom3kMrTzdewYAkIr KvFw== X-Gm-Message-State: APt69E0H8ScCGU7b7jfu8wV7NSF/LqjeKYGYMus9bdrsGAGk1DJ2QykH N0y0Ak0S1rpORvLICEhDOpXGyF07G4ki5PVoW8w8UQ== X-Google-Smtp-Source: ADUXVKJ/5WFyLZzAM4JcmO03sfc4u2XqE3+bdh9EjqK16elCeeXGNYVco3MpU/V1RAOkdupeHNmIKnmeKwA7dQSV0I4= X-Received: by 2002:a25:57d7:: with SMTP id l206-v6mr612765ybb.206.1529667931687; Fri, 22 Jun 2018 04:45:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 22 Jun 2018 07:45:20 -0400 Message-ID: Subject: Re: Packet Number Encryption Performance To: Kazuho Oku Cc: Nick Banks , IETF QUIC WG Content-Type: multipart/related; boundary="000000000000b26752056f3991da" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 11:45:36 -0000 --000000000000b26752056f3991da Content-Type: multipart/alternative; boundary="000000000000b26750056f3991d9" --000000000000b26750056f3991d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for digging into the details of this, Kazuho. <4% increase in crypto cost is a bit more than I originally expected(~2%), but crypto is less than 10% of my CPU usage, so it's still less than 0.5% total, which is acceptable to me. On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: > > > 2018-06-22 12:22 GMT+09:00 Kazuho Oku : > >> >> >> 2018-06-22 11:54 GMT+09:00 Nick Banks : >> >>> Hi Kazuho, >>> >>> >>> >>> Thanks for sharing your numbers as well! I'm bit confused where you say >>> you can reduce the 10% overhead to 2% to 4%. How do you plan on doing t= hat? >>> >> >> As stated in my previous mail, the 10% of overhead consists of three >> parts, each consuming comparable number of CPU cycles. The two among the >> three is related to the abstraction layer and how CTR is implemented, wh= ile >> the other one is the core AES-ECB operation cost. >> >> It should be able to remove the costly abstraction layer. >> >> It should also be possible to remove the overhead of CTR, since in PNE, >> we need to XOR at most 4 octets (applying XOR is the only difference >> between CTR and ECB). That cost should be something that should be possi= ble >> to be nullified. >> >> Considering these aspects, and by looking at the numbers on the OpenSSL >> source code (as well as considering the overhead of GCM), my expectation >> goes to 2% to 4%. >> > > Just did some experiments and it seems that the expectation was correct. > > The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by > doing the following: > > * remove the overhead of CTR abstraction (i.e. use the ECB backend and do > XOR by ourselves) > * remove the overhead of the abstraction layer (i.e. call the method > returned by EVP_CIPHER_meth_get_do_cipher instead of calling > EVP_EncryptUpdate) > > Of course the changes are specific to OpenSSL, but I would expect that yo= u > can expect similar numbers assuming that you have access to an optimized > AES implementation. > > >> >> >>> >>> Sent from my Windows 10 phone >>> >>> [HxS - 15254 - 16.0.10228.20075] >>> >>> >>> ------------------------------ >>> *From:* Kazuho Oku >>> *Sent:* Thursday, June 21, 2018 7:21:17 PM >>> *To:* Nick Banks >>> *Cc:* quic@ietf.org >>> *Subject:* Re: Packet Number Encryption Performance >>> >>> Hi Nick, >>> >>> Thank you for bringing the numbers to the list. >>> >>> I have just run a small benchmark using Quicly, and I see comparable >>> numbers. >>> >>> To be precise, I see 10.0% increase of CPU cycles when encrypting a >>> Initial packet of 1,280 octets. I expect that we will see similar numbe= rs >>> on other QUIC stacks that also use picotls (with OpenSSL as a backend). >>> Note that the number is only comparing the cost of encryption, the over= head >>> ratio will be much smaller if we look at the total number of CPU cycles >>> spent by a QUIC stack as a whole. >>> >>> Looking at the profile, the overhead consists of three operations that >>> each consumes comparable CPU cycles: core AES operation (using AES-NI),= CTR >>> operation overhead, CTR initialization. Note that picotls at the moment >>> provides access to CTR crypto beneath the AEAD interface, which is to b= e >>> used by the QUIC stacks. >>> >>> I would assume that we can cut down the overhead to somewhere between 2= % >>> to 4%, but it might be hard to go down to somewhere near 1%, because we >>> cannot parallelize the AES operation of PNE with that of AEAD (see >>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/a= esni-x86_64.pl#L24-L39 >>> >>> about the impact of parallelization). >>> >>> I do not think that 2% to 4% of additional overhead to the crypto is an >>> issue for QUIC/HTTP, but current overhead of 10% is something that we m= ight >>> want to decrease. I am glad to be able to learn that now. >>> >>> >>> 2018-06-22 5:48 GMT+09:00 Nick Banks < >>> nibanks=3D40microsoft.com@dmarc.ietf.org>: >>> >>>> Hello QUIC WG, >>>> >>>> >>>> >>>> I recently implemented PNE for WinQuic (using bcrypt APIs) and I >>>> decided to get some performance numbers to see what the overhead of PN= E >>>> was. I figured the rest of the WG might be interested. >>>> >>>> >>>> >>>> My test just encrypts the same buffer (size dependent on the test case= ) >>>> 10,000,000 times and measured the time it took. The test then did the = same >>>> thing, but also encrypted the packet number as well. I ran all that 10 >>>> times in total. I then collected the best times for each category to >>>> produce the following graphs and tables (full excel doc attached): >>>> >>>> >>>> >>>> >>>> >>>> *Time (ms)* >>>> >>>> *Rate (Mbps)* >>>> >>>> *Bytes* >>>> >>>> *NO PNE* >>>> >>>> *PNE* >>>> >>>> *PNE Overhead* >>>> >>>> *No PNE* >>>> >>>> *PNE* >>>> >>>> *4* >>>> >>>> 2284.671 >>>> >>>> 3027.657 >>>> >>>> 33% >>>> >>>> 140.064 >>>> >>>> 105.692 >>>> >>>> *16* >>>> >>>> 2102.402 >>>> >>>> 2828.204 >>>> >>>> 35% >>>> >>>> 608.827 >>>> >>>> 452.584 >>>> >>>> *64* >>>> >>>> 2198.883 >>>> >>>> 2907.577 >>>> >>>> 32% >>>> >>>> 2328.45 >>>> >>>> 1760.92 >>>> >>>> *256* >>>> >>>> 2758.3 >>>> >>>> 3490.28 >>>> >>>> 27% >>>> >>>> 7424.86 >>>> >>>> 5867.72 >>>> >>>> *600* >>>> >>>> 4669.283 >>>> >>>> 5424.539 >>>> >>>> 16% >>>> >>>> 10280 >>>> >>>> 8848.68 >>>> >>>> *1000* >>>> >>>> 6130.139 >>>> >>>> 6907.805 >>>> >>>> 13% >>>> >>>> 13050.3 >>>> >>>> 11581.1 >>>> >>>> *1200* >>>> >>>> 6458.679 >>>> >>>> 7229.672 >>>> >>>> 12% >>>> >>>> 14863.7 >>>> >>>> 13278.6 >>>> >>>> *1450* >>>> >>>> 7876.312 >>>> >>>> 8670.16 >>>> >>>> 10% >>>> >>>> 14727.7 >>>> >>>> 13379.2 >>>> >>>> >>>> >>>> I used a server grade lab machine I had at my disposal, running the >>>> latest Windows 10 Server DataCenter build. Again, these numbers are fo= r >>>> crypto only. No QUIC or UDP is included. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> - Nick >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Kazuho Oku >>> >> >> >> >> -- >> Kazuho Oku >> > > > > -- > Kazuho Oku > --000000000000b26750056f3991d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for digging into the details of this, Kazuho.=C2=A0= <4% increase in crypto cost is a bit more than I originally expected(~2= %), but crypto is less than 10% of my CPU usage, so it's still less tha= n 0.5% total, which is acceptable to me.

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com> wrote:


2018-06-22 12:22 GMT+09:00 Kazuho Oku <= span dir=3D"ltr"><kazuhooku@gmail.com>:


2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?


=
As stated in my previous mail, the 10% of overhead consists of three p= arts, each consuming comparable number of CPU cycles. The two among the thr= ee is related to the abstraction layer and how CTR is implemented, while th= e other one is the core AES-ECB operation cost.

It= should be able to remove the costly abstraction layer.

It should also be possible to remove the overhead of CTR, since in PN= E, we need to XOR at most 4 octets (applying XOR is the only difference bet= ween CTR and ECB). That cost should be something that should be possible to= be nullified.

Considering these aspects, and by l= ooking at the numbers on the OpenSSL source code (as well as considering th= e overhead of GCM), my expectation goes to 2% to 4%.




Of course the changes are specific to OpenSSL, but I would expect that y= ou can expect similar numbers assuming that you have access to an optimized= AES implementation.
<= div>

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@ietf.org=
Subject: Re: Packet Number Encryption Performance
=C2=A0
Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable n= umbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a In= itial packet of 1,280 octets. I expect that we will see similar numbers on = other QUIC stacks that also use picotls (with OpenSSL as a backend). Note t= hat the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look= at the total number of CPU cycles spent by a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that= each consumes comparable CPU cycles: core AES operation (using AES-NI), CT= R operation overhead, CTR initialization. Note that picotls at the moment p= rovides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between = 2% to 4%, but it might be hard to go down to somewhere near 1%, because we = cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization).

I do not think that 2% to 4% of additional overhead to the crypto is a= n issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)=

Bytes

NO PNE<= /span>

PNE

PNE Overhead

No PNE<= /span>

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0




--
Kazuho Oku



--
Kazuho Oku



--
Kazuho Oku
--000000000000b26750056f3991d9-- --000000000000b26752056f3991da Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: <876ba58c1de1a059_0.1> X-Attachment-Id: 876ba58c1de1a059_0.1 iVBORw0KGgoAAAANSUhEUgAAA58AAAHOCAYAAAFoW42RAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHIHSURBVHhe7d2NdxxVmuf5/pO2Zmeb6plqTtWs u6cbtruLql0WzeiwZtbV1ByZOSPjplCBy+UqxEsJrbF3j4+bYjxDiSrPImB5X+Nl7OJFLiyD8QtY BrmNMZhCYMuWbGQJycT6F4qbDqUyUxmRETefiPx+zrlWZGRKYeUTNx49GTdu/MmpU6eCDz74gFaS 9if6B+VRmoB2dXVFS0GwevXqaGlRd3d3tFR+peqhs7OzwfDwcBjQkZGRYGxsLHomCBYWFqKlIFi7 dm34VYGemJgIv8afLzIOuSVDQEumZkD7+/vDQ5caiqUje2iZf2cCWjIENCcXZ+aDVeveDO7cdjQ4 dOJCtPaax3d9HNxw177wNWp6nAUCmiEFpt3q/lEkZf2jKOuAZtW7skAPTenc9Fy0ZAsBTajZw+ql J+8Ozm34VvQonTTfT0BXcHpiJugf+qCpQJ5/aFW01D4EtIYkf9xMPXprtGRD3T+K3AfdZVT9O6f5 63T6Nz3Rki0d2UM3/OM7wZ6DX0SPmjO17ZaWc6IPHRHQE59eCgt8p9nfWTnxm3mbf83WU9qANjqM 1vudZ17fEczs3ho9KqbSBLT7vrejpZW533n+9JHwUFomdf8oKsLpszR/zCgPlvWoJIXqoWkDWK1j Arp+/fpoyYY7thwO/6BJopnivmMCqsFTU1NT0aP2SNoLr1w8m7ic6JiAtsvTr52Jlprz1fP9wcKX H0WPkuuYgMbHto6Pj+f6R1HSnphlUU8PzdDo2GS0tLK8SoqOCejcXH6fijTTI78+eSBseeuYgG7e vDla8mv2yK5oyY+OCWjWGn16084Pujs2oK38UVTvEDv/2fFoqX3ooQnVCuZk/59HS+1HQBPQWNO4 dh5a6yGgTUpSkrQTAS2Zjg1omj+KinB+kR66Al3HIRbzZS0EtAH3F21RgikEtI6i9UyHgDZQtGBK RwZ0pdNnOtQWMZhCD60yN3+lsMEUAhqjnjm56broUTER0Jgi90yHgEZO3WvnA/ZWdHRA3SiGsyXo mQ49FIXRdECTfq7b29sb7N27N3rUvKTbSfp6TdYoSf9vaT7XliTbcZNNtvIe0ENLhoCWTKkDqjlz HR369OmXxOfRFbfe2rU9adBDS4aAlgwBLZnSBfT7974VflU+VOmkD0Z0iWT8Qqy4gYGBUuROhx5a MgS0ZMKA0srT/iQKLEqiFAGt/qAgrt4fQ1KWm+/ElSqgg4OD4df4xB/6FEh3WnIfyrsgal18uSw4 5JYMAS2ZmgF1h6605wDRPvRQQ1R2tIqAGkJADfvBhv3hGOYXRv4YrblGd1rShMx6Xk3LmtOQgBrz 5tGz0VI6uQV069bFWZ35o2hlSSZeXgk9tI10qMwaAfVMN+Rp1uSGbwUze7ZHj5oTD2jaqQ0I6Aqa 7YlZzC1BD82B/ipNcrfBi79bFy21LveAdsofRUnz4fnBG6OlbNFDU0rzB42P6XoIaJPS/kXq+1pY AlrHxh1jwbFT09Gj5rX7YmYCGpOmF1q7Gj23gLo/hiz/UXTbg++EX2/8ydLZPxvR3BCWb07XUT1U d9q9ffDd6FFzvnr54eDyaHH+Us88oNYGTZXhMJpE5gFtNELOh5s3jkZLzSvDrCxOKQ65ndYLG8kt oLrdpOT1R9Ero4tDKps1d2xPcHnfE9Gj8ipcD/3+PYtXhjWjrL2wkcwD2t3dHS1lS9OwNnNo7cQg xmUeUDe6PEsr/aHT6UGMK+wfRbr3NZYr3B9F9MbGCtNDJ/uvDybvvz56hHoKe8hFbaYDyuE1OVMB 7Xv0/Whp8UNxJJdbQJPOCpl2RACWIoeWDAEtGQJaMm0NKHkze7kHtN4fRQQzHxxyS4aAloz3gKYZ 84PmeQ3o3/U1P9oA6XgN6M/ufypaQl7IoVimqYCmPdHt+65Czdi8eXPud3zSUJ6kd5ZKO6ig+vX0 0JIhoCVT+oDqUL5///7o0WIaiB8K3SGrLHPm0kNLhoCWDAEtmdIGVHdUUulQ685J56MhpSvddamI 6KElQ0BLhltlAYbRQQHD6KCGuPNN7kZfuiW8CqqhoaHwg0k1PV6zZk3lteJuCa/nqs/v6Ll4UabH +rBT1+rHJzFy20pzHgr5oYN2iPjd/VAcdFDAsKY7aF9fX/g5tvuTyf0pFP/zCUC2yKAdgjgnZ+E9 o4N2COKcHB0U3hDn5Oig8KaocdZNQDTzg+6pFJfkri5p1XrPdJftG/5hn7fZKOigHaIIcX76tTOm 5gaw8J413UHjn9ZqWSfP3TLss9hBlYXOTZf7fmWtIoN2iHbH+Ya79gWPPHUiepSfr08eCG9gP73j R5Wm+Zpdi69X02vVdF88fa+a0+g9m97x99FSvuigHcJXnJUVs6zPLmy5KexYV86fidYsmtz07Wgp Pxb6Bh20Q2QZ5zu2HM78z9MrF8+auzMBHRTeJImz++Q06S2Uk1Bn/OZy8jvd+1SoDqoPg9R0JQQf EhVPdZzV+dQJT3x6KVqTj0vPbDSXGZtVqA6KYtEpC3XAbc+eDB/nGef5z46HnbDInbEWOihaog6o 1oxW43zpybvDzvf1hyPRmvKjg6Kh0bHJsANmcXpipTjPHdsTdsCLv1sXrQEdFMHazYufiLo/RfMy fng07IDnH1oVrcFKCtVBqz8Y4kOi5r0w8sewEz720qloTT6mHr017ISqCatxIE6ODFoiSerBtOZP Hwk7oOrBpIhzcqY7qG4yUpYZ9LPwyuiElyw4e/C5sBNe3vdEtCYbdNDkTHdQTeEdnzmuE2hkjDrh wM7FWfLyomFrYSZ8ZmM49lPLeaODJme6g5a9tlRHzHvwtjqelQ9l6KDJme6gtQwODoYjiTR5WE9P TziBmJat0zWGeX1KqtMS6ojfzNt+H+igyRWugxaB/kxd+8jhsGbMihspM/P6jmhN8dBBkzPdQfUn bpH+zM3iE1SNklFHrHWaoujooMmZ7qBF8ObRs8Hn52ajR8lM9l+f6nRFUdFBk6ODppQ0W+qiX31i 2snooMkVroPqgyHdZKddHxI10zEn7/9uMFmAD218o4MmV7gO2i4rdUzVjp2eIVdCB02ODrqCvkff j5aWW/jyo2Bm99boEVZCB02ODtpAvflufIy6KSM6aHJ00Bpq/TmrcanUlK2hgyZX2A6ax4dEmqKj GtkyO3TQ5ArbQbNWPXscHTN7dNDkOr6Dan7VODpmfuigyXV0B9356ifREh3TBzpoch3ZQeMfAtEx /aGDJle4DqqLuCXNh0TxmQjomP7RQZMrXAdNy93zUR2TztkedNDkSt9B5+avhF/plO1HB02u1B1U p07omHbQQZMrbQf94N7/kc5pDB00uVJ2UHXMufd2R48AtMLLh0QA0sm0g7pTL3lZWFgIv05NTYUT a/f29oaP8xI/nZQH/T55X/i+d+/e8DYdPt6zNKffktD/38c+0N/fHy21fx8ggwKG0UELSlPPqMUp qzhJj/jVr9ccyGg/OmiHinfmWlZ6Hn7QQQHD6KCAYXRQwDA6qGHudohx69evD0+d6NaQ8Y/mVTPq fq6NbtehQSTx21ok+V60Bx0UMIwOChgWdlAajWavHT9+/N0/iToqAGPUSemggFF0UMAwOqgxOs0x PDwcPWqOTrmkPT3S19cXLcEiOqgxOq+pS8PUdJ4zzl1m5bjB7eqgjs5nagC9Oqx+RrzjqjPqcfzn Vq9z3w8b6KDGuE6n6U3VIXW9o6N18ce1OqjoKhSXhbu7u8OvLlNqMEKc1ldnbK5isYMO2iGUTaW6 g8I2OihgGB0UMIwOChjWdAd1nyDqEz/3oUR8GUD2UmVQfernPvmLLwPIVuZ/4pJRk1MQkEynvGd0 UAPooMnRQVOigyZHB02ODpoSHTQ5OmhydNCU6KDJ0UGTo4OmRAdNjg6azNOvnQknUnNt27Mng0Mn LkTP1qfX7Dn4RfD4ro+DO7cdXfIz1LROzzXzs3yhgxpAB21MN4JWBzp2ajpaEwR/85N90ZJf6rxq rlPnjQ5qAB10uUeeOhHccFf9Ttgp7xkd1AA66DXKSpoLeCV00Dp0YW+jkUR00OQ6vYNenJlP/Oci HbTK2rVrwyvt1UHdtYUai+uWHTpocp3aQV8Y+WPw/Xveih4lQwdNiQ6aXKd10Js3jgaPvXQqepQO HTQlOmhynbCzjY5NZvqpZ733TPedmXl9RzCzZ3swveNHYTv/0KrwnjRqbp1rep1rX588UGkruTh0 R7SULzqoAWXtoHPzV8JOqT9ls6LO4zrb5C//rKnOlIdw+w98L3qUHzqoAWXqoKvWvRF2Sg0myILr kJee2RitWXT2F/8iWio3OqgBRe+gfY++H3ZKfRqrP2V3v31t5sE0rlw8G3bKRtmxrH91VKODGlC0 nU0jetQh+4ey/X+fH7xxWaashw6aEh00uSLsbBrVk+WHPM4383NhtkyKDpoSHTQ5izvbxh1jYYfU n6x5uPTk3cGFLTdFj5Kjg9ahmc0ZSZQtCzvbzlc/CTukrubIy5XzZ8JsqazZKjpoFTeSKD56iJFE 2WjHzvbm0bNhh1SmzJs65eV9T0SPskEHTYkOmpyPne3zc7Nhh+y+7+1oTT70CezcsT1hp9TJ/7zQ QVOigyaX187mPtjRgIG8Tf+mJ+yUruWNDpoSHTS5rHY2dz4yfmFzXmYPPhd2xK9efjha4xcdNCU6 aHJpdzb3wY6+5s19wDO17ZZoTXvRQVOigybX7M7m6sg7thyO1uTL15+radBBU6KDJtdoZ7vtwXfC TqlhdHlTdlSHXPjyo2iNXXTQlOigycV3Nnf6o9XrJZvhPtjRp65FQwdNiQ6anDqkWt6+er4/7JCX R4t/sys6aAOMJGqNu3hZ87lKXlNIanCAOmS7PmnNEx20CiOJWqO5d+plyax2NnftpP50LTs6aEp0 0EVJBpun3dnclSCT/ddHazoHHTSlTu2grQw2T7KzTT16a9gpdV6yk9FBr9Kfr1NTU9Gj5nRKB3UX LWv0Tqsa7WyzR3aFHXJm99ZoDYQOepVqzKTK3EE1XWS9OrIV1Tub/mRVp0R9dNCr1EGTdtIydVB3 TjLLWelqOXu1M4ZZ8vUd0RqshA4amZ2djZaaU/QO6gac530FyMXfrQs7pfugZ+693dEzaAYdNKUi dlDdSSuPP12rqSPqQ55qnbKzZYkOetX4+Hi01LyidFDdyDXvTukGCqw0lI4Omhwd9KpaHXRhYaHQ I4nUKV8ZbW3e1kY0daQ6ZRJ00OTooA309PSEnXdubq6y7FjsoGlub9csd52kxrmmRQdNjg6akqUO mlfH1Ket6pRZXZZFB02ODpqShQ56++C7mXdMd61kHuigydFBryriQAV1zKw6p25bp5Y3OmhyHd9B NcyvSB1Uf85mMcerRvHogx6f6KDJdXwHlTSdrR0dNO1t1B3dsCevP1+bQQdNjg6aku8OmvbPWd2J uZ2dMo4OmlzHd9Dt27cvOb/ZLJ8dVB8GJaVOaW3MKx00uY7voGn56qBJ7uCc9hZ3vtBBk6ODNtDO kUQaxH7i00vRo8bcPUKso4MmRwetQ0P92jWSqNnOqU7p4/RIVuigydFBU8qrgzbTOd2fskXImnF0 0OTooCnl1UFX6pxF65RxdNDk6KAp5dFBG03Epbtsad6eIqODJkcHTSnrDtrohrNFzppxdNDk6KAp ZdlB6w1CUK1Za2aCoqKDJkcHTSmrDlqvc1568u5oqTzooMnRQVPKooPWGyFUlj9pq9FBk6ODptRq B9VNamspa+cUOmhydNA6xsbGch1JdOjEhWjpGt+Xf/lGB02ODlqHOmheI4lqXTZWxlvnVaODJkcH TSltB63+UOiby9PB/Okj0aNyo4MmRwdNKU0HHdi5dHpPzZTXSXfvooMmRwdNKU0Hjd9mQR1T2bOT 0EGTo4OmlLSD9g9de6M7sXMKHTQ5OmhKSTpovO7s1M4pdNDk6KApNdtBb7hrX7TU2Z1T6KDJ0UFT aqaDxu+3qY555eLZ6FFnooMmRwdNaaUOumrdG5U/bcPO2UGf1tZDB02ODlqHBie0MpLo1y9+FOx+ e4LOGUMHTY4O2kDakUTu2k4651J00OTooCnV66Duz9qzG4o3Z1De6KDJ0UFTqtVBtz17MvyqWyx8 /eFIMHvoxfAxFtFBk6ODplSrg2rCr1ZucFt2dNDk6KApVXdQ/Wlb9Em98kYHTY4OmlK8g+45+AUf BjWBDpocHTSleAd97KVTwdcnD0SPUA8dNDk6aEqug/63n3YHR+/5q3AZjdFBk6ODpqQOqnmFdCpl 8oHvRWvRCB00OTpok6oHKqx/4GXOcyZEB02ODtqk6qF+qjnpoEA2Wu6gAPJDBwUMK2QH1QdR8dM5 eaie/zcP/f3XRlflua3Z2dnc3zP9LvHfIa/fR7+LlGEf0Hu20j6QeQfVFS550i8wMTER9Pb2BlNT U9Ha7FXP/5sH/fyRkZGaVwVlLe/3TDta/P3K6/dRBy3LPuDes0b7AH/iAobRQQHD6KCAYXTQglpY WFhWF8Uf63np6+urWacNDQ0F69evjx5dez1soYMWlOtQ+mBBHzbowxN1UNcZ4x2u1qeQ6pxq6qh6 Xq93n4rm8YEI0qGDdqh4J1Qnr0YntYEOChhGBwUMo4MChtFBAcPooIBhdFDAMDqocf/mlwfCeYXj dO4yPvhAyzot4gZda3BCLfOfHQ/OP/CvokeLmv1etAcd1DjNK/yDDfujR9eoY3V1dVWW3XlLfXXr q03e9+fLZrto9nvRHnRQwDA6KGAYHRQwjA4KGBZ2UP0DAACaRwIFACAFEigAACmQQAEASIEECtSh 2z642zBUXz3UyOrVq6Ol2uI/19FsinncJqOW7u7uaAlAK0igQB1KdLryTq06uWkK4cHBwfD+TdVT Duv1LonqeV1mKy5xNptA3c9otK14MnQ/I/7z48ncvdZ91c/Vpb/VP9c9X719AEuRQIE6aiW6tWvX hl9Vkbqk4i5v1zpxicetd1/18zT3f61E2EwCleptVVeT+v/F58PQ611SdYl8zZo14VeXQMX9XP0/ 3OtIoEBjJFCgRKoTarwCBZAtEigAACmQQAEASIEECgBACrkk0P7+/iVfxQ2a0Nd6ywAAFEWuCbSn pyccwadRfVrWDXk0IrDeci0aFQjkrUyfwpTpdykb9rNy0Xtg+iNcEih84MAGH9jPykXvAQkUHY8D G3xgPysXvQckUHQ8Dmzwgf2sXPQekEDR8TiwwQf2s3LRe0ACRcfjwAYf/uMjB4L1296LHi068eml YM/BL4LHd30c3LntaNi+f89bwap1b6Zu7uf0D30Q/ly10bHJ4NCJC8Hc/JVoy61hPyOBAiESKLLy yuhEcNuD71SS2Q137Qu2PXsyuPX+tyvrfrhhf/Rqm05PzITJduernyxJ7O7/32xz36e2/fmTV9e9 Ea7Xzy8DEihwFQkUSZybnqskSVWLqiCb0cn7mRKyS6y/P/xltLbY9B6QQNHxOvnAhsaOnZquHPgf e+lUtDYd9rNy0XuQaQLt7e1dMgPRCy+8EH5lIgVYxoENzsYdY2Gy7Hv0/WhNdtjPykXvQeYVqBKo ZiDSPQbVdC/BetP3xZdrIYHCBw5snUkDeFx1qUE2eWM/Kxe9B3yEi47Hga0zDOwcD5PlHVsOR2v8 Yj8rF70HJFB0PA5s5aORr0qWGuRjZdQn+1m56D0ggaLjcWArrosz82FFqWTZfd/bwefnZqNn7Pl8 +78Lpnf8ffD1yQPBzJ7tV5d/FJzb8K26Tc+r6bWu6Xur25XzZ6ItLFXrtfEW/7muffV8f2W78Vbr /5ekTcaWL2y9KfofFhsJFLiKBGqTLhe5ffDdsIJUotTEAO6cpa5RtObyvieCyf7rK4li6tFbg9mD z4XPTW27pbJ+8oHvheuKLM1+Nnnfd4LJTd+OHhUfCRS4igRqx9OvnakkyXizYv6z48H5h1aFifD8 4I3B3LE90TMrYz8rF70HJFB0PA5sfr0w8sdwhh4lRp2j1Ow9Fs28vmOxYtx0XaJEWQ/7WbnoPSCB ouNxYMuWPm595KkTlepR5ybfPHo2etYmffzqkuX86SPR2myxn5WL3gMSKDoeB7bklBB1ftIlSZ2f tDyAJ07VpDsf6c5R+sB+Vi56DzJNoPGZiF588cVgYmIimJqaYiYimMaBbbnqKvLmjaNmP2ptRAnS JcvLo7UnbPGF/axc9B5kXoHGp/Krnmmoevah6uerkUDhQ6ce2JQQlRhdktREAxr5WkTfzM8FF3+3 rpIsv/5wJHrGjk7dz8pK7wEf4aLjlfXAponQNaerS5C6XtLHlHV5UqK89MzGSqLUtYtFUdb9rFPp PSCBouMV9WCgmyPrDiEuQWpk6/anDkXPFpsG9ZyNkqRaFqNg240EWi4kUOAqy31A95rUKFaXJFca rFOkA9vM7q2VBKlrK2eP7IqeWaSPYfXc7KEXozXFVqakU6bfJS29ByRQdLx29oFal3w0e4PmWiz1 ZyXA+Aw807/pCSci6FRlSjpl+l3S0ntAAkXHy7sP6JKPeBWZ52Adn/1Z5yO/evnhSoLUNHbtHulq WZmSTpl+l7T0HpBA0fGy6AOam9UlSM2uo9l22iHr/qzLQNzUdWqabPzKRduTIlhVpqRTpt8lLb0H JFB0vGb6gAbsxD9q1SQCFke0Ju3PuiuHJj13CVJ33tA6ZK9MSadMv0taeg9IoOh4//GRA8H6be+F y+4+ki5J6lKQIqnuzwtffhRcevLuSoK8sOWmZYN14AcJtFwyT6DxmYiamX2ImYjQDvEk+dc/WZzU XO2HG/ZHryiW+GjWcz//03ASdNhDAi2XzBOouARab8ahesu1KIHq/0ejJWnvHTsebPpP71QS4+r7 3wpe/P17NV9bhHbq5X8MvnjwLytJ8rP/0hucOPhmzdfSaLTkLQ19Hx/hopA0svW2B68lyVYmM293 H7hy/syyj1nTThxguT93ujLFhv0sZQLt6uqqNE0UnycSaOfyOZm5j4OBLu/QrbJcktTHrnngwGZX mWLDfpYygW7dujVYWFgIE2jeSKDlVj2ZuRJmOyYzz+JgEF4T+Xx/JlVkKziw2VWm2LCfpUygPpFA i02XfsQH7LQ6y05emu0Duv4x/lGrxZl1OLDZVabYsJ+lTKCDg4PhV1WhfIQLVYwbd4xVkqTu/nF6 YiZ6thjifeCby9NL7vahJKlLQYqCA5tdZYoN+1nKBOoTCdSO+F0/dH3kiU8vRc8Uky71cEky3oqO A5tdJNBySZVAXVIbGxsLv+aJBOqXPnKNV5Ptmo4uK5owQPOzKjFqAE+9eVo5sMEH9rNy0XuQKIGu WbOGUbgl8fiujyuJUtVlUekcZPyOH2lGt3Jggw/sZ+Wi9yD1R7hDQ0MNE6ieV5KdnZ0NE6EbtVtv uRYSaOtUVd6x5XCYKPVVj4umevCOlrOc0JwDG3xgPysXvQe5VaBKoGpKoPVmH4ov16IEqv8frfm2 4R8XJxf4t7/4QzgjT63XWG2fDF+7DOSLgRuDf3rzxZqvo9FotCxbGvq+xBVoswk0C1SgjWmyAd06 SwlTM/MUga6NdLfH0nlJ3S6r3dJ2IIvK9LuUDftZueg9SP0Rrg8k0OXcxAOHTlyI1tijSQXil4Jo Weus4sAGH9jPykXvQeIEqutAd+7cyXWgnqxa90aYMNWs0QCe84M3LlaT/dcX9jZZHNjgA/tZueg9 SJVARbchI4HmQ5MRKGFqQgLdtFnLu9/OZx7YZsQ/dtXXst1wmQMbfGA/Kxe9B3yEa4S7rKSds/ho ZKvmcHWJ0to0dXnhwAYf2M/KRe9B4gS6fv36cBIFKtDWaRCQkubTr52J1vijSQXcOcqZPdujtZ2J Axt8YD8rF70HiRKoEppG3wqjcNPTvSt9ntN0A3p0vjLL6yfLggMbfGA/Kxe9B4kSKDMRteaGu/YF AzvHo0f50Ew87iNYkmVzOLDBB/azctF7kNs5UH3EqyQ7Pj6+pHKtt1xLGRKoZv5RtanBQFm7cv5M 5SbN7bj3ZFlwYIMP7GflovcgtwTqRus2mn0ovlyLEqj+f0VsmgVIifO/jbxf8/k07aNXnwiT5dlf fif48OjBmq+h0Wg0WrKWhr4vtwSahSJWoK7izOJ2X7oPpRKma8iH5T6QVJl+l7JhPysXvQck0Ixk lTind/woTJZlu9bSMg5s8IH9rFz0HpBAM9DqOU6dx1SzPN1dmXFggw/sZ+Wi94AE2oLu+94OZw1K Q6NklTTRfhzY4AP7WbnoPSCBprDz1U/CS1KSmv5NT/jx7DeXp6M1sIADG3xgPysXvQck0AQ+Pzcb flybhC4vUdKcP30kWgNrOLDBB/azctF7QAJtkhLnnoNfRI9WpruTaF5Z2MeBDT6wn5WL3gMS6Ar0 ca1uWt0Md9kJ1WaxcGCDD+xn5aL3INcEqqn/RImwiDMRqerU5Skrufi7dWHFiWLiwAYf2M/KRe9B bglUswvpri1u2X2tt1xLuxLobQ++09SctUqaGhiEYuPABh/Yz8pF7wEf4cacm55rapCQPqadPfhc 9AhFx4ENPrCflYveAxJoROc5XxmdiB4tp0tPlDg1gTvKhQMbfGA/Kxe9Bx2fQDX1XqOqUwmTazfL jQMbfGA/Kxe9Bx2dQJU4D524ED1aisTZOTiwwQf2s3LRe9CRCfSFkT/WnUmIxNl5OLDBB/azctF7 0HEJVFWnZhSqRuLsXBzY4AP7WbnoPeiYBHrntqPB7YPvRo+uuXLxLImzw3Fggw/sZ+Wi96DUCVSX pax+8J2ag4SUMJU4GVULDmzwgf2sXPQe5JZAh4aGVpx9KL5cS6sJVInTNYfEiWoc2OAD+1m56D3I tQLdvHlz+LXe7EPx5VrSJlDdp/ORp05EjxaROFEPBzb4wH5WLnoPSvURbvXtxnR+U3dE4RwnGuHA Bh/Yz8pF70FpEmj1TEKX9z0RJk7XgHo4sMEH9rNy0XtQ+ASqu6XEq85Lz2wMJjddFz0CVsaBDT6w n5WL3oNCJ1Cd57xjy+Fweeb1HSROpMKBDT6wn5WL3oPCJlDNJHTs1HTw9ckDfESLlnBggw/sZ+Wi 96CQCVQf2X4zP8fgIGSCAxt8YD8rF70HhUmgi/fqfCNMnmfv+/Pgq5cfjp4BWsOBDT6wn5WL3oPC JNA3f35rZUTtZwN/G60FWseBDT6wn5WL3gPzCfSeXx8Lbl3/TJg4J+/7TjC56dvRs0A2OLDBB/az ctF70NYEutJMRGc2/Fml6lQD8sCBDT6wn5WL3oO2JtD4fLkAABRF2xMoAABFZDqB6vxn0atT/f/d x9NaHhwcXLZcJGvWrAm/xmNTxDjNzc2F/+fx8fHC/y6i/3NfX19luYj72cLCQuV3qBeTIsVnYGAg mJ1dvHG//s9FPg7EYyNFPg7Ef5dWjwOmE+hK50eLQMFywRF9jS8XieIwNjZWWXZfixgnd9Cq/v8X 8XcR/T46KBR9P+vv7w+/1otJfNm6iYmJSgItw3EgHpuiHwfc79LqccB0AgUAwCoSKAAAKZBAAQBI gQQKGKTBDVNTU9Gj7OhcnH7u+vXrozXJ6P/lzusBnY4ECnikBDYyMhIOMNGgEkcDgJSc3Dotf/nl l5XXKmnpmmk3GMXROjfQIT4Ypbe3d8n3OS5xrl27Nvz64x//OBwQotdt3ry58vPj3+sGjDhpky9Q NiRQwCOXQB03kUj8sobu7u5KBeqSn1vvll0VqETohtu7BKrHbl38+8T9PCVBPeeSb/UlF1p236uf q2X3f3RfgU5HAgUAIAUSKAAAKZBAAQBIgQQKAEAKJFAAAFIggQIAkAIJFMiZrsnUpSv1Jkdw63Up iZZ/+tOfhut1qUm978lCu7YLlAUJFGjCHVsOB6vWvZm4iZt44Le//W2YlNx1lO6azHiycst6rtlE dm7Dt5a1yZ/FH/93seXFJq1uF+h0JFCgBacnZoLHd30cPbJlZs/2YP70kegRgKyRQAEASIEECgBA CiRQAABSqCRQGo1Go9Fozbc/iRIpAABoEskTAICESJ4AACRE8gQAICGSJwAACZE8AQBIiOQJAEBC JE+ghq6urkpr1t69e1NNsh7f1vj4eLQ2X7rLyuzsbPQIQFIkT6CG7u7uaCkIVq9eHS011kzyjP9c p9a6PIyNjXlLzkDZkTyBGmolz+Hh4fCrq0aVjHQPT9FXlzxV1emre35iYqLyvc0kT/0ct81G23Lf F39OtxpTRRl/Pv4zXPJ0lafWVf9etbYPYCmSJ1CDkoZarWSnxCNr1qwJvzpKOvoeV33Gn3c/p9bP q16nn+N+RqNtxavI6p8f/xnutbWSZ/znutfV2j6ApUieQA3VCW1hYSHo6+sLlxsltMnJyUrVVv28 5JU89brp6elKFRn/GW6Z5Alkh+QJ1FCd0Obm5oLBwcFwOf7xpvu4VEkrnqTcY/e8S7zNJNRayavW tuLJU/8//b/cICA9736u+//GPz52yTP+c+O/F8kTaIzkCZREfGBTPAECyB7JEyiB6kqU5Anki+QJ AEBCJE8AABIieQIAkBDJEwCAhEieAAAkRPIEACChTJOnu/Ba1q5du+Qi7fgF5rWWAQAoikyTp2Yw UfJ0X0XXm7mv9ZYBACiSXJKnpicT3eGhXsKMLwMAUCS5VZ6a3UQf47rl3t7eusud4IMPPoiWiq9M vwvsYj+DD2n3MwYMeULyBJJhP4MPJE/jSJ5AMuxn8IHkaRzJE0iG/Qw+kDyNI3kCybCfwQeSp3Ek TyAZ9jP4QPI0juQJJMN+Bh9InsaRPIFk2M/gA8nTOJInkAz7GXwgeRpH8gSSYT+DDyRP40ieQDJl 2s/OTc8Ftw++G5yemInWLDp04kLw+K6Pgzu3Ha20VeveTN20Dfdz9HNd03bUsBzJ0ziSJ5BMGfYz Jaxtz568mtjeWJbobrhrXyXJueQ2N38l+s50jp2arvysePJMkpj1uv6hD8LvGx2bDH9WmZE8jSN5 AskUbT/7/NxsMLBzfFkievq1M0vWWRdPvkr8+h1u3ji65HdYqd324DuVhN336PvBjT/5Q7j+hz/b H23FDpKncSRPIJki7GfxxPj9e94KXhj5Y/TMUqrg9Jrdb09Ea8pNH0+7JOx+d9esIXkaR/IEkrG6 n+189ZNKIlCl2epHrZ1Af1jo/dJXa0iexpE8gWQs7Wc6l+gSgM4HojxInsaRPIFkLOxnSpRKmN33 vb1spCzKgeRpHMkTSKZd+9nFmfkwWSppPvbSqWgtyqrtyXNubi4YGRkJZmdnw8c7d+4MhoeHg4mJ iWBqairo7e2tu9wJSJ5AMr73Mw1uUcJU0yAXdIa2J09RQlTyXFhYCBOjkufevXvD5/S13nInIHkC yfjaz9yIWV2OockM0FlMJc+BgYGgq6srbPUSZny5E5A8gWTy3s/cNZm6FhGdq+3JUx/buoTpqPIU rVtpuexInkAyeexnuqyE85mIa3vyRGMkTyCZLPczXWrizmfuOfhFtBYgeZpH8gSSyWI/U3XJ+Uw0 QvI0juQJJJN2P9P1mG4u1keeOhGtBWojeRpH8gSSSbqfuQFAmgmoDBMafH3yQNhm9mwP21fP9wfT O360rJ3b8K1lbWrbLTVf69qlJ++u/Nx4c9uMt4UvP4r+R+lduXg2/D9l8bOyRvI0juQJJNPMfqaJ 2N25TMsDgFzymP/0veDrD0eCmd1bg6lHb62Z+Fxzic4ltsv7nqiZ3GqZ/+x4zde6Nntk15Kk6Vo8 wbp2YctNNf9/SdrZ2LI1JE/jSJ5AMvX2Mw340b0wlTB182fNCGTNN/NzwczrO8KEWZ08VPVdHh02 WYXlxf3uataQPI0jeQLJ/MdHDgTrt70XLr8yOlFJmLpXpO6daYkqvYu/W7ckSXz18sPB/Okj4fPx 9Z1I1bZ+99lDL0Zr7CB5GkfyBJp3z6+PVT6OVdNEBtYSppKjS4jnB28MZg8+Fz2znOXk0elInsaR PIHGNMin79H3lyRNtR9u2B+9ov3iCVMDeFB8JE/jSJ7Acm5eWTWNko1PYPA3P9kX3Hi1tZvOT5Iw y4vkaRzJE1isLjfuGKskTN0vs97kBe3czzQ6Vh/FKmFeemZjtBZlRPI0juSJTuVm+XHVpQb/NKMd +5lGyCphTm66rjLYB+VG8jSO5IlO8ebRs5XJ19U0y48mZE/K1372zeVpqswORvI0juSJsqr+KPaO LYfDidhblfd+ptGx7lymRsOiM5E8jSN5oixURW579mQlWeqjWM30k7W89rPp3/SECVMz/AAkT+NI nigyjYp1kxSo+ZgKL8v9bO7YnkqVqdGzgNP25KmbYY+MjASzs7PBxMTigICenp5weWpqKujt7a27 3AlInigSnbfUTD4uWWpUrO9JClrdz3Qu080fq696DFRre/IUJUQlT6e/vz/Yu3dvuKyv9ZY7AckT lukcZXyCgqzOW7Yi7X6mSdddldlo1h9AzCXPoaGh8Gu9hBlf7gQkT1iiKlLVpEuWGh0bn6DAgiT7 WXzwjyZeB5rV9uSpj227urrCNjY2VlkWfR0eXjzPUG+57EieaKfqQT46f6nzmJattJ/pPOZk//WL H8tuuyW4ct727wOb2p480RjJE77tfPWTSrJUs3y/y1pq7WfxhKn7THbSbb2QD5KncSRP5E0z99y8 cbSSLAd2jted+q4IPt/+74LpHX8f3qTZfSSrCpOEiSyRPI0jeSJro2OT4c2gXbLUgJ8Tn16Kni0u JcfzD/6rSsKcvP/68ObSQB5InsaRPNEqJcb4TD5KnEqgZXB53xOVZHn+oVXBhf9jcbq8MHk+8L3o VUD2SJ7GkTyR1MWZ+XBeWJcs9ZFss5OqW/f1yQPhR7AuQWpO2errMM/+4l8Ek5u+HT0C8kHyNI7k iWZUD/LR4zLQSFglSJcsNdhnpflk2c/gA8nTOJInatG1lfE7kBR9kE9cfLIC3eJLH80mwX4GH0ie xpE8ITpvGZ/J585tR9s+k09WNGesu4xE7auXH25poA/7GXwgeRpH8uxM1ectLc7kk5Y+do2ft7z4 u3WZXkbCfgYfSJ7GkTw7h27Ppdt0uYT5+K6Po2eKbf70kcrtvNQ02boG/uSF/Qw+kDyNI3mWlz6K 1UTqLlnqchLfdyDJQzjI58m7K8ny/OCNweyRXdGz+WM/gw8kT+NInuVRPU9sWT6K1aUiOk/pkqXO XyYd5JMlkid8IHkaR/IsNt3fMj4qtmjzxNYTHxGrpqnwrCB5wgeSp3Ekz2JRdRkf6KPZfMowKnbm 9R3hZSMuWbY6IjZPJE/4QPI0juRpk66pVGI8PTETTnV324PvlKq6XHb5yPP9wZWLZ6NnbSN5wgeS p3EkT5tWrXujkiyVOIteXWpAjwb2uGSpAT9Fvc8lyRM+tD156mbYIyMjwezsbDAxMRFMTU0Fvb29 TS13ApKnDdXVZbwVUXit5aO3VpKlLiWZ/+x49GyxkTzhQ9uTpyghKnnu3bs3fKyvzSx3ApJn+8RH xipxxu9EomWt3/12MSZcV2LUZAQuWWqSgpXmiC0qkid8KGXy1C9FoyVtT75yJPhfN/6hkjB/NXSw 5uuK0MYPjwaf/ZfeSrL8sv+7wamX/7Hma2k0WrqWRqYf23Z1dYVN9HV4eLjp5bJLGyCLrP0uGuxT fZ/LIp+7rJ5QXSNkO1GZ+gzsanvyRGMkz+xUT1KgqfA0JV5RZT2helmQPOEDydM4kmdrnn7tTHDD XfsqCbPIl5HkPaF6WZA84YOX5Dk0NBR+1Kq2evXqaC2aQfJMRjP6xEfF9g99UNj5YpUYO2WQT5ZI nvDBS/JEeiTPxnSOUve2dMlSE62X5ryl5ogd7Yxz+1kiecIHL8lzYWEhvDZzYGCgYwb6ZIXkuZSq yIGd45VkWfTJ1eeO7VkyOYFm8uG8ZWtInvDBS/LUiFolT02GsHXr1mgtmkHyDIKdr35SSZY6f6nz mEWlO5BcemZjJVnqo1jd7xLZIXnCBy/JE+l1YvKsPm+pidYvzsxHzxbP7MHnloyK7dRLSHwhecIH b8lzzZo14YAhVaBoXickT02yroE9LlnqestDJy5EzxaPJlCP3wxaU98xKtYfkid88JI89bGtZhAS PrZNpqzJ85XRiSWXkBT5o1gJJ1Z/aFUlYbbzZtCdjuQJH7wlT3epCperJFOWA4EmKNj0n659FKuZ fYp6CYlM3v/dMElORslSk6yXZWL1oiN5wgcvyRPpFflAoEtG9BGsS5iaK7bIlBzjdyJxDbaQPOGD l+SpS1U00lb6+vrCr2hO0Q4E+vjVJcubN46Gg3+cIh7UdJ2lS5L6WFYfz8rk/YsDgPQVtpA84YOX 5CkueQ4ODoZf0ZwiHAh0naVLmJqwoN7HsUX4XaovJdEMPxoAhOIgecIHb8kT6Vg9EGg0rCZWV8LU R7PNnL+0+rtoyrv4RAUM9ik2kid8yD156l6dDBZKz9KBQAnSXX+pmX10S68kLP0uM3u2V5LlhS03 MVFBiZA84UPuyVPGxsaC7u7u6BGSsHAg6Hv0/co5zFauv2zn73Ll/JnwekuXMJkGr7xInvDBS/KM W6nyVHXqBhVp2Z0jrbdcdu06EOg6THceU8tZ8P27xGf20Vc9RvmRPOGDl+S5d+/epipPfcSryRQ2 b94cfo/oa73lTuD7QKC7kihh6quuzcySj99FFaWrLpnZpzORPOFD7skz6TlPVZSqPOslzPhyPfql aM23Xa+/V6kyH3/+cM3XWG0n/vBK8MXmmyoJ89P/+vOar6PRaLSsWxqpP7ZtxCVE3TxbSVfz4Pb2 9tZd7gRpA9SMx3d9HCZMjZr1MdtPVr9L9bWXuq0X4OTZZwDHS/JUMmy28sRSeRwIXNLUJSY+pf1d NLCHay/RLJInfPCSPJFelgcClzQ1kUE7JPlddK5S97p0CZPbeKFZJE/4QPI0LosDgRs5266k6az0 u2jquyWjY6Op8IAkSJ7wgeRpXNoA3fPrY0HP5sWRs7o+04Jav0t8sgJVmoyORatInvDBS/J09/Mc Hx/nfp4JpQmQEqeSptr/9sDb0dr2c7/LVy8/XEmYOpfJZAXIEskTPnhJnrJ27dpwwJASKJqXNEDb nj1ZSZxqP9ywP3qmveLXX2oZyAvJEz54SZ6u8pT169eHX9GcZgN0bnouTJaa3ED+ru+t4Maf7AuX 26U6YXJQgw/sZ/DBS/J0l6mocUuyZJoJUP/QB2HiVAJtt/glJfp4No6DGnxgP4MPXpIn0lspQEqa vq/XrBaftKA6YcZxUIMP7GfwwUvyXFhYCM916obY27dvj9aiGfUC5C4/GR2bjNb49fXJA5XLSjRp QTODfjiowQf2M/jgJXnqnKem1NNHtpzzTKZWgHS9phKnb5rVx01coJtH6zZfSXBQgw/sZ/DBS/JE etUB0jy0vj+mdQN/Jjdd19I8shzU4AP7GXzwkjw1UEgf2WqOW+a2TcYFSLcHU7X59GvJqr205k8f CZOlkmZWU+NxUIMP7GfwIffkqbugSKNbiKE+Bej0xEyYOH3c+eTSk3df+1g248nXOajBB/Yz+OAl ecYvVaHyTOa3Ly1OsZf1janjdO7SDf7RdHl54aAGH9jP4EPuyRPpudmC8jJ78LnKucz5z45Ha/PD QQ0+sJ/BB3PJU9P4dXd3h8vxSRXqLZdV36Pvh4OD8jgQuAFAGjnrEwc1+MB+Bh9MJU99xOum8XPn SPW13nJZucQpWR4Ipnf8KEyamgWoHTiowQf2M/hgKnmOjY2FXzUqt17CjC/Xo1+qqO0/bB4N/rZv X83n0rYvNt8UJs1Phhfnl6XRaDRa6y2N3CpPTaYwMDBQWe7t7a27XDbxitNJEyCNkj17NVkqYapd 3vdE9Ex7pd3ZgCTYz+CDqeTZyWolTkkToHMb/3klcapZwUENPrCfwQeSpwH1EqckCZAmM1CyvLjz HyqJc+693dGz7cdBDT6wn8EHkmebNUqc0kyAFr78KEyUvkfPJsVBDT6wn8EHkmcbDewcb5g4ZaUA aSYgJc5vLk9Ha+zioAYf2M/gA8mzTV4Y+WNww137okf11QuQ+4g2q3lnfeCgBh/Yz+ADybMNjp2a bnrmoFoB0lR6akXDQQ0+sJ/BB5KnZxdn5hPNVRsPkG5AXbRqM46DGnxgP4MPJE/PlDjPTc9Fj1bm AuRuQv3NfPPfaw0HNfjAfgYfSJ4eKXEeOnEhetSc8cOjYdLUrcKKjoMafGA/gw8kT080OGjnq59E j5qjOWiVOHXLsDLgoAYf2M/gA8nTg+773g427lict7dZuk3YhS03lepAwEENPrCfwQeSZ850LaeS Z7N0TjMcFBTdlJrkCSTDfgYfSJ450vnNJDeznj99JEycmjHIIXkCybCfwQeSZ050KUqSxPnVyw+H ibMayRNIhv0MPpA8c6LEeXpiJnrUmM5tnn9oVfRoKZInkAz7GXwgeeZA89U2O7JW1eZXz/dHj5Yj eQLJsJ/BB3PJUze7Hh4eDpe7urqCwcHBhsvWaFTt7YPvRo/qcwODNGtQIyRPIBn2M/hgLnkqKSp5 7t27N3ysr/WWrXnz6NmmJnvXdZtKnM1cv0nyBJJhP4MPppKnS4hFTJ7NDhBy89M2ewsxkieQDPsZ fDCVPB0lT318OzU1FfT29tZdtkSJ8/Nzs9Gj2i6PDtccUdsIyRNIhv0MPphMnkVz88bRFQcIuan2 kiJ5Asmwn8EHkmeLtj17csUZhKYevTX1/TdJnkAy7GfwgeTZAl3HudJ5Tt1K7PzgjdGj5EieQDLs Z/CB5NkCJc5GN7VuNXEKyRNIhv0MPpA8U9IlKbo0pR4lTSXPVpE8gWTYz+ADyTMFTYRw57aj0aPl skqcQvIEkmE/gw8kz4RGxyYbToSQZeIUkieQDPsZfCB5JrDSRAia3D3LxCkkTyAZ9jP4QPJMQImz 3p1Ssq44HZInkAz7GXwgeTZJ13Lqms5a8kqcQvIEkmE/gw8kzyY89tKp8DZjteSZOIXkCSTDfgYf SJ4rOPHppbrnOfNOnELyBJJhP4MPJM8G3AChWhMh+EicQvIEkmE/gw8kzwaUOA+duBA9ukZJU8nT B5InkAz7GXwgedZwz6+PBX9550jNAUI+E6eQPIFk2M/gA8mzihKnKk612x58J1q7yHfiFJInkAz7 GXwwlzy7urrCm2G75cHBwYbLWfvhz/ZXkucPN+yP1rYncQrJE0iG/Qw+mEue0tvbG+zduzdc1td6 y1nT1HtKmn/X91Zw40+uTcHXrsQpJE8gGfYz+GAueS4sLATj4+N1E2Z8OUvnpufCxFmtnYlTSJ5A Muxn8MFU8lTidB/ZTkxMBFNTU2EVWm85S0qcF2fmo0eLlDjV2onkCSTDfgYfTCXPdtHsQU+/diZ6 FAQXh+4IJjd9O5je8aNoTfuQPIFk2M/gQ8cnz4Gd40tG1SpxntvwrbBd2HpTtLZ9SJ5AMuxn8KGj k+fn52aXneec/Nli4lSbfOB70dr2IXkCybCfwYeOTp5KnBoo5Chhzh58Lpi87zvhx7YWkDyBZNjP 4EPHJs/qW4wpcX794Uj0yA6SJ5AM+xl86Mjkqes5b7jr2nWcVhOnkDyBZNjP4ENHJs/4ec4wcZ48 ED2yh+QJJMN+Bh86LnlqZO3juz4Ol8NznEd2hctWkTyBZNjP4ENHJc/TEzOVqnNy03XBzOs7wmXL SJ5AMuxn8KGjkqcbXTvZf31w8XfrorW2kTyBZNjP4EPHJM9HnjoR3LHlcDD9m562zlWbFMkTSIb9 DD50RPKcm78SVp2X9z0RflxbJCRPIBn2M/hQ+uT5g3sX78/5v9/7UjhAqGhInkAy7GfwofTJ83++ 8/8NDt7zN2Hi/ObydLS2OEieQDLsZ/Ch9Mnz7NWkqcRZxKpTSJ5AMuxn8KHUyVOzCLnESfJsPw5q 8IH9DD6UMnnqcpR/88sDwScb/mXlFmOzh16Mni0WkieQDPsZfChc8pyYmAimpqaC3t7eaM1yH9/7 nTBhfrnhv4/WFBfJE0iG/Qw+FC557t27d8nXWor+UW0cyRNIhv0MPpQyeX75yz8PE+cXV78CAGBF W895dnV1BcPDw9EjAACKwfSAIQAALCJ5AgCQEMkTAICEzCZPnQ8dHByMHhXP0NBQ+DuIBkXVWi4S XVrkzk/HY1PEOK1duzbo7u4Ol4v+u7j9bHZ2ttD72cDAQPg7SL2YxJctW1hYCPr6+sLlMhwH4rEp +nEg/ru0ehwwmTy1Y8W/FtXc3FwwPj5e2dn0Nb5cJNqZ9H+Ox6aIcVLnd52n6L+L9Pf3hwfrou9n Li71YhJfLgLFxSn6cSDeZ4p+HHC/SxbHAZJnjjZv3hx+LWqncVwcitxpnLGxsfCrKoKi/y6i30NN B4Ii72dlTp5FPw5Ux0b/56LGxv0uWRwHTCZP/YIrzT5knT4ecHp6eip/fcaXi0adJh6bIsbJ/Z8V n6L/LuI+XlJsiryf6f3XQa1eTIoWH5c8y3AccLFxinwccL+L+z+3chxgwBAAAAmRPAEASIjkCQBA QiRPAAASInkCAJAQyRMAgIRInoAx69evj5aytXXr1vDyCA3FT6OZWVeATkHyBDxx1/xpWrBG6iVP d7G96CJvXa+W5CL7kZGRhskz/vNrcReWAyB5At645PnjH/84/CouCcYvylbydAnWXWyvxFed3OJz o7ok6i68j3+fuKSpr+4id71Oc7C66f3cz49/b7zabKVqBcqG5Al4Ep9txs1koq9Knm4icVHyXL16 dbgcT161KkNNLyYuebrXV3/EGk+eLgEqOcanJHM/v/p7lcirvxfodCRPwJN48hRVjg888ECYPJXA 9FgVoPvYVgkxvl7LLskqkcXv/hB/rdbFv89xH9s+++yz4XMSvwOI+/nx79VX91o+tgWuIXkCHaLW uVRXATej3rlYoBORPAEASIjkCQBAQiRPAAASInkCAJAQyRMAgIRIngAAJETyBAAgIZInAAAJkTwB AEiI5AkAQEIkTwAAEiJ5AgCQEMkTyInuYPLTn/40XK43qbrW684muuOJ7unp7nyiydrznIi9XdsF yoLkCaRw4tNLwffvfSv44Yb90ZrlXDJSYlJC0mPd5st9lXgS07Luz+m+T/fR1O3AdMuyJC4M/nVw /v7rg/nPjkdrlstju0AnIXkCK1i17s3Erfu+tyvJSIlJCSp+P0wlLdF6xy3/9re/baoCnHr01uDc hm81aP9s2brzgzeG39vKdgGQPIFU/u6nb1USparQWlzylNWrV4dfVdF1d3eHy1Irielm1PEK0CXa Zly5ePZaonzgu9Ha5bLeLtBpSJ5ASo/v+jg4dmo6emTHwpcfBTN7tkePAOSB5AkAQEIkTwAAEiJ5 AgCQEMkTAICESJ4AACRE8gQAICGSJwAACf3JBx98EC0CAAAAAJA91Z0UnwAAAACAXFF8AgAAAABy R/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJADBp7969werVq4OpqaloDVq1sLAQ DAwMBH19fcHs7Gy0FgAAPyg+AQBNGxsbC7q7u4Px8fFozeK6rq6uYHBwMFqTjSyKz1r/31q0rWZe VyTN/u4AAPhC8QkAaFq9gqZW8TY0NBQWpa4NDw9Hz1zjClfX4gVsdfHpztrF19X7fvfa+HPx56s1 U3zqNTpjOD09Haxdu7byM9P+XtrWmjVrKj9D71etYrv6PV/p/9Hod6935nNiYqLyf3FtZGQkenZR kt8fAIBaKD4BAE2rVXyqKFmpCJmbmwsLlurisF4xKK5IUzFWXZjV+/7490it/28t7neobvHfSa+p /lnu96ou/Fb6vap/ttT63uqfL+77q4tDvUfxorLW715dfDb6/1b/vGZ+fwAAGqH4BAA0rdlizhU1 8UJOzRU57kxbdQEVp2JHheSzzz67rNiqdabOtfj/L0nxudLr3P8nfmayunhr9veqty33/a6Yqy4A pdb/Q6p/bjPFZ6P/b/X3N/P7AwDQCMUnAKBpzRRz1QWUVBcp1WdCa4kXO+71rmhq9oyb7+Kz2d+r 0bbc8y+88ELN19X7fh9nPik+AQCtoPgEADSt2WKu+sykikQVM9VFigqa+FnL+PO1ih33enemTv+f +PfHiyUnvo16RVL1/yPe3LZq/X/qFV/VP6/691rpPdR7Fd92nPt/6Pvj73G918b/D9XFp1P9PtYr eik+AQCtoPgEAMCQlc6e1ioCAQAoAopPAAAAAEDuKD4BAAAAALmj+AQAAAAA5I7iEwAAAACQO4pP AAAAAEDuKD4BAAAAALmj+AQAAAAA5M5s8an7nPX29oY3ze7v76/cDNvd0Lr6Ztq6oXlPT0943zP3 vbpBdtL1AAAAAIDsmT/zqSIxXnyOjY0FXV1dleZutK2bbg8PD4evEfc46XoAAAAAQPYKWXwODg6G y5K2yKy3Pom33347fANp9tqHH35Ycz2tvY242G3ExmYjLnYbsbHbiI3NRlzstn/6p3+Kqpv8aXtm h92uXbt2yVlON9RWhaJbFy9Eh4aGKuvjhWTS9c3S/wM2WdynQVwsIzY2ERe7iI1dxMYm4mKXz9ho W0w4lBLFp13s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKFJ92sU/bRFzsIjY2ERe7iI1dxMYm 4mKXz9hoWxSfKVF82sU+bRNxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKZE8WkX+7RNxMUuYmMTcbGL 2NhFbGwiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFLmJjF7GxibjY5TM22hbFZ0oUn3axT9tEXOwi NjYRF7uIjV3ExibiYpfP2GhbFJ8pUXzaxT5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxaRf7 tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1NxMUuYmOXr9icnpgJDp240FKb m78S/bTyo8/Y5TM22hbFZ0oUn3axT9tEXOwiNjYRF7uIjT3npueCH9y7P1i17o2r7c2w/U93/yH4 P5/+p2Bg53hw57ajwR1bDleea7Xp57XabrhrX82fnXX7/j1vLdnutmdPBo/v+jhsO1/9ZElBrPcx D/QZu3zGRtui+EyJ4tMu9mmbiItdxMYm4mIXsfFLZwhVGKlY2rhjLLh54+iyAusvekeWrXNtdGwy /P7Pz81GP7GzXJyZX1JgvjI6USk+1foefb9SmN4++G7N9zBpU2EdL3j//cP7ww8B4ttVe/Po2SX/ t2OnpqP/dXIqnO/59bHwd1i/7b3w7DRW5vN4pm1RfKZE8WkX+7RNxMUuYmMTcbGL2GRLRcOeg18E jzx1Iui+7+2axYwKGJ2x0+tqFZEqXHSGL/49evz7w19Gr4BviqsrKl/8/Xvh1+ri052Vdi3t2em/ WKcPH66d9Xbttgffif43qMfn8UzbovhMieLTLvZpm4iLXcTGJuJiF7FJ58Snl4LHXjoVFgTVRYLO vmkIaCtnvoTY2JR3XOqdsf3hhv3RK1CPzz6jbVF8pkTxaRf7tE3ExS5iYxNxsYvYNKZhsjpDqYIy XghouKzObuoMWF6IjU0+4qLh1X/Xt3j2+8af7At2vz0RPYNGfPYZbYviMyWKT7vYp20iLnYRG5uI i13E5hoNgdUZy+qzmRo++cLIH8PrDX0iNjYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuJiVyfHRmc0 q6/L03V7OutkAf3GJuJil8/YaFtmi8+FhYVgYGAg6OvrC2Znl15YPjExEaxZsyYYHh6O1iwWg11d XWEbHByM1iZf3yyKT7s4wNlEXOwiNjYRF7s6JTY6q6lhsvGJfHSGU7OlWr1HJf3GJuJil8/YaFum z3yqyOzv719SfI6NjYXFor664lOFYHUhqsdJ1yeh74FNHOBsIi52ERubiItdZY2NzmrGJ27R7TJ0 VrNIt6yg39hEXOzyGRttq1DFZ7xItFB86r2j0Wg0Go1GK1o7cGgs6P/P7wR/27evUmz+21/8IXj8 +cPBe8eO1/weGo1WzuaLtlW4M59OvPjU63p6eoKpqalgbm4u6O3tDcbHxxOvT0LFJ2yyvE93MuJi F7GxibjYVcTY6Gb+uo+iKzTVdFZTtz8pE/qNTcTFLp+x0baYcCglik+72KdtIi52ERubiItd1mOj m/vrfprxazW773s7ePq1M95nn/WNfmMTcbHLZ2y0LYrPlCg+7WKftom42EVsbCIudlmKjSb+0QRA 1TPQ9g99EBw7NR29qnPQb2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTcTFrnbGRpMCbdwxtqTQVOGp 9aDfWEVc7PIZG22L4jMlik+72KdtIi52ERubiItdPmKj4bG1zmjqseVbnbQb/cYm4mKXz9hoWxSf KVF82sU+bRNxsYvY2ERc7Mo6Nrqfpq7R1HWZ8UKz79H3KTQTShqbr08eCNvMnu1hu/TMxmB6x48q 7fxDq4JzG75Fy7hd2HLTkve51Tb169XBuY3/Q3A2to3zD/6rYOHLj6JIox6fuUbbovhMieLTLvZp m4iLXcTGJuJiV9rYuOszq4fN6n6aukZzdGwyeiWSmD99JLg8+lRwbtOfLSk+JmPLtZoKSxUuF3+3 Liw8L+97olKMqunnIhvVfWb+s+NL3utW2+Qv/qxmjNXQmM9co21RfKZE8WkX+7RNxMUuYmMTcbFr pdioyNStTXQrk/iMs2q3D74bzjqrs51oTAXK5dHh4Kvn+4OpbbfULCzUwuc2/g81n1ND++V9PAsL 0PuvXxJ3PZ57b3f0CtTjM9doWxSfKVF82sU+bRNxsYvY2ERc7NEtTH5w7/6rReQblWLyb/r+EKx9 ZOl1mWoqMh/f9XFwemIm+m5Uu3L+TFhcTv+mJ5jsX1o4qJ0fvDG49OTd4RnJlc5CUnzYxvHMLp+x 0bYoPlOi+LSLfdom4mIXsbGJuNigiX80k6zOYv7lupFlRaZrZb9/ZitUGOpayuoCc3LTdeGQ19mD z4WFaBboNzYRF7t8xkbbovhMieLTLvZpm4iLXcTGJuLijxsm+8hTJ5ZN+qOmGWZ3vvpJ8PJbny8b RqvHvz/8ZfSTOpsKSF07qclk4kWmzmB+9fLD4TDavNFvbCIudvmMjbZF8ZkSxadd7NM2ERe7iI1N xCV7mtBn27Mng9sefGdJAammYbKacfbYqeno1fURmyD4+sORcEhsvMjUmU1dn6kzne1CbGwiLnb5 jI22RfGZEsWnXezTNhEXu4iNTcQlOTdEtt4ZzCQFZiOdFptahabObup6zW8ut/ZeZo1+YxNxsctn bLQtis+UKD7tYp+2ibjYRWxsIi61aZbYF0b+GN6upHoIrJobIttqgdlImWOjQlPXYRah0KyFfmMT cbHLZ2y0LYrPlCg+7WKftom42EVsbOrkuKhw1BlKFZLVxaUKThWeKkDbdbuSssRG12CGEwFtuq5S aOr6zJnXdxSi0KyF45lNxMUun7HRtig+U6L4tIt92ibiYhexsanMcdEtS9wMsrWGx+qaTA2d1SRA FmeRLWJswsmAdm8Nzj+06lqheXVZ67KaadYCjmc2ERe7fMZG26L4TIni0y72aZuIi13Exqaix0Vn L3Wfy1pnL9X6Hn0/HB574tNL0XcUh/XYXLl4Njx7qbOYrtDU2U1NBrTw5UfRq8qJ45lNxMUun7HR tswWnwsLC8HAwEDQ19cXzM5eG1YzNDQUdHV1hW14eDhau1gMuvWDg4PR2uTrm0XxaRcHOJuIi13E xibrcdGQ11dGJ4L+oQ+CmzeOLisurZ+9bIWl2KiYrD6jqUJTw2nnTx+JXtU5OJ7ZRFzs8hkbbcv0 mc+JiatJrb9/SfHpzM3NBb29vcH4+HhYCFYXonqcdH0S+h7YxAHOJuJiF7GxyUJcDp24UPfayxvu 2heevXz6tTOFPHvZinbFJpx1tuoaTXd7k7Kf0WwWxzObiItdPmOjbRWy+NRZ0c2bN4eFpyQtMuut T0Lfo/eORqPRaLSittf3Hwu2P3UouHPrgeBv+/YtKzD/7S/+EPT/53eCJ185Erx37HjNn0HLvn14 9GBw6oX/K5jYenOlyFT74sG/DD79rz8PThx8s+b30Wg0Wprmi7ZVqOLTDcWtLhT1up6enmBqamrJ GdGk65NQ8QmbLO/TnYy42EVsbMoiLm5in3r3vdRwWQ2bbefMsUWUZZ+ZO7YnvIdm/Gym2tSjtxbm 9iaWcDyzibjY5TM22hYTDqVE8WkX+7RNxMUuYmNTs3FpNDRW7c5tR3O/72WnSdNnwiJTQ2b7r19S ZOoemjN7tjNsNiMcz2wiLnb5jI22RfGZEsWnXezTNhEXu4iNTS4upydmwjOTurel7nFZXVxqYp9t z54s5cQ+VtXrM5plVmcrL/5u3bIzmRSZfnA8s4m42OUzNtoWxWdKFJ92sU/bRFzsIjbtpYJRhaOG xqqQrC4uVXAyNNYGFZeT9383OBsrKifjy1cLThWeKkD1WvjH8cwm4mKXz9hoWxSfKVF82sU+bRNx sYvY5E9DXjX0VUNgq4tLNQ2Z1T0x40NjiUv7fDM/Fw6T1Syy8XtlNmqwgX5jE3Gxy2dstC2Kz5Qo Pu1in7aJuNhFbFq30j0vNdmPzmxq8p9mh8YSl3zpzOTskV3hdZjxe2S6pgl/Zl7fEcx/djz6jiD4 +uSBYPL+pdds6vHce7ujV6Dd6Dc2ERe7fMZG26L4TIni0y72aZuIi13EpjmjY5PhxD63D767rLjU PS91TabuealrNLNAXFqn6ysv73ui5jWYatO/6QmfjxeYzSA2dhEbm4iLXT5jo21RfKZE8WkX+7RN xMUuYrNIZy91XaXOXtaa2EdFpyb2URE6N38l+q78EJeV6TYkbnisJvSpLi51RlO3MZk9+Fxw5fyZ 6LtaR2zsIjY2ERe7fMZG26L4TIni0y72aZuIi12dFJtGZy9VcOrspQrQrM5etoI+s0hnJTX8VWcp q4tLtXB47J7twfzpI9F35I/Y2EVsbCIudvmMjbZF8ZkSxadd7NM2ERe7yhQba2cvW9EpfUZnL3Xt Zb3JfbRO12XqNVZmkOV4ZhexsYm42OUzNtoWxWdKFJ92sU/bRFzsKlpsNCOsZobVDLHVxaW1s5et KFOf0UQ9M7u3hmcpq4tLNZ3VrJ7cxzKOZ3YRG5uIi10+Y6NtUXymRPFpF/u0TcTFLmux0RlJd99L zRJbXWC6mWP1mmZnji2iIvWZJRP79C+dDVZtatstwVcvPxxen6nbmBQdxzO7iI1NxMUun7HRtig+ U6L4tIt92ibiYlc7YhO/NUmt4bE6q6lrM+P3vew0lvqMuy1J3aGxOU3sYxXHM7uIjU3ExS6fsdG2 KD5Tovi0i33aJuJiV16x0bBX3Xqk79H3lxWXedyapGx89hmdjfz6w5HFobHbbllWXOo2JUUbGpsn jmd2ERubiItdPmOjbVF8pkTxaRf7tE3Exa5WYtOowNQZTZ3Z1BnOc9PFH2rpW9Z9RrPBalbY6R0/ WlZcqoWzxl4tPlWElmFobJ44ntlFbGwiLnb5jI22RfGZEsWnXezTNhEXu1aKDQVmeyTtMzoj2ei6 S90HU8Nmw+suL3fucOYscDyzi9jYRFzs8hkbbYviMyWKT7vYp20iLvaoWPzBvfuvFpFvVIrJv7pr X/DX/7Cv8pgCs32q+4yupdQ1lbq2UtdYVheXlVuSdMh1l+3E8cwuYmMTcbHLZ2y0LbPF58LCQjAw MBD09fUFs7Oz0drFoq+rqytsg4OD0drs1jeL4tMuDnA2EZf2c/fA1LWWuubyL3pHlhSZ8Qb/dDZS ZyU1K2zN6y77rw/Pal4eHQ5nl0X7cDyzi9jYRFzs8hkbbcv0mc+JiYmgv7+/Unyq4BseHg6XxT3O an0S+h7YxAHOJuLiR3WBGS8o3SQ/el6vO3TiwrKZZvX494e/jH4ashZed/n6jsbXXe7ZHt4Xkz5j F7Gxi9jYRFzs8hkbbYvi86rqx83Q98AmDnA2EZfsuGswmykwm0FsshPe73J0OBwa2+i6S922ZKXr LomLXcTGLmJjE3Gxy2dstK1CFZ963NPTE0xNTQVzc3NBb29vMD4+ntn6JCg+7eIAZxNxSUb3t9z5 6ifBnduOLiku1bK+BpPYNC8+NFaFZHVxmeXQWOJiF7Gxi9jYRFzs8hkbbYsJh1Ki+LSLfdom4rKU isY9B78IBnaOB933vb2swNS6R546Eb7m4sx89F35IDZLadbYcGjsb3rC+1tWF5iVW5KcPBB9Rz6I i13Exi5iYxNxsctnbLQtis+UKD7tYp+2qRPjorOXj+/6OLhjy+FlxaWabl2is5snPr0UfUd7dFps rlw8Gw571cywmiG2urhcMmvs1de2C8cyu4iNXcTGJuJil8/YaFsUnylRfNrFPm1TGeOiayo19FVn L2/eOLqsuLztwXfCs5dvHj2b+9nLVpQxNuHEPnu2h2cpq4tLNZ3V1NlNvc4qjmV2ERu7iI1NxMUu n7HRtjIvPnUN5dq1a8NbmNSbxEfXXK5ZsyZ8zcjISLS2WCg+7eIAZ1NR4zI6Nhk89tKp4PbBd5cV l5rcR2cvNflPu89etqKIsdG1lzp7qcl7ap29dBP76PrMlSb2sYpjmV3Exi5iYxNxsctnbLQtznym RPFpF/u0TVbjEp85tvq2I2oqOrc9ezIsQufmr0TfVS5WY+NmjtUEPnWvvTR+9rIVHMvsIjZ2ERub iItdPmOjbeVafOos6ODgYDhb7djYWLisdevXrw9nmi0yik+7OMDZ1K64aLirhr1q+KuGwVYXlxou q5ljk9yapGza2Wfik/tUF5eaOVa3LFEBeuX8meg7OgfHMruIjV3ExibiYpfP2GhbuZ/5VJGm4bUq PEVDbuO3Tykqik+7OMDZlGdcVDSqeFQRWevspSb80cQ/mgAIy+XdZ8LrL3dvDaa23bKswDz/0KrF yX2auO9lp+FYZhexsYvY2ERc7PIZG22LYbcpUXzaxT5tU6tx0TWVmhlW11hWF5e69lLDZlWAahgt ksmizzQsMAdvvHb95Xzr9yXtFBzL7CI2dhEbm4iLXT5jo23lWnwuLCwEAwMDSyYV0vDbvr4+znwi NxzgbGomLrquUtdX1prcR8NjNaus7nupe2QiO832mXCILAWmNxzL7CI2dhEbm4iLXT5jo215GXZb XXy6IbhFRvFpFwc4m1xcdAZTQ2BrFZjxyX3gh+5j+fn2fxcWlNM7/j6Y+/DN4PK+J2peg0mB6RfH MruIjV3ExibiYpfP2GhbDLtNieLTLvbp9nPXYGoobHWB6c5gahKgss4ea50KztmDzwUXfvWXwdmq AlNtsv874fN6HdqHY5ldxMYuYmMTcbHLZ2y0rdyLz/g9PdVWr15d+JluheLTLg5wfqhw1BBYFZIq KKuLTHcNpptBlrj4pTOTOkNZ7z6YOrN5fuBfL1uvNvnA96Kfgnaiz9hFbOwiNjYRF7t8xkbbyrX4 jN9qxdF1oFu3buVWK8gNB7hs6VYlr4xOBHduO7qswNQw2cdeOhUOpV0JccmHm+jnwpablhWRGkqr 53StZj1ffzgSnP3Fv1gsOjd9O5g99GL0DNqNPmMXsbGL2NhEXOzyGRttK/Pi000y5M501mplOPtJ 8WkXB7j0NBRWZzI1e2y8yFThqbOYrUz0Q1zSW/jyo/A6zKlHb11WYLrrMFVEpkVsbCIudhEbu4iN TcTFLp+x0ba45jMlik+72KdXpjOVmtin+763lxSZtz34TjgZkBsqmyXi0pi7DvPi79YFk5uuW1Jg TvZfH1x68u7c7oVJbGwiLnYRG7uIjU3ExS6fsdG2cik+3XWeZZjVth6KT7s4wF2jM5VPv3Zm2cyy KjpVfDYzXDYrxGXxOkwVkJee2Ricf2jVkgJTTYXn5dHh4Mr5M9F3+EFsbCIudhEbu4iNTcTFLp+x 0ba8nPnUtZ9r164Nh9yWpSCl+LSrUw9wOlup6y/jk/98/563wmG0Fm5d0klx+frkgeCrlx+ufx3m 6zsaXofpW6f2GeuIi13Exi5iYxNxsctnbLQtL8VnfMbbvr6+JRMQJaGf09/fH36/u7ZU9xDV+p6e nvA6UhW6vb29wfj4eOL1SVB82tUJB7jTEzPBI0+dCIvLeKGpdXrOorLFRddhqoisdR2mik4Vn61c h+lTJ/SZIiIudhEbu4iNTcTFLp+x0bYKN+xWRZ+buEiFp1s3PDwcLot7nHR9Evoe2FS2A5yGzuo6 zPgZTS1bLjRrKWJcGl2HqWGzGj6b13WYPpWtz5QFcbGL2NhFbGwiLnb5jI22VagJh5IWk0nXJ6Hv gU1FP8DptiZ3bDlcKTTV+oc+CA6duBC9opisxsXdD9PadZg+Fb3PlBVxsYvY2EVsbCIudvmMjbaV efEZv76zXkHnzozGz142o/o2LvEhvENDQ5X18e0mXd8sik+7inSA0z00dVYzPnxWM87qtiZz81ei V5VDu+Oy4v0w92w3dR2mT0XqM52EuNhFbOwiNjYRF7t8xkbbKtSZT0soPu2yvE/XKjY1E63ur1l2 PuKiYbI6S6mzldUFZhb3wywr8oBNxMUuYmMXsbGJuNjlMzbaFsVnShSfdlnap3X2cuernywpNu/c drTwQ2jTyDIubjZZFZTVRWZlmOzVQhTNIQ/YRFzsIjZ2ERubiItdPmOjbVF8pkTxaVe792nd1iR+ X81OObO5kqRx0TWWDc9iajbZq0UoWkcesIm42EVs7CI2NhEXu3zGRtvKvfh011Z2d3dXbnPibpdS ZBSfdvnqRJqF9gf37r9aYL5RKTTV/vanbwVPv3amdNdstqpeXHSdJWcx28tn4kHziItdxMYuYmMT cbHLZ2y0rVyLT00QtHnz5rDo3LlzJ8UnvPDRiY6dmg7+9Z0jS4rOeMNyJ1//f8JrLqtnlNXj8FpM zmK2DX8U2ERc7CI2dhEbm4iLXT5jo20x7DYlik+78tqnNXQ2fq/N+3/7wZJrOdX0+PeHv4y+ozOF 12PWKDK/7P8uRaZR5AGbiItdxMYuYmMTcbHLZ2y0rVyLT912ZXBwcMlZTq1bv359MDU1Fa0pJopP u7Lcp3XPTVdg6qtugYJF7t6Yk/3XLyky653JJPHYRWxsIi52ERu7iI1NxMUun7HRtrwXn2VB8WlX q/u0htR23/d2WHDecNe+sADtZAtffrR4TWb1cNlo0p9m741J4rGL2NhEXOwiNnYRG5uIi10+Y6Nt 5T7sdmxsLJxwKN5Wr17NmU/kJs0+/fm52eCOLYcrw2cfe+lUx00Y9M38XDB7ZNey2WUnN10XnuFs 9f6YJB67iI1NxMUuYmMXsbGJuNjlMzbalrcznyrWRkZGwkmItm7dSvGJ3CTZp7c9e7JScPY9+n44 g20n0NnMmd1bl80wO7XtltxmlyXx2EVsbCIudhEbu4iNTcTFLp+x0bZyP/OpW624onNgYCA88zk8 PBw9W1wUn3attE+fnpipDKvVdZyHTlyInimfemcz3XWZ86ePRK/MH4nHLmJjE3Gxi9jYRWxsIi52 +YyNtpV78VlWFJ921dunH9/1ceUsZ//QB6UbVvvN5enwrOWFLTctKTSnf9MTzB58Lny+nTjW2EVs bCIudhEbu4iNTcTFLp+x0bZyKT51L8+enp5waK2G3q5duzY846khuGVB8WlXfJ/WMNrbB98t3VlO DYu9vO+JZYXmpSfvbvnazLyQeOwiNjYRF7uIjV3ExibiYpfP2GhbuRWf27dvjx4tFmoaelsmFJ92 aZ9WkelukaJrOS/OzEfPFk84dPbgc+H1mEUpNGsh8dhFbGwiLnYRG7uIjU3ExS6fsdG2GHabEsWn TU+/dqYytFaTCRWRCsrqazSnHr01vHazyDjW2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOi+LRD127q Gk4VnLov5+PPH46esU/XYc7s2b7kHpqagXbm9R1tv0Yzaxxr7CI2NhEXu4iNXcTGJuJil8/YaFuF Kj7djLnVQ3irrzHt7e0NxsfHE69PguKz/VR0akitu57zxKeXwvWW9+n5z46Hw2XjZzU1IdDXJw9E rygvEo9dxMYm4mIXsbGL2NhEXOzyGRttq1DF59jYWDhxkWurV68OC0gVgvHbt7jHSdcnoe9Be9Qr Oh1L+/TcsT1LrtWc3HRd8NXLDwdXzp+JXtE5SDx2ERubiItdxMYuYmMTcbHLZ2y0rcIVn/EZc1cq JpOuT0LfA79WKjodn/u0Zp29OHRHWGBO7/j74PJb/3VJsanhtGUcQpsGiccuYmMTcbGL2NhFbGwi Lnb5jI22VbhrPlX0uTOf8UJ0aGiosj5eSCZd3yyKT3+aLTodX/u0is6zUZEZb+d/tSqcoRZLkXjs IjY2ERe7iI1dxMYm4mKXz9hoW0w4lBLFZ/6SFp1Onvu0znRq2KyKzMmfLS88w/UPfC96NeI41thF bGwiLnYRG7uIjU3ExS6fsdG2KD5TovjMT9qi08l6n9YtTjQDrSsudRuUhS8/Cp/TbVEm7/vOYtG5 6dvB7KEXw/VYjmONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz+y1WnQ6re7TGjI7s3trODlQWFT2 Xx9cHk0+NBtLcayxi9jYRFzsIjZ2ERubiItdPmOjbVF8pkTxma3HXjrVctHppNmnNZxWtzxxZzcv bLkpmD99JHoWWeBYYxexsYm42EVs7CI2NhEXu3zGRtui+EyJ4jMbo2OTYdGp9sroRLS2Nc3u07rd ydSjt1YKThWfnXgLFF841thFbGwiLnYRG7uIjU3ExS6fsdG2KD5TovhszefnZsOznCo6B3aOR2uz 0Wif1i1PLj1599KC8+LZ6FnkiWONXcTGJuJiF7Gxi9jYRFzs8hkbbYviMyWKz3R0XecdWw6HReft g+8GF2fmo2eyU71Pu2s4XcGpIbVuwiD4w7HGLmJjE3Gxi9jYRWxsIi52+YyNtkXxmRLFZ3KPPHWi cl3n6YmZaG323D59ed8TlUmDzj+0Kvj65IFwPdqDY41dxMYm4mIXsbGL2NhEXOzyGRtti+IzJYrP 5ulaTndd556DX0Rr86Fbn5z9ZXTrk/7rg9mDz0XPoN041thFbGwiLnYRG7uIjU3ExS6fsdG2KD5T ovhcmWatddd16qxnXuY/Ox4OpQ0Lzk3XBaef+VX0DCzhWGMXsbGJuNhFbOwiNjYRF7t8xkbbovhM ieKzvvh1nfqqx3mY2bO9ch2nJhHStZ3CPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymRPFZ29Ov nQmLzhvu2hccOzUdrc1OeHuUbbdUhtXOHdsTPXMN+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZ EsXnUvFbp2x79mS0NjuXR4crkwdN7/hReMuUetinbSIudhEbm4iLXcTGLmJjE3Gxy2dstC2Kz5Qo Pq/pH/ogLDq773s701unqMBUoemu5Zw9sit6pjH2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMl is8gGB2bDItOtTePno3Wtk4z1mpIrYrOqUdvDa5cTPaz2adtIi52ERubiItdxMYuYmMTcbHLZ2y0 LYrPlDq5+NQEQrc9+E5YdG7cMRatbd2lZzaGBaea7tGZFvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tlXI4nPnzp3BCy+8EAwPD4ePJyYmgp6enmBqaiqYm5sLent7g/Hx8cTrk+jU4vPxXR+HRaeu79R1 nq3S0Fqd3VTBef6hVeFtU1rFAc4m4mIXsbGJuNhFbOwiNjYRF7t8xkbbKlTxubCwEGzdujUsGsfG xirFpwpBtyzucdL1Seh7OsnpiZnKhEKa0bZVKjLPD964OLR22y0NJxBKigOcTcTFLmJjE3Gxi9jY RWxsIi52+YyNtlWY4lOF58DAQNDV1bWkDQ4OJi4y661PQt+j964T2p1bD4RF548e2h+8d+x4zdc0 2z569Yng3M//NCw6//ifeoIPjr1X83U0Go1Go9FoNBot/+aLtlXYaz7jZz5laGioUpC2sr5ZKj7L 7tCJC+H9OlV4arkVM3u2V67nnHl9R7Q2H0Xdp8uOuNhFbGwiLnYRG7uIjU3ExS6fsdG2mHAopTIX n5pQ6I4th1ueUOib+blg+jc9YcGpW6VoFlsf2KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpa fOqWKSo6dcZT13mmEU4itO2WsOjUdZ1ZTCKUBPu0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXxmVLZ is/47VMGdiab+depLjqvnG99YqI02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlMpUfL4yOhEW nWlvn6Ii081c286i02Gftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlMqQ/F5cWY+6L7v7bDw3Pbs yWht8+JFZ9a3S2kF+7RNxMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUtGLz8d3fRwWnTdvHA3OTc9F a5tjteh02KdtIi52ERubiItdxMYuYmMTcbHLZ2y0LYrPlIpafGpYrYbXqvB8+rVkw2OtF50O+7RN xMUuYmMTcbGL2NhFbGwiLnb5jI22RfGZUhGLT00kpKJTEwtpgqFmFaXodNinbSIudhEbm4iLXcTG LmJjE3Gxy2dstC2Kz5SKVHweOzUd3jpFhadupdKsohWdDvu0TcTFLmJjE3Gxi9jYRWxsIi52+YyN tkXxmVJRis87tx0Ni847thxu+mxnUYtOh33aJuJiF7GxibjYRWzsIjY2ERe7fMZG26L4TMl68akz nCo61Q6duBCtbazoRafDPm0TcbGL2NhEXOwiNnYRG5uIi10+Y6NtUXymZLX4jN8+ZeOOsWhtY2Up Oh32aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jMli8Wn7tWpolOz2WpW25WoyFSxWZai02Gftom4 2EVsbCIudhEbu4iNTcTFLp+x0bYoPlOyVHyOjk1Whti+MPLHaG198aJTZzx15rNM2KdtIi52ERub iItdxMYuYmMTcbHLZ2y0LYrPlNpZfJ6bngt+cO/+q8XmG5Wi86/u2hecnpiJXlFb2YtOh33aJuJi F7GxibjYRWzsIjY2ERe7fMZG26L4TKmdxeff9b1VKTqrWy2dUnQ67NM2ERe7iI1NxMUuYmMXsbGJ uNjlMzbaVqGKz4mJieDFF1+sLPf09ARTU1NLlufm5oLe3t5gfHw88fok2lV8Pv3ambDI/IuqolPX ef7+8JfRqxZ1WtHpcICzibjYRWxsIi52ERu7iI1NxMUun7HRtgp75lMFZH9/fzA7OxsWgsPDw9Ez i4WhHiddn4S+x6cTn14KC0wVmjtf/SRaW1unFp0OBzibiItdxMYm4mIXsbGL2NhEXOzyGRttq5DF 59DQUMPicaUis976JPQ9eu98tH//sK7vfDP8+t6x4zVfo/bh0YPBF5tvCovOLx78y+DEwTdrvo5G o9FoNBqNRqPR1HzRtgpVfI6NjQVdXV1LmisaVZBWr5Ok65ul4jNvbx49GxadN9y1Lzh2qv5tUHRm U2c4VXTqjKfOfHayIu3TnYS42EVsbCIudhEbu4iNTcTFLp+x0baYcCilPIvPufkrwe2D74aF58DO 5deiXrl4Npi8/7vB2avFpgpOtcmf/2kw//mH0Ss6G/u0TcTFLmJjE3Gxi9jYRWxsIi52+YyNtkXx mVJexWf8bGe9W6dMbvp2peisbuAAZxVxsYvY2ERc7CI2dhEbm4iLXT5jo21RfKaUdfGps513bDkc Fp4bd4xFa5ea2b31WqH5yz9bUnRO3n99MPfe7uiVnY192ibiYhexsYm42EVs7CI2NhEXu3zGRtui +Ewpy+Lz0IkLYdGppuVql57ZuFhgbrou+PrDkWgt6mGftom42EVsbCIudhEbu4iNTcTFLp+x0bYo PlPKqvjUNZ0qOm978J3w7GccRWc67NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Wnxdn5oOb N46Ghefjuz6O1i6a2bOdorMF7NM2ERe7iI1NxMUuYmMXsbGJuNjlMzbaFsVnSq0Un26YbfWkQrMH n6PozAD7tE3ExS5iYxNxsYvY2EVsbCIudvmMjbZF8ZlS2uJTZzlVeOpWKm6YrQpNFZwqPFWAojXs 0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdKaYrPO7cdDQvPR546ET6e/+x4MNl/fVh0fvV8f7gO rWOftom42EVsbCIudhEbu4iNTcTFLp+x0bYoPlNKUnzGr+98ZXQi+ObydHBhy01h0Tm940fBN/Nz 0SuRBfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6Vmi89jp6Yr13ee+PRSeIYzvK6z//rgyvkz 0auQJfZpm4iLXcTGJuJiF7Gxi9jYRFzs8hkbbYviM6VGxee56bngnl8fC/6Xn++/WniOBF2bDgQz 46Nh0al2eXQ4eiXywD5tE3Gxi9jYRFzsIjZ2ERubiItdPmOjbVF8plSv+FTRuWrdG+HZTrW/Xvf7 4Og9f7U4xPY3PdGrkCf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlesXnHQ/sDT6+9zvB2egs p9rZDf8suHfD49ErkDf2aZuIi13ExibiYhexsYvY2ERc7PIZG22L4jOlWsXnzlc/CT69988qRWd1 gx/s0zYRF7uIjU3ExS5iYxexsYm42OUzNtoWxWdK1cWnbqPyH9b/5+CLDf88OPezpUXn5P3XB3Pv 7Y5eibyxT9tEXOwiNjYRF7uIjV3ExibiYpfP2GhbHVt8qnjs6uoK2+DgYLS2eS/s2husvvf/C/7b T7uDw/feEHx+75+GheYXj/2YW6e0GQc4m4iLXcTGJuJiF7Gxi9jYRFzs8hkbbasji08VnsPD12ac rX7cjL33dC+5rtO1o/f+VfQKtAsHOJuIi13ExibiYhexsYvY2ERc7PIZG22L4vOqNMXnRw/8zbLC U+2zn38n/Hk0Go1Go9FoNBqNZrn94Q9/iKqb/HVs8TkxMRH09PQEU1NTwdzcXNDb2xuMj49Hzzbv 6w9Hgsn7vhMWnZObvh3MHnoxegYAAAAA4HRs8QkAAAAA8IfiEwAAAACQO4pPAAAAAEDuKD4BAAAA ALmj+Ewoq4mKkJ5i8OKLixM7xeNRLzbEzL+dO3cGL7zwQmUGaWLTXgsLC8HAwEAwMjISrVlEXNpP 73V/f38wOzu7JE7Exj/3fur9dzGRpLEgRtlrFBv+HmiverFx+HugPerFxcLfAxSfCWk64lZv0YLs qFO4TlUvNsTMHx3Utm7dGh6kxsbGKu8zsWkvxaKrq6vSVq9eHcaIuNig99fFxv1BQGzaJ55XJGks 6q1H66pjE8ffA+1VHRv+HrChOi4W/h6g+EwojyAgnaGhoYaxcI+JmR/u07T4QU1tcHCQ2LSZko3i 4Kz0/hMXf5LGoN56ZIfi0656xSd/D7RfPDb8PWBHreKz3X8PUHymoIOc60itBgDJVX9qE49DvdgQ M//in3QKsWkvJQz3PscTD3Fpr+o/0vr6+ip/JBAbvzSkbO3atZX3Vs2diU4aC2KUrXqx4e+B9mvU bxz+HvCvUVza/fcAxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAA AACA3FF8AgBKp9Z95lqZIl7T1q9fvz68GXcztP3NmzcH4+Pj0ZqlGk1pH5/6Pq34vdyS/t9lpf9/ M/S7VN9yAQDQ2Sg+AQCl44rPePGjYkiFXvX9z7q7u5cUWfF7B7rn4gWc+/5690xrdO9O0c+vXufE b+BdfQ9Dt77ePdoc/f96e3srv5P7vz/77LPLfpZ7Txz97F/96lc1//+1tlv9u65evbpS5Orm5j09 PYmKXgBAuVF8AgBKp7ooUosXovFCSs0VWPUKw3jB2ujnqKmYa+bMofs/xotf/bx4MSjxArHe9uKq i7544ey4s5LxQlXf19/fH/7u1f//ett170u86HTiPxsAAKH4BACUjivs4oWiU11gqhBzj1WA/fjH P15WMMULOBVi8dfXOrvXqPjU97v/V/X/M1581vrZ9bYXV130uQIx/nPjv6Me/+IXvwgeeOCByrrq /38z263+XZr5HgBAZ6H4BACgZFRgJ7l21J0JzVIePxMAUGwUnwAAAACA3FF8AgAAAAByR/EJAAAA AMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAA AAByR/EJAAAAAMgdxScAAAAAIHcUnwCAQpqbmwvWrl0b9PX1BbOzs5V169evD6ampsLHK3E/o6ur K2yDg4NL1tf72dXf193dHYyPj4evs6zTfl8AgC0UnwAA7+bmrwSHTlwI28WZ+WhtMq442r9/f6Vo ihdMMjExEaxZs6ZSNI2MjITrnerX7927NxgeHl7xZ1d/nw/fzM8FX588ELZvLk9Ha5Mp0u8LACgf ik8AQMsee+lUsGrdm17awM7FM27xgkhFZn9/fzA9PV1ZNzY2Vjmz5wwNDS0pQPUz4mf0VIi59Y1+ dhbF2MzurcG5Dd9qqk3+7FvB2XuXr4s/rtcuPbMx2mJ7f18AACg+AQDevDI6Efxt31vLCsp//Q8j wc5XP4le1Zzqgsid5Vy9enWlYOrt7a0MD9XzPT09SwqoekVVMz/bVzE2e/C5YPKX/3JZUTm58Z8H M6/viF7VnCL8vgCA8qL4BAB4tfvARHDTvdcK0O/f81bw/Jt/jJ5FLZfffTE4/8B3rxWe9/95cHn/ /x09CwBAMVB8AgAAAAByR/EJAAAAAMgdxScAAAAAIHcUnwAAAACA3FF8AgAAAAByR/EJAAAAAMgd xScAAAAAIHdh8Xn8+PHzWqDRaDQajUaj0Wg0Gi2Pdvz48fP/Pwyc/KN5rRTtAAAAAElFTkSuQmCC --000000000000b26752056f3991da-- From nobody Fri Jun 22 06:11:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D5130E5A for ; Fri, 22 Jun 2018 06:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 sDrmS-apHgMY for ; Fri, 22 Jun 2018 06:11:47 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 A3176130E59 for ; Fri, 22 Jun 2018 06:11:47 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id k18-v6so2360699ywm.11 for ; Fri, 22 Jun 2018 06:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=30NyicC0wwKHU9sNYE1WVnUBHAiQ5BZi+Li3DEQNZ4U=; b=eenP6gb4u89tKRWpScnH3R0lSDftxVUA0dkPejl7D+ihQ4Fyoe7VvEgqNATNAifDnr qnRVf576jqeEiFVuaGhM2lJ5f0o6bCLnmwaoBJCnW2xhzCCmz45kr2H6dRqLycdYUncD AHYZnuO3cY8FxRfarQDY7jGxuQuIwLUToaZdB3BD8iIDoQGlcBzQ1FbxcYAkx+gHq7Wg NyX4kL9IrdWevu9of6AsKuL3ZMjGn2uy1Ko8u6GSl1gL5hy5KECuIrSRhZ/yHxyENMGK +xsp7SJy5sthsb+Ro1Q7/NzciZobGHVl7ZzFiH8f1emHBN3usNQ/WRC2y1cWJrR1AMj6 vniA== 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=30NyicC0wwKHU9sNYE1WVnUBHAiQ5BZi+Li3DEQNZ4U=; b=mugc9O444Hy3j74BOnpkXX+PTgIaE7dyjLG3kOPUbUEo4OEcrYN1+DuhsLDmrpgq8L nlKUO/gWApbk9f2JtuyI7Kidy76QeLeCgsuBa+PKoVh5DsVlFr59d8F20SHTvxpkjMzO I/Pb1T9/qHrNLV29u/BMN66QqmIno+nB85D70TXcf+L/r5Vv1qtt5ljU1+5ZDxlWaQoF F1dJXU3rb6aLlgncTdcW7U8T2Rj/oKJTmacFbrMkuUgx31c/sYJ1PPSPrK8E+zoz+kDV FasEWrpOKrxax2iiJy6RkCmb9OIPI3d13pZ9p8WWgpeYv13+HvOZsKM03RlFIiCwGpAX NeIQ== X-Gm-Message-State: APt69E1uEUbFDYr7QSg0dxfbTsNcUMW/+zvxuZBqiy2jL9er6r88qTut CN7JxnQqDFXHKT1o54tDhnvs8Mor067uuJKCjvBgUQ== X-Google-Smtp-Source: ADUXVKKU3aXJBL4w8r2o47yWX5lxOE6VB0GYFLdLuysEaKqGn4IVBmHRSC8+VLspk7MEOSAePWiMA2owVTqo9oOnCMU= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr699417ywf.489.1529673106681; Fri, 22 Jun 2018 06:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 06:11:05 -0700 (PDT) In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> From: Eric Rescorla Date: Fri, 22 Jun 2018 06:11:05 -0700 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Kazuho Oku Cc: "Deval, Manasi" , Marten Seemann , Ian Swett , Jana Iyengar , Praveen Balasubramanian , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000002587e7056f3ac668" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 13:11:53 -0000 --0000000000002587e7056f3ac668 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like there are two questions at hand here: 1. Would it be architecturally better to have frames have a consistent self-contained representation? 2. Is it enough better that we should do so now. I agree with Kazuho that (a) we don't have that representation now and (b) it would be a better design to do so. I'm perhaps somewhat more positive on (2) than he is. I don't think it's critically important that we make the change, but if we were to hold a consensus call, I think I would be in favor. I'd certainly be interested in looking at a proposal if someone else were to make one. -Ekr On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku wrote: > 2018-06-22 8:08 GMT+09:00 Deval, Manasi : > > I feel that the requirement to have every value valid is somewhat > academic. > > I think that Marten is correct in pointing out that making the ACK > frame self-containing (by having a field that represents the number of > octets being consumed by the frame) would be an exception from the > design pattern we have. > > Look at STREAM frame. The field is not self-contained. Instead, it has > a Length field for the Stream Data, which is a leaf. The same goes for > NEW_CONNECTION_ID frame (that has the length field for Connection ID > field (which is also a leaf)), CONNECTION_CLOSE (length field for > Reason Phase). > > I agree with Marten, Mikkel (and possibly others as well) that having > consistency is important. > > Therefore, I agree with Mikkel that we should consider making every > frame self-contained or keeping every frame as-is (i.e. not > self-contained). > > FWIW, as described in the latter half of > https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it > is possible to make every frame self-contained *and* also make ACK > frames smaller than the current draft. Making every frame > self-contained gives us the possibility to send new extension frames > without negotiation. > > I do not think that I would push for making every frame self-contained > by myself (because I do not think it meets the high bar to have a > change at such a late moment of standardization), but as stated, my > preference goes to seeing every frame made self-contained or none of > them made as such. > > > The length value provides much more value than the block count and the > fact > > that certain values can never be achieved is an inherent property of th= e > > length. > > > > > > > > One interesting observation is that this property is not limited to > length. > > One can even make a similar argument about ACK block count. The maximum > > number of ACK blocks that can be defined will not always have a > meaningful > > value. In out examples, 0,1,2,3 are all valid. If I set the value of AC= K > > block count to have lower two bits to be 11, the maximum value is of AC= K > > blocks is =E2=80=93 4611686018427387903. This is the same value of larg= est > > acknowledged so if the ACK block count was set to this value, it would > still > > be meaningless. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Tuesday, June 19, 2018 6:44 PM > > To: Deval, Manasi > > Cc: Ian Swett ; Kazuho Oku ; > Eric > > Rescorla ; Jana Iyengar ; Praveen > > Balasubramanian ; IETF QUIC WG ; > Martin > > Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Hi Manasi, > > > > > > > >> The risk of disagreement between ack blocks and ack block count is sam= e > as > >> the risk of disagreement between ack blocks and ack length. Either way > this > >> needs to be counted up while creating the ACK and counted down while > parsing > >> it. The possibility of error is the same. Getting the ack block count > wrong > >> is as problematic as getting the ack length wrong. Do you agree? > > > > > > > > I disagree. Let's take an example of an ACK frame with one ACK range, > that > > needs a 2 byte varint to represent the First ACK Block and another 2 by= te > > varint to represent the Gap. > > > > With your proposal: > > > > The values 0 and 1 are invalid, since the length fields itself is > included > > in the length. > > The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - = 1 > are > > invalid, since the length needs to include the Largest Acknowledged and > the > > Ack Delay. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the fir= st > > valid value, and correspond to an ACK frame with no blocks. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, > since > > it would cut the varint for the First ACK Block > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, > since > > it would cut the frame after the First ACK Block (but every block must = be > > followed by a gap length) > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, > since > > it would cut the varint for the Gap > > Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is > valid > > > > There are *a lot* of invalid values that you can encode into the ACK > length > > field. More importantly, *none* of these error cases exists with the > current > > frame format. > > > > The *only* error case that can occur with our current format is that th= e > > packet is too short for the number of ACK blocks that are supposed to > > contained in the frame. This can occur with your proposal as well (in > > addition to the error cases listed above). > > > > > > > > My concern is not that it's impossible or even particularly hard to cat= ch > > these errors, but I dislike the property that some (in fact, most) > encodable > > values are invalid. > > > > > > > > Best, > > > > Marten > > > > > > > > > > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > > wrote: > > > > Hi Ian, > > > > > > > > Here is another attempt to solve the objections you raised: > > > > > > > >>I'm not a fan of this proposal, because I think it is impractical to dr= op > >> the number of ack blocks, because with the ECN proposal it becomes > >> impractically complex to parse. > > > > Is there a reason the proposal from Christian does not solve this > problem? > > > > > > > >>If we don't remove the number of ack blocks, then the ack frame is > larger, > >> but I don't think the extra size field is useful for most > implementations. > >> Also, it means the length can disagree with the actual length, which a= dd > >> complexity and the possibility of writing error-prone code. The idea = of > >> someone offloading ack processing and then proceeding to trust the > length > >> seems like someone could get wrong and cause some concerning issues. > > > > The risk of disagreement between ack blocks and ack block count is same > as > > the risk of disagreement between ack blocks and ack length. Either way > this > > needs to be counted up while creating the ACK and counted down while > parsing > > it. The possibility of error is the same. Getting the ack block count > wrong > > is as problematic as getting the ack length wrong. Do you agree? > > > > > > > >>My experience is multithreaded packet processing is more cost and work > than > >> it's worth. Sure you can't fill a 100G NIC with one connection, but > that > >> seems like an academic problem, not one for workloads I've seen. > Typically > >> the extra cost of multithreading outweighs its value. > > > > The value is two fold =E2=80=93 pre-processing and multi-threading. If = we > > pre-process the received packets such that ACKs and streams can be > > coalesced, the receive side can indicate a large chunk of information > though > > the kernel, reducing the cost of system call and protocol overhead. Thi= s > is > > the same concept as UDP segmentation taken a step further on receive > side. > > After this chunk is indicated into the QUIC protocol, the protocol may > > process stream and ACK in parallel. While folks may or may not utilize > this, > > there is an advantage here. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Ian Swett [mailto:ianswett@google.com] > > Sent: Tuesday, June 19, 2018 11:26 AM > > To: Deval, Manasi > > Cc: Marten Seemann ; Kazuho Oku > > ; Eric Rescorla ; Jana Iyengar > > ; Praveen Balasubramanian ; > IETF > > QUIC WG ; Martin Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > I'm still not interested in this change, for the reasons I stated above= . > > > > > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > > wrote: > > > > Hi All, > > > > > > > > Do we have agreement here to create a new PR? > > > > > > > > Thanks, > > > > Manasi > > > > > > > > From: Deval, Manasi > > Sent: Sunday, June 17, 2018 2:25 PM > > To: Marten Seemann ; Kazuho Oku > > > > Cc: Ian Swett ; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > > > Subject: RE: Proposal to replace ACK block count with ACK length > > > > > > > > Hi All, > > > > > > > > I have made a list of objections to the proposal and the solutions to > those > > objections discussed on this thread. > > > > > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > > > > > Christian suggested to move the ECN fields to precede the ACK blocks. > This > > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits > > would have been annoying, even though it can work. > > > > > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse= ACK to > > identify length. There are some reservations when ACK parsing gets hard= er > > for the case where the entire header needs to be parsed. > > > > > > > > Agreement from several folks here. In the original ACK defined in draft > 12 > > of the slide, one would count down number of ACK blocks to get to the > end of > > the packet. In the proposal I made, one would count down the length to > > identify the end of the packet. The logic is very similar in cycle coun= t > and > > complexity. Several folks also commented to this effect. > > > > > > > > c. Multi-threaded packet processing > > > > > > > > I would expect that there are 10s of 1000s of connections in use at any > time > > for a server with a high speed link. Multi-threading to handle each of > these > > flows / connections in parallel is necessity to be able to support larg= e > > number of connections on a high speed link. Tx segmentation, Rx > coalescing > > are well known strategies to reduce the processing cost. In initial > stages, > > code is often written as a single-threaded and then re-factored to > > parallelize cycle intensive operations. In order to allow this protocol > to > > scale in future, I would suggest we do not preclude this case. > > > > > > > > d. Increase in ACK size by 1 byte. > > > > > > > > I do not see this as a serious issue but if folks but we can consider > making > > this a varint, if others have strong feelings about it. It=E2=80=99s a = trade-off > : 2 > > reads to save 1 byte. > > > > > > > > e. Every encodable value should be valid > > > > Not every length will be valid. This is inherent to lengths. This same > issue > > ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does= the issue exist > for > > small values, it also applies to large values since data stream will be > sent > > after crypto negotiation. E.g. - how does one craft a payload with 62 > bit > > payload length in a large header? > > > > > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Sunday, June 17, 2018 6:59 AM > > To: Kazuho Oku > > Cc: Ian Swett ; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > ; Deval, Manasi > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the who= le > > packet, so as long as the packet payload is long enough, the varint > parsing > > will not fail. > > > > I don't think that specifics of programming languages matter here thoug= h, > > and I'm sure both frame formats can be reasonably implemented in C as > well > > as in Go. The reasons I'm opposed to Manasi's proposal are that it move= s > us > > away from the principle that only reasonable values should be encodable= , > and > > that it increases the size of the ACK frame, for the questionable > benefit of > > being able to parallelise the frame parser. > > > > > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > >> At least for my implementation, parsing doesn't become easier, it > becomes > >> more complex with this proposal. My varint-parser always consumes as > many > >> bytes as the varint requires, so after parsing a varint, I'd have to > >> introduce an additional check that this didn't overflow the ACK length > >> (e.g. > >> consider that I parsed the ACK frame so far that only 2 bytes are > >> remaining > >> according to ACK length field, but the next varint is 4 bytes long). > > > > Isn't your varint parser checking that it has not (or will not) run > > across the end of the packet payload for every ACK block it parses? > > I'd assume that you would be doing that, because I think that is > > necessary to avoid buffer overrun. > > > > What I am saying that that check could be converted to a overrun check > > against the end of the "frame payload", and that checking the > > remaining block count becomes unnecessary, in case we replace ACK > > Block Count with ACK Frame Length. > > > >> > >> In general, we've been moving the wire image towards making every > >> encodable > >> value valid. This proposal moves us away from that principle: > >> * some small values are always invalid (the length can never be betwee= n > 0 > >> and 3) > >> * a lot of intermediate values are invalid (if the boundary falls > inside a > >> varint, as described above) > >> Both these cases can't occur with the current ACK frame format. > >> > >> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote= : > >>> > >>> 2018-06-17 8:34 GMT+09:00 Ian Swett > >>> : > >>> > I'm not a fan of this proposal, because I think it is impractical t= o > >>> > drop > >>> > the number of ack blocks, because with the ECN proposal it becomes > >>> > impractically complex to parse. > >>> > >>> For the ECN proposal, as Christian has suggested, we can move the ECN > >>> counters before the ACK blocks. Then, it would not be complex to > >>> parse. > >>> > >>> And my view is that parsing becomes easier if we replace ACK Block > >>> Count with ACK Frame Length. > >>> > >>> Now, with ACK Block Count, we need to check the remaining number of > >>> blocks and the remaining space in the packet payload for every block > >>> that we parse. Failing to check either leads to a bug or a security > >>> issue. > >>> > >>> If we switch to ACK Frame Length, we need to only check the remaining > >>> space in the frame. > >>> > >>> I think that this is the biggest benefit of replacing ACK Block Count > >>> with ACK Frame Length. OTOH the downside is that you need extra one t= o > >>> two bits (one if the size of block / gap is expected to be below 65, > >>> two if they are expected to be above that) for encoding ACK Frame > >>> Length compared to ACK Block Count. > >>> > >>> > >>> > >>> Having said that, I honestly wonder if all the frames could have it's > >>> length being encoded (either explicitly or either as a signal that > >>> says "to the end of the packet"). Consider something like below: > >>> > >>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >>> or > >>> |1| frame-type (7) | frame-payload (*) | > >>> > >>> When MSB of the first octet set to zero, the length of the frame > >>> payload is designated by the varint that immediately follows the fram= e > >>> type. > >>> When MSB of the first octet set to one, the length of the frame > >>> payload spans to the end of the packet. > >>> > >>> In this encoding, we can always omit the Length field of a STREAM > >>> frame. So the overhead for carrying stream data will be indifferent i= n > >>> practice. > >>> > >>> For the ACK frame, we can omit the ACK Block Count field. And the > >>> overhead will be one to two bits if the ACK frame is sent in the > >>> middle of the packet (thereby using the encoding with explicit frame > >>> payload length), or one octet or more shorter if ACK is the last fram= e > >>> of the packet. > >>> > >>> We are likely to see increase of overhead for most of the other types > >>> of frames, but I do not think that would be an issue considering that > >>> they will be far seldom seen compared to STREAMs and ACKs. > >>> > >>> To summarize, my anticipation is that we can make all the frames > >>> self-contained (i.e. the length can be determined without the > >>> knowledge of how each frame is encoded) without any overhead, if we > >>> agree on making the frame type space 1 bit smaller. > >>> > >>> Finally, the biggest benefit of using a self-contained encoding of > >>> frames is that we would have the ability to introduce new optional > >>> frames without negotiation. By making the frames self-contained, QUIC > >>> endpoints will have the freedom of ignoring the frames that they do > >>> not understand. > >>> > >>> Being able to send QUIC frames defined in extensions without > >>> negotiating using Transport Parameters will be a win in both terms of > >>> security (because clients' TP is sent in clear) and flexibility > >>> (because we will be possible to send the extensions before we figure > >>> out whether the peer supports that extension). > >>> > >>> > If we don't remove the number of ack blocks, then the ack frame is > >>> > larger, > >>> > but I don't think the extra size field is useful for most > >>> > implementations. > >>> > Also, it means the length can disagree with the actual length, whic= h > >>> > add > >>> > complexity and the possibility of writing error-prone code. The id= ea > >>> > of > >>> > someone offloading ack processing and then proceeding to trust the > >>> > length > >>> > seems like someone could get wrong and cause some concerning issues= . > >>> > > >>> > My experience is multithreaded packet processing is more cost and > work > >>> > than > >>> > it's worth. Sure you can't fill a 100G NIC with one connection, bu= t > >>> > that > >>> > seems like an academic problem, not one for workloads I've seen. > >>> > Typically > >>> > the extra cost of multithreading outweighs its value. > >>> > > >>> > To be clear, I don't think this is an awful idea, but I also don't > see > >>> > the > >>> > value and it adds complexity. I read Manasi's email, but I don't > think > >>> > I > >>> > understand why any of those matter in practice. > >>> > > >>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >>> >> > >>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >>> >> > >>> >> wrote: > >>> >>> > >>> >>> This proposal increases the size of the ACK frame by 1 byte in th= e > >>> >>> common > >>> >>> case (less than 63 ACK ranges), since the ACK length field here > >>> >>> always > >>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-lengt= h > >>> >>> integer. > >>> >>> Considering how much work we put into minimising the size of the > >>> >>> frames, > >>> >>> this feels like a step in the wrong direction.. > >>> >>> > >>> >>> Regarding the processing cost, I agree with Dmitri. Handling an A= CK > >>> >>> frame > >>> >>> requires looping over and making changes to a data structure that > >>> >>> keeps > >>> >>> track of sent packets. This is much more expensive than simply > >>> >>> parsing > >>> >>> a > >>> >>> bunch of varints in the ACK frame. It seems unlikely that a > >>> >>> multi-threaded > >>> >>> packet parser would offer any real-world performance benefits. > >>> >> > >>> >> > >>> >> I don't want to overstate the benefit here, but my point isn't tha= t > >>> >> parsing is expensive but that if you want to have a multithreaded > >>> >> packet > >>> >> processing system, then it's nice to have a simpler data structure > >>> >> (the > >>> >> unparsed ACK block) to hand to the ACK processing thread. > >>> >> > >>> >> -Ekr > >>> >> > >>> >> > >>> >>> > >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >>> >>> > >>> >>> wrote: > >>> >>>> > >>> >>>> When we discussed this before, some people observed that this > >>> >>>> creates > >>> >>>> a need to encode in two passes. That's the trade-off here. (No= t > >>> >>>> expressing an opinion.) > >>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >>> >>>> wrote: > >>> >>>> > > >>> >>>> > I don't have a strong opinion on this. I'm certainly not oppos= ed > >>> >>>> > to > >>> >>>> > it. > >>> >>>> > Does anyone have a strong opposition? > >>> >>>> > > >>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >>> >>>> > wrote: > >>> >>>> >> > >>> >>>> >> I agree as well since this can help reduce per packet > processing > >>> >>>> >> overhead. ACKs are going to be the second most common frame > type > >>> >>>> >> so no > >>> >>>> >> objections to special casing. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >>> >>>> >> Rescorla > >>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >>> >>>> >> To: Deval, Manasi > >>> >>>> >> Cc: Jana Iyengar ; QUIC WG > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> I agree with Manasi here. This change would allow ack frame > >>> >>>> >> parsing > >>> >>>> >> to be more self-contained, which is an advantage for the pars= er > >>> >>>> >> and also > >>> >>>> >> potentially for parallelism (because you can quickly find the > >>> >>>> >> frame and then > >>> >>>> >> process it in parallel). > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> -Ekr > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> In general, varints require some specific logic for parsing. = To > >>> >>>> >> skip > >>> >>>> >> over any header, I have to read every single varint. As the > code > >>> >>>> >> sees Stream > >>> >>>> >> and ACK headers most frequently, that is my focus. The Strea= m > >>> >>>> >> frame has a > >>> >>>> >> length in its third field. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identif= y > >>> >>>> >> length. There are two reads each for =E2=80=98largest acknowl= edged=E2=80=99, > =E2=80=98ACK > >>> >>>> >> delay=E2=80=99 and > >>> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the tota= l number of cycles > >>> >>>> >> parse an > >>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packe= ts > >>> >>>> >> have a > >>> >>>> >> piggybacked ACK, these cycles becomes a significant bottlenec= k. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> Thanks, > >>> >>>> >> > >>> >>>> >> Manasi > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >>> >>>> >> Iyengar > >>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >>> >>>> >> To: Deval, Manasi ; QUIC WG > >>> >>>> >> > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> You're right that we no longer have the ability to skip an AC= K > >>> >>>> >> frame, > >>> >>>> >> and this crept in when we moved to varints. > >>> >>>> >> > >>> >>>> >> I believe your problem though is generally true of most frame= s > >>> >>>> >> not > >>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all fram= es > >>> >>>> >> are now all > >>> >>>> >> varints. To skip any frame, you'll need to parse the varint > >>> >>>> >> fields > >>> >>>> >> in those > >>> >>>> >> frames. If you have logic to process and skip varints, then > >>> >>>> >> skipping the ack > >>> >>>> >> block section is merely repeating this operation > (2*num_block+1) > >>> >>>> >> times. Do > >>> >>>> >> you see specific value in skipping ACK frames over the other > >>> >>>> >> control frames? > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote= : > >>> >>>> >> > - Moving the ACK length to the front of the ACK allo= ws > >>> >>>> >> > the > >>> >>>> >> > flexibility of either reading the entire ACK or > >>> >>>> >> > reading > >>> >>>> >> > the > >>> >>>> >> > first 16 bits and skipping over the length. This i= s > a > >>> >>>> >> > useful > >>> >>>> >> > feature for the case where ACK processing is split > >>> >>>> >> > into > >>> >>>> >> > multiple layers. Depending on the processor this i= s > >>> >>>> >> > run > >>> >>>> >> > on, > >>> >>>> >> > there are different advantages - > >>> >>>> >> > >>> >>>> >> Just a note. In my experience, the cost of parsing an ACK > frame > >>> >>>> >> is > >>> >>>> >> negligible compared to the cost of processing an ACK frame: > that > >>> >>>> >> is, > >>> >>>> >> poking at various memory locations to discard newly ACKed > >>> >>>> >> packets. > >>> >>>> >> > >>> >>>> >> - Dmitri. > >>> >>>> >> > >>> >>>> >> > >>> >>>> > >>> >> > >>> > > >>> > >>> > >>> > >>> -- > >>> Kazuho Oku > > > > > > > > -- > > Kazuho Oku > > > > -- > Kazuho Oku > --0000000000002587e7056f3ac668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like there are two questions at hand here:

1. Would it be architecturally better to have frame= s have a consistent self-contained
representation?
2. I= s it enough better that we should do so now.

I agr= ee with Kazuho that (a) we don't have that representation now and (b) i= t would
be a better design to do so. I'm perhaps somewhat mor= e positive on (2) than he
is. I don't think it's critical= ly important that we make the change, but if we were
to hold a co= nsensus call, I think I would be in favor. I'd certainly be interested<= /div>
in looking at a proposal if someone else were to make one.

-Ekr



On Thu, Jun 21, 2018 at= 8:45 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-22 8:08 GMT+09:00 Deval,= Manasi <manasi.deval@intel.co= m>:
> I feel that the requirement to have every value valid is somewhat acad= emic.

I think that Marten is correct in pointing out that making the ACK frame self-containing (by having a field that represents the number of
octets being consumed by the frame) would be an exception from the
design pattern we have.

Look at STREAM frame. The field is not self-contained. Instead, it has
a Length field for the Stream Data, which is a leaf. The same goes for
NEW_CONNECTION_ID frame (that has the length field for Connection ID
field (which is also a leaf)), CONNECTION_CLOSE (length field for
Reason Phase).

I agree with Marten, Mikkel (and possibly others as well) that having
consistency is important.

Therefore, I agree with Mikkel that we should consider making every
frame self-contained or keeping every frame as-is (i.e. not
self-contained).

FWIW, as described in the latter half of
https://www.ietf.org/mail-archi= ve/web/quic/current/msg04287.html, it
is possible to make every frame self-contained *and* also make ACK
frames smaller than the current draft. Making every frame
self-contained gives us the possibility to send new extension frames
without negotiation.

I do not think that I would push for making every frame self-contained
by myself (because I do not think it meets the high bar to have a
change at such a late moment of standardization), but as stated, my
preference goes to seeing every frame made self-contained or none of
them made as such.

> The length value provides much more value than the block count and the= fact
> that certain values can never be achieved is an inherent property of t= he
> length.
>
>
>
> One interesting observation is that this property is not limited to le= ngth.
> One can even make a similar argument about ACK block count. The maximu= m
> number of ACK blocks that can be defined will not always have a meanin= gful
> value. In out examples, 0,1,2,3 are all valid. If I set the value of A= CK
> block count to have lower two bits to be 11, the maximum value is of A= CK
> blocks is =E2=80=93 4611686018427387903. This is the same value of lar= gest
> acknowledged so if the ACK block count was set to this value, it would= still
> be meaningless.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Tuesday, June 19, 2018 6:44 PM
> To: Deval, Manasi <manasi= .deval@intel.com>
> Cc: Ian Swett <ianswett@goog= le.com>; Kazuho Oku <kazuh= ooku@gmail.com>; Eric
> Rescorla <ekr@rtfm.com>; Jan= a Iyengar <jri.ietf@gmail.com&= gt;; Praveen
> Balasubramanian <pravb@micro= soft.com>; IETF QUIC WG <quic@ie= tf.org>; Martin
> Thomson <martin.thomson= @gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Hi Manasi,
>
>
>
>> The risk of disagreement between ack blocks and ack block count is= same as
>> the risk of disagreement between ack blocks and ack length. Either= way this
>> needs to be counted up while creating the ACK and counted down whi= le parsing
>> it. The possibility of error is the same. Getting the ack block co= unt wrong
>> is as problematic as getting the ack length wrong. Do you agree? >
>
>
> I disagree. Let's take an example of an ACK frame with one ACK ran= ge, that
> needs a 2 byte varint to represent the First ACK Block and another 2 b= yte
> varint to represent the Gap.
>
> With your proposal:
>
> The values 0 and 1 are invalid, since the length fields itself is incl= uded
> in the length.
> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) -= 1 are
> invalid, since the length needs to include the Largest Acknowledged an= d the
> Ack Delay.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the fi= rst
> valid value, and correspond to an ACK frame with no blocks.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid,= since
> it would cut the varint for the First ACK Block
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid,= since
> it would cut the frame after the First ACK Block (but every block must= be
> followed by a gap length)
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid,= since
> it would cut the varint for the Gap
> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is= valid
>
> There are *a lot* of invalid values that you can encode into the ACK l= ength
> field. More importantly, *none* of these error cases exists with the c= urrent
> frame format.
>
> The *only* error case that can occur with our current format is that t= he
> packet is too short for the number of ACK blocks that are supposed to<= br> > contained in the frame. This can occur with your proposal as well (in<= br> > addition to the error cases listed above).
>
>
>
> My concern is not that it's impossible or even particularly hard t= o catch
> these errors, but I dislike the property that some (in fact, most) enc= odable
> values are invalid.
>
>
>
> Best,
>
> Marten
>
>
>
>
>
> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi Ian,
>
>
>
> Here is another attempt to solve the objections you raised:
>
>
>
>>I'm not a fan of this proposal, because I think it is impractic= al to drop
>> the number of ack blocks, because with the ECN proposal it becomes=
>> impractically complex to parse.
>
> Is there a reason the proposal from Christian does not solve this prob= lem?
>
>
>
>>If we don't remove the number of ack blocks, then the ack frame= is larger,
>> but I don't think the extra size field is useful for most impl= ementations.
>> Also, it means the length can disagree with the actual length, whi= ch add
>> complexity and the possibility of writing error-prone code.=C2=A0 = The idea of
>> someone offloading ack processing and then proceeding to trust the= length
>> seems like someone could get wrong and cause some concerning issue= s.
>
> The risk of disagreement between ack blocks and ack block count is sam= e as
> the risk of disagreement between ack blocks and ack length. Either way= this
> needs to be counted up while creating the ACK and counted down while p= arsing
> it. The possibility of error is the same. Getting the ack block count = wrong
> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
>>My experience is multithreaded packet processing is more cost and w= ork than
>> it's worth.=C2=A0 Sure you can't fill a 100G NIC with one = connection, but that
>> seems like an academic problem, not one for workloads I've see= n.=C2=A0 Typically
>> the extra cost of multithreading outweighs its value.
>
> The value is two fold =E2=80=93 pre-processing and multi-threading. If= we
> pre-process the received packets such that ACKs and streams can be
> coalesced, the receive side can indicate a large chunk of information = though
> the kernel, reducing the cost of system call and protocol overhead. Th= is is
> the same concept as UDP segmentation taken a step further on receive s= ide.
> After this chunk is indicated into the QUIC protocol, the protocol may=
> process stream and ACK in parallel. While folks may or may not utilize= this,
> there is an advantage here.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Ian Swett [mailto:ianswet= t@google.com]
> Sent: Tuesday, June 19, 2018 11:26 AM
> To: Deval, Manasi <manasi= .deval@intel.com>
> Cc: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>= ; Eric Rescorla <ekr@rtfm.com>; J= ana Iyengar
> <jri.ietf@gmail.com>; = Praveen Balasubramanian <pravb@mi= crosoft.com>; IETF
> QUIC WG <quic@ietf.org>; Ma= rtin Thomson <martin.thomson= @gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> I'm still not interested in this change, for the reasons I stated = above.
>
>
>
> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi All,
>
>
>
> Do we have agreement here to create a new PR?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> From: Deval, Manasi
> Sent: Sunday, June 17, 2018 2:25 PM
> To: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>=
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar= <jri.ietf@gmail.com>; Prav= een Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; = Martin Thomson
> <martin.thomson@gmail.c= om>
> Subject: RE: Proposal to replace ACK block count with ACK length
>
>
>
> Hi All,
>
>
>
> I have made a list of objections to the proposal and the solutions to = those
> objections discussed on this thread.
>
>
>
> a.=C2=A0 =C2=A0 =C2=A0 Co-existence of length field with ECN field and= ACK blocks.
>
>
>
> Christian suggested to move the ECN fields to precede the ACK blocks. = This
> is an elegant solution. Parsing entire list of ACK blocks to review EC= N bits
> would have been annoying, even though it can work.
>
>
>
> b.=C2=A0 =C2=A0 =C2=A0 There are two cases to be parsed =E2=80=93 enti= re ACK and parse ACK to
> identify length. There are some reservations when ACK parsing gets har= der
> for the case where the entire header needs to be parsed.
>
>
>
> Agreement from several folks here. In the original ACK defined in draf= t 12
> of the slide, one would count down number of ACK blocks to get to the = end of
> the packet. In the proposal I made, one would count down the length to=
> identify the end of the packet. The logic is very similar in cycle cou= nt and
> complexity. Several folks also commented to this effect.
>
>
>
> c.=C2=A0 =C2=A0 =C2=A0 Multi-threaded packet processing
>
>
>
> I would expect that there are 10s of 1000s of connections in use at an= y time
> for a server with a high speed link. Multi-threading to handle each of= these
> flows / connections in parallel is necessity to be able to support lar= ge
> number of connections on a high speed link. Tx segmentation, Rx coales= cing
> are well known strategies to reduce the processing cost. In initial st= ages,
> code is often written as a single-threaded and then re-factored to
> parallelize cycle intensive operations. In order to allow this protoco= l to
> scale in future, I would suggest we do not preclude this case.
>
>
>
> d.=C2=A0 =C2=A0 =C2=A0 Increase in ACK size by 1 byte.
>
>
>
> I do not see this as a serious issue but if folks but we can consider = making
> this a varint, if others have strong feelings about it. It=E2=80=99s a= trade-off : 2
> reads to save 1 byte.
>
>
>
> e.=C2=A0 =C2=A0 =C2=A0 Every encodable value should be valid
>
> Not every length will be valid. This is inherent to lengths. This same= issue
> ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only doe= s the issue exist for
> small values, it also applies to large values since data stream will b= e sent
> after crypto negotiation.=C2=A0 E.g.=C2=A0 - how does one craft a payl= oad with 62 bit
> payload length in a large header?
>
>
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Sunday, June 17, 2018 6:59 AM
> To: Kazuho Oku <kazuhooku@gm= ail.com>
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar= <jri.ietf@gmail.com>; Prav= een Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; = Martin Thomson
> <martin.thomson@gmail.c= om>; Deval, Manasi <man= asi.deval@intel.com>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Maybe it's specific to Go, but I'm using a single io.Reader fo= r the whole
> packet, so as long as the packet payload is long enough, the varint pa= rsing
> will not fail.
>
> I don't think that specifics of programming languages matter here = though,
> and I'm sure both frame formats can be reasonably implemented in C= as well
> as in Go. The reasons I'm opposed to Manasi's proposal are tha= t it moves us
> away from the principle that only reasonable values should be encodabl= e, and
> that it increases the size of the ACK frame, for the questionable bene= fit of
> being able to parallelise the frame parser.
>
>
>
> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> 2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.com>:
>> At least for my implementation, parsing doesn't become easier,= it becomes
>> more complex with this proposal. My varint-parser always consumes = as many
>> bytes as the varint requires, so after parsing a varint, I'd h= ave to
>> introduce an additional check that this didn't overflow the AC= K length
>> (e.g.
>> consider that I parsed the ACK frame so far that only 2 bytes are<= br> >> remaining
>> according to ACK length field, but the next varint is 4 bytes long= ).
>
> Isn't your varint parser checking that it has not (or will not) ru= n
> across the end of the packet payload for every ACK block it parses? > I'd assume that you would be doing that, because I think that is > necessary to avoid buffer overrun.
>
> What I am saying that that check could be converted to a overrun check=
> against the end of the "frame payload", and that checking th= e
> remaining block count becomes unnecessary, in case we replace ACK
> Block Count with ACK Frame Length.
>
>>
>> In general, we've been moving the wire image towards making ev= ery
>> encodable
>> value valid. This proposal moves us away from that principle:
>> * some small values are always invalid (the length can never be be= tween 0
>> and 3)
>> * a lot of intermediate values are invalid (if the boundary falls = inside a
>> varint, as described above)
>> Both these cases can't occur with the current ACK frame format= .
>>
>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>>> <ianswett=3D= 40google.com@dmarc.ietf.org>:
>>> > I'm not a fan of this proposal, because I think it is= impractical to
>>> > drop
>>> > the number of ack blocks, because with the ECN proposal i= t becomes
>>> > impractically complex to parse.
>>>
>>> For the ECN proposal, as Christian has suggested, we can move = the ECN
>>> counters before the ACK blocks. Then, it would not be complex = to
>>> parse.
>>>
>>> And my view is that parsing becomes easier if we replace ACK B= lock
>>> Count with ACK Frame Length.
>>>
>>> Now, with ACK Block Count, we need to check the remaining numb= er of
>>> blocks and the remaining space in the packet payload for every= block
>>> that we parse. Failing to check either leads to a bug or a sec= urity
>>> issue.
>>>
>>> If we switch to ACK Frame Length, we need to only check the re= maining
>>> space in the frame.
>>>
>>> I think that this is the biggest benefit of replacing ACK Bloc= k Count
>>> with ACK Frame Length. OTOH the downside is that you need extr= a one to
>>> two bits (one if the size of block / gap is expected to be bel= ow 65,
>>> two if they are expected to be above that) for encoding ACK Fr= ame
>>> Length compared to ACK Block Count.
>>>
>>>
>>>
>>> Having said that, I honestly wonder if all the frames could ha= ve it's
>>> length being encoded (either explicitly or either as a signal = that
>>> says "to the end of the packet"). Consider something= like below:
>>>
>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload = (*) |
>>>=C2=A0 or
>>> |1| frame-type (7) | frame-payload (*) |
>>>
>>> When MSB of the first octet set to zero, the length of the fra= me
>>> payload is designated by the varint that immediately follows t= he frame
>>> type.
>>> When MSB of the first octet set to one, the length of the fram= e
>>> payload spans to the end of the packet.
>>>
>>> In this encoding, we can always omit the Length field of a STR= EAM
>>> frame. So the overhead for carrying stream data will be indiff= erent in
>>> practice.
>>>
>>> For the ACK frame, we can omit the ACK Block Count field. And = the
>>> overhead will be one to two bits if the ACK frame is sent in t= he
>>> middle of the packet (thereby using the encoding with explicit= frame
>>> payload length), or one octet or more shorter if ACK is the la= st frame
>>> of the packet.
>>>
>>> We are likely to see increase of overhead for most of the othe= r types
>>> of frames, but I do not think that would be an issue consideri= ng that
>>> they will be far seldom seen compared to STREAMs and ACKs.
>>>
>>> To summarize, my anticipation is that we can make all the fram= es
>>> self-contained (i.e. the length can be determined without the<= br> >>> knowledge of how each frame is encoded) without any overhead, = if we
>>> agree on making the frame type space 1 bit smaller.
>>>
>>> Finally, the biggest benefit of using a self-contained encodin= g of
>>> frames is that we would have the ability to introduce new opti= onal
>>> frames without negotiation. By making the frames self-containe= d, QUIC
>>> endpoints will have the freedom of ignoring the frames that th= ey do
>>> not understand.
>>>
>>> Being able to send QUIC frames defined in extensions without >>> negotiating using Transport Parameters will be a win in both t= erms of
>>> security (because clients' TP is sent in clear) and flexib= ility
>>> (because we will be possible to send the extensions before we = figure
>>> out whether the peer supports that extension).
>>>
>>> > If we don't remove the number of ack blocks, then the= ack frame is
>>> > larger,
>>> > but I don't think the extra size field is useful for = most
>>> > implementations.
>>> > Also, it means the length can disagree with the actual le= ngth, which
>>> > add
>>> > complexity and the possibility of writing error-prone cod= e.=C2=A0 The idea
>>> > of
>>> > someone offloading ack processing and then proceeding to = trust the
>>> > length
>>> > seems like someone could get wrong and cause some concern= ing issues.
>>> >
>>> > My experience is multithreaded packet processing is more = cost and work
>>> > than
>>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC = with one connection, but
>>> > that
>>> > seems like an academic problem, not one for workloads I&#= 39;ve seen.
>>> > Typically
>>> > the extra cost of multithreading outweighs its value.
>>> >
>>> > To be clear, I don't think this is an awful idea, but= I also don't see
>>> > the
>>> > value and it adds complexity.=C2=A0 I read Manasi's e= mail, but I don't think
>>> > I
>>> > understand why any of those matter in practice.
>>> >
>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>> >>
>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>>> >> <marten= seemann@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> This proposal increases the size of the ACK frame= by 1 byte in the
>>> >>> common
>>> >>> case (less than 63 ACK ranges), since the ACK len= gth field here
>>> >>> always
>>> >>> consumes 2 bytes, whereas the ACK Block Count is = a variable-length
>>> >>> integer.
>>> >>> Considering how much work we put into minimising = the size of the
>>> >>> frames,
>>> >>> this feels like a step in the wrong direction.. >>> >>>
>>> >>> Regarding the processing cost, I agree with Dmitr= i. Handling an ACK
>>> >>> frame
>>> >>> requires looping over and making changes to a dat= a structure that
>>> >>> keeps
>>> >>> track of sent packets. This is much more expensiv= e than simply
>>> >>> parsing
>>> >>> a
>>> >>> bunch of varints in the ACK frame. It seems unlik= ely that a
>>> >>> multi-threaded
>>> >>> packet parser would offer any real-world performa= nce benefits.
>>> >>
>>> >>
>>> >> I don't want to overstate the benefit here, but m= y point isn't that
>>> >> parsing is expensive but that if you want to have a m= ultithreaded
>>> >> packet
>>> >> processing system, then it's nice to have a simpl= er data structure
>>> >> (the
>>> >> unparsed ACK block) to hand to the ACK processing thr= ead.
>>> >>
>>> >> -Ekr
>>> >>
>>> >>
>>> >>>
>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >>> >>> <m= artin.thomson@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> When we discussed this before, some people ob= served that this
>>> >>>> creates
>>> >>>> a need to encode in two passes.=C2=A0 That= 9;s the trade-off here.=C2=A0 (Not
>>> >>>> expressing an opinion.)
>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar = <jri.ietf@gmail.com>
>>> >>>> wrote:
>>> >>>> >
>>> >>>> > I don't have a strong opinion on thi= s. I'm certainly not opposed
>>> >>>> > to
>>> >>>> > it.
>>> >>>> > Does anyone have a strong opposition? >>> >>>> >
>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen = Balasubramanian
>>> >>>> > <pravb@microsoft.com> wrote:
>>> >>>> >>
>>> >>>> >> I agree as well since this can help = reduce per packet processing
>>> >>>> >> overhead. ACKs are going to be the s= econd most common frame type
>>> >>>> >> so no
>>> >>>> >> objections to special casing.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric
>>> >>>> >> Rescorla
>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM<= br> >>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>
>>> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK= block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> I agree with Manasi here. This chang= e would allow ack frame
>>> >>>> >> parsing
>>> >>>> >> to be more self-contained, which is = an advantage for the parser
>>> >>>> >> and also
>>> >>>> >> potentially for parallelism (because= you can quickly find the
>>> >>>> >> frame and then
>>> >>>> >> process it in parallel).
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> -Ekr
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Dev= al, Manasi
>>> >>>> >> <manasi.deval@intel.com> wrote:
>>> >>>> >>
>>> >>>> >> In general, varints require some spe= cific logic for parsing. To
>>> >>>> >> skip
>>> >>>> >> over any header, I have to read ever= y single varint. As the code
>>> >>>> >> sees Stream
>>> >>>> >> and ACK headers most frequently, tha= t is my focus.=C2=A0 The Stream
>>> >>>> >> frame has a
>>> >>>> >> length in its third field.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> ACK parsing, however, needs 6 + 2*nu= m_blocks reads to identify
>>> >>>> >> length. There are two reads each for= =E2=80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>>> >>>> >> delay=E2=80=99 and
>>> >>>> >> =E2=80=98ACK block count=E2=80=99. T= he pain point is the total number of cycles
>>> >>>> >> parse an
>>> >>>> >> ACK. If I am processing 10M pps, whe= re 10% - 30% of the packets
>>> >>>> >> have a
>>> >>>> >> piggybacked ACK, these cycles become= s a significant bottleneck.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Thanks,
>>> >>>> >>
>>> >>>> >> Manasi
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana
>>> >>>> >> Iyengar
>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM<= br> >>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG
>>> >>>> >> <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK= block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> You're right that we no longer h= ave the ability to skip an ACK
>>> >>>> >> frame,
>>> >>>> >> and this crept in when we moved to v= arints.
>>> >>>> >>
>>> >>>> >> I believe your problem though is gen= erally true of most frames
>>> >>>> >> not
>>> >>>> >> just ACKs, since ids, packet numbers= , and numbers in all frames
>>> >>>> >> are now all
>>> >>>> >> varints. To skip any frame, you'= ll need to parse the varint
>>> >>>> >> fields
>>> >>>> >> in those
>>> >>>> >> frames. If you have logic to process= and skip varints, then
>>> >>>> >> skipping the ack
>>> >>>> >> block section is merely repeating th= is operation (2*num_block+1)
>>> >>>> >> times. Do
>>> >>>> >> you see specific value in skipping A= CK frames over the other
>>> >>>> >> control frames?
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmit= ri Tikhonov
>>> >>>> >> <dtikhonov@litespeedtech..com>= wrote:
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM += 0000, Deval, Manasi wrote:
>>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mo= ving the ACK length to the front of the ACK allows
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 flexibility of either reading the entire ACK or
>>> >>>> >> > reading
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 first 16 bits and skipping over the length. This is a
>>> >>>> >> > useful
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 feature for the case where ACK processing is split
>>> >>>> >> > into
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 multiple layers. Depending on the processor this is
>>> >>>> >> > run
>>> >>>> >> > on,
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 there are different advantages -
>>> >>>> >>
>>> >>>> >> Just a note.=C2=A0 In my experience,= the cost of parsing an ACK frame
>>> >>>> >> is
>>> >>>> >> negligible compared to the cost of p= rocessing an ACK frame: that
>>> >>>> >> is,
>>> >>>> >> poking at various memory locations t= o discard newly ACKed
>>> >>>> >> packets.
>>> >>>> >>
>>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>>> >>>> >>
>>> >>>> >>
>>> >>>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku

--0000000000002587e7056f3ac668-- From nobody Fri Jun 22 08:01:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79118130E91 for ; Fri, 22 Jun 2018 08:01:05 -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, UNPARSEABLE_RELAY=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 UaoBqChkiYS2 for ; Fri, 22 Jun 2018 08:00:56 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 C759B130E8E for ; Fri, 22 Jun 2018 08:00:55 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q4-v6so6390889iob.2 for ; Fri, 22 Jun 2018 08:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6zoCPnJsbftl6As3ks0tzgX4UjVBNh//HomexXxe3EA=; b=jrb2N68z77qw3R/pXOFCasD+sNwI94TAnEpyhj9gvCpwpPsXzRLF+QWtA2RSPBRjkX NLp+XYT9T+Q1hcS4tB60o75h/aEqsp1iixcfsSzgMeHHl24LYPVVY2S0lcdVfeMReozP eOUGh0ZqynH8Jm04zISi1TkVonCwWbmbdXLdzjHW5Qlec4V03rxFAXJJZVPwpgD068hR aLbDWl/fXl8CZqaF5zT4uqpOBeAliyXTDifkw6A10PeFyX9W45iRehFFWEnOCGUMMgfL 9sJzK0T3po5nPUXJKKdOFbBnA8hKbmngG1STTTEjgDPyAMWtl9HXbVjH70QxdS9E4EmT wf4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=6zoCPnJsbftl6As3ks0tzgX4UjVBNh//HomexXxe3EA=; b=oelibE0EIemM9BpwJdhPszqRPgxKqKpgvkRg2EOtUP2xYB9GT2nB6VPw2jowRieJRd IHQH0oxax4ZJ0Ualcrbcs9+VulYXHWQ09IfN0KB1myPktr7ovb0LCl2vS4J/P3FXWwiw 2b7+yNovoOmhRCf39x4fH5rgPZ7WSQRFdhvFZuxEppSRPKk498EiJzJm1thM6pYLHGg9 YkhkmksdzdmiCrs+gqbIAnN7jOKQJaOUH7ow+mkpJYfPyqL3fjiJ3XrtRz+uir57dA7a GVl4FcYtWZP53p68+/Fx5wxXSrzdEWYBLjNRKzcPB9ElZdqXeZL01/KZV1nTJiq7MUcP ds1Q== X-Gm-Message-State: APt69E1NqMd8VKra42U/Bpc9dyxTQ1IoofIAGX6P7xhn7PkcNM5tL2VE BAe09LjDNbfBVHlLyXdjiUo/YG0aUM4Hl8+gXBQ= X-Google-Smtp-Source: AAOMgpfn3skES2ftFyxs8NYr8U0l0wEYDmqB5appYINCx/iyqPe0IHnKG5M/lJAZ/V095w0GMrszScmLmQb+k+6+/1M= X-Received: by 2002:a6b:93c6:: with SMTP id v189-v6mr1585458iod.274.1529679653372; Fri, 22 Jun 2018 08:00:53 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Jun 2018 11:00:52 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 22 Jun 2018 11:00:52 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Eric Rescorla , Kazuho Oku Cc: "Deval, Manasi" , Jana Iyengar , IETF QUIC WG , Marten Seemann , Martin Thomson , Ian Swett , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="0000000000005c0ce3056f3c4cd9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:01:06 -0000 --0000000000005c0ce3056f3c4cd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I said earlier, I also favour a length prefix. But, Ian does have a point: Writing data is generally more expensive than reading data. Especially if you have to traverse long data structures to find the length before you can start writing and/or you may have to conservatively reserve extra space for a length field. So before deciding one way or the other, the cost of writing needs to be well understood, also in scenarios with large MTU=E2=80=99s. In the flatbuffers space that I=E2=80=99m involved with, streaming has turn= ed to be an issue because data cannot be transmitted in parts without index data on a separate channel to recombined fragments. A simple, but non-standard, change in the format would fix this. JSON and CoAP allows streaming, but many other formats do not, including later versions of protocol buffers, as I understand. An odd consequence of making both read and write efficient is that length better work better if stored at the end and packets read backwards. This requires a single total length prefix but this is stored in the datagram header. This is probably too odd-ball, but still a consideration worth noting. The second best alternative may therefore be to allow writes to be fast and reads to be decent. Yet, I still like length prefixes if they could be made write efficient because high performance low-latency processes care zero about ACK and can consume a packet directly while a background process handles all the latency insensitive ACK and retransmission logic. The question is also, where is the pressure: an IoT aggregator might be massively read intensive while a web cache would be very write intensive. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote: It seems like there are two questions at hand here: 1. Would it be architecturally better to have frames have a consistent self-contained representation? 2. Is it enough better that we should do so now. I agree with Kazuho that (a) we don't have that representation now and (b) it would be a better design to do so. I'm perhaps somewhat more positive on (2) than he is. I don't think it's critically important that we make the change, but if we were to hold a consensus call, I think I would be in favor. I'd certainly be interested in looking at a proposal if someone else were to make one. -Ekr On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku wrote: > 2018-06-22 8:08 GMT+09:00 Deval, Manasi : > > I feel that the requirement to have every value valid is somewhat > academic. > > I think that Marten is correct in pointing out that making the ACK > frame self-containing (by having a field that represents the number of > octets being consumed by the frame) would be an exception from the > design pattern we have. > > Look at STREAM frame. The field is not self-contained. Instead, it has > a Length field for the Stream Data, which is a leaf. The same goes for > NEW_CONNECTION_ID frame (that has the length field for Connection ID > field (which is also a leaf)), CONNECTION_CLOSE (length field for > Reason Phase). > > I agree with Marten, Mikkel (and possibly others as well) that having > consistency is important. > > Therefore, I agree with Mikkel that we should consider making every > frame self-contained or keeping every frame as-is (i.e. not > self-contained). > > FWIW, as described in the latter half of > https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it > is possible to make every frame self-contained *and* also make ACK > frames smaller than the current draft. Making every frame > self-contained gives us the possibility to send new extension frames > without negotiation. > > I do not think that I would push for making every frame self-contained > by myself (because I do not think it meets the high bar to have a > change at such a late moment of standardization), but as stated, my > preference goes to seeing every frame made self-contained or none of > them made as such. > > > The length value provides much more value than the block count and the > fact > > that certain values can never be achieved is an inherent property of th= e > > length. > > > > > > > > One interesting observation is that this property is not limited to > length. > > One can even make a similar argument about ACK block count. The maximum > > number of ACK blocks that can be defined will not always have a > meaningful > > value. In out examples, 0,1,2,3 are all valid. If I set the value of AC= K > > block count to have lower two bits to be 11, the maximum value is of AC= K > > blocks is =E2=80=93 4611686018427387903. This is the same value of larg= est > > acknowledged so if the ACK block count was set to this value, it would > still > > be meaningless. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Tuesday, June 19, 2018 6:44 PM > > To: Deval, Manasi > > > Cc: Ian Swett ; Kazuho Oku ; > Eric > > Rescorla ; Jana Iyengar ; Praveen > > Balasubramanian ; IETF QUIC WG ; > Martin > > Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Hi Manasi, > > > > > > > >> The risk of disagreement between ack blocks and ack block count is sam= e > as > >> the risk of disagreement between ack blocks and ack length. Either way > this > >> needs to be counted up while creating the ACK and counted down while > parsing > >> it. The possibility of error is the same. Getting the ack block count > wrong > >> is as problematic as getting the ack length wrong. Do you agree? > > > > > > > > I disagree. Let's take an example of an ACK frame with one ACK range, > that > > needs a 2 byte varint to represent the First ACK Block and another 2 by= te > > varint to represent the Gap. > > > > With your proposal: > > > > The values 0 and 1 are invalid, since the length fields itself is > included > > in the length. > > The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - = 1 > are > > invalid, since the length needs to include the Largest Acknowledged and > the > > Ack Delay. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the fir= st > > valid value, and correspond to an ACK frame with no blocks. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, > since > > it would cut the varint for the First ACK Block > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, > since > > it would cut the frame after the First ACK Block (but every block must = be > > followed by a gap length) > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, > since > > it would cut the varint for the Gap > > Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is > valid > > > > There are *a lot* of invalid values that you can encode into the ACK > length > > field. More importantly, *none* of these error cases exists with the > current > > frame format. > > > > The *only* error case that can occur with our current format is that th= e > > packet is too short for the number of ACK blocks that are supposed to > > contained in the frame. This can occur with your proposal as well (in > > addition to the error cases listed above). > > > > > > > > My concern is not that it's impossible or even particularly hard to cat= ch > > these errors, but I dislike the property that some (in fact, most) > encodable > > values are invalid. > > > > > > > > Best, > > > > Marten > > > > > > > > > > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > > wrote: > > > > Hi Ian, > > > > > > > > Here is another attempt to solve the objections you raised: > > > > > > > >>I'm not a fan of this proposal, because I think it is impractical to dr= op > >> the number of ack blocks, because with the ECN proposal it becomes > >> impractically complex to parse. > > > > Is there a reason the proposal from Christian does not solve this > problem? > > > > > > > >>If we don't remove the number of ack blocks, then the ack frame is > larger, > >> but I don't think the extra size field is useful for most > implementations. > >> Also, it means the length can disagree with the actual length, which a= dd > >> complexity and the possibility of writing error-prone code. The idea = of > >> someone offloading ack processing and then proceeding to trust the > length > >> seems like someone could get wrong and cause some concerning issues. > > > > The risk of disagreement between ack blocks and ack block count is same > as > > the risk of disagreement between ack blocks and ack length. Either way > this > > needs to be counted up while creating the ACK and counted down while > parsing > > it. The possibility of error is the same. Getting the ack block count > wrong > > is as problematic as getting the ack length wrong. Do you agree? > > > > > > > >>My experience is multithreaded packet processing is more cost and work > than > >> it's worth. Sure you can't fill a 100G NIC with one connection, but > that > >> seems like an academic problem, not one for workloads I've seen. > Typically > >> the extra cost of multithreading outweighs its value. > > > > The value is two fold =E2=80=93 pre-processing and multi-threading. If = we > > pre-process the received packets such that ACKs and streams can be > > coalesced, the receive side can indicate a large chunk of information > though > > the kernel, reducing the cost of system call and protocol overhead. Thi= s > is > > the same concept as UDP segmentation taken a step further on receive > side. > > After this chunk is indicated into the QUIC protocol, the protocol may > > process stream and ACK in parallel. While folks may or may not utilize > this, > > there is an advantage here. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Ian Swett [mailto:ianswett@google.com] > > Sent: Tuesday, June 19, 2018 11:26 AM > > To: Deval, Manasi > > > Cc: Marten Seemann ; Kazuho Oku > > ; Eric Rescorla ; Jana Iyengar > > ; Praveen Balasubramanian ; > IETF > > QUIC WG ; Martin Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > I'm still not interested in this change, for the reasons I stated above= . > > > > > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > > wrote: > > > > Hi All, > > > > > > > > Do we have agreement here to create a new PR? > > > > > > > > Thanks, > > > > Manasi > > > > > > > > From: Deval, Manasi > > Sent: Sunday, June 17, 2018 2:25 PM > > To: Marten Seemann ; Kazuho Oku > > > > Cc: Ian Swett <40google.com@dmarc.ietf..org>>; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > > > Subject: RE: Proposal to replace ACK block count with ACK length > > > > > > > > Hi All, > > > > > > > > I have made a list of objections to the proposal and the solutions to > those > > objections discussed on this thread. > > > > > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > > > > > Christian suggested to move the ECN fields to precede the ACK blocks. > This > > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits > > would have been annoying, even though it can work. > > > > > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse= ACK to > > identify length. There are some reservations when ACK parsing gets hard= er > > for the case where the entire header needs to be parsed. > > > > > > > > Agreement from several folks here. In the original ACK defined in draft > 12 > > of the slide, one would count down number of ACK blocks to get to the > end of > > the packet. In the proposal I made, one would count down the length to > > identify the end of the packet. The logic is very similar in cycle coun= t > and > > complexity. Several folks also commented to this effect. > > > > > > > > c. Multi-threaded packet processing > > > > > > > > I would expect that there are 10s of 1000s of connections in use at any > time > > for a server with a high speed link. Multi-threading to handle each of > these > > flows / connections in parallel is necessity to be able to support larg= e > > number of connections on a high speed link. Tx segmentation, Rx > coalescing > > are well known strategies to reduce the processing cost. In initial > stages, > > code is often written as a single-threaded and then re-factored to > > parallelize cycle intensive operations. In order to allow this protocol > to > > scale in future, I would suggest we do not preclude this case. > > > > > > > > d. Increase in ACK size by 1 byte. > > > > > > > > I do not see this as a serious issue but if folks but we can consider > making > > this a varint, if others have strong feelings about it. It=E2=80=99s a = trade-off > : 2 > > reads to save 1 byte. > > > > > > > > e. Every encodable value should be valid > > > > Not every length will be valid. This is inherent to lengths. This same > issue > > ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does= the issue exist > for > > small values, it also applies to large values since data stream will be > sent > > after crypto negotiation. E.g. - how does one craft a payload with 62 > bit > > payload length in a large header? > > > > > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Sunday, June 17, 2018 6:59 AM > > To: Kazuho Oku > > Cc: Ian Swett <40google.com@dmarc.ietf..org>>; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > ; Deval, Manasi > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the who= le > > packet, so as long as the packet payload is long enough, the varint > parsing > > will not fail. > > > > I don't think that specifics of programming languages matter here thoug= h, > > and I'm sure both frame formats can be reasonably implemented in C as > well > > as in Go. The reasons I'm opposed to Manasi's proposal are that it move= s > us > > away from the principle that only reasonable values should be encodable= , > and > > that it increases the size of the ACK frame, for the questionable > benefit of > > being able to parallelise the frame parser. > > > > > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > >> At least for my implementation, parsing doesn't become easier, it > becomes > >> more complex with this proposal. My varint-parser always consumes as > many > >> bytes as the varint requires, so after parsing a varint, I'd have to > >> introduce an additional check that this didn't overflow the ACK length > >> (e.g. > >> consider that I parsed the ACK frame so far that only 2 bytes are > >> remaining > >> according to ACK length field, but the next varint is 4 bytes long). > > > > Isn't your varint parser checking that it has not (or will not) run > > across the end of the packet payload for every ACK block it parses? > > I'd assume that you would be doing that, because I think that is > > necessary to avoid buffer overrun. > > > > What I am saying that that check could be converted to a overrun check > > against the end of the "frame payload", and that checking the > > remaining block count becomes unnecessary, in case we replace ACK > > Block Count with ACK Frame Length. > > > >> > >> In general, we've been moving the wire image towards making every > >> encodable > >> value valid. This proposal moves us away from that principle: > >> * some small values are always invalid (the length can never be betwee= n > 0 > >> and 3) > >> * a lot of intermediate values are invalid (if the boundary falls > inside a > >> varint, as described above) > >> Both these cases can't occur with the current ACK frame format.. > >> > >> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote= : > >>> > >>> 2018-06-17 8:34 GMT+09:00 Ian Swett > >>> : > >>> > I'm not a fan of this proposal, because I think it is impractical t= o > >>> > drop > >>> > the number of ack blocks, because with the ECN proposal it becomes > >>> > impractically complex to parse. > >>> > >>> For the ECN proposal, as Christian has suggested, we can move the ECN > >>> counters before the ACK blocks. Then, it would not be complex to > >>> parse. > >>> > >>> And my view is that parsing becomes easier if we replace ACK Block > >>> Count with ACK Frame Length. > >>> > >>> Now, with ACK Block Count, we need to check the remaining number of > >>> blocks and the remaining space in the packet payload for every block > >>> that we parse. Failing to check either leads to a bug or a security > >>> issue. > >>> > >>> If we switch to ACK Frame Length, we need to only check the remaining > >>> space in the frame. > >>> > >>> I think that this is the biggest benefit of replacing ACK Block Count > >>> with ACK Frame Length. OTOH the downside is that you need extra one t= o > >>> two bits (one if the size of block / gap is expected to be below 65, > >>> two if they are expected to be above that) for encoding ACK Frame > >>> Length compared to ACK Block Count. > >>> > >>> > >>> > >>> Having said that, I honestly wonder if all the frames could have it's > >>> length being encoded (either explicitly or either as a signal that > >>> says "to the end of the packet"). Consider something like below: > >>> > >>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >>> or > >>> |1| frame-type (7) | frame-payload (*) | > >>> > >>> When MSB of the first octet set to zero, the length of the frame > >>> payload is designated by the varint that immediately follows the fram= e > >>> type. > >>> When MSB of the first octet set to one, the length of the frame > >>> payload spans to the end of the packet. > >>> > >>> In this encoding, we can always omit the Length field of a STREAM > >>> frame. So the overhead for carrying stream data will be indifferent i= n > >>> practice. > >>> > >>> For the ACK frame, we can omit the ACK Block Count field. And the > >>> overhead will be one to two bits if the ACK frame is sent in the > >>> middle of the packet (thereby using the encoding with explicit frame > >>> payload length), or one octet or more shorter if ACK is the last fram= e > >>> of the packet. > >>> > >>> We are likely to see increase of overhead for most of the other types > >>> of frames, but I do not think that would be an issue considering that > >>> they will be far seldom seen compared to STREAMs and ACKs. > >>> > >>> To summarize, my anticipation is that we can make all the frames > >>> self-contained (i.e. the length can be determined without the > >>> knowledge of how each frame is encoded) without any overhead, if we > >>> agree on making the frame type space 1 bit smaller. > >>> > >>> Finally, the biggest benefit of using a self-contained encoding of > >>> frames is that we would have the ability to introduce new optional > >>> frames without negotiation. By making the frames self-contained, QUIC > >>> endpoints will have the freedom of ignoring the frames that they do > >>> not understand. > >>> > >>> Being able to send QUIC frames defined in extensions without > >>> negotiating using Transport Parameters will be a win in both terms of > >>> security (because clients' TP is sent in clear) and flexibility > >>> (because we will be possible to send the extensions before we figure > >>> out whether the peer supports that extension). > >>> > >>> > If we don't remove the number of ack blocks, then the ack frame is > >>> > larger, > >>> > but I don't think the extra size field is useful for most > >>> > implementations. > >>> > Also, it means the length can disagree with the actual length, whic= h > >>> > add > >>> > complexity and the possibility of writing error-prone code. The id= ea > >>> > of > >>> > someone offloading ack processing and then proceeding to trust the > >>> > length > >>> > seems like someone could get wrong and cause some concerning issues= . > >>> > > >>> > My experience is multithreaded packet processing is more cost and > work > >>> > than > >>> > it's worth. Sure you can't fill a 100G NIC with one connection, bu= t > >>> > that > >>> > seems like an academic problem, not one for workloads I've seen. > >>> > Typically > >>> > the extra cost of multithreading outweighs its value. > >>> > > >>> > To be clear, I don't think this is an awful idea, but I also don't > see > >>> > the > >>> > value and it adds complexity. I read Manasi's email, but I don't > think > >>> > I > >>> > understand why any of those matter in practice. > >>> > > >>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >>> >> > >>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >>> >> > >>> >> wrote: > >>> >>> > >>> >>> This proposal increases the size of the ACK frame by 1 byte in th= e > >>> >>> common > >>> >>> case (less than 63 ACK ranges), since the ACK length field here > >>> >>> always > >>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-lengt= h > >>> >>> integer. > >>> >>> Considering how much work we put into minimising the size of the > >>> >>> frames, > >>> >>> this feels like a step in the wrong direction.. > >>> >>> > >>> >>> Regarding the processing cost, I agree with Dmitri. Handling an A= CK > >>> >>> frame > >>> >>> requires looping over and making changes to a data structure that > >>> >>> keeps > >>> >>> track of sent packets. This is much more expensive than simply > >>> >>> parsing > >>> >>> a > >>> >>> bunch of varints in the ACK frame. It seems unlikely that a > >>> >>> multi-threaded > >>> >>> packet parser would offer any real-world performance benefits. > >>> >> > >>> >> > >>> >> I don't want to overstate the benefit here, but my point isn't tha= t > >>> >> parsing is expensive but that if you want to have a multithreaded > >>> >> packet > >>> >> processing system, then it's nice to have a simpler data structure > >>> >> (the > >>> >> unparsed ACK block) to hand to the ACK processing thread. > >>> >> > >>> >> -Ekr > >>> >> > >>> >> > >>> >>> > >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >>> >>> > >>> >>> wrote: > >>> >>>> > >>> >>>> When we discussed this before, some people observed that this > >>> >>>> creates > >>> >>>> a need to encode in two passes. That's the trade-off here. (No= t > >>> >>>> expressing an opinion.) > >>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >>> >>>> wrote: > >>> >>>> > > >>> >>>> > I don't have a strong opinion on this. I'm certainly not oppos= ed > >>> >>>> > to > >>> >>>> > it. > >>> >>>> > Does anyone have a strong opposition? > >>> >>>> > > >>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >>> >>>> > wrote: > >>> >>>> >> > >>> >>>> >> I agree as well since this can help reduce per packet > processing > >>> >>>> >> overhead. ACKs are going to be the second most common frame > type > >>> >>>> >> so no > >>> >>>> >> objections to special casing. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >>> >>>> >> Rescorla > >>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >>> >>>> >> To: Deval, Manasi > >>> >>>> >> Cc: Jana Iyengar ; QUIC WG > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> I agree with Manasi here. This change would allow ack frame > >>> >>>> >> parsing > >>> >>>> >> to be more self-contained, which is an advantage for the pars= er > >>> >>>> >> and also > >>> >>>> >> potentially for parallelism (because you can quickly find the > >>> >>>> >> frame and then > >>> >>>> >> process it in parallel). > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> -Ekr > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> In general, varints require some specific logic for parsing. = To > >>> >>>> >> skip > >>> >>>> >> over any header, I have to read every single varint. As the > code > >>> >>>> >> sees Stream > >>> >>>> >> and ACK headers most frequently, that is my focus. The Strea= m > >>> >>>> >> frame has a > >>> >>>> >> length in its third field. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identif= y > >>> >>>> >> length. There are two reads each for =E2=80=98largest acknowl= edged=E2=80=99, > =E2=80=98ACK > >>> >>>> >> delay=E2=80=99 and > >>> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the tota= l number of cycles > >>> >>>> >> parse an > >>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packe= ts > >>> >>>> >> have a > >>> >>>> >> piggybacked ACK, these cycles becomes a significant bottlenec= k. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> Thanks, > >>> >>>> >> > >>> >>>> >> Manasi > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >>> >>>> >> Iyengar > >>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >>> >>>> >> To: Deval, Manasi ; QUIC WG > >>> >>>> >> > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> You're right that we no longer have the ability to skip an AC= K > >>> >>>> >> frame, > >>> >>>> >> and this crept in when we moved to varints. > >>> >>>> >> > >>> >>>> >> I believe your problem though is generally true of most frame= s > >>> >>>> >> not > >>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all fram= es > >>> >>>> >> are now all > >>> >>>> >> varints. To skip any frame, you'll need to parse the varint > >>> >>>> >> fields > >>> >>>> >> in those > >>> >>>> >> frames. If you have logic to process and skip varints, then > >>> >>>> >> skipping the ack > >>> >>>> >> block section is merely repeating this operation > (2*num_block+1) > >>> >>>> >> times. Do > >>> >>>> >> you see specific value in skipping ACK frames over the other > >>> >>>> >> control frames? > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote= : > >>> >>>> >> > - Moving the ACK length to the front of the ACK allo= ws > >>> >>>> >> > the > >>> >>>> >> > flexibility of either reading the entire ACK or > >>> >>>> >> > reading > >>> >>>> >> > the > >>> >>>> >> > first 16 bits and skipping over the length. This i= s > a > >>> >>>> >> > useful > >>> >>>> >> > feature for the case where ACK processing is split > >>> >>>> >> > into > >>> >>>> >> > multiple layers. Depending on the processor this i= s > >>> >>>> >> > run > >>> >>>> >> > on, > >>> >>>> >> > there are different advantages - > >>> >>>> >> > >>> >>>> >> Just a note. In my experience, the cost of parsing an ACK > frame > >>> >>>> >> is > >>> >>>> >> negligible compared to the cost of processing an ACK frame: > that > >>> >>>> >> is, > >>> >>>> >> poking at various memory locations to discard newly ACKed > >>> >>>> >> packets. > >>> >>>> >> > >>> >>>> >> - Dmitri. > >>> >>>> >> > >>> >>>> >> > >>> >>>> > >>> >> > >>> > > >>> > >>> > >>> > >>> -- > >>> Kazuho Oku > > > > > > > > -- > > Kazuho Oku > > > > -- > Kazuho Oku > --0000000000005c0ce3056f3c4cd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = As I said earlier, I= also favour a length prefix. But, Ian does have a point:

Writing data is generally more expensi= ve than reading data. Especially if you have to traverse long data structur= es to find the length before you can start writing and/or you may have to c= onservatively reserve extra space for a length field.

So before deciding one way or the other, t= he cost of writing needs to be well understood, also in scenarios with larg= e MTU=E2=80=99s.

In t= he flatbuffers space that I=E2=80=99m involved with, streaming has turned t= o be an issue because data cannot be transmitted in parts without index dat= a on a separate channel to recombined fragments. A simple, but non-standard= , change in the format would fix this. JSON and CoAP allows streaming, but = many other formats do not, including later versions of protocol buffers, as= I understand.
An odd= consequence of making both read and write efficient is that length better = work better if stored at the end and packets read backwards. This requires = a single total length prefix but this is stored in the datagram header. Thi= s is probably too odd-ball, but still a consideration worth noting.

The second best alternative = may therefore be to allow writes to be fast and reads to be decent.

Yet, I still like length pre= fixes if they could be made write efficient because high performance low-la= tency processes care zero about ACK and can consume a packet directly while= a background process handles all the latency insensitive ACK and retransmi= ssion logic.
=
The ques= tion is also, where is the pressure: an IoT aggregator might be massively r= ead intensive while a web cache would be very write intensive.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen=


On 22 June 2018 at 15.12.0= 9, Eric Rescorla (ekr@rtfm.com) wrote:<= /p>

It seems like there are two questions at hand here:

1. Would it be architecturally better to have frames have a consistent self-contained
representation?
2. Is it enough better that we should do so now.

I agree with Kazuho that (a) we don't have that representation now and (b) it would
be a better design to do so. I'm perhaps somewhat more positive on (2) than he
is. I don't think it's critically important that we make the change, but if we were
to hold a consensus call, I think I would be in favor. I'd certainly be interested
in looking at a proposal if someone else were to make one.

-Ekr



On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-22 8:08 GMT+09:00 Deval, Manasi <manasi.deval@intel.com>:
> I feel that the requirement to have every value valid is somewhat academic.

I think that Marten is correct in pointing out that making the ACK
frame self-containing (by having a field that represents the number of
octets being consumed by the frame) would be an exception from the
design pattern we have.

Look at STREAM frame. The field is not self-contained. Instead, it has
a Length field for the Stream Data, which is a leaf. The same goes for
NEW_CONNECTION_ID frame (that has the length field for Connection ID
field (which is also a leaf)), CONNECTION_CLOSE (length field for
Reason Phase).

I agree with Marten, Mikkel (and possibly others as well) that having
consistency is important.

Therefore, I agree with Mikkel that we should consider making every
frame self-contained or keeping every frame as-is (i.e. not
self-contained).

FWIW, as described in the latter half of
https://www.ietf.org/mail-archi= ve/web/quic/current/msg04287.html, it
is possible to make every frame self-contained *and* also make ACK
frames smaller than the current draft. Making every frame
self-contained gives us the possibility to send new extension frames
without negotiation.

I do not think that I would push for making every frame self-contained
by myself (because I do not think it meets the high bar to have a
change at such a late moment of standardization), but as stated, my
preference goes to seeing every frame made self-contained or none of
them made as such.

> The length value provides much more value than the block count and the fact
> that certain values can never be achieved is an inherent property of the
> length.
>
>
>
> One interesting observation is that this property is not limited to length.
> One can even make a similar argument about ACK block count. The maximum
> number of ACK blocks that can be defined will not always have a meaningful
> value. In out examples, 0,1,2,3 are all valid. If I set the value of ACK
> block count to have lower two bits to be 11, the maximum value is of ACK
> blocks is =E2=80=93 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would still
> be meaningless.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Tuesday, June 19, 2018 6:44 PM
> To: Deval, Manasi <manasi= ..deval@intel.com>
> Cc: Ian Swett <ianswett@goog= le.com>; Kazuho Oku <kazuhooku@gmail.com>; Eric
> Rescorla <ekr@rtfm.com>; Jan= a Iyengar <jri.ietf@gmail.com>; Praveen
> Balasubramanian <pravb@micro= soft.com>; IETF QUIC WG <quic@ietf.org>; Martin
> Thomson <martin.thomson= @gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Hi Manasi,
>
>
>
>> The risk of disagreement between ack blocks and ack block count is same as
>> the risk of disagreement between ack blocks and ack length. Either way this
>> needs to be counted up while creating the ACK and counted down while parsing
>> it. The possibility of error is the same. Getting the ack block count wrong
>> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
> I disagree. Let's take an example of an ACK frame with one ACK range, that
> needs a 2 byte varint to represent the First ACK Block and another 2 byte
> varint to represent the Gap.
>
> With your proposal:
>
> The values 0 and 1 are invalid, since the length fields itself is included
> in the length.
> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 are
> invalid, since the length needs to include the Largest Acknowledged and the
> Ack Delay.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first
> valid value, and correspond to an ACK frame with no blocks.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, since
> it would cut the varint for the First ACK Block
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, since
> it would cut the frame after the First ACK Block (but every block must be
> followed by a gap length)
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, since
> it would cut the varint for the Gap
> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is valid
>
> There are *a lot* of invalid values that you can encode into the ACK length
> field. More importantly, *none* of these error cases exists with the current
> frame format.
>
> The *only* error case that can occur with our current format is that the
> packet is too short for the number of ACK blocks that are supposed to
> contained in the frame. This can occur with your proposal as well (in
> addition to the error cases listed above).
>
>
>
> My concern is not that it's impossible or even particularly hard to catch
> these errors, but I dislike the property that some (in fact, most) encodable
> values are invalid.
>
>
>
> Best,
>
> Marten
>
>
>
>
>
> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi Ian,
>
>
>
> Here is another attempt to solve the objections you raised:
>
>
>
>>I'm not a fan of this proposal, because I think it is impractical to drop
>> the number of ack blocks, because with the ECN proposal it becomes
>> impractically complex to parse.
>
> Is there a reason the proposal from Christian does not solve this problem?
>
>
>
>>If we don't remove the number of ack blocks, then the ack frame is larger,
>> but I don't think the extra size field is useful for most implementations.
>> Also, it means the length can disagree with the actual length, which add
>> complexity and the possibility of writing error-prone code.=C2=A0 The idea of
>> someone offloading ack processing and then proceeding to trust the length
>> seems like someone could get wrong and cause some concerning issues.
>
> The risk of disagreement between ack blocks and ack block count is same as
> the risk of disagreement between ack blocks and ack length. Either way this
> needs to be counted up while creating the ACK and counted down while parsing
> it. The possibility of error is the same. Getting the ack block count wrong
> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
>>My experience is multithreaded packet processing is more cost and work than
>> it's worth.=C2=A0 Sure you can't fill a 100G NIC with one connection, but that
>> seems like an academic problem, not one for workloads I've seen.=C2=A0 Typically
>> the extra cost of multithreading outweighs its value.
>
> The value is two fold =E2=80=93 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be
> coalesced, the receive side can indicate a large chunk of information though
> the kernel, reducing the cost of system call and protocol overhead. This is
> the same concept as UDP segmentation taken a step further on receive side.
> After this chunk is indicated into the QUIC protocol, the protocol may
> process stream and ACK in parallel. While folks may or may not utilize this,
> there is an advantage here.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Ian Swett [mailto:ianswet= t@google.com]
> Sent: Tuesday, June 19, 2018 11:26 AM
> To: Deval, Manasi <manasi= ..deval@intel.com>
> Cc: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>= ; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar
> <jri.ietf@gmail.com>; = Praveen Balasubramanian <pravb@microsoft.= com>; IETF
> QUIC WG <quic@ietf.org>; Ma= rtin Thomson <martin.thomson@gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> I'm still not interested in this change, for the reasons I stated above.
>
>
>
> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi All,
>
>
>
> Do we have agreement here to create a new PR?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> From: Deval, Manasi
> Sent: Sunday, June 17, 2018 2:25 PM
> To: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>=
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>= ;; Praveen Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; Martin Thomson
> <martin.thomson@gmail.c= om>
> Subject: RE: Proposal to replace ACK block count with ACK length
>
>
>
> Hi All,
>
>
>
> I have made a list of objections to the proposal and the solutions to those
> objections discussed on this thread.
>
>
>
> a.=C2=A0 =C2=A0 =C2=A0 Co-existence of length field with ECN field and ACK blocks.
>
>
>
> Christian suggested to move the ECN fields to precede the ACK blocks. This
> is an elegant solution. Parsing entire list of ACK blocks to review ECN bits
> would have been annoying, even though it can work.
>
>
>
> b.=C2=A0 =C2=A0 =C2=A0 There are two cases to be parsed =E2=80=93 entire ACK and parse ACK to
> identify length. There are some reservations when ACK parsing gets harder
> for the case where the entire header needs to be parsed.
>
>
>
> Agreement from several folks here. In the original ACK defined in draft 12
> of the slide, one would count down number of ACK blocks to get to the end of
> the packet. In the proposal I made, one would count down the length to
> identify the end of the packet. The logic is very similar in cycle count and
> complexity. Several folks also commented to this effect.
>
>
>
> c.=C2=A0 =C2=A0 =C2=A0 Multi-threaded packet processing
>
>
>
> I would expect that there are 10s of 1000s of connections in use at any time
> for a server with a high speed link. Multi-threading to handle each of these
> flows / connections in parallel is necessity to be able to support large
> number of connections on a high speed link. Tx segmentation, Rx coalescing
> are well known strategies to reduce the processing cost. In initial stages,
> code is often written as a single-threaded and then re-factored to
> parallelize cycle intensive operations. In order to allow this protocol to
> scale in future, I would suggest we do not preclude this case.
>
>
>
> d.=C2=A0 =C2=A0 =C2=A0 Increase in ACK size by 1 byte.
>
>
>
> I do not see this as a serious issue but if folks but we can consider making
> this a varint, if others have strong feelings about it. It=E2=80=99s a trade-off : 2
> reads to save 1 byte.
>
>
>
> e.=C2=A0 =C2=A0 =C2=A0 Every encodable value should be valid
>
> Not every length will be valid. This is inherent to lengths. This same issue
> ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only doe= s the issue exist for
> small values, it also applies to large values since data stream will be sent
> after crypto negotiation.=C2=A0 E.g.=C2=A0 - how does one craft a payload with 62 bit
> payload length in a large header?
>
>
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Sunday, June 17, 2018 6:59 AM
> To: Kazuho Oku <kazuhooku@gm= ail.com>
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>= ;; Praveen Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; Martin Thomson
> <martin.thomson@gmail.c= om>; Deval, Manasi <manasi.deval@in= tel.com>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Maybe it's specific to Go, but I'm using a single io.Reader for the whole
> packet, so as long as the packet payload is long enough, the varint parsing
> will not fail.
>
> I don't think that specifics of programming languages matter here though,
> and I'm sure both frame formats can be reasonably implemented in C as well
> as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us
> away from the principle that only reasonable values should be encodable, and
> that it increases the size of the ACK frame, for the questionable benefit of
> being able to parallelise the frame parser.
>
>
>
> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> 2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.com>:
>> At least for my implementation, parsing doesn't become easier, it becomes
>> more complex with this proposal. My varint-parser always consumes as many
>> bytes as the varint requires, so after parsing a varint, I'd have to
>> introduce an additional check that this didn't overflow the ACK length
>> (e.g.
>> consider that I parsed the ACK frame so far that only 2 bytes are
>> remaining
>> according to ACK length field, but the next varint is 4 bytes long).
>
> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is
> necessary to avoid buffer overrun.
>
> What I am saying that that check could be converted to a overrun check
> against the end of the "frame payload", and that checking the
> remaining block count becomes unnecessary, in case we replace ACK
> Block Count with ACK Frame Length.
>
>>
>> In general, we've been moving the wire image towards making every
>> encodable
>> value valid. This proposal moves us away from that principle:
>> * some small values are always invalid (the length can never be between 0
>> and 3)
>> * a lot of intermediate values are invalid (if the boundary falls inside a
>> varint, as described above)
>> Both these cases can't occur with the current ACK frame format..
>>
>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>>> <ianswett=3D= 40google.com@dmarc.ietf.org>:
>>> > I'm not a fan of this proposal, because I think it is impractical to
>>> > drop
>>> > the number of ack blocks, because with the ECN proposal it becomes
>>> > impractically complex to parse.
>>>
>>> For the ECN proposal, as Christian has suggested, we can move the ECN
>>> counters before the ACK blocks. Then, it would not be complex to
>>> parse.
>>>
>>> And my view is that parsing becomes easier if we replace ACK Block
>>> Count with ACK Frame Length.
>>>
>>> Now, with ACK Block Count, we need to check the remaining number of
>>> blocks and the remaining space in the packet payload for every block
>>> that we parse. Failing to check either leads to a bug or a security
>>> issue.
>>>
>>> If we switch to ACK Frame Length, we need to only check the remaining
>>> space in the frame.
>>>
>>> I think that this is the biggest benefit of replacing ACK Block Count
>>> with ACK Frame Length. OTOH the downside is that you need extra one to
>>> two bits (one if the size of block / gap is expected to be below 65,
>>> two if they are expected to be above that) for encoding ACK Frame
>>> Length compared to ACK Block Count.
>>>
>>>
>>>
>>> Having said that, I honestly wonder if all the frames could have it's
>>> length being encoded (either explicitly or either as a signal that
>>> says "to the end of the packet"). Consider something like below:
>>>
>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) |
>>>=C2=A0 or
>>> |1| frame-type (7) | frame-payload (*) |
>>>
>>> When MSB of the first octet set to zero, the length of the frame
>>> payload is designated by the varint that immediately follows the frame
>>> type.
>>> When MSB of the first octet set to one, the length of the frame
>>> payload spans to the end of the packet.
>>>
>>> In this encoding, we can always omit the Length field of a STREAM
>>> frame. So the overhead for carrying stream data will be indifferent in
>>> practice.
>>>
>>> For the ACK frame, we can omit the ACK Block Count field. And the
>>> overhead will be one to two bits if the ACK frame is sent in the
>>> middle of the packet (thereby using the encoding with explicit frame
>>> payload length), or one octet or more shorter if ACK is the last frame
>>> of the packet.
>>>
>>> We are likely to see increase of overhead for most of the other types
>>> of frames, but I do not think that would be an issue considering that
>>> they will be far seldom seen compared to STREAMs and ACKs.
>>>
>>> To summarize, my anticipation is that we can make all the frames
>>> self-contained (i.e. the length can be determined without the
>>> knowledge of how each frame is encoded) without any overhead, if we
>>> agree on making the frame type space 1 bit smaller.
>>>
>>> Finally, the biggest benefit of using a self-contained encoding of
>>> frames is that we would have the ability to introduce new optional
>>> frames without negotiation. By making the frames self-contained, QUIC
>>> endpoints will have the freedom of ignoring the frames that they do
>>> not understand.
>>>
>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both terms of
>>> security (because clients' TP is sent in clear) and flexibility
>>> (because we will be possible to send the extensions before we figure
>>> out whether the peer supports that extension).
>>>
>>> > If we don't remove the number of ack blocks, then the ack frame is
>>> > larger,
>>> > but I don't think the extra size field is useful for most
>>> > implementations.
>>> > Also, it means the length can disagree with the actual length, which
>>> > add
>>> > complexity and the possibility of writing error-prone code.=C2=A0 The idea
>>> > of
>>> > someone offloading ack processing and then proceeding to trust the
>>> > length
>>> > seems like someone could get wrong and cause some concerning issues.
>>> >
>>> > My experience is multithreaded packet processing is more cost and work
>>> > than
>>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with one connection, but
>>> > that
>>> > seems like an academic problem, not one for workloads I've seen.
>>> > Typically
>>> > the extra cost of multithreading outweighs its value.
>>> >
>>> > To be clear, I don't think this is an awful idea, but I also don't see
>>> > the
>>> > value and it adds complexity.=C2=A0 I read Manasi's email, but I don't think
>>> > I
>>> > understand why any of those matter in practice.
>>> >
>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>> >>
>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>>> >> <marten= seemann@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> This proposal increases the size of the ACK frame by 1 byte in the
>>> >>> common
>>> >>> case (less than 63 ACK ranges), since the ACK length field here
>>> >>> always
>>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length
>>> >>> integer.
>>> >>> Considering how much work we put into minimising the size of the
>>> >>> frames,
>>> >>> this feels like a step in the wrong direction..
>>> >>>
>>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK
>>> >>> frame
>>> >>> requires looping over and making changes to a data structure that
>>> >>> keeps
>>> >>> track of sent packets. This is much more expensive than simply
>>> >>> parsing
>>> >>> a
>>> >>> bunch of varints in the ACK frame. It seems unlikely that a
>>> >>> multi-threaded
>>> >>> packet parser would offer any real-world performance benefits.
>>> >>
>>> >>
>>> >> I don't want to overstate the benefit here, but my point isn't that
>>> >> parsing is expensive but that if you want to have a multithreaded
>>> >> packet
>>> >> processing system, then it's nice to have a simpler data structure
>>> >> (the
>>> >> unparsed ACK block) to hand to the ACK processing thread.
>>> >>
>>> >> -Ekr
>>> >>
>>> >>
>>> >>>
>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> <m= artin.thomson@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> When we discussed this before, some people observed that this
>>> >>>> creates
>>> >>>> a need to encode in two passes.=C2=A0 That's the trade-off here.=C2=A0 (Not
>>> >>>> expressing an opinion.)
>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <jri.ietf@gmail.com>= ;
>>> >>>> wrote:
>>> >>>> >
>>> >>>> > I don't have a strong opinion on this. I'm certainly not opposed
>>> >>>> > to
>>> >>>> > it.
>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >
>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian
>>> >>>> > <pravb@microsoft.com> wrote:
>>> >>>> >>
>>> >>>> >> I agree as well since this can help reduce per packet processing
>>> >>>> >> overhead. ACKs are going to be the second most common frame type
>>> >>>> >> so no
>>> >>>> >> objections to special casing.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric
>>> >>>> >> Rescorla
>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>= ;
>>> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> I agree with Manasi here. This change would allow ack frame
>>> >>>> >> parsing
>>> >>>> >> to be more self-contained, which is an advantage for the parser
>>> >>>> >> and also
>>> >>>> >> potentially for parallelism (because you can quickly find the
>>> >>>> >> frame and then
>>> >>>> >> process it in parallel).
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> -Ekr
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi
>>> >>>> >> <manasi.deval@intel.com> wrote:
>>> >>>> >>
>>> >>>> >> In general, varints require some specific logic for parsing. To
>>> >>>> >> skip
>>> >>>> >> over any header, I have to read every single varint. As the code
>>> >>>> >> sees Stream
>>> >>>> >> and ACK headers most frequently, that is my focus.=C2=A0 The Stream
>>> >>>> >> frame has a
>>> >>>> >> length in its third field.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify
>>> >>>> >> length. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>>> >>>> >> delay=E2=80=99 and
>>> >>>> >> =E2=80=98ACK block count=E2=80=99. T= he pain point is the total number of cycles
>>> >>>> >> parse an
>>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets
>>> >>>> >> have a
>>> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Thanks,
>>> >>>> >>
>>> >>>> >> Manasi
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana
>>> >>>> >> Iyengar
>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>= ;; QUIC WG
>>> >>>> >> <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> You're right that we no longer have the ability to skip an ACK
>>> >>>> >> frame,
>>> >>>> >> and this crept in when we moved to varints.
>>> >>>> >>
>>> >>>> >> I believe your problem though is generally true of most frames
>>> >>>> >> not
>>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames
>>> >>>> >> are now all
>>> >>>> >> varints. To skip any frame, you'll need to parse the varint
>>> >>>> >> fields
>>> >>>> >> in those
>>> >>>> >> frames. If you have logic to process and skip varints, then
>>> >>>> >> skipping the ack
>>> >>>> >> block section is merely repeating this operation (2*num_block+1)
>>> >>>> >> times. Do
>>> >>>> >> you see specific value in skipping ACK frames over the other
>>> >>>> >> control frames?
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov
>>> >>>> >> <dtikhonov@litespeedtech..com> wrote:
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the front of the ACK allows
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either reading the entire ACK or
>>> >>>> >> > reading
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping over the length. This is a
>>> >>>> >> > useful
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where ACK processing is split
>>> >>>> >> > into
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending on the processor this is
>>> >>>> >> > run
>>> >>>> >> > on,
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advantages -
>>> >>>> >>
>>> >>>> >> Just a note.=C2=A0 In my experience, the cost of parsing an ACK frame
>>> >>>> >> is
>>> >>>> >> negligible compared to the cost of processing an ACK frame: that
>>> >>>> >> is,
>>> >>>> >> poking at various memory locations to discard newly ACKed
>>> >>>> >> packets.
>>> >>>> >>
>>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>>> >>>> >>
>>> >>>> >>
>>> >>>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku

--0000000000005c0ce3056f3c4cd9-- From nobody Fri Jun 22 09:15:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA55130F00 for ; Fri, 22 Jun 2018 09:15:09 -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, UNPARSEABLE_RELAY=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 Ze_pUovLZAwQ for ; Fri, 22 Jun 2018 09:15:03 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 762C5130EBE for ; Fri, 22 Jun 2018 09:15:03 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id i23-v6so3679237iog.10 for ; Fri, 22 Jun 2018 09:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Apz8H5X8s26dm3oyOvjd7O0aPgyKdkKUR42cowQa1yc=; b=rcky2kajCozvYFVVAv+zcZ3RHgrcNSs3C2s0DrOak/0r6tI2e2S5CMqN5RgtSniD1M loLPfCGUb1ufWkcjFQ11uZxvDmPveGqZopZ1ClhbB4R4rPTnE4jq9UTHLqH4dXgb+z9R jgxTY95L8SLDKLYieHLNzHYClkU3t73D8MW0af8PYMzeORUhg25NC9qYlhzxciB/y7BN Pld8m4WBjsYAlb4h1AoCQ3nKd12hWMtxvLkHpoR9/8t/6fZKCQogwXkIeTsWsXAa2dCv JNryUWx9QcdpgIm3ky9k6PAKZ+/FHr4XAeOBYnljhKO9E8G38XOPhc18hIss5i6uEohH rK5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Apz8H5X8s26dm3oyOvjd7O0aPgyKdkKUR42cowQa1yc=; b=LFaUB9Z49wNcOnUi6RYyVJEl4CPslriBZbM6KzSYsmrjg+prT0MJ4jfTVU1QoPKcjj IzJghIwISEPUel8lGiBUH7s1pixnEk7JbKpa3DIqvPXISKC2ScccGpO0DKLSpOzGlnRu PZwU/fw3h0oklStgPoECyLhx0aJehtTbbvJNr96D4RB4IXqBKXRflS9W2dKAkazOh4B6 e1AXvBxmgjm5t6Az2uJ9UDtmPpJxOBgpBmmfVeDEc2qhZ5Ixcv0QFOXFrxpQ71VP2lVN pLkO7G1YZkelOxoimruYnkIolwMIidotXvXVYKiHhhSu1V/lIxXzaNC4OA8HQgsr8l5C YZzg== X-Gm-Message-State: APt69E0UD9Ip5WPKuEuR1209YyncZjhICBwpED12Ec0va1Gy25XNp80M BbK0b8qhsbldnvgHyWi4iqWwmG74pQRCyCuOrXg= X-Google-Smtp-Source: AAOMgpcIIPRAp1JJ8sPuASlp0JVTuhC1GYIDI6Eau52XwWuD6bfJkrWnKl04aXZuPBuKiW2iTXB/RvQyZupeTC9LOMM= X-Received: by 2002:a6b:93c6:: with SMTP id v189-v6mr1834225iod.274.1529684102661; Fri, 22 Jun 2018 09:15:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Jun 2018 12:15:01 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 22 Jun 2018 12:15:01 -0400 Message-ID: Subject: Re: Proposal to replace ACK block count with ACK length To: Eric Rescorla , Kazuho Oku Cc: Jana Iyengar , IETF QUIC WG , "Deval, Manasi" , Marten Seemann , Martin Thomson , Ian Swett , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="0000000000008ece6f056f3d55ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:15:19 -0000 --0000000000008ece6f056f3d55ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another option is to write out frames as is without length except as needed for varints. When a packet is nearly done, a run-length encoded frame index is placed in the packet tail. It could also include the frame types. A reader can now directly find or skip ACK frames and the writer does not have to compute lengths before writing. Of course, the reader needs to be able to locate the index at the tail which can be tricky with coalesced packets, but not impossible. Isn=E2=80=99t this largely how zip-files work? Mikkel On 22 June 2018 at 17.00.52, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gm= ail.com) wrote: As I said earlier, I also favour a length prefix. But, Ian does have a point: Writing data is generally more expensive than reading data. Especially if you have to traverse long data structures to find the length before you can start writing and/or you may have to conservatively reserve extra space for a length field. So before deciding one way or the other, the cost of writing needs to be well understood, also in scenarios with large MTU=E2=80=99s. In the flatbuffers space that I=E2=80=99m involved with, streaming has turn= ed to be an issue because data cannot be transmitted in parts without index data on a separate channel to recombined fragments. A simple, but non-standard, change in the format would fix this. JSON and CoAP allows streaming, but many other formats do not, including later versions of protocol buffers, as I understand. An odd consequence of making both read and write efficient is that length better work better if stored at the end and packets read backwards. This requires a single total length prefix but this is stored in the datagram header. This is probably too odd-ball, but still a consideration worth noting. The second best alternative may therefore be to allow writes to be fast and reads to be decent. Yet, I still like length prefixes if they could be made write efficient because high performance low-latency processes care zero about ACK and can consume a packet directly while a background process handles all the latency insensitive ACK and retransmission logic. The question is also, where is the pressure: an IoT aggregator might be massively read intensive while a web cache would be very write intensive. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote: It seems like there are two questions at hand here: 1. Would it be architecturally better to have frames have a consistent self-contained representation? 2. Is it enough better that we should do so now. I agree with Kazuho that (a) we don't have that representation now and (b) it would be a better design to do so. I'm perhaps somewhat more positive on (2) than he is. I don't think it's critically important that we make the change, but if we were to hold a consensus call, I think I would be in favor. I'd certainly be interested in looking at a proposal if someone else were to make one. -Ekr On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku wrote: > 2018-06-22 8:08 GMT+09:00 Deval, Manasi : > > I feel that the requirement to have every value valid is somewhat > academic. > > I think that Marten is correct in pointing out that making the ACK > frame self-containing (by having a field that represents the number of > octets being consumed by the frame) would be an exception from the > design pattern we have. > > Look at STREAM frame. The field is not self-contained. Instead, it has > a Length field for the Stream Data, which is a leaf. The same goes for > NEW_CONNECTION_ID frame (that has the length field for Connection ID > field (which is also a leaf)), CONNECTION_CLOSE (length field for > Reason Phase). > > I agree with Marten, Mikkel (and possibly others as well) that having > consistency is important. > > Therefore, I agree with Mikkel that we should consider making every > frame self-contained or keeping every frame as-is (i.e. not > self-contained). > > FWIW, as described in the latter half of > https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it > is possible to make every frame self-contained *and* also make ACK > frames smaller than the current draft. Making every frame > self-contained gives us the possibility to send new extension frames > without negotiation. > > I do not think that I would push for making every frame self-contained > by myself (because I do not think it meets the high bar to have a > change at such a late moment of standardization), but as stated, my > preference goes to seeing every frame made self-contained or none of > them made as such. > > > The length value provides much more value than the block count and the > fact > > that certain values can never be achieved is an inherent property of th= e > > length. > > > > > > > > One interesting observation is that this property is not limited to > length. > > One can even make a similar argument about ACK block count. The maximum > > number of ACK blocks that can be defined will not always have a > meaningful > > value. In out examples, 0,1,2,3 are all valid. If I set the value of AC= K > > block count to have lower two bits to be 11, the maximum value is of AC= K > > blocks is =E2=80=93 4611686018427387903. This is the same value of larg= est > > acknowledged so if the ACK block count was set to this value, it would > still > > be meaningless. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Tuesday, June 19, 2018 6:44 PM > > To: Deval, Manasi > > > Cc: Ian Swett ; Kazuho Oku ; > Eric > > Rescorla ; Jana Iyengar ; Praveen > > Balasubramanian ; IETF QUIC WG ; > Martin > > Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Hi Manasi, > > > > > > > >> The risk of disagreement between ack blocks and ack block count is sam= e > as > >> the risk of disagreement between ack blocks and ack length. Either way > this > >> needs to be counted up while creating the ACK and counted down while > parsing > >> it. The possibility of error is the same. Getting the ack block count > wrong > >> is as problematic as getting the ack length wrong. Do you agree? > > > > > > > > I disagree. Let's take an example of an ACK frame with one ACK range, > that > > needs a 2 byte varint to represent the First ACK Block and another 2 by= te > > varint to represent the Gap. > > > > With your proposal: > > > > The values 0 and 1 are invalid, since the length fields itself is > included > > in the length. > > The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - = 1 > are > > invalid, since the length needs to include the Largest Acknowledged and > the > > Ack Delay. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the fir= st > > valid value, and correspond to an ACK frame with no blocks. > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, > since > > it would cut the varint for the First ACK Block > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, > since > > it would cut the frame after the First ACK Block (but every block must = be > > followed by a gap length) > > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, > since > > it would cut the varint for the Gap > > Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is > valid > > > > There are *a lot* of invalid values that you can encode into the ACK > length > > field. More importantly, *none* of these error cases exists with the > current > > frame format. > > > > The *only* error case that can occur with our current format is that th= e > > packet is too short for the number of ACK blocks that are supposed to > > contained in the frame. This can occur with your proposal as well (in > > addition to the error cases listed above). > > > > > > > > My concern is not that it's impossible or even particularly hard to cat= ch > > these errors, but I dislike the property that some (in fact, most) > encodable > > values are invalid. > > > > > > > > Best, > > > > Marten > > > > > > > > > > > > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi > > wrote: > > > > Hi Ian, > > > > > > > > Here is another attempt to solve the objections you raised: > > > > > > > >>I'm not a fan of this proposal, because I think it is impractical to dr= op > >> the number of ack blocks, because with the ECN proposal it becomes > >> impractically complex to parse. > > > > Is there a reason the proposal from Christian does not solve this > problem? > > > > > > > >>If we don't remove the number of ack blocks, then the ack frame is > larger, > >> but I don't think the extra size field is useful for most > implementations. > >> Also, it means the length can disagree with the actual length, which a= dd > >> complexity and the possibility of writing error-prone code. The idea = of > >> someone offloading ack processing and then proceeding to trust the > length > >> seems like someone could get wrong and cause some concerning issues. > > > > The risk of disagreement between ack blocks and ack block count is same > as > > the risk of disagreement between ack blocks and ack length. Either way > this > > needs to be counted up while creating the ACK and counted down while > parsing > > it. The possibility of error is the same. Getting the ack block count > wrong > > is as problematic as getting the ack length wrong. Do you agree? > > > > > > > >>My experience is multithreaded packet processing is more cost and work > than > >> it's worth. Sure you can't fill a 100G NIC with one connection, but > that > >> seems like an academic problem, not one for workloads I've seen. > Typically > >> the extra cost of multithreading outweighs its value. > > > > The value is two fold =E2=80=93 pre-processing and multi-threading. If = we > > pre-process the received packets such that ACKs and streams can be > > coalesced, the receive side can indicate a large chunk of information > though > > the kernel, reducing the cost of system call and protocol overhead. Thi= s > is > > the same concept as UDP segmentation taken a step further on receive > side. > > After this chunk is indicated into the QUIC protocol, the protocol may > > process stream and ACK in parallel. While folks may or may not utilize > this, > > there is an advantage here. > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Ian Swett [mailto:ianswett@google.com] > > Sent: Tuesday, June 19, 2018 11:26 AM > > To: Deval, Manasi > > > Cc: Marten Seemann ; Kazuho Oku > > ; Eric Rescorla ; Jana Iyengar > > ; Praveen Balasubramanian ; > IETF > > QUIC WG ; Martin Thomson > > > > > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > I'm still not interested in this change, for the reasons I stated above= . > > > > > > > > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi > > wrote: > > > > Hi All, > > > > > > > > Do we have agreement here to create a new PR? > > > > > > > > Thanks, > > > > Manasi > > > > > > > > From: Deval, Manasi > > Sent: Sunday, June 17, 2018 2:25 PM > > To: Marten Seemann ; Kazuho Oku > > > > Cc: Ian Swett <40google.com@dmarc.ietf..org>>; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > > > Subject: RE: Proposal to replace ACK block count with ACK length > > > > > > > > Hi All, > > > > > > > > I have made a list of objections to the proposal and the solutions to > those > > objections discussed on this thread. > > > > > > > > a. Co-existence of length field with ECN field and ACK blocks. > > > > > > > > Christian suggested to move the ECN fields to precede the ACK blocks. > This > > is an elegant solution. Parsing entire list of ACK blocks to review ECN > bits > > would have been annoying, even though it can work. > > > > > > > > b. There are two cases to be parsed =E2=80=93 entire ACK and parse= ACK to > > identify length. There are some reservations when ACK parsing gets hard= er > > for the case where the entire header needs to be parsed. > > > > > > > > Agreement from several folks here. In the original ACK defined in draft > 12 > > of the slide, one would count down number of ACK blocks to get to the > end of > > the packet. In the proposal I made, one would count down the length to > > identify the end of the packet. The logic is very similar in cycle coun= t > and > > complexity. Several folks also commented to this effect. > > > > > > > > c. Multi-threaded packet processing > > > > > > > > I would expect that there are 10s of 1000s of connections in use at any > time > > for a server with a high speed link. Multi-threading to handle each of > these > > flows / connections in parallel is necessity to be able to support larg= e > > number of connections on a high speed link. Tx segmentation, Rx > coalescing > > are well known strategies to reduce the processing cost. In initial > stages, > > code is often written as a single-threaded and then re-factored to > > parallelize cycle intensive operations. In order to allow this protocol > to > > scale in future, I would suggest we do not preclude this case. > > > > > > > > d. Increase in ACK size by 1 byte. > > > > > > > > I do not see this as a serious issue but if folks but we can consider > making > > this a varint, if others have strong feelings about it. It=E2=80=99s a = trade-off > : 2 > > reads to save 1 byte. > > > > > > > > e. Every encodable value should be valid > > > > Not every length will be valid. This is inherent to lengths. This same > issue > > ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only does= the issue exist > for > > small values, it also applies to large values since data stream will be > sent > > after crypto negotiation. E.g. - how does one craft a payload with 62 > bit > > payload length in a large header? > > > > > > > > > > > > Thanks, > > > > Manasi > > > > > > > > > > > > From: Marten Seemann [mailto:martenseemann@gmail.com] > > Sent: Sunday, June 17, 2018 6:59 AM > > To: Kazuho Oku > > Cc: Ian Swett <40google.com@dmarc.ietf..org>>; Eric Rescorla > > ; Jana Iyengar ; Praveen > Balasubramanian > > ; IETF QUIC WG ; Martin Thomson > > ; Deval, Manasi > > Subject: Re: Proposal to replace ACK block count with ACK length > > > > > > > > Maybe it's specific to Go, but I'm using a single io.Reader for the who= le > > packet, so as long as the packet payload is long enough, the varint > parsing > > will not fail. > > > > I don't think that specifics of programming languages matter here thoug= h, > > and I'm sure both frame formats can be reasonably implemented in C as > well > > as in Go. The reasons I'm opposed to Manasi's proposal are that it move= s > us > > away from the principle that only reasonable values should be encodable= , > and > > that it increases the size of the ACK frame, for the questionable > benefit of > > being able to parallelise the frame parser. > > > > > > > > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku wrote: > > > > 2018-06-17 22:36 GMT+09:00 Marten Seemann : > >> At least for my implementation, parsing doesn't become easier, it > becomes > >> more complex with this proposal. My varint-parser always consumes as > many > >> bytes as the varint requires, so after parsing a varint, I'd have to > >> introduce an additional check that this didn't overflow the ACK length > >> (e.g. > >> consider that I parsed the ACK frame so far that only 2 bytes are > >> remaining > >> according to ACK length field, but the next varint is 4 bytes long). > > > > Isn't your varint parser checking that it has not (or will not) run > > across the end of the packet payload for every ACK block it parses? > > I'd assume that you would be doing that, because I think that is > > necessary to avoid buffer overrun. > > > > What I am saying that that check could be converted to a overrun check > > against the end of the "frame payload", and that checking the > > remaining block count becomes unnecessary, in case we replace ACK > > Block Count with ACK Frame Length. > > > >> > >> In general, we've been moving the wire image towards making every > >> encodable > >> value valid. This proposal moves us away from that principle: > >> * some small values are always invalid (the length can never be betwee= n > 0 > >> and 3) > >> * a lot of intermediate values are invalid (if the boundary falls > inside a > >> varint, as described above) > >> Both these cases can't occur with the current ACK frame format.. > >> > >> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku wrote= : > >>> > >>> 2018-06-17 8:34 GMT+09:00 Ian Swett > >>> : > >>> > I'm not a fan of this proposal, because I think it is impractical t= o > >>> > drop > >>> > the number of ack blocks, because with the ECN proposal it becomes > >>> > impractically complex to parse. > >>> > >>> For the ECN proposal, as Christian has suggested, we can move the ECN > >>> counters before the ACK blocks. Then, it would not be complex to > >>> parse. > >>> > >>> And my view is that parsing becomes easier if we replace ACK Block > >>> Count with ACK Frame Length. > >>> > >>> Now, with ACK Block Count, we need to check the remaining number of > >>> blocks and the remaining space in the packet payload for every block > >>> that we parse. Failing to check either leads to a bug or a security > >>> issue. > >>> > >>> If we switch to ACK Frame Length, we need to only check the remaining > >>> space in the frame. > >>> > >>> I think that this is the biggest benefit of replacing ACK Block Count > >>> with ACK Frame Length. OTOH the downside is that you need extra one t= o > >>> two bits (one if the size of block / gap is expected to be below 65, > >>> two if they are expected to be above that) for encoding ACK Frame > >>> Length compared to ACK Block Count. > >>> > >>> > >>> > >>> Having said that, I honestly wonder if all the frames could have it's > >>> length being encoded (either explicitly or either as a signal that > >>> says "to the end of the packet"). Consider something like below: > >>> > >>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) | > >>> or > >>> |1| frame-type (7) | frame-payload (*) | > >>> > >>> When MSB of the first octet set to zero, the length of the frame > >>> payload is designated by the varint that immediately follows the fram= e > >>> type. > >>> When MSB of the first octet set to one, the length of the frame > >>> payload spans to the end of the packet. > >>> > >>> In this encoding, we can always omit the Length field of a STREAM > >>> frame. So the overhead for carrying stream data will be indifferent i= n > >>> practice. > >>> > >>> For the ACK frame, we can omit the ACK Block Count field. And the > >>> overhead will be one to two bits if the ACK frame is sent in the > >>> middle of the packet (thereby using the encoding with explicit frame > >>> payload length), or one octet or more shorter if ACK is the last fram= e > >>> of the packet. > >>> > >>> We are likely to see increase of overhead for most of the other types > >>> of frames, but I do not think that would be an issue considering that > >>> they will be far seldom seen compared to STREAMs and ACKs. > >>> > >>> To summarize, my anticipation is that we can make all the frames > >>> self-contained (i.e. the length can be determined without the > >>> knowledge of how each frame is encoded) without any overhead, if we > >>> agree on making the frame type space 1 bit smaller. > >>> > >>> Finally, the biggest benefit of using a self-contained encoding of > >>> frames is that we would have the ability to introduce new optional > >>> frames without negotiation. By making the frames self-contained, QUIC > >>> endpoints will have the freedom of ignoring the frames that they do > >>> not understand. > >>> > >>> Being able to send QUIC frames defined in extensions without > >>> negotiating using Transport Parameters will be a win in both terms of > >>> security (because clients' TP is sent in clear) and flexibility > >>> (because we will be possible to send the extensions before we figure > >>> out whether the peer supports that extension). > >>> > >>> > If we don't remove the number of ack blocks, then the ack frame is > >>> > larger, > >>> > but I don't think the extra size field is useful for most > >>> > implementations. > >>> > Also, it means the length can disagree with the actual length, whic= h > >>> > add > >>> > complexity and the possibility of writing error-prone code. The id= ea > >>> > of > >>> > someone offloading ack processing and then proceeding to trust the > >>> > length > >>> > seems like someone could get wrong and cause some concerning issues= . > >>> > > >>> > My experience is multithreaded packet processing is more cost and > work > >>> > than > >>> > it's worth. Sure you can't fill a 100G NIC with one connection, bu= t > >>> > that > >>> > seems like an academic problem, not one for workloads I've seen. > >>> > Typically > >>> > the extra cost of multithreading outweighs its value. > >>> > > >>> > To be clear, I don't think this is an awful idea, but I also don't > see > >>> > the > >>> > value and it adds complexity. I read Manasi's email, but I don't > think > >>> > I > >>> > understand why any of those matter in practice. > >>> > > >>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla wrote: > >>> >> > >>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann > >>> >> > >>> >> wrote: > >>> >>> > >>> >>> This proposal increases the size of the ACK frame by 1 byte in th= e > >>> >>> common > >>> >>> case (less than 63 ACK ranges), since the ACK length field here > >>> >>> always > >>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-lengt= h > >>> >>> integer. > >>> >>> Considering how much work we put into minimising the size of the > >>> >>> frames, > >>> >>> this feels like a step in the wrong direction.. > >>> >>> > >>> >>> Regarding the processing cost, I agree with Dmitri. Handling an A= CK > >>> >>> frame > >>> >>> requires looping over and making changes to a data structure that > >>> >>> keeps > >>> >>> track of sent packets. This is much more expensive than simply > >>> >>> parsing > >>> >>> a > >>> >>> bunch of varints in the ACK frame. It seems unlikely that a > >>> >>> multi-threaded > >>> >>> packet parser would offer any real-world performance benefits. > >>> >> > >>> >> > >>> >> I don't want to overstate the benefit here, but my point isn't tha= t > >>> >> parsing is expensive but that if you want to have a multithreaded > >>> >> packet > >>> >> processing system, then it's nice to have a simpler data structure > >>> >> (the > >>> >> unparsed ACK block) to hand to the ACK processing thread. > >>> >> > >>> >> -Ekr > >>> >> > >>> >> > >>> >>> > >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson > >>> >>> > >>> >>> wrote: > >>> >>>> > >>> >>>> When we discussed this before, some people observed that this > >>> >>>> creates > >>> >>>> a need to encode in two passes. That's the trade-off here. (No= t > >>> >>>> expressing an opinion.) > >>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar > >>> >>>> wrote: > >>> >>>> > > >>> >>>> > I don't have a strong opinion on this. I'm certainly not oppos= ed > >>> >>>> > to > >>> >>>> > it. > >>> >>>> > Does anyone have a strong opposition? > >>> >>>> > > >>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian > >>> >>>> > wrote: > >>> >>>> >> > >>> >>>> >> I agree as well since this can help reduce per packet > processing > >>> >>>> >> overhead. ACKs are going to be the second most common frame > type > >>> >>>> >> so no > >>> >>>> >> objections to special casing. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric > >>> >>>> >> Rescorla > >>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM > >>> >>>> >> To: Deval, Manasi > >>> >>>> >> Cc: Jana Iyengar ; QUIC WG > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> I agree with Manasi here. This change would allow ack frame > >>> >>>> >> parsing > >>> >>>> >> to be more self-contained, which is an advantage for the pars= er > >>> >>>> >> and also > >>> >>>> >> potentially for parallelism (because you can quickly find the > >>> >>>> >> frame and then > >>> >>>> >> process it in parallel). > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> -Ekr > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> In general, varints require some specific logic for parsing. = To > >>> >>>> >> skip > >>> >>>> >> over any header, I have to read every single varint. As the > code > >>> >>>> >> sees Stream > >>> >>>> >> and ACK headers most frequently, that is my focus. The Strea= m > >>> >>>> >> frame has a > >>> >>>> >> length in its third field. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identif= y > >>> >>>> >> length. There are two reads each for =E2=80=98largest acknowl= edged=E2=80=99, > =E2=80=98ACK > >>> >>>> >> delay=E2=80=99 and > >>> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the tota= l number of cycles > >>> >>>> >> parse an > >>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packe= ts > >>> >>>> >> have a > >>> >>>> >> piggybacked ACK, these cycles becomes a significant bottlenec= k. > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> Thanks, > >>> >>>> >> > >>> >>>> >> Manasi > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana > >>> >>>> >> Iyengar > >>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM > >>> >>>> >> To: Deval, Manasi ; QUIC WG > >>> >>>> >> > >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK > length > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> You're right that we no longer have the ability to skip an AC= K > >>> >>>> >> frame, > >>> >>>> >> and this crept in when we moved to varints. > >>> >>>> >> > >>> >>>> >> I believe your problem though is generally true of most frame= s > >>> >>>> >> not > >>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all fram= es > >>> >>>> >> are now all > >>> >>>> >> varints. To skip any frame, you'll need to parse the varint > >>> >>>> >> fields > >>> >>>> >> in those > >>> >>>> >> frames. If you have logic to process and skip varints, then > >>> >>>> >> skipping the ack > >>> >>>> >> block section is merely repeating this operation > (2*num_block+1) > >>> >>>> >> times. Do > >>> >>>> >> you see specific value in skipping ACK frames over the other > >>> >>>> >> control frames? > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov > >>> >>>> >> wrote: > >>> >>>> >> > >>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote= : > >>> >>>> >> > - Moving the ACK length to the front of the ACK allo= ws > >>> >>>> >> > the > >>> >>>> >> > flexibility of either reading the entire ACK or > >>> >>>> >> > reading > >>> >>>> >> > the > >>> >>>> >> > first 16 bits and skipping over the length. This i= s > a > >>> >>>> >> > useful > >>> >>>> >> > feature for the case where ACK processing is split > >>> >>>> >> > into > >>> >>>> >> > multiple layers. Depending on the processor this i= s > >>> >>>> >> > run > >>> >>>> >> > on, > >>> >>>> >> > there are different advantages - > >>> >>>> >> > >>> >>>> >> Just a note. In my experience, the cost of parsing an ACK > frame > >>> >>>> >> is > >>> >>>> >> negligible compared to the cost of processing an ACK frame: > that > >>> >>>> >> is, > >>> >>>> >> poking at various memory locations to discard newly ACKed > >>> >>>> >> packets. > >>> >>>> >> > >>> >>>> >> - Dmitri. > >>> >>>> >> > >>> >>>> >> > >>> >>>> > >>> >> > >>> > > >>> > >>> > >>> > >>> -- > >>> Kazuho Oku > > > > > > > > -- > > Kazuho Oku > > > > -- > Kazuho Oku > --0000000000008ece6f056f3d55ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Another option is to= write out frames as is without length except as needed for varints. When a= packet is nearly done, a run-length encoded frame index is placed in the p= acket tail. It could also include the frame types. A reader can now directl= y find or skip ACK frames and the writer does not have to compute lengths b= efore writing. Of course, the reader needs to be able to locate the index a= t the tail which can be tricky with coalesced packets, but not impossible. = Isn=E2=80=99t this largely how zip-files work?

Mikkel

On 22 June 2018 at 17.00.52, Mikkel Fa= hn=C3=B8e J=C3=B8rgensen (mikkelfj@gm= ail.com) wrote:

=
As I said earlier, I also favour a length prefix. But, Ian does have a point:

Writing data is generally more expensive than reading data. Especially if you have to traverse long data structures to find the length before you can start writing and/or you may have to conservatively reserve extra space for a length field.

So before deciding one way or the other, the cost of writing needs to be well understood, also in scenarios with large MTU=E2=80=99s.

In the flatbuffers space that I=E2=80=99m involved with, streaming has turned to be an issue because data cannot be transmitted in parts without index data on a separate channel to recombined fragments. A simple, but non-standard, change in the format would fix this. JSON and CoAP allows streaming, but many other formats do not, including later versions of protocol buffers, as I understand.

An odd consequence of making both read and write efficient is that length better work better if stored at the end and packets read backwards. This requires a single total length prefix but this is stored in the datagram header. This is probably too odd-ball, but still a consideration worth noting.

The second best alternative may therefore be to allow writes to be fast and reads to be decent.

Yet, I still like length prefixes if they could be made write efficient because high performance low-latency processes care zero about ACK and can consume a packet directly while a background process handles all the latency insensitive ACK and retransmission logic.

The question is also, where is the pressure: an IoT aggregator might be massively read intensive while a web cache would be very write intensive.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote:

It seems like there are two questions at hand here:

1. Would it be architecturally better to have frames have a consistent self-contained
representation?
2. Is it enough better that we should do so now.

I agree with Kazuho that (a) we don't have that representation now and (b) it would
be a better design to do so. I'm perhaps somewhat more positive on (2) than he
is. I don't think it's critically important that we make the change, but if we were
to hold a consensus call, I think I would be in favor. I'd certainly be interested
in looking at a proposal if someone else were to make one.

-Ekr
On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
2018-06-22 8:08 GMT+09:00 Deval, Manasi <manasi.deval@intel.com>:
> I feel that the requirement to have every value valid is somewhat academic.

I think that Marten is correct in pointing out that making the ACK
frame self-containing (by having a field that represents the number of
octets being consumed by the frame) would be an exception from the
design pattern we have.

Look at STREAM frame. The field is not self-contained. Instead, it has
a Length field for the Stream Data, which is a leaf. The same goes for
NEW_CONNECTION_ID frame (that has the length field for Connection ID
field (which is also a leaf)), CONNECTION_CLOSE (length field for
Reason Phase).

I agree with Marten, Mikkel (and possibly others as well) that having
consistency is important.

Therefore, I agree with Mikkel that we should consider making every
frame self-contained or keeping every frame as-is (i.e. not
self-contained).

FWIW, as described in the latter half of
https://www.ietf.org/mail-archi= ve/web/quic/current/msg04287.html, it
is possible to make every frame self-contained *and* also make ACK
frames smaller than the current draft. Making every frame
self-contained gives us the possibility to send new extension frames
without negotiation.

I do not think that I would push for making every frame self-contained
by myself (because I do not think it meets the high bar to have a
change at such a late moment of standardization), but as stated, my
preference goes to seeing every frame made self-contained or none of
them made as such.

> The length value provides much more value than the block count and the fact
> that certain values can never be achieved is an inherent property of the
> length.
>
>
>
> One interesting observation is that this property is not limited to length.
> One can even make a similar argument about ACK block count. The maximum
> number of ACK blocks that can be defined will not always have a meaningful
> value. In out examples, 0,1,2,3 are all valid. If I set the value of ACK
> block count to have lower two bits to be 11, the maximum value is of ACK
> blocks is =E2=80=93 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would still
> be meaningless.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Tuesday, June 19, 2018 6:44 PM
> To: Deval, Manasi <manasi= ..deval@intel.com>
> Cc: Ian Swett <ianswett@goog= le.com>; Kazuho Oku <kazuhooku@gmail.com>; Eric
> Rescorla <ekr@rtfm.com>; Jan= a Iyengar <jri.ietf@gmail.com>; Praveen
> Balasubramanian <pravb@micro= soft.com>; IETF QUIC WG <quic@ietf.org>; Martin
> Thomson <martin.thomson= @gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Hi Manasi,
>
>
>
>> The risk of disagreement between ack blocks and ack block count is same as
>> the risk of disagreement between ack blocks and ack length. Either way this
>> needs to be counted up while creating the ACK and counted down while parsing
>> it. The possibility of error is the same. Getting the ack block count wrong
>> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
> I disagree. Let's take an example of an ACK frame with one ACK range, that
> needs a 2 byte varint to represent the First ACK Block and another 2 byte
> varint to represent the Gap.
>
> With your proposal:
>
> The values 0 and 1 are invalid, since the length fields itself is included
> in the length.
> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 are
> invalid, since the length needs to include the Largest Acknowledged and the
> Ack Delay.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first
> valid value, and correspond to an ACK frame with no blocks.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, since
> it would cut the varint for the First ACK Block
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, since
> it would cut the frame after the First ACK Block (but every block must be
> followed by a gap length)
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, since
> it would cut the varint for the Gap
> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is valid
>
> There are *a lot* of invalid values that you can encode into the ACK length
> field. More importantly, *none* of these error cases exists with the current
> frame format.
>
> The *only* error case that can occur with our current format is that the
> packet is too short for the number of ACK blocks that are supposed to
> contained in the frame. This can occur with your proposal as well (in
> addition to the error cases listed above).
>
>
>
> My concern is not that it's impossible or even particularly hard to catch
> these errors, but I dislike the property that some (in fact, most) encodable
> values are invalid.
>
>
>
> Best,
>
> Marten
>
>
>
>
>
> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi Ian,
>
>
>
> Here is another attempt to solve the objections you raised:
>
>
>
>>I'm not a fan of this proposal, because I think it is impractical to drop
>> the number of ack blocks, because with the ECN proposal it becomes
>> impractically complex to parse.
>
> Is there a reason the proposal from Christian does not solve this problem?
>
>
>
>>If we don't remove the number of ack blocks, then the ack frame is larger,
>> but I don't think the extra size field is useful for most implementations.
>> Also, it means the length can disagree with the actual length, which add
>> complexity and the possibility of writing error-prone code.=C2=A0 The idea of
>> someone offloading ack processing and then proceeding to trust the length
>> seems like someone could get wrong and cause some concerning issues.
>
> The risk of disagreement between ack blocks and ack block count is same as
> the risk of disagreement between ack blocks and ack length. Either way this
> needs to be counted up while creating the ACK and counted down while parsing
> it. The possibility of error is the same. Getting the ack block count wrong
> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
>>My experience is multithreaded packet processing is more cost and work than
>> it's worth.=C2=A0 Sure you can't fill a 100G NIC with one connection, but that
>> seems like an academic problem, not one for workloads I've seen.=C2=A0 Typically
>> the extra cost of multithreading outweighs its value.
>
> The value is two fold =E2=80=93 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be
> coalesced, the receive side can indicate a large chunk of information though
> the kernel, reducing the cost of system call and protocol overhead. This is
> the same concept as UDP segmentation taken a step further on receive side.
> After this chunk is indicated into the QUIC protocol, the protocol may
> process stream and ACK in parallel. While folks may or may not utilize this,
> there is an advantage here.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Ian Swett [mailto:ianswet= t@google.com]
> Sent: Tuesday, June 19, 2018 11:26 AM
> To: Deval, Manasi <manasi= ..deval@intel.com>
> Cc: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>= ; Eric Rescorla <ekr@rtfm.com>; Jana Iyengar
> <jri.ietf@gmail.com>; = Praveen Balasubramanian <pravb@microsoft.= com>; IETF
> QUIC WG <quic@ietf.org>; Ma= rtin Thomson <martin.thomson@gmail.com>
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> I'm still not interested in this change, for the reasons I stated above.
>
>
>
> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com>
> wrote:
>
> Hi All,
>
>
>
> Do we have agreement here to create a new PR?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> From: Deval, Manasi
> Sent: Sunday, June 17, 2018 2:25 PM
> To: Marten Seemann <mart= enseemann@gmail.com>; Kazuho Oku
> <kazuhooku@gmail.com>=
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>= ;; Praveen Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; Martin Thomson
> <martin.thomson@gmail.c= om>
> Subject: RE: Proposal to replace ACK block count with ACK length
>
>
>
> Hi All,
>
>
>
> I have made a list of objections to the proposal and the solutions to those
> objections discussed on this thread.
>
>
>
> a.=C2=A0 =C2=A0 =C2=A0 Co-existence of length field with ECN field and ACK blocks.
>
>
>
> Christian suggested to move the ECN fields to precede the ACK blocks. This
> is an elegant solution. Parsing entire list of ACK blocks to review ECN bits
> would have been annoying, even though it can work.
>
>
>
> b.=C2=A0 =C2=A0 =C2=A0 There are two cases to be parsed =E2=80=93 entire ACK and parse ACK to
> identify length. There are some reservations when ACK parsing gets harder
> for the case where the entire header needs to be parsed.
>
>
>
> Agreement from several folks here. In the original ACK defined in draft 12
> of the slide, one would count down number of ACK blocks to get to the end of
> the packet. In the proposal I made, one would count down the length to
> identify the end of the packet. The logic is very similar in cycle count and
> complexity. Several folks also commented to this effect.
>
>
>
> c.=C2=A0 =C2=A0 =C2=A0 Multi-threaded packet processing
>
>
>
> I would expect that there are 10s of 1000s of connections in use at any time
> for a server with a high speed link. Multi-threading to handle each of these
> flows / connections in parallel is necessity to be able to support large
> number of connections on a high speed link. Tx segmentation, Rx coalescing
> are well known strategies to reduce the processing cost. In initial stages,
> code is often written as a single-threaded and then re-factored to
> parallelize cycle intensive operations. In order to allow this protocol to
> scale in future, I would suggest we do not preclude this case.
>
>
>
> d.=C2=A0 =C2=A0 =C2=A0 Increase in ACK size by 1 byte.
>
>
>
> I do not see this as a serious issue but if folks but we can consider making
> this a varint, if others have strong feelings about it. It=E2=80=99s a trade-off : 2
> reads to save 1 byte.
>
>
>
> e.=C2=A0 =C2=A0 =C2=A0 Every encodable value should be valid
>
> Not every length will be valid. This is inherent to lengths. This same issue
> ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only doe= s the issue exist for
> small values, it also applies to large values since data stream will be sent
> after crypto negotiation.=C2=A0 E.g.=C2=A0 - how does one craft a payload with 62 bit
> payload length in a large header?
>
>
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Sunday, June 17, 2018 6:59 AM
> To: Kazuho Oku <kazuhooku@gm= ail.com>
> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric Rescorla
> <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>= ;; Praveen Balasubramanian
> <pravb@microsoft.com>= ; IETF QUIC WG <quic@ietf.org>; Martin Thomson
> <martin.thomson@gmail.c= om>; Deval, Manasi <manasi.deval@in= tel.com>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Maybe it's specific to Go, but I'm using a single io.Reader for the whole
> packet, so as long as the packet payload is long enough, the varint parsing
> will not fail.
>
> I don't think that specifics of programming languages matter here though,
> and I'm sure both frame formats can be reasonably implemented in C as well
> as in Go. The reasons I'm opposed to Manasi's proposal are that it moves us
> away from the principle that only reasonable values should be encodable, and
> that it increases the size of the ACK frame, for the questionable benefit of
> being able to parallelise the frame parser.
>
>
>
> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> 2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.com>:
>> At least for my implementation, parsing doesn't become easier, it becomes
>> more complex with this proposal. My varint-parser always consumes as many
>> bytes as the varint requires, so after parsing a varint, I'd have to
>> introduce an additional check that this didn't overflow the ACK length
>> (e.g.
>> consider that I parsed the ACK frame so far that only 2 bytes are
>> remaining
>> according to ACK length field, but the next varint is 4 bytes long).
>
> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is
> necessary to avoid buffer overrun.
>
> What I am saying that that check could be converted to a overrun check
> against the end of the "frame payload", and that checking the
> remaining block count becomes unnecessary, in case we replace ACK
> Block Count with ACK Frame Length.
>
>>
>> In general, we've been moving the wire image towards making every
>> encodable
>> value valid. This proposal moves us away from that principle:
>> * some small values are always invalid (the length can never be between 0
>> and 3)
>> * a lot of intermediate values are invalid (if the boundary falls inside a
>> varint, as described above)
>> Both these cases can't occur with the current ACK frame format..
>>
>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>>> <ianswett=3D= 40google.com@dmarc.ietf.org>:
>>> > I'm not a fan of this proposal, because I think it is impractical to
>>> > drop
>>> > the number of ack blocks, because with the ECN proposal it becomes
>>> > impractically complex to parse.
>>>
>>> For the ECN proposal, as Christian has suggested, we can move the ECN
>>> counters before the ACK blocks. Then, it would not be complex to
>>> parse.
>>>
>>> And my view is that parsing becomes easier if we replace ACK Block
>>> Count with ACK Frame Length.
>>>
>>> Now, with ACK Block Count, we need to check the remaining number of
>>> blocks and the remaining space in the packet payload for every block
>>> that we parse. Failing to check either leads to a bug or a security
>>> issue.
>>>
>>> If we switch to ACK Frame Length, we need to only check the remaining
>>> space in the frame.
>>>
>>> I think that this is the biggest benefit of replacing ACK Block Count
>>> with ACK Frame Length. OTOH the downside is that you need extra one to
>>> two bits (one if the size of block / gap is expected to be below 65,
>>> two if they are expected to be above that) for encoding ACK Frame
>>> Length compared to ACK Block Count.
>>>
>>>
>>>
>>> Having said that, I honestly wonder if all the frames could have it's
>>> length being encoded (either explicitly or either as a signal that
>>> says "to the end of the packet"). Consider something like below:
>>>
>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) |
>>>=C2=A0 or
>>> |1| frame-type (7) | frame-payload (*) |
>>>
>>> When MSB of the first octet set to zero, the length of the frame
>>> payload is designated by the varint that immediately follows the frame
>>> type.
>>> When MSB of the first octet set to one, the length of the frame
>>> payload spans to the end of the packet.
>>>
>>> In this encoding, we can always omit the Length field of a STREAM
>>> frame. So the overhead for carrying stream data will be indifferent in
>>> practice.
>>>
>>> For the ACK frame, we can omit the ACK Block Count field. And the
>>> overhead will be one to two bits if the ACK frame is sent in the
>>> middle of the packet (thereby using the encoding with explicit frame
>>> payload length), or one octet or more shorter if ACK is the last frame
>>> of the packet.
>>>
>>> We are likely to see increase of overhead for most of the other types
>>> of frames, but I do not think that would be an issue considering that
>>> they will be far seldom seen compared to STREAMs and ACKs.
>>>
>>> To summarize, my anticipation is that we can make all the frames
>>> self-contained (i.e. the length can be determined without the
>>> knowledge of how each frame is encoded) without any overhead, if we
>>> agree on making the frame type space 1 bit smaller.
>>>
>>> Finally, the biggest benefit of using a self-contained encoding of
>>> frames is that we would have the ability to introduce new optional
>>> frames without negotiation. By making the frames self-contained, QUIC
>>> endpoints will have the freedom of ignoring the frames that they do
>>> not understand.
>>>
>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both terms of
>>> security (because clients' TP is sent in clear) and flexibility
>>> (because we will be possible to send the extensions before we figure
>>> out whether the peer supports that extension).
>>>
>>> > If we don't remove the number of ack blocks, then the ack frame is
>>> > larger,
>>> > but I don't think the extra size field is useful for most
>>> > implementations.
>>> > Also, it means the length can disagree with the actual length, which
>>> > add
>>> > complexity and the possibility of writing error-prone code.=C2=A0 The idea
>>> > of
>>> > someone offloading ack processing and then proceeding to trust the
>>> > length
>>> > seems like someone could get wrong and cause some concerning issues.
>>> >
>>> > My experience is multithreaded packet processing is more cost and work
>>> > than
>>> > it's worth.=C2=A0 Sure you can't fill a 100G NIC with one connection, but
>>> > that
>>> > seems like an academic problem, not one for workloads I've seen.
>>> > Typically
>>> > the extra cost of multithreading outweighs its value.
>>> >
>>> > To be clear, I don't think this is an awful idea, but I also don't see
>>> > the
>>> > value and it adds complexity.=C2=A0 I read Manasi's email, but I don't think
>>> > I
>>> > understand why any of those matter in practice.
>>> >
>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>> >>
>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>>> >> <marten= seemann@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> This proposal increases the size of the ACK frame by 1 byte in the
>>> >>> common
>>> >>> case (less than 63 ACK ranges), since the ACK length field here
>>> >>> always
>>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length
>>> >>> integer.
>>> >>> Considering how much work we put into minimising the size of the
>>> >>> frames,
>>> >>> this feels like a step in the wrong direction..
>>> >>>
>>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK
>>> >>> frame
>>> >>> requires looping over and making changes to a data structure that
>>> >>> keeps
>>> >>> track of sent packets. This is much more expensive than simply
>>> >>> parsing
>>> >>> a
>>> >>> bunch of varints in the ACK frame. It seems unlikely that a
>>> >>> multi-threaded
>>> >>> packet parser would offer any real-world performance benefits.
>>> >>
>>> >>
>>> >> I don't want to overstate the benefit here, but my point isn't that
>>> >> parsing is expensive but that if you want to have a multithreaded
>>> >> packet
>>> >> processing system, then it's nice to have a simpler data structure
>>> >> (the
>>> >> unparsed ACK block) to hand to the ACK processing thread.
>>> >>
>>> >> -Ekr
>>> >>
>>> >>
>>> >>>
>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> <m= artin.thomson@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> When we discussed this before, some people observed that this
>>> >>>> creates
>>> >>>> a need to encode in two passes.=C2=A0 That's the trade-off here.=C2=A0 (Not
>>> >>>> expressing an opinion.)
>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <jri.ietf@gmail.com>= ;
>>> >>>> wrote:
>>> >>>> >
>>> >>>> > I don't have a strong opinion on this. I'm certainly not opposed
>>> >>>> > to
>>> >>>> > it.
>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >
>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian
>>> >>>> > <pravb@microsoft.com> wrote:
>>> >>>> >>
>>> >>>> >> I agree as well since this can help reduce per packet processing
>>> >>>> >> overhead. ACKs are going to be the second most common frame type
>>> >>>> >> so no
>>> >>>> >> objections to special casing.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric
>>> >>>> >> Rescorla
>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>= ;
>>> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> I agree with Manasi here. This change would allow ack frame
>>> >>>> >> parsing
>>> >>>> >> to be more self-contained, which is an advantage for the parser
>>> >>>> >> and also
>>> >>>> >> potentially for parallelism (because you can quickly find the
>>> >>>> >> frame and then
>>> >>>> >> process it in parallel).
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> -Ekr
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi
>>> >>>> >> <manasi.deval@intel.com> wrote:
>>> >>>> >>
>>> >>>> >> In general, varints require some specific logic for parsing. To
>>> >>>> >> skip
>>> >>>> >> over any header, I have to read every single varint. As the code
>>> >>>> >> sees Stream
>>> >>>> >> and ACK headers most frequently, that is my focus.=C2=A0 The Stream
>>> >>>> >> frame has a
>>> >>>> >> length in its third field.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify
>>> >>>> >> length. There are two reads each for =E2=80=98largest acknowledged=E2=80=99, =E2=80=98ACK
>>> >>>> >> delay=E2=80=99 and
>>> >>>> >> =E2=80=98ACK block count=E2=80=99. T= he pain point is the total number of cycles
>>> >>>> >> parse an
>>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets
>>> >>>> >> have a
>>> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Thanks,
>>> >>>> >>
>>> >>>> >> Manasi
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana
>>> >>>> >> Iyengar
>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>= ;; QUIC WG
>>> >>>> >> <quic@ietf.org>
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK length
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> You're right that we no longer have the ability to skip an ACK
>>> >>>> >> frame,
>>> >>>> >> and this crept in when we moved to varints.
>>> >>>> >>
>>> >>>> >> I believe your problem though is generally true of most frames
>>> >>>> >> not
>>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames
>>> >>>> >> are now all
>>> >>>> >> varints. To skip any frame, you'll need to parse the varint
>>> >>>> >> fields
>>> >>>> >> in those
>>> >>>> >> frames. If you have logic to process and skip varints, then
>>> >>>> >> skipping the ack
>>> >>>> >> block section is merely repeating this operation (2*num_block+1)
>>> >>>> >> times. Do
>>> >>>> >> you see specific value in skipping ACK frames over the other
>>> >>>> >> control frames?
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov
>>> >>>> >> <dtikhonov@litespeedtech..com> wrote:
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>>> >>>> >> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving the ACK length to the front of the ACK allows
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flexibility of either reading the entire ACK or
>>> >>>> >> > reading
>>> >>>> >> > the
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first 16 bits and skipping over the length. This is a
>>> >>>> >> > useful
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature for the case where ACK processing is split
>>> >>>> >> > into
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple layers. Depending on the processor this is
>>> >>>> >> > run
>>> >>>> >> > on,
>>> >>>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are different advantages -
>>> >>>> >>
>>> >>>> >> Just a note.=C2=A0 In my experience, the cost of parsing an ACK frame
>>> >>>> >> is
>>> >>>> >> negligible compared to the cost of processing an ACK frame: that
>>> >>>> >> is,
>>> >>>> >> poking at various memory locations to discard newly ACKed
>>> >>>> >> packets.
>>> >>>> >>
>>> >>>> >>=C2=A0 =C2=A0- Dmitri.
>>> >>>> >>
>>> >>>> >>
>>> >>>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku

--0000000000008ece6f056f3d55ba-- From nobody Fri Jun 22 09:26:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87682130EAE for ; Fri, 22 Jun 2018 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoHGdACw8v7j for ; Fri, 22 Jun 2018 09:26:46 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A060F130EA6 for ; Fri, 22 Jun 2018 09:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9v9W6Rxzc53eXwAUt0wy8Cl4z4YjoblLiPqfpwZuCRw=; b=kdUUNupuWUsKuwFaCiKQuKl6IyXt6mFG33CFKfu8v7HnHpw7znxUdXpqWlGo6ZIoDPAUsIpSP8OA/6OeBhPQ6gk1beZ3jkiw5hHlDn1QMmKFv9OKuzbzOKlg5jonRgCKHNYq1c3MLoTtBofNPcQM5X1w6spXJomk67W+crtcQZ0= Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.10; Fri, 22 Jun 2018 16:26:44 +0000 Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::45a2:e78:b9f8:3598]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::45a2:e78:b9f8:3598%3]) with mapi id 15.20.0906.013; Fri, 22 Jun 2018 16:26:44 +0000 From: Praveen Balasubramanian To: Ian Swett , Kazuho Oku CC: Nick Banks , IETF QUIC WG Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgA== Date: Fri, 22 Jun 2018 16:26:44 +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: [2001:4898:80e8:0:19c3:384a:d0f:b138] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0118; 7:xxZz/qICTDkze/ftZ8g/bnJAjBaBbZszqBvwAacYlBFfAF59pCdCwOsj1eQVhe/6mrb+nEhEsrbxXC4XX1247L7i9zymv84YMZSVYwONkGPKKHfbaJD0R5st5opK+KLQPabtw33OAxlFCck10/AetYnyMJ96ybKXevPp3bfvGCZXOybM2nDFQwrBfXZhpvuo8oTpvBN+GnBCvA5zY0tGSm8E/gzhG/yzEVlg4imqHThMwLINT5ArJLzQImwCcwa9 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a67df7ba-3302-4442-73be-08d5d85cf1a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989114)(4534165)(4627221)(201703031133081)(201702281549075)(8990104)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0118; x-ms-traffictypediagnostic: CY4PR21MB0118: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0118; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0118; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(39380400002)(396003)(346002)(199004)(189003)(55016002)(4326008)(59450400001)(68736007)(486006)(9686003)(54896002)(74316002)(2900100001)(316002)(10290500003)(3480700004)(606006)(25786009)(86362001)(22452003)(6306002)(478600001)(236005)(97736004)(6436002)(229853002)(106356001)(54556002)(7696005)(5890100001)(733005)(76176011)(33656002)(53936002)(93886005)(476003)(105586002)(86612001)(5250100002)(3660700001)(19609705001)(2906002)(99286004)(53946003)(10090500001)(3280700002)(11346002)(46003)(6116002)(446003)(14454004)(561924002)(790700001)(8936002)(6246003)(81166006)(53546011)(6506007)(186003)(102836004)(81156014)(5660300001)(7736002)(966005)(110136005)(345774005)(54906003)(8990500004)(8676002)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3sbvUpYYFnVFbKcIuWDQW/W5uUxMNtUTmL/jEqHCmCK0VZwN0ljOpSCdgd8FggJIUv9vLkfHi8PvsRUWOAD6gxHg7Hah326khcAsjITQtKlAHg3QQ6zmuD7s9T2jKqtY6BG3/hlD16rrdz+TdqfOOaQ7StSdxm/3lwLPbST40GUAOY4ap45BgxSrgiNp4QMdlePyanwVcUd3fTKy8q4szti5iOu6FMHbuj6bB+kXW+YEyMAOqMkL0WJHjWTOf+LuCtx0e6Wc8W4iZB2Zpoo4x4yUbZOCsY7UPHS6RB8xT5BUrgh+EaqKTUgO0YTFMM1i spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB06303A8C17796335F3A3FDE2B6750CY4PR21MB0630namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a67df7ba-3302-4442-73be-08d5d85cf1a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 16:26:44.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0118 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:26:51 -0000 --_000_CY4PR21MB06303A8C17796335F3A3FDE2B6750CY4PR21MB0630namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWFuLCBkbyB5b3UgZXhwZWN0IHRoYXQgZnJhY3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRvIGhvbGQg b25jZSB0aGUgVURQIHN0YWNrIGlzIG9wdGltaXplZD8gSXMgeW91ciBtZWFzdXJlbWVudCBvbiB0 b3Agb2YgdGhlIHJlY2VudCBrZXJuZWwgaW1wcm92ZW1lbnRzPyBJIGV4cGVjdCBjcnlwdG8gZnJh Y3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRvIGtlZXAgaW5jcmVhc2luZyBvdmVyIHRpbWUgYXMgdGhl IG5ldHdvcmsgc3RhY2sgYm90dGxlbmVja3MgYXJlIGVsaW1pbmF0ZWQuDQoNCkthenVobywgc2hv dWxkIHRoZSBkcmFmdCBkZXNjcmliZSB0aGUgb3B0aW1pemF0aW9ucyB5b3UgYXJlIG1ha2luZz8g T3IgYXJlIHRoZXNlIGFyZSB0b28gT3BlblNTTCBzcGVjaWZpYz8NCg0KRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDog RnJpZGF5LCBKdW5lIDIyLCAyMDE4IDQ6NDUgQU0NClRvOiBLYXp1aG8gT2t1IDxrYXp1aG9va3VA Z21haWwuY29tPg0KQ2M6IE5pY2sgQmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbT47IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5 cHRpb24gUGVyZm9ybWFuY2UNCg0KVGhhbmtzIGZvciBkaWdnaW5nIGludG8gdGhlIGRldGFpbHMg b2YgdGhpcywgS2F6dWhvLiAgPDQlIGluY3JlYXNlIGluIGNyeXB0byBjb3N0IGlzIGEgYml0IG1v cmUgdGhhbiBJIG9yaWdpbmFsbHkgZXhwZWN0ZWQofjIlKSwgYnV0IGNyeXB0byBpcyBsZXNzIHRo YW4gMTAlIG9mIG15IENQVSB1c2FnZSwgc28gaXQncyBzdGlsbCBsZXNzIHRoYW4gMC41JSB0b3Rh bCwgd2hpY2ggaXMgYWNjZXB0YWJsZSB0byBtZS4NCg0KT24gRnJpLCBKdW4gMjIsIDIwMTggYXQg Mjo0NSBBTSBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VA Z21haWwuY29tPj4gd3JvdGU6DQoNCg0KMjAxOC0wNi0yMiAxMjoyMiBHTVQrMDk6MDAgS2F6dWhv IE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+Og0K DQoNCjIwMTgtMDYtMjIgMTE6NTQgR01UKzA5OjAwIE5pY2sgQmFua3MgPG5pYmFua3NAbWljcm9z b2Z0LmNvbTxtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tPj46DQpIaSBLYXp1aG8sDQoNClRo YW5rcyBmb3Igc2hhcmluZyB5b3VyIG51bWJlcnMgYXMgd2VsbCEgSSdtIGJpdCBjb25mdXNlZCB3 aGVyZSB5b3Ugc2F5IHlvdSBjYW4gcmVkdWNlIHRoZSAxMCUgb3ZlcmhlYWQgdG8gMiUgdG8gNCUu IEhvdyBkbyB5b3UgcGxhbiBvbiBkb2luZyB0aGF0Pw0KDQpBcyBzdGF0ZWQgaW4gbXkgcHJldmlv dXMgbWFpbCwgdGhlIDEwJSBvZiBvdmVyaGVhZCBjb25zaXN0cyBvZiB0aHJlZSBwYXJ0cywgZWFj aCBjb25zdW1pbmcgY29tcGFyYWJsZSBudW1iZXIgb2YgQ1BVIGN5Y2xlcy4gVGhlIHR3byBhbW9u ZyB0aGUgdGhyZWUgaXMgcmVsYXRlZCB0byB0aGUgYWJzdHJhY3Rpb24gbGF5ZXIgYW5kIGhvdyBD VFIgaXMgaW1wbGVtZW50ZWQsIHdoaWxlIHRoZSBvdGhlciBvbmUgaXMgdGhlIGNvcmUgQUVTLUVD QiBvcGVyYXRpb24gY29zdC4NCg0KSXQgc2hvdWxkIGJlIGFibGUgdG8gcmVtb3ZlIHRoZSBjb3N0 bHkgYWJzdHJhY3Rpb24gbGF5ZXIuDQoNCkl0IHNob3VsZCBhbHNvIGJlIHBvc3NpYmxlIHRvIHJl bW92ZSB0aGUgb3ZlcmhlYWQgb2YgQ1RSLCBzaW5jZSBpbiBQTkUsIHdlIG5lZWQgdG8gWE9SIGF0 IG1vc3QgNCBvY3RldHMgKGFwcGx5aW5nIFhPUiBpcyB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdl ZW4gQ1RSIGFuZCBFQ0IpLiBUaGF0IGNvc3Qgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IHNob3Vs ZCBiZSBwb3NzaWJsZSB0byBiZSBudWxsaWZpZWQuDQoNCkNvbnNpZGVyaW5nIHRoZXNlIGFzcGVj dHMsIGFuZCBieSBsb29raW5nIGF0IHRoZSBudW1iZXJzIG9uIHRoZSBPcGVuU1NMIHNvdXJjZSBj b2RlIChhcyB3ZWxsIGFzIGNvbnNpZGVyaW5nIHRoZSBvdmVyaGVhZCBvZiBHQ00pLCBteSBleHBl Y3RhdGlvbiBnb2VzIHRvIDIlIHRvIDQlLg0KDQpKdXN0IGRpZCBzb21lIGV4cGVyaW1lbnRzIGFu ZCBpdCBzZWVtcyB0aGF0IHRoZSBleHBlY3RhdGlvbiB3YXMgY29ycmVjdC4NCg0KVGhlIGJlbmNo bWFya3MgdGVsbCBtZSB0aGF0IHRoZSBvdmVyaGVhZCBnb2VzIGRvd24gZnJvbSAxMC4wJSB0byAz LjglLCBieSBkb2luZyB0aGUgZm9sbG93aW5nOg0KDQoqIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2Yg Q1RSIGFic3RyYWN0aW9uIChpLmUuIHVzZSB0aGUgRUNCIGJhY2tlbmQgYW5kIGRvIFhPUiBieSBv dXJzZWx2ZXMpDQoqIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2YgdGhlIGFic3RyYWN0aW9uIGxheWVy IChpLmUuIGNhbGwgdGhlIG1ldGhvZCByZXR1cm5lZCBieSBFVlBfQ0lQSEVSX21ldGhfZ2V0X2Rv X2NpcGhlciBpbnN0ZWFkIG9mIGNhbGxpbmcgRVZQX0VuY3J5cHRVcGRhdGUpDQoNCk9mIGNvdXJz ZSB0aGUgY2hhbmdlcyBhcmUgc3BlY2lmaWMgdG8gT3BlblNTTCwgYnV0IEkgd291bGQgZXhwZWN0 IHRoYXQgeW91IGNhbiBleHBlY3Qgc2ltaWxhciBudW1iZXJzIGFzc3VtaW5nIHRoYXQgeW91IGhh dmUgYWNjZXNzIHRvIGFuIG9wdGltaXplZCBBRVMgaW1wbGVtZW50YXRpb24uDQoNCg0KDQpTZW50 IGZyb20gbXkgV2luZG93cyAxMCBwaG9uZQ0KW0h4UyAtIDE1MjU0IC0gMTYuMC4xMDIyOC4yMDA3 NV0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEthenVobyBPa3Ug PGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KU2VudDog VGh1cnNkYXksIEp1bmUgMjEsIDIwMTggNzoyMToxNyBQTQ0KVG86IE5pY2sgQmFua3MNCkNjOiBx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBhY2tldCBO dW1iZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZQ0KDQpIaSBOaWNrLA0KDQpUaGFuayB5b3UgZm9y IGJyaW5naW5nIHRoZSBudW1iZXJzIHRvIHRoZSBsaXN0Lg0KDQpJIGhhdmUganVzdCBydW4gYSBz bWFsbCBiZW5jaG1hcmsgdXNpbmcgUXVpY2x5LCBhbmQgSSBzZWUgY29tcGFyYWJsZSBudW1iZXJz Lg0KDQpUbyBiZSBwcmVjaXNlLCBJIHNlZSAxMC4wJSBpbmNyZWFzZSBvZiBDUFUgY3ljbGVzIHdo ZW4gZW5jcnlwdGluZyBhIEluaXRpYWwgcGFja2V0IG9mIDEsMjgwIG9jdGV0cy4gSSBleHBlY3Qg dGhhdCB3ZSB3aWxsIHNlZSBzaW1pbGFyIG51bWJlcnMgb24gb3RoZXIgUVVJQyBzdGFja3MgdGhh dCBhbHNvIHVzZSBwaWNvdGxzICh3aXRoIE9wZW5TU0wgYXMgYSBiYWNrZW5kKS4gTm90ZSB0aGF0 IHRoZSBudW1iZXIgaXMgb25seSBjb21wYXJpbmcgdGhlIGNvc3Qgb2YgZW5jcnlwdGlvbiwgdGhl IG92ZXJoZWFkIHJhdGlvIHdpbGwgYmUgbXVjaCBzbWFsbGVyIGlmIHdlIGxvb2sgYXQgdGhlIHRv dGFsIG51bWJlciBvZiBDUFUgY3ljbGVzIHNwZW50IGJ5IGEgUVVJQyBzdGFjayBhcyBhIHdob2xl Lg0KDQpMb29raW5nIGF0IHRoZSBwcm9maWxlLCB0aGUgb3ZlcmhlYWQgY29uc2lzdHMgb2YgdGhy ZWUgb3BlcmF0aW9ucyB0aGF0IGVhY2ggY29uc3VtZXMgY29tcGFyYWJsZSBDUFUgY3ljbGVzOiBj b3JlIEFFUyBvcGVyYXRpb24gKHVzaW5nIEFFUy1OSSksIENUUiBvcGVyYXRpb24gb3ZlcmhlYWQs IENUUiBpbml0aWFsaXphdGlvbi4gTm90ZSB0aGF0IHBpY290bHMgYXQgdGhlIG1vbWVudCBwcm92 aWRlcyBhY2Nlc3MgdG8gQ1RSIGNyeXB0byBiZW5lYXRoIHRoZSBBRUFEIGludGVyZmFjZSwgd2hp Y2ggaXMgdG8gYmUgdXNlZCBieSB0aGUgUVVJQyBzdGFja3MuDQoNCkkgd291bGQgYXNzdW1lIHRo YXQgd2UgY2FuIGN1dCBkb3duIHRoZSBvdmVyaGVhZCB0byBzb21ld2hlcmUgYmV0d2VlbiAyJSB0 byA0JSwgYnV0IGl0IG1pZ2h0IGJlIGhhcmQgdG8gZ28gZG93biB0byBzb21ld2hlcmUgbmVhciAx JSwgYmVjYXVzZSB3ZSBjYW5ub3QgcGFyYWxsZWxpemUgdGhlIEFFUyBvcGVyYXRpb24gb2YgUE5F IHdpdGggdGhhdCBvZiBBRUFEIChzZWUgaHR0cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNz bC9ibG9iL09wZW5TU0xfMV8xXzBoL2NyeXB0by9hZXMvYXNtL2Flc25pLXg4Nl82NC5wbCNMMjQt TDM5PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm9wZW5zc2wlMkZvcGVuc3NsJTJGYmxvYiUyRk9wZW5T U0xfMV8xXzBoJTJGY3J5cHRvJTJGYWVzJTJGYXNtJTJGYWVzbmkteDg2XzY0LnBsJTIzTDI0LUwz OSZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3QzExZDU1ZjE3MzMzZTRh Nzk1ZDcwMDhkNWQ3ZTZkOTNjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjY1MjMwODg0Mzk5NDEzNCZzZGF0YT1rcU16NFNzTiUyRjJFckdLMDZRejhaMHZV enBsNE1paXBuTkUyd0FNVWI0NmMlM0QmcmVzZXJ2ZWQ9MD4gYWJvdXQgdGhlIGltcGFjdCBvZiBw YXJhbGxlbGl6YXRpb24pLg0KDQpJIGRvIG5vdCB0aGluayB0aGF0IDIlIHRvIDQlIG9mIGFkZGl0 aW9uYWwgb3ZlcmhlYWQgdG8gdGhlIGNyeXB0byBpcyBhbiBpc3N1ZSBmb3IgUVVJQy9IVFRQLCBi dXQgY3VycmVudCBvdmVyaGVhZCBvZiAxMCUgaXMgc29tZXRoaW5nIHRoYXQgd2UgbWlnaHQgd2Fu dCB0byBkZWNyZWFzZS4gSSBhbSBnbGFkIHRvIGJlIGFibGUgdG8gbGVhcm4gdGhhdCBub3cuDQoN Cg0KMjAxOC0wNi0yMiA1OjQ4IEdNVCswOTowMCBOaWNrIEJhbmtzIDxuaWJhbmtzPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc+PjoNCkhlbGxvIFFVSUMgV0csDQoNCkkgcmVjZW50bHkgaW1wbGVtZW50ZWQg UE5FIGZvciBXaW5RdWljICh1c2luZyBiY3J5cHQgQVBJcykgYW5kIEkgZGVjaWRlZCB0byBnZXQg c29tZSBwZXJmb3JtYW5jZSBudW1iZXJzIHRvIHNlZSB3aGF0IHRoZSBvdmVyaGVhZCBvZiBQTkUg d2FzLiBJIGZpZ3VyZWQgdGhlIHJlc3Qgb2YgdGhlIFdHIG1pZ2h0IGJlIGludGVyZXN0ZWQuDQoN Ck15IHRlc3QganVzdCBlbmNyeXB0cyB0aGUgc2FtZSBidWZmZXIgKHNpemUgZGVwZW5kZW50IG9u IHRoZSB0ZXN0IGNhc2UpIDEwLDAwMCwwMDAgdGltZXMgYW5kIG1lYXN1cmVkIHRoZSB0aW1lIGl0 IHRvb2suIFRoZSB0ZXN0IHRoZW4gZGlkIHRoZSBzYW1lIHRoaW5nLCBidXQgYWxzbyBlbmNyeXB0 ZWQgdGhlIHBhY2tldCBudW1iZXIgYXMgd2VsbC4gSSByYW4gYWxsIHRoYXQgMTAgdGltZXMgaW4g dG90YWwuIEkgdGhlbiBjb2xsZWN0ZWQgdGhlIGJlc3QgdGltZXMgZm9yIGVhY2ggY2F0ZWdvcnkg dG8gcHJvZHVjZSB0aGUgZm9sbG93aW5nIGdyYXBocyBhbmQgdGFibGVzIChmdWxsIGV4Y2VsIGRv YyBhdHRhY2hlZCk6DQoNCltjaWQ6aW1hZ2UwMDMucG5nQDAxRDQwOTY2Ljc2NTVCNkIwXQ0KDQoN ClRpbWUgKG1zKQ0KDQpSYXRlIChNYnBzKQ0KDQpCeXRlcw0KDQpOTyBQTkUNCg0KUE5FDQoNClBO RSBPdmVyaGVhZA0KDQpObyBQTkUNCg0KUE5FDQoNCjQNCg0KMjI4NC42NzENCg0KMzAyNy42NTcN Cg0KMzMlDQoNCjE0MC4wNjQNCg0KMTA1LjY5Mg0KDQoxNg0KDQoyMTAyLjQwMg0KDQoyODI4LjIw NA0KDQozNSUNCg0KNjA4LjgyNw0KDQo0NTIuNTg0DQoNCjY0DQoNCjIxOTguODgzDQoNCjI5MDcu NTc3DQoNCjMyJQ0KDQoyMzI4LjQ1DQoNCjE3NjAuOTINCg0KMjU2DQoNCjI3NTguMw0KDQozNDkw LjI4DQoNCjI3JQ0KDQo3NDI0Ljg2DQoNCjU4NjcuNzINCg0KNjAwDQoNCjQ2NjkuMjgzDQoNCjU0 MjQuNTM5DQoNCjE2JQ0KDQoxMDI4MA0KDQo4ODQ4LjY4DQoNCjEwMDANCg0KNjEzMC4xMzkNCg0K NjkwNy44MDUNCg0KMTMlDQoNCjEzMDUwLjMNCg0KMTE1ODEuMQ0KDQoxMjAwDQoNCjY0NTguNjc5 DQoNCjcyMjkuNjcyDQoNCjEyJQ0KDQoxNDg2My43DQoNCjEzMjc4LjYNCg0KMTQ1MA0KDQo3ODc2 LjMxMg0KDQo4NjcwLjE2DQoNCjEwJQ0KDQoxNDcyNy43DQoNCjEzMzc5LjINCg0KDQpJIHVzZWQg YSBzZXJ2ZXIgZ3JhZGUgbGFiIG1hY2hpbmUgSSBoYWQgYXQgbXkgZGlzcG9zYWwsIHJ1bm5pbmcg dGhlIGxhdGVzdCBXaW5kb3dzIDEwIFNlcnZlciBEYXRhQ2VudGVyIGJ1aWxkLiBBZ2FpbiwgdGhl c2UgbnVtYmVycyBhcmUgZm9yIGNyeXB0byBvbmx5LiBObyBRVUlDIG9yIFVEUCBpcyBpbmNsdWRl ZC4NCg0KVGhhbmtzLA0KLSBOaWNrDQoNCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQoNCg0KDQotLQ0K S2F6dWhvIE9rdQ0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_CY4PR21MB06303A8C17796335F3A3FDE2B6750CY4PR21MB0630namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm0t NjI4MjQ5OTg2MTMzNDEwNDA1MWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy02MjgyNDk5ODYx MzM0MTA0MDUxaG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklhbiwgZG8geW91IGV4cGVjdCB0aGF0IGZyYWN0aW9uIG9mIG92ZXJhbGwgY29zdCB0byBo b2xkIG9uY2UgdGhlIFVEUCBzdGFjayBpcyBvcHRpbWl6ZWQ/IElzIHlvdXIgbWVhc3VyZW1lbnQg b24gdG9wIG9mIHRoZSByZWNlbnQga2VybmVsIGltcHJvdmVtZW50cz8gSSBleHBlY3QgY3J5cHRv IGZyYWN0aW9uIG9mIG92ZXJhbGwgY29zdCB0byBrZWVwIGluY3JlYXNpbmcgb3ZlciB0aW1lIGFz IHRoZSBuZXR3b3JrDQogc3RhY2sgYm90dGxlbmVja3MgYXJlIGVsaW1pbmF0ZWQuIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5LYXp1aG8sIHNob3VsZCB0aGUgZHJhZnQgZGVzY3JpYmUgdGhlIG9w dGltaXphdGlvbnMgeW91IGFyZSBtYWtpbmc/IE9yIGFyZSB0aGVzZSBhcmUgdG9vIE9wZW5TU0wg c3BlY2lmaWM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5JYW4gU3dldHQ8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDQ6NDUgQU08YnI+DQo8Yj5U bzo8L2I+IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBOaWNrIEJhbmtzICZsdDtuaWJhbmtzQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQg TnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgZGlnZ2luZyBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoaXMsIEthenVoby4m bmJzcDsgJmx0OzQlIGluY3JlYXNlIGluIGNyeXB0byBjb3N0IGlzIGEgYml0IG1vcmUgdGhhbiBJ IG9yaWdpbmFsbHkgZXhwZWN0ZWQofjIlKSwgYnV0IGNyeXB0byBpcyBsZXNzIHRoYW4gMTAlIG9m IG15IENQVSB1c2FnZSwgc28gaXQncyBzdGlsbCBsZXNzIHRoYW4gMC41JSB0b3RhbCwgd2hpY2gg aXMgYWNjZXB0YWJsZSB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgSnVuIDIyLCAyMDE4IGF0IDI6NDUgQU0gS2F6dWhvIE9rdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iPmthenVob29rdUBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxOC0wNi0y MiAxMjoyMiBHTVQmIzQzOzA5OjAwIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1 aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4m Z3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxOC0wNi0yMiAxMTo1NCBHTVQmIzQzOzA5 OjAwIE5pY2sgQmFua3MgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj5uaWJhbmtzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEthenVobyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIG51bWJlcnMgYXMgd2Vs bCEgSSdtIGJpdCBjb25mdXNlZCB3aGVyZSB5b3Ugc2F5IHlvdSBjYW4gcmVkdWNlIHRoZSAxMCUg b3ZlcmhlYWQgdG8gMiUgdG8gNCUuIEhvdyBkbyB5b3UgcGxhbiBvbiBkb2luZyB0aGF0PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIHN0YXRlZCBpbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgMTAlIG9m IG92ZXJoZWFkIGNvbnNpc3RzIG9mIHRocmVlIHBhcnRzLCBlYWNoIGNvbnN1bWluZyBjb21wYXJh YmxlIG51bWJlciBvZiBDUFUgY3ljbGVzLiBUaGUgdHdvIGFtb25nIHRoZSB0aHJlZSBpcyByZWxh dGVkIHRvIHRoZSBhYnN0cmFjdGlvbiBsYXllciBhbmQgaG93IENUUiBpcyBpbXBsZW1lbnRlZCwg d2hpbGUgdGhlIG90aGVyIG9uZSBpcyB0aGUNCiBjb3JlIEFFUy1FQ0Igb3BlcmF0aW9uIGNvc3Qu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IHNob3VsZCBiZSBhYmxlIHRvIHJlbW92ZSB0aGUgY29zdGx5IGFic3RyYWN0aW9uIGxheWVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBz aG91bGQgYWxzbyBiZSBwb3NzaWJsZSB0byByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiwgc2lu Y2UgaW4gUE5FLCB3ZSBuZWVkIHRvIFhPUiBhdCBtb3N0IDQgb2N0ZXRzIChhcHBseWluZyBYT1Ig aXMgdGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIENUUiBhbmQgRUNCKS4gVGhhdCBjb3N0IHNo b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgcG9zc2libGUgdG8gYmUgbnVsbGlmaWVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D b25zaWRlcmluZyB0aGVzZSBhc3BlY3RzLCBhbmQgYnkgbG9va2luZyBhdCB0aGUgbnVtYmVycyBv biB0aGUgT3BlblNTTCBzb3VyY2UgY29kZSAoYXMgd2VsbCBhcyBjb25zaWRlcmluZyB0aGUgb3Zl cmhlYWQgb2YgR0NNKSwgbXkgZXhwZWN0YXRpb24gZ29lcyB0byAyJSB0byA0JS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBkaWQgc29tZSBleHBlcmltZW50cyBhbmQg aXQgc2VlbXMgdGhhdCB0aGUgZXhwZWN0YXRpb24gd2FzIGNvcnJlY3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBiZW5jaG1hcmtzIHRl bGwgbWUgdGhhdCB0aGUgb3ZlcmhlYWQgZ29lcyBkb3duIGZyb20gMTAuMCUgdG8gMy44JSwgYnkg ZG9pbmcgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KiByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiBhYnN0cmFjdGlv biAoaS5lLiB1c2UgdGhlIEVDQiBiYWNrZW5kIGFuZCBkbyBYT1IgYnkgb3Vyc2VsdmVzKTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiByZW1vdmUg dGhlIG92ZXJoZWFkIG9mIHRoZSBhYnN0cmFjdGlvbiBsYXllciAoaS5lLiBjYWxsIHRoZSBtZXRo b2QgcmV0dXJuZWQgYnkgRVZQX0NJUEhFUl9tZXRoX2dldF9kb19jaXBoZXIgaW5zdGVhZCBvZiBj YWxsaW5nIEVWUF9FbmNyeXB0VXBkYXRlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UgdGhlIGNoYW5nZXMgYXJlIHNwZWNpZmlj IHRvIE9wZW5TU0wsIGJ1dCBJIHdvdWxkIGV4cGVjdCB0aGF0IHlvdSBjYW4gZXhwZWN0IHNpbWls YXIgbnVtYmVycyBhc3N1bWluZyB0aGF0IHlvdSBoYXZlIGFjY2VzcyB0byBhbiBvcHRpbWl6ZWQg QUVTIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZW50IGZyb20gbXkgV2luZG93 cyAxMCBwaG9uZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bSHhTIC0g MTUyNTQgLSAxNi4wLjEwMjI4LjIwMDc1XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy02Mjgy NDk5ODYxMzM0MTA0MDUxbV84NDcxMDcxMzU5ODE4MTM3MTA3bV8tNzc2Mjk4MTIxMzEzODc4Mzc0 ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBLYXp1 aG8gT2t1ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxOCA3OjIx OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBOaWNrIEJhbmtzPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYu b3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8L3NwYW4+IDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBOaWNrLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIG51bWJlcnMgdG8gdGhlIGxpc3QuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2 ZSBqdXN0IHJ1biBhIHNtYWxsIGJlbmNobWFyayB1c2luZyBRdWljbHksIGFuZCBJIHNlZSBjb21w YXJhYmxlIG51bWJlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvIGJlIHByZWNpc2UsIEkgc2VlIDEwLjAlIGluY3JlYXNlIG9mIENQVSBj eWNsZXMgd2hlbiBlbmNyeXB0aW5nIGEgSW5pdGlhbCBwYWNrZXQgb2YgMSwyODAgb2N0ZXRzLiBJ IGV4cGVjdCB0aGF0IHdlIHdpbGwgc2VlIHNpbWlsYXIgbnVtYmVycyBvbiBvdGhlciBRVUlDIHN0 YWNrcyB0aGF0IGFsc28gdXNlIHBpY290bHMgKHdpdGggT3BlblNTTCBhcyBhIGJhY2tlbmQpLiBO b3RlIHRoYXQgdGhlIG51bWJlciBpcw0KIG9ubHkgY29tcGFyaW5nIHRoZSBjb3N0IG9mIGVuY3J5 cHRpb24sIHRoZSBvdmVyaGVhZCByYXRpbyB3aWxsIGJlIG11Y2ggc21hbGxlciBpZiB3ZSBsb29r IGF0IHRoZSB0b3RhbCBudW1iZXIgb2YgQ1BVIGN5Y2xlcyBzcGVudCBieSBhIFFVSUMgc3RhY2sg YXMgYSB3aG9sZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TG9va2luZyBhdCB0aGUgcHJvZmlsZSwgdGhlIG92ZXJoZWFkIGNvbnNpc3RzIG9m IHRocmVlIG9wZXJhdGlvbnMgdGhhdCBlYWNoIGNvbnN1bWVzIGNvbXBhcmFibGUgQ1BVIGN5Y2xl czogY29yZSBBRVMgb3BlcmF0aW9uICh1c2luZyBBRVMtTkkpLCBDVFIgb3BlcmF0aW9uIG92ZXJo ZWFkLCBDVFIgaW5pdGlhbGl6YXRpb24uIE5vdGUgdGhhdCBwaWNvdGxzIGF0IHRoZSBtb21lbnQg cHJvdmlkZXMgYWNjZXNzIHRvDQogQ1RSIGNyeXB0byBiZW5lYXRoIHRoZSBBRUFEIGludGVyZmFj ZSwgd2hpY2ggaXMgdG8gYmUgdXNlZCBieSB0aGUgUVVJQyBzdGFja3MuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYXNzdW1lIHRo YXQgd2UgY2FuIGN1dCBkb3duIHRoZSBvdmVyaGVhZCB0byBzb21ld2hlcmUgYmV0d2VlbiAyJSB0 byA0JSwgYnV0IGl0IG1pZ2h0IGJlIGhhcmQgdG8gZ28gZG93biB0byBzb21ld2hlcmUgbmVhciAx JSwgYmVjYXVzZSB3ZSBjYW5ub3QgcGFyYWxsZWxpemUgdGhlIEFFUyBvcGVyYXRpb24gb2YgUE5F IHdpdGggdGhhdCBvZiBBRUFEIChzZWUNCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm9w ZW5zc2wlMkZvcGVuc3NsJTJGYmxvYiUyRk9wZW5TU0xfMV8xXzBoJTJGY3J5cHRvJTJGYWVzJTJG YXNtJTJGYWVzbmkteDg2XzY0LnBsJTIzTDI0LUwzOSZhbXA7ZGF0YT0wMiU3QzAxJTdDbmliYW5r cyU0MG1pY3Jvc29mdC5jb20lN0MxMWQ1NWYxNzMzM2U0YTc5NWQ3MDA4ZDVkN2U2ZDkzYyU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTIzMDg4NDM5OTQx MzQmYW1wO3NkYXRhPWtxTXo0U3NOJTJGMkVyR0swNlF6OFowdlV6cGw0TWlpcG5ORTJ3QU1VYjQ2 YyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29t L29wZW5zc2wvb3BlbnNzbC9ibG9iL09wZW5TU0xfMV8xXzBoL2NyeXB0by9hZXMvYXNtL2Flc25p LXg4Nl82NC5wbCNMMjQtTDM5PC9hPiBhYm91dCB0aGUgaW1wYWN0IG9mIHBhcmFsbGVsaXphdGlv bikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZG8gbm90IHRoaW5rIHRoYXQgMiUgdG8gNCUgb2YgYWRkaXRpb25hbCBvdmVyaGVhZCB0byB0 aGUgY3J5cHRvIGlzIGFuIGlzc3VlIGZvciBRVUlDL0hUVFAsIGJ1dCBjdXJyZW50IG92ZXJoZWFk IG9mIDEwJSBpcyBzb21ldGhpbmcgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGRlY3JlYXNlLiBJIGFt IGdsYWQgdG8gYmUgYWJsZSB0byBsZWFybiB0aGF0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE4LTA2LTIyIDU6NDggR01UJiM0 MzswOTowMCBOaWNrIEJhbmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rcz00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uaWJhbmtzPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SGVsbG8gUVVJQyBXRyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgcmVjZW50bHkgaW1wbGVtZW50ZWQgUE5FIGZvciBXaW5RdWljICh1c2luZyBiY3J5cHQg QVBJcykgYW5kIEkgZGVjaWRlZCB0byBnZXQgc29tZSBwZXJmb3JtYW5jZSBudW1iZXJzIHRvIHNl ZSB3aGF0IHRoZSBvdmVyaGVhZCBvZiBQTkUgd2FzLiBJIGZpZ3VyZWQgdGhlIHJlc3Qgb2YgdGhl IFdHIG1pZ2h0DQogYmUgaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15 IHRlc3QganVzdCBlbmNyeXB0cyB0aGUgc2FtZSBidWZmZXIgKHNpemUgZGVwZW5kZW50IG9uIHRo ZSB0ZXN0IGNhc2UpIDEwLDAwMCwwMDAgdGltZXMgYW5kIG1lYXN1cmVkIHRoZSB0aW1lIGl0IHRv b2suIFRoZSB0ZXN0IHRoZW4gZGlkIHRoZSBzYW1lIHRoaW5nLCBidXQgYWxzbyBlbmNyeXB0ZWQg dGhlDQogcGFja2V0IG51bWJlciBhcyB3ZWxsLiBJIHJhbiBhbGwgdGhhdCAxMCB0aW1lcyBpbiB0 b3RhbC4gSSB0aGVuIGNvbGxlY3RlZCB0aGUgYmVzdCB0aW1lcyBmb3IgZWFjaCBjYXRlZ29yeSB0 byBwcm9kdWNlIHRoZSBmb2xsb3dpbmcgZ3JhcGhzIGFuZCB0YWJsZXMgKGZ1bGwgZXhjZWwgZG9j IGF0dGFjaGVkKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpbWcgYm9yZGVyPSIwIiB3 aWR0aD0iOTI3IiBoZWlnaHQ9IjQ2MiIgc3R5bGU9IndpZHRoOjkuNjU2MmluO2hlaWdodDo0Ljgx MjVpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJjaWQ6aW1hZ2UwMDMucG5nQDAxRDQwOTY2Ljc2 NTVCNkIwIiBhbHQ9ImNpZDppbWFnZTAwMy5wbmdAMDFENDA5NjYuNzY1NUI2QjAiPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iNTAxIiBzdHlsZT0id2lkdGg6Mzc2LjBwdDtib3JkZXItY29s bGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0 ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBw dDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRk IHdpZHRoPSIxMjgiIG5vd3JhcD0iIiBjb2xzcGFuPSIyIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjk2LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGlt ZSAobXMpPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBu b3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjExOSIgbm93 cmFwPSIiIGNvbHNwYW49IjIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6ODkuMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SYXRlIChNYnBzKTwvc3Bhbj48 L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0 aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkJ5dGVzPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk5PIFBORTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6 NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QTkU8L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxp Z249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSIxMjciIG5vd3JhcD0iIiBjb2xz cGFuPSIyIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjk1LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UE5FIE92ZXJoZWFkPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk5vIFBORTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1 OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QTkU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRo PSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj40PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9 IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGlu ZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjIyODQuNjcxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i NjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5n OjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+MzAyNy42NTc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYz IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjMzJTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dy YXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTQw LjA2NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEwNS42 OTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0 OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxl PSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+ DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjE2PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxl PSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIxMDIuNDAyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjgyOC4yMDQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i d2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4N CjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjM1JTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0 LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+NjA4LjgyNzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41 cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjQ1Mi41ODQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjY0PC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIxOTguODgz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjkwNy41Nzc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMyJTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJv dHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjMyOC40NTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjE3NjAuOTI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQg d2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7 cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjI1Njwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0 O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4yNzU4LjM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4zNDkwLjI4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRo PSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4yNyU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBu b3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjc0MjQuODY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41 ODY3LjcyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Imhl aWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj42MDA8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJp Z2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NDY2OS4yODM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41NDI0LjUzOTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0 eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4w cHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTYlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lk dGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMDI4MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjg4NDguNjg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEw MDA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NjEz MC4xMzk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy aWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj42OTA3 LjgwNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0i IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmln aHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTMlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxp Z249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMzA1MC4zPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTE1ODEuMTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4N Cjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MTIwMDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6 NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj42NDU4LjY3OTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjcyMjkuNjcyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0K PHRkIHdpZHRoPSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4xMiU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lk dGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjE0ODYzLjc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4xMzI3OC42PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg c3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0i Ym90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDto ZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xNDUwPC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWdu PSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjc4NzYuMzEyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ODY3MC4xNjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJv dHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTAlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xNDcyNy43PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTMzNzkuMjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHVzZWQg YSBzZXJ2ZXIgZ3JhZGUgbGFiIG1hY2hpbmUgSSBoYWQgYXQgbXkgZGlzcG9zYWwsIHJ1bm5pbmcg dGhlIGxhdGVzdCBXaW5kb3dzIDEwIFNlcnZlciBEYXRhQ2VudGVyIGJ1aWxkLiBBZ2FpbiwgdGhl c2UgbnVtYmVycyBhcmUgZm9yIGNyeXB0byBvbmx5LiBObyBRVUlDIG9yIFVEUCBpcyBpbmNsdWRl ZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwi Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkthenVobyBPa3U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8c3BhbiBj bGFzcz0ibS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiIj48bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0ibS02MjgyNDk5ODYx MzM0MTA0MDUxaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkthenVobyBPa3U8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5LYXp1aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB06303A8C17796335F3A3FDE2B6750CY4PR21MB0630namp_-- From nobody Fri Jun 22 09:34:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442AF130EAF for ; Fri, 22 Jun 2018 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aahgoEZkfr5 for ; Fri, 22 Jun 2018 09:34:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8D5130EAC for ; Fri, 22 Jun 2018 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oOifkpsviKqMLB4CrMMTkN7JSCVG/p3L1d7krFYQ4M0=; b=oa08mTvDfxN1EFoG7RKQBaaXj7q4QPCK+fXqL+o5zwPEd51hbdMpWJhfuvJMqhLLC0sWnEeXogUirlVLjxfA6V835LsSAmD9It5q7h9KluTEd2Gx+JdLXEHvgT1wJFOGNyBwtUeiXy9GiC5CCdLn6lskRCuak984vXCcwINs1L8= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1126.namprd21.prod.outlook.com (52.132.132.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.8; Fri, 22 Jun 2018 16:34:39 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Fri, 22 Jun 2018 16:34:39 +0000 From: Nick Banks To: Praveen Balasubramanian , Ian Swett , Kazuho Oku CC: IETF QUIC WG Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgAAAjosm Date: Fri, 22 Jun 2018 16:34:38 +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: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1126; 7:0r4X4Wxdm2IWo2dhpQJCIGPV9sE/2HQ2/rjKhmzsmJoezda7Tmp1kOCNTwYgjauJUJlX3LfhHZp/jIEDayVHfPxlLafg0gebysSjsauAR8S181Qz7F7Fsuhkz/ZB9+ggc/Rt5QrdOOSJCSpr1ULWOILMmny9W3tTGbrAHAygbVgSt8mjl4rCw0i+bHN8b+izxsF2gGwns0fbtPOjKXhbIsOmocBUzhsVA1EoTc+KyiEYKE6ivzDH6bwNxa1ubLfS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 21a9f385-251b-4d4a-49a3-08d5d85e0c77 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989114)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1126; x-ms-traffictypediagnostic: DM5PR2101MB1126: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(156600954879566)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1126; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1126; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(39380400002)(376002)(346002)(189003)(199004)(476003)(81156014)(81166006)(1511001)(966005)(733005)(8936002)(606006)(478600001)(66066001)(229853002)(5890100001)(10290500003)(5660300001)(6436002)(5250100002)(22452003)(486006)(86612001)(345774005)(86362001)(316002)(110136005)(3480700004)(561924002)(93886005)(236005)(55016002)(11346002)(9686003)(8676002)(2900100001)(446003)(54556002)(54896002)(6306002)(7736002)(99286004)(8990500004)(68736007)(2906002)(7696005)(26005)(53546011)(14454004)(6116002)(97736004)(3280700002)(10090500001)(74316002)(33656002)(790700001)(3846002)(53936002)(6506007)(102836004)(105586002)(6246003)(39060400002)(106356001)(25786009)(4326008)(76176011)(3660700001)(59450400001)(53946003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1126; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: d2RomNRnidx5hXgb2jA0O23SazqLg0oAODpNbYXjIwt1PvoSv2GNATbE6jyaQEu5tBT804wnYdlfjef2E/teYRnoX9awVgNrSw8ryCUU+a08pOG+vCL33rtvNuePRnJ6jy/YQ1JpPIB8ZJ3jRmtv37DdXI//Jp8fSl4Ih4dbTuRZmKEw1iYHxIK/r4IlZCdXr790oyXfzFNhe7KIl2N8nbU5PsjxVUEqhK5OCR9ksm+eJIqaNXmWbV4XtZLyuVUxEV3NuwUuiUA/qukSKDBIuerkHUZ1llxsPhc1rwIVjYcXkznQ0jdxI6KWSTOvFQSS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901939C8975A87AA74219B9B3750DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21a9f385-251b-4d4a-49a3-08d5d85e0c77 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 16:34:38.8811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1126 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:34:48 -0000 --_000_DM5PR2101MB0901939C8975A87AA74219B9B3750DM5PR2101MB0901_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I just want to add, my implementation already uses ECB from bcrypt (and I d= o the XOR) already. Bcrypt doesn=92t expose CTR mode directly. Sent from Mail for Window= s 10 ________________________________ From: Praveen Balasubramanian Sent: Friday, June 22, 2018 9:26:44 AM To: Ian Swett; Kazuho Oku Cc: Nick Banks; IETF QUIC WG Subject: RE: Packet Number Encryption Performance Ian, do you expect that fraction of overall cost to hold once the UDP stack= is optimized? Is your measurement on top of the recent kernel improvements= ? I expect crypto fraction of overall cost to keep increasing over time as = the network stack bottlenecks are eliminated. Kazuho, should the draft describe the optimizations you are making? Or are = these are too OpenSSL specific? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett Sent: Friday, June 22, 2018 4:45 AM To: Kazuho Oku Cc: Nick Banks ; IETF QUIC WG Subject: Re: Packet Number Encryption Performance Thanks for digging into the details of this, Kazuho. <4% increase in crypt= o cost is a bit more than I originally expected(~2%), but crypto is less th= an 10% of my CPU usage, so it's still less than 0.5% total, which is accept= able to me. On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku > wrote: 2018-06-22 12:22 GMT+09:00 Kazuho Oku >: 2018-06-22 11:54 GMT+09:00 Nick Banks >: Hi Kazuho, Thanks for sharing your numbers as well! I'm bit confused where you say you= can reduce the 10% overhead to 2% to 4%. How do you plan on doing that? As stated in my previous mail, the 10% of overhead consists of three parts,= each consuming comparable number of CPU cycles. The two among the three is= related to the abstraction layer and how CTR is implemented, while the oth= er one is the core AES-ECB operation cost. It should be able to remove the costly abstraction layer. It should also be possible to remove the overhead of CTR, since in PNE, we = need to XOR at most 4 octets (applying XOR is the only difference between C= TR and ECB). That cost should be something that should be possible to be nu= llified. Considering these aspects, and by looking at the numbers on the OpenSSL sou= rce code (as well as considering the overhead of GCM), my expectation goes = to 2% to 4%. Just did some experiments and it seems that the expectation was correct. The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by d= oing the following: * remove the overhead of CTR abstraction (i.e. use the ECB backend and do X= OR by ourselves) * remove the overhead of the abstraction layer (i.e. call the method return= ed by EVP_CIPHER_meth_get_do_cipher instead of calling EVP_EncryptUpdate) Of course the changes are specific to OpenSSL, but I would expect that you = can expect similar numbers assuming that you have access to an optimized AE= S implementation. Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ________________________________ From: Kazuho Oku > Sent: Thursday, June 21, 2018 7:21:17 PM To: Nick Banks Cc: quic@ietf.org Subject: Re: Packet Number Encryption Performance Hi Nick, Thank you for bringing the numbers to the list. I have just run a small benchmark using Quicly, and I see comparable number= s. To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial= packet of 1,280 octets. I expect that we will see similar numbers on other= QUIC stacks that also use picotls (with OpenSSL as a backend). Note that t= he number is only comparing the cost of encryption, the overhead ratio will= be much smaller if we look at the total number of CPU cycles spent by a QU= IC stack as a whole. Looking at the profile, the overhead consists of three operations that each= consumes comparable CPU cycles: core AES operation (using AES-NI), CTR ope= ration overhead, CTR initialization. Note that picotls at the moment provid= es access to CTR crypto beneath the AEAD interface, which is to be used by = the QUIC stacks. I would assume that we can cut down the overhead to somewhere between 2% to= 4%, but it might be hard to go down to somewhere near 1%, because we canno= t parallelize the AES operation of PNE with that of AEAD (see https://githu= b.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L2= 4-L39 about the impact of parallelization). I do not think that 2% to 4% of additional overhead to the crypto is an iss= ue for QUIC/HTTP, but current overhead of 10% is something that we might wa= nt to decrease. I am glad to be able to learn that now. 2018-06-22 5:48 GMT+09:00 Nick Banks >: Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): [cid:image003.png@01D40966.7655B6B0] Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick -- Kazuho Oku -- Kazuho Oku -- Kazuho Oku --_000_DM5PR2101MB0901939C8975A87AA74219B9B3750DM5PR2101MB0901_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=92t expose CTR mode= directly.

 

Sent from Mail for Windows 10

 

From: Praveen Balasubramani= an
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance
 

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep i= ncreasing over time as the network stack bottlenecks are eliminated.

 

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@= ietf.org>
Subject: Re: Packet Number Encryption Performance

 

Thanks for digging into the details of this, Kazuho.=   <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still less t= han 0.5% total, which is acceptable to me.

 

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

 

 

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com&= gt;:

 

 

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com<= /a>>:

Hi Kazuho,

 

Thanks for sharing your numbers as well! I'm bit confused where yo= u say you can reduce the 10% overhead to 2% to 4%. How do you plan on doing= that?

 

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is imp= lemented, while the other one is the core AES-ECB operation cost.

 

It should be able to remove the costly abstraction l= ayer.

 

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that shou= ld be possible to be nullified.

 

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

 

Just did some experiments and it seems that the expe= ctation was correct.

 

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

 

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

 

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

 

 

 

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

 

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance =

 

Hi Nick,

 

Thank you for bringing the numbers to the list.=

 

I have just run a small benchmark using Quicly, and = I see comparable numbers.

 

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as = a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much sma= ller if we look at the total number of CPU cycles spent by a QUIC stack as = a whole.

 

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picot= ls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC sta= cks.

 

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of = AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization).

 

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that n= ow.

 

 

2018-06-22 5:48 GMT+09:00 Nick Banks <niba= nks=3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt APIs) and I d= ecided to get some performance numbers to see what the overhead of PNE was.= I figured the rest of the WG might be interested.

 

My test just encrypts the same buffer (size dependent on the test = case) 10,000,000 times and measured the time it took. The test then did the= same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

 

3D"cid:image003.png@01D40966.=

 

Time (ms)

Rate (Mbps)

Bytes

NO PNE

PNE

PNE Overhead<= /p>

No PNE

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my disposal, running th= e latest Windows 10 Server DataCenter build. Again, these numbers are for c= rypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 



 

--

Kazuho Oku



 

--

Kazuho Oku=



 

--

Kazuho Oku

--_000_DM5PR2101MB0901939C8975A87AA74219B9B3750DM5PR2101MB0901_-- From nobody Fri Jun 22 11:52:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30F130EF7 for ; Fri, 22 Jun 2018 11:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 D_hpNVbJNnsj for ; Fri, 22 Jun 2018 11:51:51 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 91A27130EEC for ; Fri, 22 Jun 2018 11:51:51 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id b125-v6so2739977ywe.1 for ; Fri, 22 Jun 2018 11:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iky+FwCgmBCKJQKAq5RgMLd4Dk4APYhQ4LiLPNIPzYE=; b=HlGWxKrEK7w6M0EvDROk11HKKF04W+7clWLVrW5KTvh7edtULkxafISFSzzV80HPkC L+HKr4Fv3UNu7FW9R+/YRZDOrfr2YHOQ4VeG3FGONpQJQ1cT42LHGG4MikasxkjTdrl9 hVMtcc8DvLJJKM0KQcWfpoV24piErmlqtBGYkl7DR2Pp3Ys9LL5eJDJVEo6ZOLVT7sLz dn9e20fjIgcdl/UAJy5xes3nkI5D90t0OAmxzpOQLxz5RlRQG7j7VWH5Ve3uC0cPNXkk aYjxhzsi33UJiAdu2xEbeF1pDmeqrSA01fu9B4u87Y9s7bUKelWaVigtNZySPrS+OoCk EqmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iky+FwCgmBCKJQKAq5RgMLd4Dk4APYhQ4LiLPNIPzYE=; b=G1NCnaBpO8uMSnxzVBfpAXUMGHGjQxH/2oOZEVuUBtEgV9vFvHNgYUjrCVI0slJdu5 l90H+A/IG82SRd8HtTOcDLG3dmI9lgokcyZrkDbidxem24a8/S/U+YA64HJCQvNIq/v2 0iTq8EaWHsoQ/Xoa/1JMOgL7P/+na/hGFNrR41UAOFbj4yvTyUUBtKZ5aKay8iXQ93+p 1QxzNbtkAhL+e+jsJYQiP5p7ysEAMlG6cZxdFTSsm6wphmpMl+ooDe6zD9cygxi2MLgV o22NSBvPu1eU6T4wX+oxY1PDISQ5FZkJoJg2bZBZUYNCsOFJpuY5fD02bm507SqmhOvU JS3w== X-Gm-Message-State: APt69E2In1ikE935fxK2GTW5CA+6nrRw0RQhvmkITmiorg4syoFvyA99 PyvLQdnQMtjiFTOoUURlBFn8W+6Sw8mjej59A4HxvQ== X-Google-Smtp-Source: ADUXVKIhyX6CIlNU0PqQ+0GGUbBLDvoDrYop7hysUA3s7ymFn00OYWSztyLTvgNMXY4ebwRbH5LszdHTsNTrV8yrQ8w= X-Received: by 2002:a81:3208:: with SMTP id y8-v6mr1369075ywy.361.1529693510432; Fri, 22 Jun 2018 11:51:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 22 Jun 2018 14:51:38 -0400 Message-ID: Subject: Re: Packet Number Encryption Performance To: nibanks=40microsoft.com@dmarc.ietf.org Cc: Praveen Balasubramanian , Kazuho Oku , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004eb6f6056f3f86d5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:52:06 -0000 --0000000000004eb6f6056f3f86d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I expect crypto to increase as a fraction of CPU, but I don't expect it to go much higher than 10%. But who knows, maybe 2 years from now everything else will be very optimized and crypto will be 15%? On Fri, Jun 22, 2018 at 12:34 PM Nick Banks wrote: > I just want to add, my implementation already uses ECB from bcrypt (and I > do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directly. > > > > Sent from Mail for > Windows 10 > > > ------------------------------ > *From:* Praveen Balasubramanian > *Sent:* Friday, June 22, 2018 9:26:44 AM > *To:* Ian Swett; Kazuho Oku > *Cc:* Nick Banks; IETF QUIC WG > *Subject:* RE: Packet Number Encryption Performance > > > Ian, do you expect that fraction of overall cost to hold once the UDP > stack is optimized? Is your measurement on top of the recent kernel > improvements? I expect crypto fraction of overall cost to keep increasing > over time as the network stack bottlenecks are eliminated. > > > > Kazuho, should the draft describe the optimizations you are making? Or ar= e > these are too OpenSSL specific? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Friday, June 22, 2018 4:45 AM > *To:* Kazuho Oku > *Cc:* Nick Banks ; IETF QUIC WG > *Subject:* Re: Packet Number Encryption Performance > > > > Thanks for digging into the details of this, Kazuho. <4% increase in > crypto cost is a bit more than I originally expected(~2%), but crypto is > less than 10% of my CPU usage, so it's still less than 0.5% total, which = is > acceptable to me. > > > > On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: > > > > > > 2018-06-22 12:22 GMT+09:00 Kazuho Oku : > > > > > > 2018-06-22 11:54 GMT+09:00 Nick Banks : > > Hi Kazuho, > > > > Thanks for sharing your numbers as well! I'm bit confused where you say > you can reduce the 10% overhead to 2% to 4%. How do you plan on doing tha= t? > > > > As stated in my previous mail, the 10% of overhead consists of three > parts, each consuming comparable number of CPU cycles. The two among the > three is related to the abstraction layer and how CTR is implemented, whi= le > the other one is the core AES-ECB operation cost. > > > > It should be able to remove the costly abstraction layer. > > > > It should also be possible to remove the overhead of CTR, since in PNE, w= e > need to XOR at most 4 octets (applying XOR is the only difference between > CTR and ECB). That cost should be something that should be possible to be > nullified. > > > > Considering these aspects, and by looking at the numbers on the OpenSSL > source code (as well as considering the overhead of GCM), my expectation > goes to 2% to 4%. > > > > Just did some experiments and it seems that the expectation was correct. > > > > The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by > doing the following: > > > > * remove the overhead of CTR abstraction (i.e. use the ECB backend and do > XOR by ourselves) > > * remove the overhead of the abstraction layer (i.e. call the method > returned by EVP_CIPHER_meth_get_do_cipher instead of calling > EVP_EncryptUpdate) > > > > Of course the changes are specific to OpenSSL, but I would expect that yo= u > can expect similar numbers assuming that you have access to an optimized > AES implementation. > > > > > > > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > > *From:* Kazuho Oku > *Sent:* Thursday, June 21, 2018 7:21:17 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Packet Number Encryption Performance > > > > Hi Nick, > > > > Thank you for bringing the numbers to the list. > > > > I have just run a small benchmark using Quicly, and I see comparable > numbers. > > > > To be precise, I see 10.0% increase of CPU cycles when encrypting a > Initial packet of 1,280 octets. I expect that we will see similar numbers > on other QUIC stacks that also use picotls (with OpenSSL as a backend). > Note that the number is only comparing the cost of encryption, the overhe= ad > ratio will be much smaller if we look at the total number of CPU cycles > spent by a QUIC stack as a whole. > > > > Looking at the profile, the overhead consists of three operations that > each consumes comparable CPU cycles: core AES operation (using AES-NI), C= TR > operation overhead, CTR initialization. Note that picotls at the moment > provides access to CTR crypto beneath the AEAD interface, which is to be > used by the QUIC stacks. > > > > I would assume that we can cut down the overhead to somewhere between 2% > to 4%, but it might be hard to go down to somewhere near 1%, because we > cannot parallelize the AES operation of PNE with that of AEAD (see > https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aes= ni-x86_64.pl#L24-L39 > > about the impact of parallelization). > > > > I do not think that 2% to 4% of additional overhead to the crypto is an > issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht > want to decrease. I am glad to be able to learn that now. > > > > > > 2018-06-22 5:48 GMT+09:00 Nick Banks < > nibanks=3D40microsoft.com@dmarc.ietf.org>: > > Hello QUIC WG, > > > > I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided > to get some performance numbers to see what the overhead of PNE was. I > figured the rest of the WG might be interested. > > > > My test just encrypts the same buffer (size dependent on the test case) > 10,000,000 times and measured the time it took. The test then did the sam= e > thing, but also encrypted the packet number as well. I ran all that 10 > times in total. I then collected the best times for each category to > produce the following graphs and tables (full excel doc attached): > > > > [image: cid:image003.png@01D40966.7655B6B0] > > > > *Time (ms)* > > *Rate (Mbps)* > > *Bytes* > > *NO PNE* > > *PNE* > > *PNE Overhead* > > *No PNE* > > *PNE* > > *4* > > 2284.671 > > 3027.657 > > 33% > > 140.064 > > 105.692 > > *16* > > 2102.402 > > 2828.204 > > 35% > > 608.827 > > 452.584 > > *64* > > 2198.883 > > 2907.577 > > 32% > > 2328.45 > > 1760.92 > > *256* > > 2758.3 > > 3490.28 > > 27% > > 7424.86 > > 5867.72 > > *600* > > 4669.283 > > 5424.539 > > 16% > > 10280 > > 8848.68 > > *1000* > > 6130.139 > > 6907.805 > > 13% > > 13050.3 > > 11581.1 > > *1200* > > 6458.679 > > 7229.672 > > 12% > > 14863.7 > > 13278.6 > > *1450* > > 7876.312 > > 8670.16 > > 10% > > 14727.7 > > 13379.2 > > > > I used a server grade lab machine I had at my disposal, running the lates= t > Windows 10 Server DataCenter build. Again, these numbers are for crypto > only. No QUIC or UDP is included. > > > > Thanks, > > - Nick > > > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > --0000000000004eb6f6056f3f86d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I expect crypto to increase as a fraction of CPU, but I do= n't expect it to go much higher than 10%.

But who kn= ows, maybe 2 years from now everything else will be very optimized and cryp= to will be 15%?

= On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> wro= te:

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CT= R mode directly.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From:= Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance
=C2=A0

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep i= ncreasing over time as the network stack bottlenecks are eliminated.

=C2=A0

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

=C2=A0

Thanks for digging into the details of this, Kazuho.= =C2=A0 <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still le= ss than 0.5% total, which is acceptable to me.

=C2=A0

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com= > wrote:

=C2=A0

=C2=A0

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:=

=C2=A0

=C2=A0

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&= gt;:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?

=C2=A0

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is imp= lemented, while the other one is the core AES-ECB operation cost.

=C2=A0

It should be able to remove the costly abstraction l= ayer.

=C2=A0

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that shou= ld be possible to be nullified.

=C2=A0

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

=C2=A0

Just did some experiments and it seems that the expe= ctation was correct.

=C2=A0

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

=C2=A0

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

=C2=A0

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

=C2=A0

=C2=A0

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance <= /u>

=C2=A0

Hi Nick,

=C2=A0

Thank you for bringing the numbers to the list.

=C2=A0

I have just run a small benchmark using Quicly, and = I see comparable numbers.

=C2=A0

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as = a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much sma= ller if we look at the total number of CPU cycles spent by a QUIC stack as = a whole.

=C2=A0

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picot= ls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC sta= cks.

=C2=A0

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of = AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization).<= /p>

=C2=A0

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that n= ow.

=C2=A0

=C2=A0

2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks= =3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

=C2=A0

3D"cid:image003.png@01D40966.7655B6B0"

=C2=A0

Time (ms)<= u>

Rate (Mbps)

Bytes

NO PNE<= /u>

PNE=

PNE Overhead

No PNE<= /u>

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku

--0000000000004eb6f6056f3f86d5-- From nobody Fri Jun 22 17:01:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D684126CB6 for ; Fri, 22 Jun 2018 17:01:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 98ZMas7mlu_T for ; Fri, 22 Jun 2018 17:01:37 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 29E54130F26 for ; Fri, 22 Jun 2018 17:01:37 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id 30-v6so4155947pld.13 for ; Fri, 22 Jun 2018 17:01:37 -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=NyuvHV5bvJ1gaIk+KhTsn6oCvaYOdeNHfEKFt7Sesjc=; b=r5tvlbR0n/lHtQV5KfjUGgzoKm0oFovOiXKq91U5GYAOS5ilTHoLEDXB7XMAXMbRWV OwYhzegMvdyOKBeHVmrQK1tG7twMxA5hJPsDh0e77tC2Gm6/nkuI4+bV6jvDbsFj16wU EiYpZx8qIQCHFv7ERZVnzNjiJ2jfM1K5B0RTfP+NbQAFres29TMhFzBKcZQOjPJ27TYL uz7k1q0ZAw53+mgjhrdAVSJ6gief9ORugk6i25GPu5qMIIaSMv2qoSKHZd4r84gp3mT1 QBZCzui8ld9cXPr7QR0sx3JHamjrltksOwdIfIqtQjPcuIi/Lfo6OR0Z9g63W58Z5pDl OONw== 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=NyuvHV5bvJ1gaIk+KhTsn6oCvaYOdeNHfEKFt7Sesjc=; b=tde/JbR/cVAi8QakUe4BzmS+6LDYmQEfXmUWvjn6AHuw0OffSvP33b1LfGD7ktMl28 dZM3BZ2y3wZa2IkeY0rkWcp2eiL3gdfqNIJSmDUzgMFYtXnPEq2roy4b4Z9N7JAuaeGP EvsMEOhTDZ7sfPShJLRpRWKg2PB7QIhxEsmxbiUjqX+idEfanHpQzUtIHbg2H2/mtdmB Usdo2PDdhMHcSCK3WoAiZ7OVpg6hkQ+Y/29IDAn3ZVYIqAV7ELxd5l3IJqh3qHL2Cdud RPJjxky0MnETYi7jGDYsesj+lMAVClq9RxMIJNGcvZTASPTvmO12qXAycRFkckSAnErd tF5Q== X-Gm-Message-State: APt69E1RjyynUlWeBP4wdR9UqeFCwy2XLS6yIHC6k92w9YA9iTRBHnnU l4cjwCtv3S9GWMVswQxR6Kd3k86D0ugO8xClpL4= X-Google-Smtp-Source: ADUXVKJq8/wcvoltjTRcjdflKUDb+r8iUY0+g6rB9tXLprZGpcoPfKMtCb+03UgnW2X9EU1LYQIOg+Qnpw0IUd73d3Q= X-Received: by 2002:a17:902:c3:: with SMTP id a61-v6mr3575008pla.149.1529712096681; Fri, 22 Jun 2018 17:01:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 22 Jun 2018 17:01:35 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Sat, 23 Jun 2018 09:01:35 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Ian Swett Cc: Nick Banks , Praveen Balasubramanian , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000021a29e056f43dabd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 00:01:43 -0000 --00000000000021a29e056f43dabd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-06-23 3:51 GMT+09:00 Ian Swett : > I expect crypto to increase as a fraction of CPU, but I don't expect it t= o > go much higher than 10%. > > But who knows, maybe 2 years from now everything else will be very > optimized and crypto will be 15%? > Ian, thank you for sharing the proportion of CPU cycles we are likely to spend for crypto. Your numbers relieves me, because even if the cost of crypto goes to 15%, the overhead of PNE will be less than 1% (0.15*0.04=3D0.006). I would also like to note that it is likely that HyperThreading, when used, will eliminate the overhead of PNE. This is because IIUC PNE is a marginal additional use of the AES-NI engine, which have been mostly idle. The overhead of crypto is small (i.e. 15%) that we will rarely see contention on the engine. While one hyperthread does AES, the other hyperthread will run at full speed doing other operations. Also considering the fact that the number of CPU cycles spent per QUIC packet does not change a lot with PNE, I would not be surprised to see *no* decrease of throughput when PNE is used on a HyperThreading architecture. In such case, what we will only observe is the raise of the utilization ratio of the AES-NI engine. > > On Fri, Jun 22, 2018 at 12:34 PM Nick Banks dmarc.ietf.org> wrote: > >> I just want to add, my implementation already uses ECB from bcrypt (and = I >> do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directly. >> >> >> >> Sent from Mail for >> Windows 10 >> >> >> ------------------------------ >> *From:* Praveen Balasubramanian >> *Sent:* Friday, June 22, 2018 9:26:44 AM >> *To:* Ian Swett; Kazuho Oku >> *Cc:* Nick Banks; IETF QUIC WG >> *Subject:* RE: Packet Number Encryption Performance >> >> >> Ian, do you expect that fraction of overall cost to hold once the UDP >> stack is optimized? Is your measurement on top of the recent kernel >> improvements? I expect crypto fraction of overall cost to keep increasin= g >> over time as the network stack bottlenecks are eliminated. >> >> >> >> Kazuho, should the draft describe the optimizations you are making? Or >> are these are too OpenSSL specific? >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett >> *Sent:* Friday, June 22, 2018 4:45 AM >> *To:* Kazuho Oku >> *Cc:* Nick Banks ; IETF QUIC WG >> *Subject:* Re: Packet Number Encryption Performance >> >> >> >> Thanks for digging into the details of this, Kazuho. <4% increase in >> crypto cost is a bit more than I originally expected(~2%), but crypto is >> less than 10% of my CPU usage, so it's still less than 0.5% total, which= is >> acceptable to me. >> >> >> >> On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: >> >> >> >> >> >> 2018-06-22 12:22 GMT+09:00 Kazuho Oku : >> >> >> >> >> >> 2018-06-22 11:54 GMT+09:00 Nick Banks : >> >> Hi Kazuho, >> >> >> >> Thanks for sharing your numbers as well! I'm bit confused where you say >> you can reduce the 10% overhead to 2% to 4%. How do you plan on doing th= at? >> >> >> >> As stated in my previous mail, the 10% of overhead consists of three >> parts, each consuming comparable number of CPU cycles. The two among the >> three is related to the abstraction layer and how CTR is implemented, wh= ile >> the other one is the core AES-ECB operation cost. >> >> >> >> It should be able to remove the costly abstraction layer. >> >> >> >> It should also be possible to remove the overhead of CTR, since in PNE, >> we need to XOR at most 4 octets (applying XOR is the only difference >> between CTR and ECB). That cost should be something that should be possi= ble >> to be nullified. >> >> >> >> Considering these aspects, and by looking at the numbers on the OpenSSL >> source code (as well as considering the overhead of GCM), my expectation >> goes to 2% to 4%. >> >> >> >> Just did some experiments and it seems that the expectation was correct. >> >> >> >> The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, b= y >> doing the following: >> >> >> >> * remove the overhead of CTR abstraction (i.e. use the ECB backend and d= o >> XOR by ourselves) >> >> * remove the overhead of the abstraction layer (i.e. call the method >> returned by EVP_CIPHER_meth_get_do_cipher instead of calling >> EVP_EncryptUpdate) >> >> >> >> Of course the changes are specific to OpenSSL, but I would expect that >> you can expect similar numbers assuming that you have access to an >> optimized AES implementation. >> >> >> >> >> >> >> >> Sent from my Windows 10 phone >> >> [HxS - 15254 - 16.0.10228.20075] >> >> >> ------------------------------ >> >> *From:* Kazuho Oku >> *Sent:* Thursday, June 21, 2018 7:21:17 PM >> *To:* Nick Banks >> *Cc:* quic@ietf.org >> *Subject:* Re: Packet Number Encryption Performance >> >> >> >> Hi Nick, >> >> >> >> Thank you for bringing the numbers to the list. >> >> >> >> I have just run a small benchmark using Quicly, and I see comparable >> numbers. >> >> >> >> To be precise, I see 10.0% increase of CPU cycles when encrypting a >> Initial packet of 1,280 octets. I expect that we will see similar number= s >> on other QUIC stacks that also use picotls (with OpenSSL as a backend). >> Note that the number is only comparing the cost of encryption, the overh= ead >> ratio will be much smaller if we look at the total number of CPU cycles >> spent by a QUIC stack as a whole. >> >> >> >> Looking at the profile, the overhead consists of three operations that >> each consumes comparable CPU cycles: core AES operation (using AES-NI), = CTR >> operation overhead, CTR initialization. Note that picotls at the moment >> provides access to CTR crypto beneath the AEAD interface, which is to be >> used by the QUIC stacks. >> >> >> >> I would assume that we can cut down the overhead to somewhere between 2% >> to 4%, but it might be hard to go down to somewhere near 1%, because we >> cannot parallelize the AES operation of PNE with that of AEAD (see >> https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/ >> crypto/aes/asm/aesni-x86_64.pl#L24-L39 >> >> about the impact of parallelization). >> >> >> >> I do not think that 2% to 4% of additional overhead to the crypto is an >> issue for QUIC/HTTP, but current overhead of 10% is something that we mi= ght >> want to decrease. I am glad to be able to learn that now. >> >> >> >> >> >> 2018-06-22 5:48 GMT+09:00 Nick Banks > dmarc.ietf.org>: >> >> Hello QUIC WG, >> >> >> >> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided >> to get some performance numbers to see what the overhead of PNE was. I >> figured the rest of the WG might be interested. >> >> >> >> My test just encrypts the same buffer (size dependent on the test case) >> 10,000,000 times and measured the time it took. The test then did the sa= me >> thing, but also encrypted the packet number as well. I ran all that 10 >> times in total. I then collected the best times for each category to >> produce the following graphs and tables (full excel doc attached): >> >> >> >> [image: cid:image003.png@01D40966.7655B6B0] >> >> >> >> *Time (ms)* >> >> *Rate (Mbps)* >> >> *Bytes* >> >> *NO PNE* >> >> *PNE* >> >> *PNE Overhead* >> >> *No PNE* >> >> *PNE* >> >> *4* >> >> 2284.671 >> >> 3027.657 >> >> 33% >> >> 140.064 >> >> 105.692 >> >> *16* >> >> 2102.402 >> >> 2828.204 >> >> 35% >> >> 608.827 >> >> 452.584 >> >> *64* >> >> 2198.883 >> >> 2907.577 >> >> 32% >> >> 2328.45 >> >> 1760.92 >> >> *256* >> >> 2758.3 >> >> 3490.28 >> >> 27% >> >> 7424.86 >> >> 5867.72 >> >> *600* >> >> 4669.283 >> >> 5424.539 >> >> 16% >> >> 10280 >> >> 8848.68 >> >> *1000* >> >> 6130.139 >> >> 6907.805 >> >> 13% >> >> 13050.3 >> >> 11581.1 >> >> *1200* >> >> 6458.679 >> >> 7229.672 >> >> 12% >> >> 14863.7 >> >> 13278.6 >> >> *1450* >> >> 7876.312 >> >> 8670.16 >> >> 10% >> >> 14727.7 >> >> 13379.2 >> >> >> >> I used a server grade lab machine I had at my disposal, running the >> latest Windows 10 Server DataCenter build. Again, these numbers are for >> crypto only. No QUIC or UDP is included. >> >> >> >> Thanks, >> >> - Nick >> >> >> >> >> >> >> >> -- >> >> Kazuho Oku >> >> >> >> >> >> -- >> >> Kazuho Oku >> >> >> >> >> >> -- >> >> Kazuho Oku >> >> --=20 Kazuho Oku --00000000000021a29e056f43dabd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-06-23 3:51 GMT+09:00 Ian Swett <ianswett@google.com>:
I expect crypto to = increase as a fraction of CPU, but I don't expect it to go much higher = than 10%.

But who knows, maybe 2 years from now everythi= ng else will be very optimized and crypto will be 15%?

Ian, thank you for sharing the proportion of CPU cy= cles we are likely to spend for crypto.

Your numbe= rs relieves me, because even if the cost of crypto goes to 15%, the overhea= d of PNE will be less than 1% (0.15*0.04=3D0.006).

I would also like to note that it is likely that HyperThreading, when used= , will eliminate the overhead of PNE.

This is beca= use IIUC PNE is a marginal additional use of the AES-NI engine, which have = been mostly idle. The overhead of crypto is small (i.e. 15%) that we will r= arely see contention on the engine. While one hyperthread does AES, the oth= er hyperthread will run at full speed doing other operations.
Also considering the fact that the number of CPU cycles spent p= er QUIC packet does not change a lot with PNE, I would not be surprised to = see *no* decrease of throughput when PNE is used on a HyperThreading archit= ecture. In such case, what we will only observe is the raise of the utiliza= tion ratio of the AES-NI engine.
=C2=A0

On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <nib= anks=3D= 40microsoft.com@dmarc.ietf.org> wrote:

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CT= R mode directly.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance
=C2=A0

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep i= ncreasing over time as the network stack bottlenecks are eliminated.

=C2=A0

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

=C2=A0

Thanks for digging into the details of this, Kazuho.= =C2=A0 <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still le= ss than 0.5% total, which is acceptable to me.

=C2=A0

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com= > wrote:

=C2=A0

=C2=A0

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:=

=C2=A0

=C2=A0

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&= gt;:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?

=C2=A0

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is imp= lemented, while the other one is the core AES-ECB operation cost.

=C2=A0

It should be able to remove the costly abstraction l= ayer.

=C2=A0

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that shou= ld be possible to be nullified.

=C2=A0

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

=C2=A0

Just did some experiments and it seems that the expe= ctation was correct.

=C2=A0

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

=C2=A0

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

=C2=A0

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

=C2=A0

=C2=A0

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance <= /u>

=C2=A0

Hi Nick,

=C2=A0

Thank you for bringing the numbers to the list.

=C2=A0

I have just run a small benchmark using Quicly, and = I see comparable numbers.

=C2=A0

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as = a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much sma= ller if we look at the total number of CPU cycles spent by a QUIC stack as = a whole.

=C2=A0

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picot= ls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC sta= cks.

=C2=A0

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of = AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

=C2=A0

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that n= ow.

=C2=A0

=C2=A0

2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks= =3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

=C2=A0

3D"cid:image003.png@01D40966.7655B6B0"=

=C2=A0

Time (ms)<= u>

Rate (Mbps)

Bytes

NO PNE<= /u>

PNE=

PNE Overhead

No PNE<= /u>

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku




--
=
Kazuho Ok= u
--00000000000021a29e056f43dabd-- From nobody Fri Jun 22 17:34:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44221271FF for ; Fri, 22 Jun 2018 17:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD-lA9FeKg6D for ; Fri, 22 Jun 2018 17:34:10 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730092.outbound.protection.outlook.com [40.107.73.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F82E126CB6 for ; Fri, 22 Jun 2018 17:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k96rc36ULvZ2iztx3JX3Lj+uLZW07aYGKPwYVjup7Lw=; b=ZCUJ+j18KoFFvS2oe4CGQtuIWkgb0BNPlQjA+ZG21eMnTyq6ewgbAFm8repq4glq6Vys/wUDRzKXCFJqS1lImQDKAuJY1ZylF9tCuDB/XT4/soJ1t9fMz4uz95nEOp/ojOAapHt1g9dIbwyZj7iWLqRDqZ3HthOwmjeYR05HLNs= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1062.namprd21.prod.outlook.com (52.132.128.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.3; Sat, 23 Jun 2018 00:34:07 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%4]) with mapi id 15.20.0906.013; Sat, 23 Jun 2018 00:34:07 +0000 From: Nick Banks To: Kazuho Oku , Ian Swett , IETF QUIC WG CC: Praveen Balasubramanian Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgAAAjosmAATQHgAACtMrgAABFu2Q Date: Sat, 23 Jun 2018 00:34:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-23T00:34:04.5232167Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:a:8d71:982c:2f5c:c56f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1062; 7:Hb8asHX7IGlSu7IdB6YX6eYdpH3Ki2yjBbKKy8HMPV96sk0UrGLmidKaTQCE1UU718kPhFicWIYPcAT5aorYcqoVxRhBpDsU1TLn5jg3z7J/n7fkQiH6wgQqmuvRezbQWTwzLmmxLCp7oIL9pgt6NSqNSegcz1fcP7ZSF8Ct0zDEREix/bJtDIPVwxdgP4OvyzqtEfdj1q5wizlcPTUCDk6O7ptzAhneijmGXADiiouV+utMTST3bhfTA1vDRs0N x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 03601473-3771-42b8-2825-08d5d8a1080c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1062; x-ms-traffictypediagnostic: DM5PR2101MB1062: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(211936372134217)(153496737603132)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1062; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1062; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(366004)(39860400002)(189003)(199004)(76176011)(25786009)(316002)(2900100001)(53546011)(54896002)(486006)(186003)(7696005)(86612001)(8936002)(3480700004)(229853002)(4326008)(606006)(97736004)(10090500001)(22452003)(8990500004)(99286004)(46003)(19609705001)(476003)(6306002)(9686003)(11346002)(59450400001)(14454004)(102836004)(55016002)(236005)(86362001)(446003)(6506007)(561924002)(39060400002)(6436002)(93886005)(6246003)(966005)(74316002)(33656002)(107886003)(3280700002)(53936002)(5890100001)(10290500003)(53946003)(68736007)(8676002)(345774005)(3660700001)(5250100002)(81166006)(81156014)(106356001)(5660300001)(105586002)(2906002)(6116002)(7736002)(110136005)(790700001)(478600001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1062; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qgv9vY0BM0o2TmFkocQh8ZfTXrK0e6UMEcfcZ+bwSXnQ8HIrwx+QFmmLfyn0Whmr2qzKdfUhLHcvUgHUOrxTLg0JoCGz2TtOY8Z3kTs1MaWVDVccZ+t8UqSe5FTFlgmOfmC90wlJbh3pafJyF0GeXPLCoEB3UPC2lMbtgMEbVno0Ws66/Mri0qc/4au7qs+RO3lJ08+CEGm16KlaxlevYmSk/yGSujHQNt7UwjJ8a4VavuqCnyA7sDJRC1nrjksvRn7atUhKV/b4bUPMaU8rUCh99tXYFLXPyMjnpepxfYLhNkg4of1Hnk1aFaytH0f5 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB09014CF646E0DA727AD79486B3740DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03601473-3771-42b8-2825-08d5d8a1080c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 00:34:07.7430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1062 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 00:34:15 -0000 --_000_DM5PR2101MB09014CF646E0DA727AD79486B3740DM5PR2101MB0901_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEd1eXMsDQoNCkkgc3BlbnQgdGhlIGJldHRlciBwYXJ0IG9mIHRoZSBkYXkgZ2V0dGluZyBz b21lIHBlcmZvcm1hbmNlIHRyYWNlcyBvZiBXaW5RdWljIHdpdGhvdXQgUE5FLiBPdXIgaW1wbGVt ZW50YXRpb24gc3VwcG9ydHMgYm90aCB1c2VyIG1vZGUgYW5kIGtlcm5lbCBtb2RlLCBzbyBJIGdv dCBudW1iZXJzIGZvciBib3RoLiBUaGUgZm9sbG93aW5nIHRhYmxlIHNob3dzIHRoZSByZWxhdGl2 ZSBDUFUgY29zdCBvZiBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIFFVSUMgc2VuZCBwYXRoOg0KDQoN Cg0KVXNlciBNb2RlDQoNCktlcm5lbCBNb2RlDQoNClVEUCBTZW5kDQoNCjY0LjclDQoNCjQxLjQl DQoNCkVuY3J5cHRpb24NCg0KMjIuNSUNCg0KMzguNSUNCg0KUGFja2V0IEJ1aWxkaW5nL0ZyYW1p bmcNCg0KNyUNCg0KMTUlDQoNCk1pc2NlbGxhbmVvdXMNCg0KNS44JQ0KDQo1LjElDQoNCg0KVGhl c2UgbnVtYmVycyBkZWZpbml0ZWx5IHNob3cgdGhhdCBlbmNyeXB0aW9uIGlzIGEgbXVjaCBsYXJn ZXIgcG9ydGlvbiBvZiBDUFUuDQoNCi0gTmljaw0KDQoNCkZyb206IEthenVobyBPa3UgPGthenVo b29rdUBnbWFpbC5jb20+DQpTZW50OiBGcmlkYXksIEp1bmUgMjIsIDIwMTggNTowMiBQTQ0KVG86 IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4NCkNjOiBOaWNrIEJhbmtzIDxuaWJhbmtz QG1pY3Jvc29mdC5jb20+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0 LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQYWNrZXQg TnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2UNCg0KDQoNCjIwMTgtMDYtMjMgMzo1MSBHTVQr MDk6MDAgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29n bGUuY29tPj46DQpJIGV4cGVjdCBjcnlwdG8gdG8gaW5jcmVhc2UgYXMgYSBmcmFjdGlvbiBvZiBD UFUsIGJ1dCBJIGRvbid0IGV4cGVjdCBpdCB0byBnbyBtdWNoIGhpZ2hlciB0aGFuIDEwJS4NCg0K QnV0IHdobyBrbm93cywgbWF5YmUgMiB5ZWFycyBmcm9tIG5vdyBldmVyeXRoaW5nIGVsc2Ugd2ls bCBiZSB2ZXJ5IG9wdGltaXplZCBhbmQgY3J5cHRvIHdpbGwgYmUgMTUlPw0KDQpJYW4sIHRoYW5r IHlvdSBmb3Igc2hhcmluZyB0aGUgcHJvcG9ydGlvbiBvZiBDUFUgY3ljbGVzIHdlIGFyZSBsaWtl bHkgdG8gc3BlbmQgZm9yIGNyeXB0by4NCg0KWW91ciBudW1iZXJzIHJlbGlldmVzIG1lLCBiZWNh dXNlIGV2ZW4gaWYgdGhlIGNvc3Qgb2YgY3J5cHRvIGdvZXMgdG8gMTUlLCB0aGUgb3ZlcmhlYWQg b2YgUE5FIHdpbGwgYmUgbGVzcyB0aGFuIDElICgwLjE1KjAuMDQ9MC4wMDYpLg0KDQpJIHdvdWxk IGFsc28gbGlrZSB0byBub3RlIHRoYXQgaXQgaXMgbGlrZWx5IHRoYXQgSHlwZXJUaHJlYWRpbmcs IHdoZW4gdXNlZCwgd2lsbCBlbGltaW5hdGUgdGhlIG92ZXJoZWFkIG9mIFBORS4NCg0KVGhpcyBp cyBiZWNhdXNlIElJVUMgUE5FIGlzIGEgbWFyZ2luYWwgYWRkaXRpb25hbCB1c2Ugb2YgdGhlIEFF Uy1OSSBlbmdpbmUsIHdoaWNoIGhhdmUgYmVlbiBtb3N0bHkgaWRsZS4gVGhlIG92ZXJoZWFkIG9m IGNyeXB0byBpcyBzbWFsbCAoaS5lLiAxNSUpIHRoYXQgd2Ugd2lsbCByYXJlbHkgc2VlIGNvbnRl bnRpb24gb24gdGhlIGVuZ2luZS4gV2hpbGUgb25lIGh5cGVydGhyZWFkIGRvZXMgQUVTLCB0aGUg b3RoZXIgaHlwZXJ0aHJlYWQgd2lsbCBydW4gYXQgZnVsbCBzcGVlZCBkb2luZyBvdGhlciBvcGVy YXRpb25zLg0KDQpBbHNvIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgdGhlIG51bWJlciBvZiBD UFUgY3ljbGVzIHNwZW50IHBlciBRVUlDIHBhY2tldCBkb2VzIG5vdCBjaGFuZ2UgYSBsb3Qgd2l0 aCBQTkUsIEkgd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWUgKm5vKiBkZWNyZWFzZSBvZiB0 aHJvdWdocHV0IHdoZW4gUE5FIGlzIHVzZWQgb24gYSBIeXBlclRocmVhZGluZyBhcmNoaXRlY3R1 cmUuIEluIHN1Y2ggY2FzZSwgd2hhdCB3ZSB3aWxsIG9ubHkgb2JzZXJ2ZSBpcyB0aGUgcmFpc2Ug b2YgdGhlIHV0aWxpemF0aW9uIHJhdGlvIG9mIHRoZSBBRVMtTkkgZW5naW5lLg0KDQoNCk9uIEZy aSwgSnVuIDIyLCAyMDE4IGF0IDEyOjM0IFBNIE5pY2sgQmFua3MgPG5pYmFua3M9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCkkganVzdCB3YW50IHRvIGFkZCwgbXkgaW1wbGVtZW50YXRpb24gYWxyZWFk eSB1c2VzIEVDQiBmcm9tIGJjcnlwdCAoYW5kIEkgZG8gdGhlIFhPUikgYWxyZWFkeS4gQmNyeXB0 IGRvZXNu4oCZdCBleHBvc2UgQ1RSIG1vZGUgZGlyZWN0bHkuDQoNClNlbnQgZnJvbSBNYWlsPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ28ubWljcm9zb2Z0LmNvbSUyRmZ3bGluayUyRiUzRkxpbmtJZCUzRDU1MDk4NiZkYXRh PTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2U2ZWZhMzYzYmMyNTQ3MTY3YThj MDhkNWQ4OWM4MGU3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjY1MzA4OTA1OTI2ODgzNiZzZGF0YT1hZVU3ajVsaENJTTE4S0c1YzZvcEc0cDdhbXdoQ1di Um5mbm04c0RXN2hjJTNEJnJlc2VydmVkPTA+IGZvciBXaW5kb3dzIDEwDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2Vu dDogRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDk6MjY6NDQgQU0NClRvOiBJYW4gU3dldHQ7IEthenVo byBPa3UNCkNjOiBOaWNrIEJhbmtzOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFJFOiBQYWNrZXQg TnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2UNCg0KSWFuLCBkbyB5b3UgZXhwZWN0IHRoYXQg ZnJhY3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRvIGhvbGQgb25jZSB0aGUgVURQIHN0YWNrIGlzIG9w dGltaXplZD8gSXMgeW91ciBtZWFzdXJlbWVudCBvbiB0b3Agb2YgdGhlIHJlY2VudCBrZXJuZWwg aW1wcm92ZW1lbnRzPyBJIGV4cGVjdCBjcnlwdG8gZnJhY3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRv IGtlZXAgaW5jcmVhc2luZyBvdmVyIHRpbWUgYXMgdGhlIG5ldHdvcmsgc3RhY2sgYm90dGxlbmVj a3MgYXJlIGVsaW1pbmF0ZWQuDQoNCkthenVobywgc2hvdWxkIHRoZSBkcmFmdCBkZXNjcmliZSB0 aGUgb3B0aW1pemF0aW9ucyB5b3UgYXJlIG1ha2luZz8gT3IgYXJlIHRoZXNlIGFyZSB0b28gT3Bl blNTTCBzcGVjaWZpYz8NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0K U2VudDogRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDQ6NDUgQU0NClRvOiBLYXp1aG8gT2t1IDxrYXp1 aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4NCkNjOiBOaWNrIEJh bmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb208bWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbT4+ OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZQ0KDQpUaGFua3Mg Zm9yIGRpZ2dpbmcgaW50byB0aGUgZGV0YWlscyBvZiB0aGlzLCBLYXp1aG8uICA8NCUgaW5jcmVh c2UgaW4gY3J5cHRvIGNvc3QgaXMgYSBiaXQgbW9yZSB0aGFuIEkgb3JpZ2luYWxseSBleHBlY3Rl ZCh+MiUpLCBidXQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUgb2YgbXkgQ1BVIHVzYWdlLCBzbyBp dCdzIHN0aWxsIGxlc3MgdGhhbiAwLjUlIHRvdGFsLCB3aGljaCBpcyBhY2NlcHRhYmxlIHRvIG1l Lg0KDQpPbiBGcmksIEp1biAyMiwgMjAxOCBhdCAyOjQ1IEFNIEthenVobyBPa3UgPGthenVob29r dUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoyMDE4 LTA2LTIyIDEyOjIyIEdNVCswOTowMCBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1h aWx0bzprYXp1aG9va3VAZ21haWwuY29tPj46DQoNCg0KMjAxOC0wNi0yMiAxMTo1NCBHTVQrMDk6 MDAgTmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPG1haWx0bzpuaWJhbmtzQG1pY3Jv c29mdC5jb20+PjoNCkhpIEthenVobywNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgbnVtYmVy cyBhcyB3ZWxsISBJJ20gYml0IGNvbmZ1c2VkIHdoZXJlIHlvdSBzYXkgeW91IGNhbiByZWR1Y2Ug dGhlIDEwJSBvdmVyaGVhZCB0byAyJSB0byA0JS4gSG93IGRvIHlvdSBwbGFuIG9uIGRvaW5nIHRo YXQ/DQoNCkFzIHN0YXRlZCBpbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgMTAlIG9mIG92ZXJoZWFk IGNvbnNpc3RzIG9mIHRocmVlIHBhcnRzLCBlYWNoIGNvbnN1bWluZyBjb21wYXJhYmxlIG51bWJl ciBvZiBDUFUgY3ljbGVzLiBUaGUgdHdvIGFtb25nIHRoZSB0aHJlZSBpcyByZWxhdGVkIHRvIHRo ZSBhYnN0cmFjdGlvbiBsYXllciBhbmQgaG93IENUUiBpcyBpbXBsZW1lbnRlZCwgd2hpbGUgdGhl IG90aGVyIG9uZSBpcyB0aGUgY29yZSBBRVMtRUNCIG9wZXJhdGlvbiBjb3N0Lg0KDQpJdCBzaG91 bGQgYmUgYWJsZSB0byByZW1vdmUgdGhlIGNvc3RseSBhYnN0cmFjdGlvbiBsYXllci4NCg0KSXQg c2hvdWxkIGFsc28gYmUgcG9zc2libGUgdG8gcmVtb3ZlIHRoZSBvdmVyaGVhZCBvZiBDVFIsIHNp bmNlIGluIFBORSwgd2UgbmVlZCB0byBYT1IgYXQgbW9zdCA0IG9jdGV0cyAoYXBwbHlpbmcgWE9S IGlzIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiBDVFIgYW5kIEVDQikuIFRoYXQgY29zdCBz aG91bGQgYmUgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGJlIG51bGxpZmll ZC4NCg0KQ29uc2lkZXJpbmcgdGhlc2UgYXNwZWN0cywgYW5kIGJ5IGxvb2tpbmcgYXQgdGhlIG51 bWJlcnMgb24gdGhlIE9wZW5TU0wgc291cmNlIGNvZGUgKGFzIHdlbGwgYXMgY29uc2lkZXJpbmcg dGhlIG92ZXJoZWFkIG9mIEdDTSksIG15IGV4cGVjdGF0aW9uIGdvZXMgdG8gMiUgdG8gNCUuDQoN Ckp1c3QgZGlkIHNvbWUgZXhwZXJpbWVudHMgYW5kIGl0IHNlZW1zIHRoYXQgdGhlIGV4cGVjdGF0 aW9uIHdhcyBjb3JyZWN0Lg0KDQpUaGUgYmVuY2htYXJrcyB0ZWxsIG1lIHRoYXQgdGhlIG92ZXJo ZWFkIGdvZXMgZG93biBmcm9tIDEwLjAlIHRvIDMuOCUsIGJ5IGRvaW5nIHRoZSBmb2xsb3dpbmc6 DQoNCiogcmVtb3ZlIHRoZSBvdmVyaGVhZCBvZiBDVFIgYWJzdHJhY3Rpb24gKGkuZS4gdXNlIHRo ZSBFQ0IgYmFja2VuZCBhbmQgZG8gWE9SIGJ5IG91cnNlbHZlcykNCiogcmVtb3ZlIHRoZSBvdmVy aGVhZCBvZiB0aGUgYWJzdHJhY3Rpb24gbGF5ZXIgKGkuZS4gY2FsbCB0aGUgbWV0aG9kIHJldHVy bmVkIGJ5IEVWUF9DSVBIRVJfbWV0aF9nZXRfZG9fY2lwaGVyIGluc3RlYWQgb2YgY2FsbGluZyBF VlBfRW5jcnlwdFVwZGF0ZSkNCg0KT2YgY291cnNlIHRoZSBjaGFuZ2VzIGFyZSBzcGVjaWZpYyB0 byBPcGVuU1NMLCBidXQgSSB3b3VsZCBleHBlY3QgdGhhdCB5b3UgY2FuIGV4cGVjdCBzaW1pbGFy IG51bWJlcnMgYXNzdW1pbmcgdGhhdCB5b3UgaGF2ZSBhY2Nlc3MgdG8gYW4gb3B0aW1pemVkIEFF UyBpbXBsZW1lbnRhdGlvbi4NCg0KDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIDEwIHBob25lDQpb SHhTIC0gMTUyNTQgLSAxNi4wLjEwMjI4LjIwMDc1XQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxOCA3OjIx OjE3IFBNDQpUbzogTmljayBCYW5rcw0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNl DQoNCkhpIE5pY2ssDQoNClRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIG51bWJlcnMgdG8gdGhl IGxpc3QuDQoNCkkgaGF2ZSBqdXN0IHJ1biBhIHNtYWxsIGJlbmNobWFyayB1c2luZyBRdWljbHks IGFuZCBJIHNlZSBjb21wYXJhYmxlIG51bWJlcnMuDQoNClRvIGJlIHByZWNpc2UsIEkgc2VlIDEw LjAlIGluY3JlYXNlIG9mIENQVSBjeWNsZXMgd2hlbiBlbmNyeXB0aW5nIGEgSW5pdGlhbCBwYWNr ZXQgb2YgMSwyODAgb2N0ZXRzLiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgc2VlIHNpbWlsYXIgbnVt YmVycyBvbiBvdGhlciBRVUlDIHN0YWNrcyB0aGF0IGFsc28gdXNlIHBpY290bHMgKHdpdGggT3Bl blNTTCBhcyBhIGJhY2tlbmQpLiBOb3RlIHRoYXQgdGhlIG51bWJlciBpcyBvbmx5IGNvbXBhcmlu ZyB0aGUgY29zdCBvZiBlbmNyeXB0aW9uLCB0aGUgb3ZlcmhlYWQgcmF0aW8gd2lsbCBiZSBtdWNo IHNtYWxsZXIgaWYgd2UgbG9vayBhdCB0aGUgdG90YWwgbnVtYmVyIG9mIENQVSBjeWNsZXMgc3Bl bnQgYnkgYSBRVUlDIHN0YWNrIGFzIGEgd2hvbGUuDQoNCkxvb2tpbmcgYXQgdGhlIHByb2ZpbGUs IHRoZSBvdmVyaGVhZCBjb25zaXN0cyBvZiB0aHJlZSBvcGVyYXRpb25zIHRoYXQgZWFjaCBjb25z dW1lcyBjb21wYXJhYmxlIENQVSBjeWNsZXM6IGNvcmUgQUVTIG9wZXJhdGlvbiAodXNpbmcgQUVT LU5JKSwgQ1RSIG9wZXJhdGlvbiBvdmVyaGVhZCwgQ1RSIGluaXRpYWxpemF0aW9uLiBOb3RlIHRo YXQgcGljb3RscyBhdCB0aGUgbW9tZW50IHByb3ZpZGVzIGFjY2VzcyB0byBDVFIgY3J5cHRvIGJl bmVhdGggdGhlIEFFQUQgaW50ZXJmYWNlLCB3aGljaCBpcyB0byBiZSB1c2VkIGJ5IHRoZSBRVUlD IHN0YWNrcy4NCg0KSSB3b3VsZCBhc3N1bWUgdGhhdCB3ZSBjYW4gY3V0IGRvd24gdGhlIG92ZXJo ZWFkIHRvIHNvbWV3aGVyZSBiZXR3ZWVuIDIlIHRvIDQlLCBidXQgaXQgbWlnaHQgYmUgaGFyZCB0 byBnbyBkb3duIHRvIHNvbWV3aGVyZSBuZWFyIDElLCBiZWNhdXNlIHdlIGNhbm5vdCBwYXJhbGxl bGl6ZSB0aGUgQUVTIG9wZXJhdGlvbiBvZiBQTkUgd2l0aCB0aGF0IG9mIEFFQUQgKHNlZSBodHRw czovL2dpdGh1Yi5jb20vb3BlbnNzbC9vcGVuc3NsL2Jsb2IvT3BlblNTTF8xXzFfMGgvY3J5cHRv L2Flcy9hc20vYWVzbmkteDg2XzY0LnBsI0wyNC1MMzk8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGb3Bl bnNzbCUyRm9wZW5zc2wlMkZibG9iJTJGT3BlblNTTF8xXzFfMGglMkZjcnlwdG8lMkZhZXMlMkZh c20lMkZhZXNuaS14ODZfNjQucGwlMjNMMjQtTDM5JmRhdGE9MDIlN0MwMSU3Q25pYmFua3MlNDBt aWNyb3NvZnQuY29tJTdDMTFkNTVmMTczMzNlNGE3OTVkNzAwOGQ1ZDdlNmQ5M2MlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjUyMzA4ODQzOTk0MTM0JnNk YXRhPWtxTXo0U3NOJTJGMkVyR0swNlF6OFowdlV6cGw0TWlpcG5ORTJ3QU1VYjQ2YyUzRCZyZXNl cnZlZD0wPiBhYm91dCB0aGUgaW1wYWN0IG9mIHBhcmFsbGVsaXphdGlvbikuDQoNCkkgZG8gbm90 IHRoaW5rIHRoYXQgMiUgdG8gNCUgb2YgYWRkaXRpb25hbCBvdmVyaGVhZCB0byB0aGUgY3J5cHRv IGlzIGFuIGlzc3VlIGZvciBRVUlDL0hUVFAsIGJ1dCBjdXJyZW50IG92ZXJoZWFkIG9mIDEwJSBp cyBzb21ldGhpbmcgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGRlY3JlYXNlLiBJIGFtIGdsYWQgdG8g YmUgYWJsZSB0byBsZWFybiB0aGF0IG5vdy4NCg0KDQoyMDE4LTA2LTIyIDU6NDggR01UKzA5OjAw IE5pY2sgQmFua3MgPG5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzpuaWJhbmtzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+Og0KSGVsbG8gUVVJQyBX RywNCg0KSSByZWNlbnRseSBpbXBsZW1lbnRlZCBQTkUgZm9yIFdpblF1aWMgKHVzaW5nIGJjcnlw dCBBUElzKSBhbmQgSSBkZWNpZGVkIHRvIGdldCBzb21lIHBlcmZvcm1hbmNlIG51bWJlcnMgdG8g c2VlIHdoYXQgdGhlIG92ZXJoZWFkIG9mIFBORSB3YXMuIEkgZmlndXJlZCB0aGUgcmVzdCBvZiB0 aGUgV0cgbWlnaHQgYmUgaW50ZXJlc3RlZC4NCg0KTXkgdGVzdCBqdXN0IGVuY3J5cHRzIHRoZSBz YW1lIGJ1ZmZlciAoc2l6ZSBkZXBlbmRlbnQgb24gdGhlIHRlc3QgY2FzZSkgMTAsMDAwLDAwMCB0 aW1lcyBhbmQgbWVhc3VyZWQgdGhlIHRpbWUgaXQgdG9vay4gVGhlIHRlc3QgdGhlbiBkaWQgdGhl IHNhbWUgdGhpbmcsIGJ1dCBhbHNvIGVuY3J5cHRlZCB0aGUgcGFja2V0IG51bWJlciBhcyB3ZWxs LiBJIHJhbiBhbGwgdGhhdCAxMCB0aW1lcyBpbiB0b3RhbC4gSSB0aGVuIGNvbGxlY3RlZCB0aGUg YmVzdCB0aW1lcyBmb3IgZWFjaCBjYXRlZ29yeSB0byBwcm9kdWNlIHRoZSBmb2xsb3dpbmcgZ3Jh cGhzIGFuZCB0YWJsZXMgKGZ1bGwgZXhjZWwgZG9jIGF0dGFjaGVkKToNCg0KDQoNCg0KVGltZSAo bXMpDQoNClJhdGUgKE1icHMpDQoNCkJ5dGVzDQoNCk5PIFBORQ0KDQpQTkUNCg0KUE5FIE92ZXJo ZWFkDQoNCk5vIFBORQ0KDQpQTkUNCg0KNA0KDQoyMjg0LjY3MQ0KDQozMDI3LjY1Nw0KDQozMyUN Cg0KMTQwLjA2NA0KDQoxMDUuNjkyDQoNCjE2DQoNCjIxMDIuNDAyDQoNCjI4MjguMjA0DQoNCjM1 JQ0KDQo2MDguODI3DQoNCjQ1Mi41ODQNCg0KNjQNCg0KMjE5OC44ODMNCg0KMjkwNy41NzcNCg0K MzIlDQoNCjIzMjguNDUNCg0KMTc2MC45Mg0KDQoyNTYNCg0KMjc1OC4zDQoNCjM0OTAuMjgNCg0K MjclDQoNCjc0MjQuODYNCg0KNTg2Ny43Mg0KDQo2MDANCg0KNDY2OS4yODMNCg0KNTQyNC41MzkN Cg0KMTYlDQoNCjEwMjgwDQoNCjg4NDguNjgNCg0KMTAwMA0KDQo2MTMwLjEzOQ0KDQo2OTA3Ljgw NQ0KDQoxMyUNCg0KMTMwNTAuMw0KDQoxMTU4MS4xDQoNCjEyMDANCg0KNjQ1OC42NzkNCg0KNzIy OS42NzINCg0KMTIlDQoNCjE0ODYzLjcNCg0KMTMyNzguNg0KDQoxNDUwDQoNCjc4NzYuMzEyDQoN Cjg2NzAuMTYNCg0KMTAlDQoNCjE0NzI3LjcNCg0KMTMzNzkuMg0KDQoNCkkgdXNlZCBhIHNlcnZl ciBncmFkZSBsYWIgbWFjaGluZSBJIGhhZCBhdCBteSBkaXNwb3NhbCwgcnVubmluZyB0aGUgbGF0 ZXN0IFdpbmRvd3MgMTAgU2VydmVyIERhdGFDZW50ZXIgYnVpbGQuIEFnYWluLCB0aGVzZSBudW1i ZXJzIGFyZSBmb3IgY3J5cHRvIG9ubHkuIE5vIFFVSUMgb3IgVURQIGlzIGluY2x1ZGVkLg0KDQpU aGFua3MsDQotIE5pY2sNCg0KDQoNCg0KLS0NCkthenVobyBPa3UNCg0KDQoNCi0tDQpLYXp1aG8g T2t1DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_DM5PR2101MB09014CF646E0DA727AD79486B3740DM5PR2101MB0901_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm0t ODQ4MjI5NjMzOTg1MjU3MTI2OW0tODQwODg0NzQyNzA5MzIyMzQ3Nm0tNjI4MjQ5OTg2MTMzNDEw NDA1MWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy04NDgyMjk2MzM5ODUyNTcxMjY5bV8tODQw ODg0NzQyNzA5MzIyMzQ3Nm0tNjI4MjQ5OTg2MTMzNDEwNDA1MWhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXkg R3V5cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzcGVudCB0aGUgYmV0dGVyIHBhcnQgb2Yg dGhlIGRheSBnZXR0aW5nIHNvbWUgcGVyZm9ybWFuY2UgdHJhY2VzIG9mIFdpblF1aWMNCjxiPndp dGhvdXQgUE5FPC9iPi4gT3VyIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGJvdGggdXNlciBtb2Rl IGFuZCBrZXJuZWwgbW9kZSwgc28gSSBnb3QgbnVtYmVycyBmb3IgYm90aC4gVGhlIGZvbGxvd2lu ZyB0YWJsZSBzaG93cyB0aGUgcmVsYXRpdmUgQ1BVIGNvc3Qgb2YgZGlmZmVyZW50IHBhcnRzIG9m IHRoZSBRVUlDIHNlbmQgcGF0aDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJtYXJnaW4tbGVm dDozMC4ycHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3 aWR0aD0iMTc1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iODQi IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NjMuMHB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPlVzZXIgTW9kZTxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9Ijk2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEuMGluO2JvcmRlcjpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPktlcm5lbCBNb2RlPG86cD48L286 cD48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE3NSIgdmFsaWduPSJ0 b3AiIHN0eWxlPSJ3aWR0aDoxMzEuNHB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2Jv cmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+VURQIFNlbmQ8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI4NCIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wcHQ7Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42NC43JTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iOTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MS4waW47Ym9yZGVyLXRvcDpu b25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40MS40JTxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8dHI+DQo8dGQgd2lkdGg9IjE3NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0 aDoxMzEuNHB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RW5j cnlwdGlvbjxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxpZ249 InRvcCIgc3R5bGU9IndpZHRoOjYzLjBwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjIyLjUlPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI5NiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxLjBpbjtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxl ZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0 OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjM4LjUlPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEzMS40cHQ7Ym9y ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5QYWNrZXQgQnVpbGRpbmcv RnJhbWluZzxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxpZ249 InRvcCIgc3R5bGU9IndpZHRoOjYzLjBwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjclPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI5NiIgdmFs aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxLjBpbjtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6 bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjE1JTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgd2lkdGg9IjE3NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMzEuNHB0O2JvcmRlcjpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+TWlzY2VsbGFuZW91czxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxpZ249InRvcCIgc3R5bGU9Indp ZHRoOjYzLjBwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUu OCU8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijk2IiB2YWxpZ249InRvcCIgc3R5 bGU9IndpZHRoOjEuMGluO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1i b3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+NS4xJTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlc2UgbnVtYmVycyBkZWZpbml0ZWx5IHNob3cgdGhhdCBlbmNyeXB0aW9uIGlz IGEgbXVjaCBsYXJnZXIgcG9ydGlvbiBvZiBDUFUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g TmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21h aWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDU6MDIg UE08YnI+DQo8Yj5Ubzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IE5pY2sgQmFua3MgJmx0O25pYmFua3NAbWljcm9zb2Z0LmNvbSZndDs7 IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgSUVU RiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog UGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y MDE4LTA2LTIzIDM6NTEgR01UJiM0MzswOTowMCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0 bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBleHBlY3Qg Y3J5cHRvIHRvIGluY3JlYXNlIGFzIGEgZnJhY3Rpb24gb2YgQ1BVLCBidXQgSSBkb24ndCBleHBl Y3QgaXQgdG8gZ28gbXVjaCBoaWdoZXIgdGhhbiAxMCUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgd2hvIGtub3dzLCBtYXliZSAyIHllYXJzIGZyb20g bm93IGV2ZXJ5dGhpbmcgZWxzZSB3aWxsIGJlIHZlcnkgb3B0aW1pemVkIGFuZCBjcnlwdG8gd2ls bCBiZSAxNSU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuLCB0aGFuayB5b3UgZm9yIHNoYXJpbmcg dGhlIHByb3BvcnRpb24gb2YgQ1BVIGN5Y2xlcyB3ZSBhcmUgbGlrZWx5IHRvIHNwZW5kIGZvciBj cnlwdG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllvdXIgbnVtYmVycyByZWxpZXZlcyBtZSwgYmVjYXVzZSBldmVuIGlmIHRoZSBjb3N0IG9m IGNyeXB0byBnb2VzIHRvIDE1JSwgdGhlIG92ZXJoZWFkIG9mIFBORSB3aWxsIGJlIGxlc3MgdGhh biAxJSAoMC4xNSowLjA0PTAuMDA2KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBhbHNvIGxpa2UgdG8gbm90ZSB0aGF0IGl0IGlz IGxpa2VseSB0aGF0IEh5cGVyVGhyZWFkaW5nLCB3aGVuIHVzZWQsIHdpbGwgZWxpbWluYXRlIHRo ZSBvdmVyaGVhZCBvZiBQTkUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYmVjYXVzZSBJSVVDIFBORSBpcyBhIG1hcmdpbmFsIGFk ZGl0aW9uYWwgdXNlIG9mIHRoZSBBRVMtTkkgZW5naW5lLCB3aGljaCBoYXZlIGJlZW4gbW9zdGx5 IGlkbGUuIFRoZSBvdmVyaGVhZCBvZiBjcnlwdG8gaXMgc21hbGwgKGkuZS4gMTUlKSB0aGF0IHdl IHdpbGwgcmFyZWx5IHNlZSBjb250ZW50aW9uIG9uIHRoZSBlbmdpbmUuIFdoaWxlIG9uZSBoeXBl cnRocmVhZCBkb2VzIEFFUywgdGhlIG90aGVyDQogaHlwZXJ0aHJlYWQgd2lsbCBydW4gYXQgZnVs bCBzcGVlZCBkb2luZyBvdGhlciBvcGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRo YXQgdGhlIG51bWJlciBvZiBDUFUgY3ljbGVzIHNwZW50IHBlciBRVUlDIHBhY2tldCBkb2VzIG5v dCBjaGFuZ2UgYSBsb3Qgd2l0aCBQTkUsIEkgd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWUg Km5vKiBkZWNyZWFzZSBvZiB0aHJvdWdocHV0IHdoZW4gUE5FIGlzIHVzZWQgb24gYSBIeXBlclRo cmVhZGluZyBhcmNoaXRlY3R1cmUuIEluIHN1Y2ggY2FzZSwgd2hhdA0KIHdlIHdpbGwgb25seSBv YnNlcnZlIGlzIHRoZSByYWlzZSBvZiB0aGUgdXRpbGl6YXRpb24gcmF0aW8gb2YgdGhlIEFFUy1O SSBlbmdpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIEp1biAyMiwgMjAxOCBhdCAxMjozNCBQTSBOaWNrIEJhbmtzICZsdDtu aWJhbmtzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBqdXN0IHdhbnQgdG8gYWRkLCBteSBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5IHVzZXMgRUNCIGZy b20gYmNyeXB0IChhbmQgSSBkbyB0aGUgWE9SKSBhbHJlYWR5LiBCY3J5cHQgZG9lc27igJl0IGV4 cG9zZSBDVFIgbW9kZSBkaXJlY3RseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlbnQg ZnJvbQ0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZnby5taWNyb3NvZnQuY29tJTJGZndsaW5rJTJGJTNGTGlu a0lkJTNENTUwOTg2JmFtcDtkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3 Q2U2ZWZhMzYzYmMyNTQ3MTY3YThjMDhkNWQ4OWM4MGU3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1MzA4OTA1OTI2ODgzNiZhbXA7c2RhdGE9YWVVN2o1 bGhDSU0xOEtHNWM2b3BHNHA3YW13aENXYlJuZm5tOHNEVzdoYyUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPg0KTWFpbDwvYT4gZm9yIFdpbmRvd3MgMTA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0K PGRpdiBpZD0ibV8tODQ4MjI5NjMzOTg1MjU3MTI2OW1fLTg0MDg4NDc0MjcwOTMyMjM0NzZkaXZS cGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyMiwgMjAxOCA5 OjI2OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQ7IEthenVobyBPa3U8YnI+DQo8Yj5D Yzo8L2I+IE5pY2sgQmFua3M7IElFVEYgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog UGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNlPC9zcGFuPiA8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWFuLCBk byB5b3UgZXhwZWN0IHRoYXQgZnJhY3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRvIGhvbGQgb25jZSB0 aGUgVURQIHN0YWNrIGlzIG9wdGltaXplZD8gSXMgeW91ciBtZWFzdXJlbWVudCBvbiB0b3Agb2Yg dGhlIHJlY2VudCBrZXJuZWwgaW1wcm92ZW1lbnRzPyBJIGV4cGVjdCBjcnlwdG8gZnJhY3Rpb24N CiBvZiBvdmVyYWxsIGNvc3QgdG8ga2VlcCBpbmNyZWFzaW5nIG92ZXIgdGltZSBhcyB0aGUgbmV0 d29yayBzdGFjayBib3R0bGVuZWNrcyBhcmUgZWxpbWluYXRlZC4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+S2F6dWhvLCBzaG91bGQgdGhlIGRyYWZ0IGRlc2NyaWJlIHRoZSBvcHRpbWl6 YXRpb25zIHlvdSBhcmUgbWFraW5nPyBPciBhcmUgdGhlc2UgYXJlIHRvbyBPcGVuU1NMIHNwZWNp ZmljPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0 PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyMiwgMjAxOCA0OjQ1IEFNPGJyPg0KPGI+ VG86PC9iPiBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gTmljayBCYW5rcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm5pYmFua3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBJRVRGIFFV SUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgTnVt YmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFua3MgZm9yIGRpZ2dpbmcgaW50byB0aGUgZGV0YWlscyBvZiB0aGlzLCBLYXp1aG8u Jm5ic3A7ICZsdDs0JSBpbmNyZWFzZSBpbiBjcnlwdG8gY29zdCBpcyBhIGJpdCBtb3JlIHRoYW4g SSBvcmlnaW5hbGx5IGV4cGVjdGVkKH4yJSksIGJ1dCBjcnlwdG8gaXMgbGVzcyB0aGFuIDEwJSBv ZiBteSBDUFUgdXNhZ2UsIHNvDQogaXQncyBzdGlsbCBsZXNzIHRoYW4gMC41JSB0b3RhbCwgd2hp Y2ggaXMgYWNjZXB0YWJsZSB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBGcmksIEp1biAyMiwgMjAxOCBhdCAyOjQ1IEFNIEthenVobyBP a3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4yMDE4LTA2LTIyIDEyOjIyIEdNVCYjNDM7MDk6MDAgS2F6dWhv IE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4yMDE4LTA2LTIyIDExOjU0IEdNVCYjNDM7MDk6MDAgTmljayBCYW5rcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5pYmFu a3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGkgS2F6dWhvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh bmtzIGZvciBzaGFyaW5nIHlvdXIgbnVtYmVycyBhcyB3ZWxsISBJJ20gYml0IGNvbmZ1c2VkIHdo ZXJlIHlvdSBzYXkgeW91IGNhbiByZWR1Y2UgdGhlIDEwJSBvdmVyaGVhZCB0byAyJSB0byA0JS4g SG93IGRvIHlvdSBwbGFuIG9uIGRvaW5nIHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFz IHN0YXRlZCBpbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgMTAlIG9mIG92ZXJoZWFkIGNvbnNpc3Rz IG9mIHRocmVlIHBhcnRzLCBlYWNoIGNvbnN1bWluZyBjb21wYXJhYmxlIG51bWJlciBvZiBDUFUg Y3ljbGVzLiBUaGUgdHdvIGFtb25nIHRoZSB0aHJlZSBpcyByZWxhdGVkIHRvIHRoZSBhYnN0cmFj dGlvbg0KIGxheWVyIGFuZCBob3cgQ1RSIGlzIGltcGxlbWVudGVkLCB3aGlsZSB0aGUgb3RoZXIg b25lIGlzIHRoZSBjb3JlIEFFUy1FQ0Igb3BlcmF0aW9uIGNvc3QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBzaG91bGQgYmUgYWJs ZSB0byByZW1vdmUgdGhlIGNvc3RseSBhYnN0cmFjdGlvbiBsYXllci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHNob3VsZCBhbHNv IGJlIHBvc3NpYmxlIHRvIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2YgQ1RSLCBzaW5jZSBpbiBQTkUs IHdlIG5lZWQgdG8gWE9SIGF0IG1vc3QgNCBvY3RldHMgKGFwcGx5aW5nIFhPUiBpcyB0aGUgb25s eSBkaWZmZXJlbmNlIGJldHdlZW4gQ1RSIGFuZCBFQ0IpLiBUaGF0IGNvc3Qgc2hvdWxkDQogYmUg c29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGJlIG51bGxpZmllZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnNp ZGVyaW5nIHRoZXNlIGFzcGVjdHMsIGFuZCBieSBsb29raW5nIGF0IHRoZSBudW1iZXJzIG9uIHRo ZSBPcGVuU1NMIHNvdXJjZSBjb2RlIChhcyB3ZWxsIGFzIGNvbnNpZGVyaW5nIHRoZSBvdmVyaGVh ZCBvZiBHQ00pLCBteSBleHBlY3RhdGlvbiBnb2VzIHRvIDIlIHRvIDQlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdCBkaWQgc29tZSBleHBlcmltZW50cyBhbmQg aXQgc2VlbXMgdGhhdCB0aGUgZXhwZWN0YXRpb24gd2FzIGNvcnJlY3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgYmVuY2htYXJr cyB0ZWxsIG1lIHRoYXQgdGhlIG92ZXJoZWFkIGdvZXMgZG93biBmcm9tIDEwLjAlIHRvIDMuOCUs IGJ5IGRvaW5nIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2YgQ1RSIGFi c3RyYWN0aW9uIChpLmUuIHVzZSB0aGUgRUNCIGJhY2tlbmQgYW5kIGRvIFhPUiBieSBvdXJzZWx2 ZXMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiogcmVtb3ZlIHRoZSBvdmVyaGVhZCBvZiB0aGUgYWJzdHJhY3Rpb24gbGF5ZXIgKGkuZS4gY2Fs bCB0aGUgbWV0aG9kIHJldHVybmVkIGJ5IEVWUF9DSVBIRVJfbWV0aF9nZXRfZG9fY2lwaGVyIGlu c3RlYWQgb2YgY2FsbGluZyBFVlBfRW5jcnlwdFVwZGF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9mIGNvdXJzZSB0aGUgY2hhbmdl cyBhcmUgc3BlY2lmaWMgdG8gT3BlblNTTCwgYnV0IEkgd291bGQgZXhwZWN0IHRoYXQgeW91IGNh biBleHBlY3Qgc2ltaWxhciBudW1iZXJzIGFzc3VtaW5nIHRoYXQgeW91IGhhdmUgYWNjZXNzIHRv IGFuIG9wdGltaXplZCBBRVMgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5T ZW50IGZyb20gbXkgV2luZG93cyAxMCBwaG9uZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5bSHhTIC0gMTUyNTQgLSAxNi4wLjEwMjI4LjIwMDc1XTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+ DQo8ZGl2IGlkPSJtXy04NDgyMjk2MzM5ODUyNTcxMjY5bV8tODQwODg0NzQyNzA5MzIyMzQ3Nm1f LTYyODI0OTk4NjEzMzQxMDQwNTFtXzg0NzEwNzEzNTk4MTgxMzcxMDdtXy03NzYyOTgxMjEzMTM4 NzgzNzRkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4gS2F6dWhvIE9rdSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjEsIDIw MTggNzoyMToxNyBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBCYW5rczxicj4NCjxiPkNjOjwvYj4g PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Y0BpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNlPC9zcGFuPiA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIE5pY2ssDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFuayB5b3UgZm9yIGJyaW5naW5nIHRoZSBudW1iZXJz IHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBoYXZlIGp1c3QgcnVuIGEgc21hbGwgYmVuY2htYXJrIHVzaW5nIFF1 aWNseSwgYW5kIEkgc2VlIGNvbXBhcmFibGUgbnVtYmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGJlIHByZWNpc2UsIEkgc2Vl IDEwLjAlIGluY3JlYXNlIG9mIENQVSBjeWNsZXMgd2hlbiBlbmNyeXB0aW5nIGEgSW5pdGlhbCBw YWNrZXQgb2YgMSwyODAgb2N0ZXRzLiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgc2VlIHNpbWlsYXIg bnVtYmVycyBvbiBvdGhlciBRVUlDIHN0YWNrcyB0aGF0IGFsc28gdXNlDQogcGljb3RscyAod2l0 aCBPcGVuU1NMIGFzIGEgYmFja2VuZCkuIE5vdGUgdGhhdCB0aGUgbnVtYmVyIGlzIG9ubHkgY29t cGFyaW5nIHRoZSBjb3N0IG9mIGVuY3J5cHRpb24sIHRoZSBvdmVyaGVhZCByYXRpbyB3aWxsIGJl IG11Y2ggc21hbGxlciBpZiB3ZSBsb29rIGF0IHRoZSB0b3RhbCBudW1iZXIgb2YgQ1BVIGN5Y2xl cyBzcGVudCBieSBhIFFVSUMgc3RhY2sgYXMgYSB3aG9sZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxvb2tpbmcgYXQgdGhlIHByb2Zp bGUsIHRoZSBvdmVyaGVhZCBjb25zaXN0cyBvZiB0aHJlZSBvcGVyYXRpb25zIHRoYXQgZWFjaCBj b25zdW1lcyBjb21wYXJhYmxlIENQVSBjeWNsZXM6IGNvcmUgQUVTIG9wZXJhdGlvbiAodXNpbmcg QUVTLU5JKSwgQ1RSIG9wZXJhdGlvbiBvdmVyaGVhZCwgQ1RSIGluaXRpYWxpemF0aW9uLg0KIE5v dGUgdGhhdCBwaWNvdGxzIGF0IHRoZSBtb21lbnQgcHJvdmlkZXMgYWNjZXNzIHRvIENUUiBjcnlw dG8gYmVuZWF0aCB0aGUgQUVBRCBpbnRlcmZhY2UsIHdoaWNoIGlzIHRvIGJlIHVzZWQgYnkgdGhl IFFVSUMgc3RhY2tzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBhc3N1bWUgdGhhdCB3ZSBjYW4gY3V0IGRvd24gdGhlIG92 ZXJoZWFkIHRvIHNvbWV3aGVyZSBiZXR3ZWVuIDIlIHRvIDQlLCBidXQgaXQgbWlnaHQgYmUgaGFy ZCB0byBnbyBkb3duIHRvIHNvbWV3aGVyZSBuZWFyIDElLCBiZWNhdXNlIHdlIGNhbm5vdCBwYXJh bGxlbGl6ZSB0aGUgQUVTIG9wZXJhdGlvbg0KIG9mIFBORSB3aXRoIHRoYXQgb2YgQUVBRCAoc2Vl IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm9wZW5zc2wlMkZvcGVuc3NsJTJGYmxvYiUy Rk9wZW5TU0xfMV8xXzBoJTJGY3J5cHRvJTJGYWVzJTJGYXNtJTJGYWVzbmkteDg2XzY0LnBsJTIz TDI0LUwzOSZhbXA7ZGF0YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jvc29mdC5jb20lN0MxMWQ1 NWYxNzMzM2U0YTc5NWQ3MDA4ZDVkN2U2ZDkzYyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTIzMDg4NDM5OTQxMzQmYW1wO3NkYXRhPWtxTXo0U3NOJTJG MkVyR0swNlF6OFowdlV6cGw0TWlpcG5ORTJ3QU1VYjQ2YyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9ibG9iL09w ZW5TU0xfMV8xXzBoL2NyeXB0by9hZXMvYXNtL2Flc25pLXg4Nl82NC5wbCNMMjQtTDM5PC9hPiBh Ym91dCB0aGUgaW1wYWN0IG9mIHBhcmFsbGVsaXphdGlvbikuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvIG5vdCB0aGluayB0aGF0 IDIlIHRvIDQlIG9mIGFkZGl0aW9uYWwgb3ZlcmhlYWQgdG8gdGhlIGNyeXB0byBpcyBhbiBpc3N1 ZSBmb3IgUVVJQy9IVFRQLCBidXQgY3VycmVudCBvdmVyaGVhZCBvZiAxMCUgaXMgc29tZXRoaW5n IHRoYXQgd2UgbWlnaHQgd2FudCB0byBkZWNyZWFzZS4gSSBhbSBnbGFkIHRvDQogYmUgYWJsZSB0 byBsZWFybiB0aGF0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE4LTA2LTIyIDU6NDggR01UJiM0MzswOTowMCBOaWNr IEJhbmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uaWJhbmtzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGVsbG8gUVVJQyBXRyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVjZW50 bHkgaW1wbGVtZW50ZWQgUE5FIGZvciBXaW5RdWljICh1c2luZyBiY3J5cHQgQVBJcykgYW5kIEkg ZGVjaWRlZCB0byBnZXQgc29tZSBwZXJmb3JtYW5jZSBudW1iZXJzIHRvIHNlZSB3aGF0IHRoZSBv dmVyaGVhZCBvZiBQTkUgd2FzLiBJIGZpZ3VyZWQgdGhlIHJlc3Qgb2YgdGhlIFdHIG1pZ2h0DQog YmUgaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHRlc3QganVzdCBl bmNyeXB0cyB0aGUgc2FtZSBidWZmZXIgKHNpemUgZGVwZW5kZW50IG9uIHRoZSB0ZXN0IGNhc2Up IDEwLDAwMCwwMDAgdGltZXMgYW5kIG1lYXN1cmVkIHRoZSB0aW1lIGl0IHRvb2suIFRoZSB0ZXN0 IHRoZW4gZGlkIHRoZSBzYW1lIHRoaW5nLCBidXQgYWxzbyBlbmNyeXB0ZWQgdGhlDQogcGFja2V0 IG51bWJlciBhcyB3ZWxsLiBJIHJhbiBhbGwgdGhhdCAxMCB0aW1lcyBpbiB0b3RhbC4gSSB0aGVu IGNvbGxlY3RlZCB0aGUgYmVzdCB0aW1lcyBmb3IgZWFjaCBjYXRlZ29yeSB0byBwcm9kdWNlIHRo ZSBmb2xsb3dpbmcgZ3JhcGhzIGFuZCB0YWJsZXMgKGZ1bGwgZXhjZWwgZG9jIGF0dGFjaGVkKTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iNTAxIiBzdHlsZT0id2lkdGg6Mzc2LjBwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2Ui Pg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSIxMjgiIG5v d3JhcD0iIiBjb2xzcGFuPSIyIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjk2LjBwdDtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGltZSAobXMpPC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWdu PSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0i Ym90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDto ZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjExOSIgbm93cmFwPSIiIGNvbHNwYW49 IjIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6ODkuMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SYXRlIChNYnBzKTwvc3Bhbj48L2I+PG86cD48L286cD48 L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9 IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGlu ZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkJ5dGVzPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk5PIFBORTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QTkU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8L3RkPg0KPHRkIHdpZHRoPSIxMjciIG5vd3JhcD0iIiBjb2xzcGFuPSIyIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjk1LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+UE5FIE92ZXJoZWFkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5vIFBORTwvc3Bh bj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5QTkU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIi IHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj40PC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIyODQuNjcx PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzAyNy42NTc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMzJTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJv dHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTQwLjA2NDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEwNS42OTI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQg d2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7 cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjE2PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg d2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7 cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjIxMDIuNDAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3 aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+MjgyOC4yMDQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lk dGg9IjYzIiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjM1JTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTki IG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+NjA4LjgyNzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBu b3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjQ1Mi41ODQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0i aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpy aWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjY0PC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpy aWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIxOTguODgzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJp Z2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjkwNy41Nzc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0 eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdo dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMyJTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjMyOC40NTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0 aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjE3NjAuOTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dy YXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjI1Njwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4y NzU4LjM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy aWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4zNDkw LjI4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0i IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIgbm93cmFwPSIi IHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yNyU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWdu PSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjc0MjQuODY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0i Ym90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDto ZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41ODY3LjcyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0K PHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDgu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj42MDA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+NDY2OS4yODM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDgu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj41NDI0LjUzOTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4w cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBw dDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+MTYlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRo PSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4xMDI4MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjg4NDguNjg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEwMDA8L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJv dHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NjEzMC4xMzk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90 dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWln aHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxp Z246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj42OTA3LjgwNTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRv bSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu OnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTMlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHls ZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMzA1MC4zPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTE1ODEuMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQi IG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+MTIwMDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj42NDU4LjY3OTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjcyMjkuNjcyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQi IG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4xMiU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjE0ODYz Ljc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIi IHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMzI3OC42 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDox NS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i d2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0K PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xNDUwPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxl PSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjc4NzYuMzEyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ODY3MC4xNjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTAlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0K PHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQu NXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4xNDcyNy43PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVw dDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+MTMzNzkuMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHVzZWQgYSBzZXJ2ZXIgZ3JhZGUg bGFiIG1hY2hpbmUgSSBoYWQgYXQgbXkgZGlzcG9zYWwsIHJ1bm5pbmcgdGhlIGxhdGVzdCBXaW5k b3dzIDEwIFNlcnZlciBEYXRhQ2VudGVyIGJ1aWxkLiBBZ2FpbiwgdGhlc2UgbnVtYmVycyBhcmUg Zm9yIGNyeXB0byBvbmx5LiBObyBRVUlDIG9yIFVEUCBpcyBpbmNsdWRlZC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJtLTg0 ODIyOTYzMzk4NTI1NzEyNjltLTg0MDg4NDc0MjcwOTMyMjM0NzZtLTYyODI0OTk4NjEzMzQxMDQw NTFob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPC9zcGFuPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij5LYXp1aG8gT2t1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+S2F6dWhvIE9rdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXp1aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR2101MB09014CF646E0DA727AD79486B3740DM5PR2101MB0901_-- From nobody Sat Jun 23 00:00:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA487130E9A for ; Sat, 23 Jun 2018 00:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, 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 3fcrRGG3aibs for ; Sat, 23 Jun 2018 00:00:11 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 0AA1B130DDA for ; Sat, 23 Jun 2018 00:00:10 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id w7-v6so4190444pfn.9 for ; Sat, 23 Jun 2018 00:00:10 -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=Q9NWYdfzjiiOHRyl7WoTBwZe4AGdATJY1S2wasUItpU=; b=hzuEuCSb9CTCEX5s00kFle23Uw/5q28xPBfROCZKpt7+6lyXBtIt6WkmblLXCbDVKZ u3BmUoIWmKXb299YRd95DqNMpyDE+f6WrtsR5h0DXvUezFZJm/Dx+l/oEECckX9xP4Xh MO1hXyZSXD8nWJST7TbDtQK4PFkm6c4OAEX9PKBhdhlB5K2fWB1gS3SxNLnwAOTrQxwc RzMPJtka3FCmhT59+4FU5OdQMeBuT4GETYnQzMhkI6zYWTWtwUUmGNnjmn0Wr5k+Uije DObAUr+6oDtp8rTYrbD669Iki1WXwAt/NT3Hg9gEFr8GP0Ar/Ls/s21TG0LkNWMleyOS lIdA== 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=Q9NWYdfzjiiOHRyl7WoTBwZe4AGdATJY1S2wasUItpU=; b=HF83MOGhisGnK74A9TPT4h+E7iKWuU2xeEZRfovATopf2rsvh67Ej3HEZ6y0qCvFCY JDKC+qQL/NexVo3qRhjA67hBj+77AjT84KYIBuBDP2RLnngSboput4Uxa/UCN/wa+Gc4 TrVgK13NpGUXgK90LlXuIcSK3Rdz0kF5NFHEbL/oeNEjyYtYMxYZ8HDkSrqtSACtIpuk jDFl0+tfGEJHPUOII2xWiZlW2w2282yuGqUOmlslYMmS2kDbpDykHlQhgo7Hj7h4Ceeg 3fttLfXSeB0vY64dKqcsw8S83LFmYKVbLV2AaaLbhNIi2+KgeARobzl7qy/lkCxt/QrS RPnQ== X-Gm-Message-State: APt69E0etDOt/PW/iQlbJR7k+t2N0vM4eOUJUYMQTquuiykEIoVgYGAz c3k8D+CdTrpNGaz7hGJufwVDQvlq3I2moAyMT6uKUg== X-Google-Smtp-Source: ADUXVKKZGIQpqECpa9FvfqEvqnfzLTW0LSyHojHsecQazRWXxmohqaAKXLpDV1YPyHH6GXDzdjlZeao6XjHHGw3aE+M= X-Received: by 2002:a63:6e08:: with SMTP id j8-v6mr3910813pgc.428.1529737210296; Sat, 23 Jun 2018 00:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sat, 23 Jun 2018 00:00:09 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Sat, 23 Jun 2018 16:00:09 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: Ian Swett , IETF QUIC WG , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="00000000000004fe9a056f49b379" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 07:00:16 -0000 --00000000000004fe9a056f49b379 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IIUC, Ian should be talking about performance numbers that you would see on a server that is handling real workload. Not the breakdown of numbers within the QUIC stack. Let's talk about nanoseconds per packet rather than the ratio, because ratio depends on what you use as a "total" is. My benchmarks tell me that, on OpenSSL 1.1.0 running on Core i7 @ 2.5GHz (MacBook Pro 15" Mid 2015), the numbers are: without-PNE: 585ns / packet with-PNE: 607ns / packet (* this is the optimized version with 3.8% overhead) Assuming that your peak rate is 1Gbit/CPU core (would be enough to saturate 25Gb Ethernet), the ratio of CPU cycles for running the crypto will be: all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/packet =3D 5.93 % PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet =3D 0.22 % Of course, these numbers are what is expected when a server is sending or receiving full-sized packets in one direction. In reality, there would be at least some flow in the opposite direction, so the number will be higher, but not as much as 2x. Or if you are sending small-sized packet in *both* directions *and* saturating the link, the ratio will be higher. But looking at the numbers, I'd assume that 10% is a logical number for workload Ian has, and also for people who are involved in content distribution. As shown, I think that sharing the PPS and average packet size that our workload will have, along with the raw numbers of the crypto (i.e. nsec / packet) will give us a better understanding on how much the actual overhead is. Do you mind sharing your expectations? 2018-06-23 9:34 GMT+09:00 Nick Banks : > Hey Guys, > > > > I spent the better part of the day getting some performance traces of > WinQuic *without PNE*. Our implementation supports both user mode and > kernel mode, so I got numbers for both. The following table shows the > relative CPU cost of different parts of the QUIC send path: > > > > > > *User Mode* > > *Kernel Mode* > > *UDP Send* > > 64.7% > > 41.4% > > *Encryption* > > 22.5% > > 38.5% > > *Packet Building/Framing* > > 7% > > 15% > > *Miscellaneous* > > 5.8% > > 5.1% > > > > These numbers definitely show that encryption is a much larger portion of > CPU. > > > > - Nick > > > > > > *From:* Kazuho Oku > *Sent:* Friday, June 22, 2018 5:02 PM > *To:* Ian Swett > *Cc:* Nick Banks ; Praveen Balasubramanian < > pravb@microsoft.com>; IETF QUIC WG > > *Subject:* Re: Packet Number Encryption Performance > > > > > > > > 2018-06-23 3:51 GMT+09:00 Ian Swett : > > I expect crypto to increase as a fraction of CPU, but I don't expect it t= o > go much higher than 10%. > > > > But who knows, maybe 2 years from now everything else will be very > optimized and crypto will be 15%? > > > > Ian, thank you for sharing the proportion of CPU cycles we are likely to > spend for crypto. > > > > Your numbers relieves me, because even if the cost of crypto goes to 15%, > the overhead of PNE will be less than 1% (0.15*0.04=3D0.006). > > > > I would also like to note that it is likely that HyperThreading, when > used, will eliminate the overhead of PNE. > > > > This is because IIUC PNE is a marginal additional use of the AES-NI > engine, which have been mostly idle. The overhead of crypto is small (i.e= . > 15%) that we will rarely see contention on the engine. While one > hyperthread does AES, the other hyperthread will run at full speed doing > other operations. > > > > Also considering the fact that the number of CPU cycles spent per QUIC > packet does not change a lot with PNE, I would not be surprised to see *n= o* > decrease of throughput when PNE is used on a HyperThreading architecture. > In such case, what we will only observe is the raise of the utilization > ratio of the AES-NI engine. > > > > > > On Fri, Jun 22, 2018 at 12:34 PM Nick Banks dmarc.ietf.org> wrote: > > I just want to add, my implementation already uses ECB from bcrypt (and I > do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directly. > > > > Sent from Mail > > for Windows 10 > > > ------------------------------ > > *From:* Praveen Balasubramanian > *Sent:* Friday, June 22, 2018 9:26:44 AM > *To:* Ian Swett; Kazuho Oku > *Cc:* Nick Banks; IETF QUIC WG > *Subject:* RE: Packet Number Encryption Performance > > > > Ian, do you expect that fraction of overall cost to hold once the UDP > stack is optimized? Is your measurement on top of the recent kernel > improvements? I expect crypto fraction of overall cost to keep increasing > over time as the network stack bottlenecks are eliminated. > > > > Kazuho, should the draft describe the optimizations you are making? Or ar= e > these are too OpenSSL specific? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Friday, June 22, 2018 4:45 AM > *To:* Kazuho Oku > *Cc:* Nick Banks ; IETF QUIC WG > *Subject:* Re: Packet Number Encryption Performance > > > > Thanks for digging into the details of this, Kazuho. <4% increase in > crypto cost is a bit more than I originally expected(~2%), but crypto is > less than 10% of my CPU usage, so it's still less than 0.5% total, which = is > acceptable to me. > > > > On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: > > > > > > 2018-06-22 12:22 GMT+09:00 Kazuho Oku : > > > > > > 2018-06-22 11:54 GMT+09:00 Nick Banks : > > Hi Kazuho, > > > > Thanks for sharing your numbers as well! I'm bit confused where you say > you can reduce the 10% overhead to 2% to 4%. How do you plan on doing tha= t? > > > > As stated in my previous mail, the 10% of overhead consists of three > parts, each consuming comparable number of CPU cycles. The two among the > three is related to the abstraction layer and how CTR is implemented, whi= le > the other one is the core AES-ECB operation cost. > > > > It should be able to remove the costly abstraction layer. > > > > It should also be possible to remove the overhead of CTR, since in PNE, w= e > need to XOR at most 4 octets (applying XOR is the only difference between > CTR and ECB). That cost should be something that should be possible to be > nullified. > > > > Considering these aspects, and by looking at the numbers on the OpenSSL > source code (as well as considering the overhead of GCM), my expectation > goes to 2% to 4%. > > > > Just did some experiments and it seems that the expectation was correct. > > > > The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by > doing the following: > > > > * remove the overhead of CTR abstraction (i.e. use the ECB backend and do > XOR by ourselves) > > * remove the overhead of the abstraction layer (i.e. call the method > returned by EVP_CIPHER_meth_get_do_cipher instead of calling > EVP_EncryptUpdate) > > > > Of course the changes are specific to OpenSSL, but I would expect that yo= u > can expect similar numbers assuming that you have access to an optimized > AES implementation. > > > > > > > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > > *From:* Kazuho Oku > *Sent:* Thursday, June 21, 2018 7:21:17 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Packet Number Encryption Performance > > > > Hi Nick, > > > > Thank you for bringing the numbers to the list. > > > > I have just run a small benchmark using Quicly, and I see comparable > numbers. > > > > To be precise, I see 10.0% increase of CPU cycles when encrypting a > Initial packet of 1,280 octets. I expect that we will see similar numbers > on other QUIC stacks that also use picotls (with OpenSSL as a backend). > Note that the number is only comparing the cost of encryption, the overhe= ad > ratio will be much smaller if we look at the total number of CPU cycles > spent by a QUIC stack as a whole. > > > > Looking at the profile, the overhead consists of three operations that > each consumes comparable CPU cycles: core AES operation (using AES-NI), C= TR > operation overhead, CTR initialization. Note that picotls at the moment > provides access to CTR crypto beneath the AEAD interface, which is to be > used by the QUIC stacks. > > > > I would assume that we can cut down the overhead to somewhere between 2% > to 4%, but it might be hard to go down to somewhere near 1%, because we > cannot parallelize the AES operation of PNE with that of AEAD (see > https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/ > crypto/aes/asm/aesni-x86_64.pl#L24-L39 > > about the impact of parallelization). > > > > I do not think that 2% to 4% of additional overhead to the crypto is an > issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht > want to decrease. I am glad to be able to learn that now. > > > > > > 2018-06-22 5:48 GMT+09:00 Nick Banks dmarc.ietf.org>: > > Hello QUIC WG, > > > > I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided > to get some performance numbers to see what the overhead of PNE was. I > figured the rest of the WG might be interested. > > > > My test just encrypts the same buffer (size dependent on the test case) > 10,000,000 times and measured the time it took. The test then did the sam= e > thing, but also encrypted the packet number as well. I ran all that 10 > times in total. I then collected the best times for each category to > produce the following graphs and tables (full excel doc attached): > > > > > > > > *Time (ms)* > > *Rate (Mbps)* > > *Bytes* > > *NO PNE* > > *PNE* > > *PNE Overhead* > > *No PNE* > > *PNE* > > *4* > > 2284.671 > > 3027.657 > > 33% > > 140.064 > > 105.692 > > *16* > > 2102.402 > > 2828.204 > > 35% > > 608.827 > > 452.584 > > *64* > > 2198.883 > > 2907.577 > > 32% > > 2328.45 > > 1760.92 > > *256* > > 2758.3 > > 3490.28 > > 27% > > 7424.86 > > 5867.72 > > *600* > > 4669.283 > > 5424.539 > > 16% > > 10280 > > 8848.68 > > *1000* > > 6130.139 > > 6907.805 > > 13% > > 13050.3 > > 11581.1 > > *1200* > > 6458.679 > > 7229.672 > > 12% > > 14863.7 > > 13278.6 > > *1450* > > 7876.312 > > 8670.16 > > 10% > > 14727.7 > > 13379.2 > > > > I used a server grade lab machine I had at my disposal, running the lates= t > Windows 10 Server DataCenter build. Again, these numbers are for crypto > only. No QUIC or UDP is included. > > > > Thanks, > > - Nick > > > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > --=20 Kazuho Oku --00000000000004fe9a056f49b379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIUC, Ian should be talking about performance numbers that= you would see on a server that is handling real workload. Not the breakdow= n of numbers within the QUIC stack.

Let's talk about= nanoseconds per packet rather than the ratio, because ratio depends on wha= t you use as a "total" is.

My benchmarks= tell me that, on OpenSSL 1.1.0 running on Core i7 @ 2.5GHz (MacBook Pro 15= " Mid 2015), the numbers are:

without-PNE: 58= 5ns / packet
with-PNE: 607ns / packet (* this is the optimized ve= rsion with 3.8% overhead)

Assuming that your peak = rate is 1Gbit/CPU core (would be enough to saturate 25Gb Ethernet), the rat= io of CPU cycles for running the crypto will be:

a= ll crypto: 0.125GB/sec / 1280bytes/packet * 607ns/packet =3D 5.93 %
PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet =3D 0.22 %

Of course, these numbers are what is expected when a server= is sending or receiving full-sized packets in one direction. In reality, t= here would be at least some flow in the opposite direction, so the number w= ill be higher, but not as much as 2x. Or if you are sending small-sized pac= ket in *both* directions *and* saturating the link, the ratio will be highe= r.

But looking at the numbers, I&#= 39;d assume that 10% is a logical number for workload Ian has, and also for= people who are involved in content distribution.

As shown, I think that sharing = the PPS and average packet size that our workload will have, along with the= raw numbers of the crypto (i.e. nsec / packet) will give us a better under= standing on how much the actual overhead is. Do you mind sharing your expec= tations?

201= 8-06-23 9:34 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hey Guys,

=C2=A0

I spent the better part of the day getting some perf= ormance traces of WinQuic without PNE. Our implementation supports both user mode and kernel m= ode, so I got numbers for both. The following table shows the relative CPU = cost of different parts of the QUIC send path:

=C2=A0

=C2=A0

User Mode

Kernel Mode

UDP Send

64.7%

41.4%

Encryption

22.5%

38.5%

Packet Building/Framing

7%

15%

Miscellaneous

5.8%

5.1%

=C2=A0

These numbers definitely show that encryption is a m= uch larger portion of CPU.

=C2=A0

- Nick

=C2=A0

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, June 22, 2018 5:02 PM
To: Ian Swett <ianswett@google.com>
Cc: Nick Banks <nibanks@microsoft.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <= quic@ietf.org>


Subject: Re: Packet Number Encryption Performance

=C2=A0

=C2=A0

=C2=A0

2018-06-23 3:51 GMT+09:00 Ian Swett <ianswett@google.com>:

I expect crypto to increase as a fraction of CPU, bu= t I don't expect it to go much higher than 10%.

=C2=A0

But who knows, maybe 2 years from now everything els= e will be very optimized and crypto will be 15%?

=C2=A0

Ian, thank you for sharing the proportion of CPU cyc= les we are likely to spend for crypto.

=C2=A0

Your numbers relieves me, because even if the cost o= f crypto goes to 15%, the overhead of PNE will be less than 1% (0.15*0.04= =3D0.006).

=C2=A0

I would also like to note that it is likely that Hyp= erThreading, when used, will eliminate the overhead of PNE.

=C2=A0

This is because IIUC PNE is a marginal additional us= e of the AES-NI engine, which have been mostly idle. The overhead of crypto= is small (i.e. 15%) that we will rarely see contention on the engine. Whil= e one hyperthread does AES, the other hyperthread will run at full speed doing other operations.

=C2=A0

Also considering the fact that the number of CPU cyc= les spent per QUIC packet does not change a lot with PNE, I would not be su= rprised to see *no* decrease of throughput when PNE is used on a HyperThrea= ding architecture. In such case, what we will only observe is the raise of the utilization ratio of the AES-NI e= ngine.

=C2=A0

=C2=A0

On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <niba= nks=3D4= 0microsoft.com@dmarc.ietf.org> wrote:

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CT= R mode directly.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance <= /u>

=C2=A0

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep increasing over time as the network stack bottlene= cks are eliminated.

=C2=A0

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

=C2=A0

Thanks for digging into the details of this, Kazuho.= =C2=A0 <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still less than 0.5% total, which is acceptable to me.<= /u>

=C2=A0

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com= > wrote:

=C2=A0

=C2=A0

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:=

=C2=A0

=C2=A0

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&= gt;:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?

=C2=A0

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB = operation cost.

=C2=A0

It should be able to remove the costly abstraction l= ayer.

=C2=A0

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that should be possible to be nullified.

=C2=A0

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

=C2=A0

Just did some experiments and it seems that the expe= ctation was correct.

=C2=A0

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

=C2=A0

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

=C2=A0

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

=C2=A0

=C2=A0

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance <= /u>

=C2=A0

Hi Nick,

=C2=A0

Thank you for bringing the numbers to the list.

=C2=A0

I have just run a small benchmark using Quicly, and = I see comparable numbers.

=C2=A0

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparin= g the cost of encryption, the overhead ratio will be much smaller if we loo= k at the total number of CPU cycles spent by a QUIC stack as a whole.

=C2=A0

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the = AEAD interface, which is to be used by the QUIC stacks.

=C2=A0

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

=C2=A0

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that now.

=C2=A0

=C2=A0

2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks= =3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

=C2=A0

=C2=A0

=C2=A0

Time (ms)<= u>

Rate (Mbps)

Bytes

NO PNE<= /u>

PNE=

PNE Overhead

No PNE<= /u>

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku




--
Kazuho Oku
--00000000000004fe9a056f49b379-- From nobody Sat Jun 23 07:54:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA78A130E64 for ; Sat, 23 Jun 2018 07:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh-7NQK1nodK for ; Sat, 23 Jun 2018 07:54:18 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720098.outbound.protection.outlook.com [40.107.72.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB0E130E60 for ; Sat, 23 Jun 2018 07:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=na2pHscnkCO+/CiVoe9O1keH7aClgGrYSnFjyVWFBD8=; b=Lk32D45HCu1Ot9xnC5it8eGtt/v2YjyW++pBNOvHc3zXc9gpBOlYulKJj67rj0wARS+H5Np1zyAoLTa14NmwY5Y4xzNMKt2u7xXch7Qafc+ecq05b9ELKQiJ68DUoKnMjylRlHBDnOj6I0Fb0SEbRNKwkGjaAhjgtC50ZFv5YXM= Received: from MW2PR2101MB0908.namprd21.prod.outlook.com (52.132.152.28) by MW2PR2101MB0971.namprd21.prod.outlook.com (52.132.146.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.2; Sat, 23 Jun 2018 14:54:15 +0000 Received: from MW2PR2101MB0908.namprd21.prod.outlook.com ([fe80::b10b:34e9:2e4d:839d]) by MW2PR2101MB0908.namprd21.prod.outlook.com ([fe80::b10b:34e9:2e4d:839d%5]) with mapi id 15.20.0930.004; Sat, 23 Jun 2018 14:54:15 +0000 From: Nick Banks To: Kazuho Oku , IETF QUIC WG CC: Ian Swett , Praveen Balasubramanian Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgAAAjosmAATQHgAACtMrgAABFu2QAA2HWoAAECJDgA== Date: Sat, 23 Jun 2018 14:54:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-23T14:54:13.5885339Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8:656c:bd3d:ead:b82f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB0971; 7:O2dXOuu50g7dHS9+Z9ZSuyzrAtb8tM60CyBu2k2r1132zLrtQ2r2CgT3oDgJ/z4ggbcS8FwUOm7Lj1Sowi7CT+HkUtY8KmRYpgjK91zBrB7cWORRst48jAbPsH+LpcOVtH2zQyxmo5YtAsBX9mB6kq8wJZci8GVxaPWEv976Wu3vCW8FPqWFfQfEg7HDYfxhTNJPU6KcOX6AtQreDg3d7IJMFiJkWYSSaRiOQXsVqIeGSfdFhDmAQhkaIYYrt/3L x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ca6575ea-e4e8-4a22-21b2-08d5d9193089 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR2101MB0971; x-ms-traffictypediagnostic: MW2PR2101MB0971: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(211936372134217)(153496737603132)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR2101MB0971; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB0971; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(39380400002)(366004)(376002)(189003)(51444003)(199004)(5660300001)(39060400002)(6436002)(107886003)(6246003)(4326008)(6306002)(54896002)(55016002)(229853002)(19609705001)(6116002)(790700001)(9686003)(486006)(476003)(14454004)(3280700002)(8990500004)(11346002)(446003)(236005)(440504004)(606006)(5250100002)(517774005)(5890100001)(3660700001)(10090500001)(53946003)(2906002)(25786009)(5070765005)(53936002)(68736007)(10290500003)(86362001)(186003)(76176011)(345774005)(99286004)(478600001)(86612001)(7696005)(46003)(2900100001)(8936002)(59450400001)(74316002)(561924002)(3480700004)(33656002)(6506007)(97736004)(7736002)(53546011)(110136005)(966005)(316002)(54906003)(22452003)(105586002)(81156014)(93886005)(81166006)(8676002)(102836004)(106356001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0971; H:MW2PR2101MB0908.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QWR52Va/09PdtcsVjG6/EoYRbPjAyPiS0j0Avm+xz2J/T3O3Y1W6aU4AC7zbWI9ydyAxS9YMNs8ofo7rAy+6cwQkD2G8n6KPDuSJKhdmYOChiaQSvCZ6R4pU/ujbjCOlZWVED2nSnzTuDOHQUQwKkwfyp2PbATNleob/GpgfquR6Wi/qmqWOsInSOywnDxNntTwCq0uJJ7+3539jErQ6etKBMkAZTI4WDK3vGHc8Agj2TzuaJJKi2pagxKd4UI1RGnxzzOobfGQud4Yinp8bewWVGqSGICSsi6UOZkINQJzxQ4idNg0ypHVLeQ/mjo+/+HSGQFQjTGJuCwzgTHKY3hI2w2JZRgBS3B1BJyFDsaI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB0908B9F435EC23FB9152DC3BB3740MW2PR2101MB0908_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca6575ea-e4e8-4a22-21b2-08d5d9193089 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 14:54:15.2795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0971 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 14:54:24 -0000 --_000_MW2PR2101MB0908B9F435EC23FB9152DC3BB3740MW2PR2101MB0908_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoZSBudW1iZXJzIGZvciByZWFsIHdvcmsgbG9hZHMgd2lsbCBiZSBpbnRl cmVzdGluZywgYnV0IEkgZG8gYmVsaWV2ZSB0aGF0IHJhdyBRVUlDIHN0YWNrIG51bWJlcnMgYXJl IGFsc28gaW1wb3J0YW50LiBUaGV5IHdpbGwgcmVwcmVzZW50IHlvdXIgYmVzdCBjYXNlIHNjZW5h cmlvLg0KDQpGb3IgbXkgdGVzdGluZywgSSBoYXZlIGEgZmFpcmx5IHNpbXBsZSB0ZXN0IG9mIG9w ZW5pbmcgYSBzaW5nbGUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtIGFuZCBqdXN0IGNvbnRpbnVhbGx5 IHNlbmRpbmcgZGF0YSB1bnRpbCB0aGUgY29yZSBnZXRzIHNhdHVyYXRlZC4gRnJvbSB0aGF0LCBJ IGdyYWIgdGhlIHBlcmZvcm1hbmNlIHRyYWNlLCBhbmQgc3BlY2lmaWNhbGx5IGxvb2sgYXQgdGhl IGNvbXBvc2l0aW9uIG9mIHRoZSBRVUlDIHN0YWNr4oCZcyBzZW5kIHBhdGguIFRoZSBzZW5kIHBh dGggY29uc3RpdHV0ZXMgZ2VuZXJhbGx5IGFsbCBvZiB0aGUgQ1BVIGZvciB0aGUgd2hvbGUgY29u bmVjdGlvbiBhbnl3YXlzICh3aXRoIGp1c3QgYSBsaXR0bGUgb3ZlcmhlYWQgc2VlbiBmcm9tIHJl Y2VpdmluZyBhbmQgcHJvY2Vzc2luZyBBQ0tzKS4gVGhlIG1hY2hpbmUgSSB1c2VkIHdhcyBhbm90 aGVyIHNlcnZlciBncmFkZSBtYWNoaW5lIHJ1bm5pbmcgdGhlIGxhdGVzdCBXaW5kb3dzIDEwIFNl cnZlciBEYXRhY2VudGVyLg0KDQpTbyB0aGUgcGVyY2VudGFnZXMgSSBzaGFyZWQgYXJlIGZvciBq dXN0IHRoZSBRVUlDIHNlbmQgcGF0aCAoYWdhaW4sIG5vIFBORSB3aXRoIHRoZXNlIG51bWJlcnMp LiBUaGUgbnVtYmVycyBhcmUgZm9yIHRoZSBwZXJjZW50YWdlIG9mIHRvdGFsIENQVSBmb3IgYWxs IHBhY2tldHMgc2VudCwgYnV0IHNpbmNlIGFsbCBwYWNrZXRzIHdlcmUgcHJldHR5IG11Y2ggdGhl IHNhbWUgc2l6ZSwgdGhlIG51bWJlcnMgc2hvdWxkIHN0aWxsIGhvbGQgZm9yIGEgc2luZ2xlIHBh Y2tldC4gQW5kIGJvdHRvbSBsaW5lLCBlbmNyeXB0aW9uIGlzIGEgbG90IG1vcmUgb2YgYW4gaW1w YWN0IHRoYW4gMTAlLiBBbmQgYXMgd2UgYnJpbmcgaW4gbW9yZSBwZXJmb3JtYW5jZSBpbXByb3Zl bWVudHMgZm9yIFVEUCBzZW5kIHBhdGggaW4gV2luZG93cywgd2UgZXhwZWN0IGVuY3J5cHRpb24g dG8gYmUgaGlnaGVyIGFuZCBoaWdoZXIgcGVyY2VudGFnZS4NCg0KLSBOaWNrDQoNCkZyb206IEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTZW50OiBTYXR1cmRheSwgSnVuZSAyMywg MjAxOCAxMjowMCBBTQ0KVG86IE5pY2sgQmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbT4NCkNj OiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NClN1 YmplY3Q6IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2UNCg0KSUlVQywg SWFuIHNob3VsZCBiZSB0YWxraW5nIGFib3V0IHBlcmZvcm1hbmNlIG51bWJlcnMgdGhhdCB5b3Ug d291bGQgc2VlIG9uIGEgc2VydmVyIHRoYXQgaXMgaGFuZGxpbmcgcmVhbCB3b3JrbG9hZC4gTm90 IHRoZSBicmVha2Rvd24gb2YgbnVtYmVycyB3aXRoaW4gdGhlIFFVSUMgc3RhY2suDQoNCkxldCdz IHRhbGsgYWJvdXQgbmFub3NlY29uZHMgcGVyIHBhY2tldCByYXRoZXIgdGhhbiB0aGUgcmF0aW8s IGJlY2F1c2UgcmF0aW8gZGVwZW5kcyBvbiB3aGF0IHlvdSB1c2UgYXMgYSAidG90YWwiIGlzLg0K DQpNeSBiZW5jaG1hcmtzIHRlbGwgbWUgdGhhdCwgb24gT3BlblNTTCAxLjEuMCBydW5uaW5nIG9u IENvcmUgaTcgQCAyLjVHSHogKE1hY0Jvb2sgUHJvIDE1IiBNaWQgMjAxNSksIHRoZSBudW1iZXJz IGFyZToNCg0Kd2l0aG91dC1QTkU6IDU4NW5zIC8gcGFja2V0DQp3aXRoLVBORTogNjA3bnMgLyBw YWNrZXQgKCogdGhpcyBpcyB0aGUgb3B0aW1pemVkIHZlcnNpb24gd2l0aCAzLjglIG92ZXJoZWFk KQ0KDQpBc3N1bWluZyB0aGF0IHlvdXIgcGVhayByYXRlIGlzIDFHYml0L0NQVSBjb3JlICh3b3Vs ZCBiZSBlbm91Z2ggdG8gc2F0dXJhdGUgMjVHYiBFdGhlcm5ldCksIHRoZSByYXRpbyBvZiBDUFUg Y3ljbGVzIGZvciBydW5uaW5nIHRoZSBjcnlwdG8gd2lsbCBiZToNCg0KYWxsIGNyeXB0bzogMC4x MjVHQi9zZWMgLyAxMjgwYnl0ZXMvcGFja2V0ICogNjA3bnMvcGFja2V0ID0gNS45MyAlDQpQTkU6 IDAuMTI1R0Ivc2VjIC8gMTI4MGJ5dGVzL3BhY2tldCAqIDIyLjRucy9wYWNrZXQgPSAwLjIyICUN Cg0KT2YgY291cnNlLCB0aGVzZSBudW1iZXJzIGFyZSB3aGF0IGlzIGV4cGVjdGVkIHdoZW4gYSBz ZXJ2ZXIgaXMgc2VuZGluZyBvciByZWNlaXZpbmcgZnVsbC1zaXplZCBwYWNrZXRzIGluIG9uZSBk aXJlY3Rpb24uIEluIHJlYWxpdHksIHRoZXJlIHdvdWxkIGJlIGF0IGxlYXN0IHNvbWUgZmxvdyBp biB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLCBzbyB0aGUgbnVtYmVyIHdpbGwgYmUgaGlnaGVyLCBi dXQgbm90IGFzIG11Y2ggYXMgMnguIE9yIGlmIHlvdSBhcmUgc2VuZGluZyBzbWFsbC1zaXplZCBw YWNrZXQgaW4gKmJvdGgqIGRpcmVjdGlvbnMgKmFuZCogc2F0dXJhdGluZyB0aGUgbGluaywgdGhl IHJhdGlvIHdpbGwgYmUgaGlnaGVyLg0KDQpCdXQgbG9va2luZyBhdCB0aGUgbnVtYmVycywgSSdk IGFzc3VtZSB0aGF0IDEwJSBpcyBhIGxvZ2ljYWwgbnVtYmVyIGZvciB3b3JrbG9hZCBJYW4gaGFz LCBhbmQgYWxzbyBmb3IgcGVvcGxlIHdobyBhcmUgaW52b2x2ZWQgaW4gY29udGVudCBkaXN0cmli dXRpb24uDQoNCkFzIHNob3duLCBJIHRoaW5rIHRoYXQgc2hhcmluZyB0aGUgUFBTIGFuZCBhdmVy YWdlIHBhY2tldCBzaXplIHRoYXQgb3VyIHdvcmtsb2FkIHdpbGwgaGF2ZSwgYWxvbmcgd2l0aCB0 aGUgcmF3IG51bWJlcnMgb2YgdGhlIGNyeXB0byAoaS5lLiBuc2VjIC8gcGFja2V0KSB3aWxsIGdp dmUgdXMgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvbiBob3cgbXVjaCB0aGUgYWN0dWFsIG92ZXJo ZWFkIGlzLiBEbyB5b3UgbWluZCBzaGFyaW5nIHlvdXIgZXhwZWN0YXRpb25zPw0KDQoyMDE4LTA2 LTIzIDk6MzQgR01UKzA5OjAwIE5pY2sgQmFua3MgPG5pYmFua3NAbWljcm9zb2Z0LmNvbTxtYWls dG86bmliYW5rc0BtaWNyb3NvZnQuY29tPj46DQpIZXkgR3V5cywNCg0KSSBzcGVudCB0aGUgYmV0 dGVyIHBhcnQgb2YgdGhlIGRheSBnZXR0aW5nIHNvbWUgcGVyZm9ybWFuY2UgdHJhY2VzIG9mIFdp blF1aWMgd2l0aG91dCBQTkUuIE91ciBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3RoIHVzZXIg bW9kZSBhbmQga2VybmVsIG1vZGUsIHNvIEkgZ290IG51bWJlcnMgZm9yIGJvdGguIFRoZSBmb2xs b3dpbmcgdGFibGUgc2hvd3MgdGhlIHJlbGF0aXZlIENQVSBjb3N0IG9mIGRpZmZlcmVudCBwYXJ0 cyBvZiB0aGUgUVVJQyBzZW5kIHBhdGg6DQoNCg0KDQpVc2VyIE1vZGUNCg0KS2VybmVsIE1vZGUN Cg0KVURQIFNlbmQNCg0KNjQuNyUNCg0KNDEuNCUNCg0KRW5jcnlwdGlvbg0KDQoyMi41JQ0KDQoz OC41JQ0KDQpQYWNrZXQgQnVpbGRpbmcvRnJhbWluZw0KDQo3JQ0KDQoxNSUNCg0KTWlzY2VsbGFu ZW91cw0KDQo1LjglDQoNCjUuMSUNCg0KDQpUaGVzZSBudW1iZXJzIGRlZmluaXRlbHkgc2hvdyB0 aGF0IGVuY3J5cHRpb24gaXMgYSBtdWNoIGxhcmdlciBwb3J0aW9uIG9mIENQVS4NCg0KLSBOaWNr DQoNCg0KRnJvbTogS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhv b2t1QGdtYWlsLmNvbT4+DQpTZW50OiBGcmlkYXksIEp1bmUgMjIsIDIwMTggNTowMiBQTQ0KVG86 IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv bT4+DQpDYzogTmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPG1haWx0bzpuaWJhbmtz QG1pY3Jvc29mdC5jb20+PjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29m dC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFBhY2tldCBOdW1i ZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZQ0KDQoNCg0KMjAxOC0wNi0yMyAzOjUxIEdNVCswOTow MCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5j b20+PjoNCkkgZXhwZWN0IGNyeXB0byB0byBpbmNyZWFzZSBhcyBhIGZyYWN0aW9uIG9mIENQVSwg YnV0IEkgZG9uJ3QgZXhwZWN0IGl0IHRvIGdvIG11Y2ggaGlnaGVyIHRoYW4gMTAlLg0KDQpCdXQg d2hvIGtub3dzLCBtYXliZSAyIHllYXJzIGZyb20gbm93IGV2ZXJ5dGhpbmcgZWxzZSB3aWxsIGJl IHZlcnkgb3B0aW1pemVkIGFuZCBjcnlwdG8gd2lsbCBiZSAxNSU/DQoNCklhbiwgdGhhbmsgeW91 IGZvciBzaGFyaW5nIHRoZSBwcm9wb3J0aW9uIG9mIENQVSBjeWNsZXMgd2UgYXJlIGxpa2VseSB0 byBzcGVuZCBmb3IgY3J5cHRvLg0KDQpZb3VyIG51bWJlcnMgcmVsaWV2ZXMgbWUsIGJlY2F1c2Ug ZXZlbiBpZiB0aGUgY29zdCBvZiBjcnlwdG8gZ29lcyB0byAxNSUsIHRoZSBvdmVyaGVhZCBvZiBQ TkUgd2lsbCBiZSBsZXNzIHRoYW4gMSUgKDAuMTUqMC4wND0wLjAwNikuDQoNCkkgd291bGQgYWxz byBsaWtlIHRvIG5vdGUgdGhhdCBpdCBpcyBsaWtlbHkgdGhhdCBIeXBlclRocmVhZGluZywgd2hl biB1c2VkLCB3aWxsIGVsaW1pbmF0ZSB0aGUgb3ZlcmhlYWQgb2YgUE5FLg0KDQpUaGlzIGlzIGJl Y2F1c2UgSUlVQyBQTkUgaXMgYSBtYXJnaW5hbCBhZGRpdGlvbmFsIHVzZSBvZiB0aGUgQUVTLU5J IGVuZ2luZSwgd2hpY2ggaGF2ZSBiZWVuIG1vc3RseSBpZGxlLiBUaGUgb3ZlcmhlYWQgb2YgY3J5 cHRvIGlzIHNtYWxsIChpLmUuIDE1JSkgdGhhdCB3ZSB3aWxsIHJhcmVseSBzZWUgY29udGVudGlv biBvbiB0aGUgZW5naW5lLiBXaGlsZSBvbmUgaHlwZXJ0aHJlYWQgZG9lcyBBRVMsIHRoZSBvdGhl ciBoeXBlcnRocmVhZCB3aWxsIHJ1biBhdCBmdWxsIHNwZWVkIGRvaW5nIG90aGVyIG9wZXJhdGlv bnMuDQoNCkFsc28gY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCB0aGUgbnVtYmVyIG9mIENQVSBj eWNsZXMgc3BlbnQgcGVyIFFVSUMgcGFja2V0IGRvZXMgbm90IGNoYW5nZSBhIGxvdCB3aXRoIFBO RSwgSSB3b3VsZCBub3QgYmUgc3VycHJpc2VkIHRvIHNlZSAqbm8qIGRlY3JlYXNlIG9mIHRocm91 Z2hwdXQgd2hlbiBQTkUgaXMgdXNlZCBvbiBhIEh5cGVyVGhyZWFkaW5nIGFyY2hpdGVjdHVyZS4g SW4gc3VjaCBjYXNlLCB3aGF0IHdlIHdpbGwgb25seSBvYnNlcnZlIGlzIHRoZSByYWlzZSBvZiB0 aGUgdXRpbGl6YXRpb24gcmF0aW8gb2YgdGhlIEFFUy1OSSBlbmdpbmUuDQoNCg0KT24gRnJpLCBK dW4gMjIsIDIwMTggYXQgMTI6MzQgUE0gTmljayBCYW5rcyA8bmliYW5rcz00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KSSBqdXN0IHdhbnQgdG8gYWRkLCBteSBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5IHVz ZXMgRUNCIGZyb20gYmNyeXB0IChhbmQgSSBkbyB0aGUgWE9SKSBhbHJlYWR5LiBCY3J5cHQgZG9l c27igJl0IGV4cG9zZSBDVFIgbW9kZSBkaXJlY3RseS4NCg0KU2VudCBmcm9tIE1haWw8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZnby5taWNyb3NvZnQuY29tJTJGZndsaW5rJTJGJTNGTGlua0lkJTNENTUwOTg2JmRhdGE9MDIl N0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDZTZlZmEzNjNiYzI1NDcxNjdhOGMwOGQ1 ZDg5YzgwZTclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 NjUzMDg5MDU5MjY4ODM2JnNkYXRhPWFlVTdqNWxoQ0lNMThLRzVjNm9wRzRwN2Ftd2hDV2JSbmZu bThzRFc3aGMlM0QmcmVzZXJ2ZWQ9MD4gZm9yIFdpbmRvd3MgMTANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBG cmlkYXksIEp1bmUgMjIsIDIwMTggOToyNjo0NCBBTQ0KVG86IElhbiBTd2V0dDsgS2F6dWhvIE9r dQ0KQ2M6IE5pY2sgQmFua3M7IElFVEYgUVVJQyBXRw0KU3ViamVjdDogUkU6IFBhY2tldCBOdW1i ZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZQ0KDQpJYW4sIGRvIHlvdSBleHBlY3QgdGhhdCBmcmFj dGlvbiBvZiBvdmVyYWxsIGNvc3QgdG8gaG9sZCBvbmNlIHRoZSBVRFAgc3RhY2sgaXMgb3B0aW1p emVkPyBJcyB5b3VyIG1lYXN1cmVtZW50IG9uIHRvcCBvZiB0aGUgcmVjZW50IGtlcm5lbCBpbXBy b3ZlbWVudHM/IEkgZXhwZWN0IGNyeXB0byBmcmFjdGlvbiBvZiBvdmVyYWxsIGNvc3QgdG8ga2Vl cCBpbmNyZWFzaW5nIG92ZXIgdGltZSBhcyB0aGUgbmV0d29yayBzdGFjayBib3R0bGVuZWNrcyBh cmUgZWxpbWluYXRlZC4NCg0KS2F6dWhvLCBzaG91bGQgdGhlIGRyYWZ0IGRlc2NyaWJlIHRoZSBv cHRpbWl6YXRpb25zIHlvdSBhcmUgbWFraW5nPyBPciBhcmUgdGhlc2UgYXJlIHRvbyBPcGVuU1NM IHNwZWNpZmljPw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSWFuIFN3ZXR0DQpTZW50 OiBGcmlkYXksIEp1bmUgMjIsIDIwMTggNDo0NSBBTQ0KVG86IEthenVobyBPa3UgPGthenVob29r dUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KQ2M6IE5pY2sgQmFua3Mg PG5pYmFua3NAbWljcm9zb2Z0LmNvbTxtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tPj47IElF VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSZTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNlDQoNClRoYW5rcyBmb3Ig ZGlnZ2luZyBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoaXMsIEthenVoby4gIDw0JSBpbmNyZWFzZSBp biBjcnlwdG8gY29zdCBpcyBhIGJpdCBtb3JlIHRoYW4gSSBvcmlnaW5hbGx5IGV4cGVjdGVkKH4y JSksIGJ1dCBjcnlwdG8gaXMgbGVzcyB0aGFuIDEwJSBvZiBteSBDUFUgdXNhZ2UsIHNvIGl0J3Mg c3RpbGwgbGVzcyB0aGFuIDAuNSUgdG90YWwsIHdoaWNoIGlzIGFjY2VwdGFibGUgdG8gbWUuDQoN Ck9uIEZyaSwgSnVuIDIyLCAyMDE4IGF0IDI6NDUgQU0gS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdt YWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCjIwMTgtMDYt MjIgMTI6MjIgR01UKzA5OjAwIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRv OmthenVob29rdUBnbWFpbC5jb20+PjoNCg0KDQoyMDE4LTA2LTIyIDExOjU0IEdNVCswOTowMCBO aWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb208bWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0 LmNvbT4+Og0KSGkgS2F6dWhvLA0KDQpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciBudW1iZXJzIGFz IHdlbGwhIEknbSBiaXQgY29uZnVzZWQgd2hlcmUgeW91IHNheSB5b3UgY2FuIHJlZHVjZSB0aGUg MTAlIG92ZXJoZWFkIHRvIDIlIHRvIDQlLiBIb3cgZG8geW91IHBsYW4gb24gZG9pbmcgdGhhdD8N Cg0KQXMgc3RhdGVkIGluIG15IHByZXZpb3VzIG1haWwsIHRoZSAxMCUgb2Ygb3ZlcmhlYWQgY29u c2lzdHMgb2YgdGhyZWUgcGFydHMsIGVhY2ggY29uc3VtaW5nIGNvbXBhcmFibGUgbnVtYmVyIG9m IENQVSBjeWNsZXMuIFRoZSB0d28gYW1vbmcgdGhlIHRocmVlIGlzIHJlbGF0ZWQgdG8gdGhlIGFi c3RyYWN0aW9uIGxheWVyIGFuZCBob3cgQ1RSIGlzIGltcGxlbWVudGVkLCB3aGlsZSB0aGUgb3Ro ZXIgb25lIGlzIHRoZSBjb3JlIEFFUy1FQ0Igb3BlcmF0aW9uIGNvc3QuDQoNCkl0IHNob3VsZCBi ZSBhYmxlIHRvIHJlbW92ZSB0aGUgY29zdGx5IGFic3RyYWN0aW9uIGxheWVyLg0KDQpJdCBzaG91 bGQgYWxzbyBiZSBwb3NzaWJsZSB0byByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiwgc2luY2Ug aW4gUE5FLCB3ZSBuZWVkIHRvIFhPUiBhdCBtb3N0IDQgb2N0ZXRzIChhcHBseWluZyBYT1IgaXMg dGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIENUUiBhbmQgRUNCKS4gVGhhdCBjb3N0IHNob3Vs ZCBiZSBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgcG9zc2libGUgdG8gYmUgbnVsbGlmaWVkLg0K DQpDb25zaWRlcmluZyB0aGVzZSBhc3BlY3RzLCBhbmQgYnkgbG9va2luZyBhdCB0aGUgbnVtYmVy cyBvbiB0aGUgT3BlblNTTCBzb3VyY2UgY29kZSAoYXMgd2VsbCBhcyBjb25zaWRlcmluZyB0aGUg b3ZlcmhlYWQgb2YgR0NNKSwgbXkgZXhwZWN0YXRpb24gZ29lcyB0byAyJSB0byA0JS4NCg0KSnVz dCBkaWQgc29tZSBleHBlcmltZW50cyBhbmQgaXQgc2VlbXMgdGhhdCB0aGUgZXhwZWN0YXRpb24g d2FzIGNvcnJlY3QuDQoNClRoZSBiZW5jaG1hcmtzIHRlbGwgbWUgdGhhdCB0aGUgb3ZlcmhlYWQg Z29lcyBkb3duIGZyb20gMTAuMCUgdG8gMy44JSwgYnkgZG9pbmcgdGhlIGZvbGxvd2luZzoNCg0K KiByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiBhYnN0cmFjdGlvbiAoaS5lLiB1c2UgdGhlIEVD QiBiYWNrZW5kIGFuZCBkbyBYT1IgYnkgb3Vyc2VsdmVzKQ0KKiByZW1vdmUgdGhlIG92ZXJoZWFk IG9mIHRoZSBhYnN0cmFjdGlvbiBsYXllciAoaS5lLiBjYWxsIHRoZSBtZXRob2QgcmV0dXJuZWQg YnkgRVZQX0NJUEhFUl9tZXRoX2dldF9kb19jaXBoZXIgaW5zdGVhZCBvZiBjYWxsaW5nIEVWUF9F bmNyeXB0VXBkYXRlKQ0KDQpPZiBjb3Vyc2UgdGhlIGNoYW5nZXMgYXJlIHNwZWNpZmljIHRvIE9w ZW5TU0wsIGJ1dCBJIHdvdWxkIGV4cGVjdCB0aGF0IHlvdSBjYW4gZXhwZWN0IHNpbWlsYXIgbnVt YmVycyBhc3N1bWluZyB0aGF0IHlvdSBoYXZlIGFjY2VzcyB0byBhbiBvcHRpbWl6ZWQgQUVTIGlt cGxlbWVudGF0aW9uLg0KDQoNCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmUNCltIeFMg LSAxNTI1NCAtIDE2LjAuMTAyMjguMjAwNzVdDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1 aG9va3VAZ21haWwuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDIxLCAyMDE4IDc6MjE6MTcg UE0NClRvOiBOaWNrIEJhbmtzDQpDYzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2UNCg0K SGkgTmljaywNCg0KVGhhbmsgeW91IGZvciBicmluZ2luZyB0aGUgbnVtYmVycyB0byB0aGUgbGlz dC4NCg0KSSBoYXZlIGp1c3QgcnVuIGEgc21hbGwgYmVuY2htYXJrIHVzaW5nIFF1aWNseSwgYW5k IEkgc2VlIGNvbXBhcmFibGUgbnVtYmVycy4NCg0KVG8gYmUgcHJlY2lzZSwgSSBzZWUgMTAuMCUg aW5jcmVhc2Ugb2YgQ1BVIGN5Y2xlcyB3aGVuIGVuY3J5cHRpbmcgYSBJbml0aWFsIHBhY2tldCBv ZiAxLDI4MCBvY3RldHMuIEkgZXhwZWN0IHRoYXQgd2Ugd2lsbCBzZWUgc2ltaWxhciBudW1iZXJz IG9uIG90aGVyIFFVSUMgc3RhY2tzIHRoYXQgYWxzbyB1c2UgcGljb3RscyAod2l0aCBPcGVuU1NM IGFzIGEgYmFja2VuZCkuIE5vdGUgdGhhdCB0aGUgbnVtYmVyIGlzIG9ubHkgY29tcGFyaW5nIHRo ZSBjb3N0IG9mIGVuY3J5cHRpb24sIHRoZSBvdmVyaGVhZCByYXRpbyB3aWxsIGJlIG11Y2ggc21h bGxlciBpZiB3ZSBsb29rIGF0IHRoZSB0b3RhbCBudW1iZXIgb2YgQ1BVIGN5Y2xlcyBzcGVudCBi eSBhIFFVSUMgc3RhY2sgYXMgYSB3aG9sZS4NCg0KTG9va2luZyBhdCB0aGUgcHJvZmlsZSwgdGhl IG92ZXJoZWFkIGNvbnNpc3RzIG9mIHRocmVlIG9wZXJhdGlvbnMgdGhhdCBlYWNoIGNvbnN1bWVz IGNvbXBhcmFibGUgQ1BVIGN5Y2xlczogY29yZSBBRVMgb3BlcmF0aW9uICh1c2luZyBBRVMtTkkp LCBDVFIgb3BlcmF0aW9uIG92ZXJoZWFkLCBDVFIgaW5pdGlhbGl6YXRpb24uIE5vdGUgdGhhdCBw aWNvdGxzIGF0IHRoZSBtb21lbnQgcHJvdmlkZXMgYWNjZXNzIHRvIENUUiBjcnlwdG8gYmVuZWF0 aCB0aGUgQUVBRCBpbnRlcmZhY2UsIHdoaWNoIGlzIHRvIGJlIHVzZWQgYnkgdGhlIFFVSUMgc3Rh Y2tzLg0KDQpJIHdvdWxkIGFzc3VtZSB0aGF0IHdlIGNhbiBjdXQgZG93biB0aGUgb3ZlcmhlYWQg dG8gc29tZXdoZXJlIGJldHdlZW4gMiUgdG8gNCUsIGJ1dCBpdCBtaWdodCBiZSBoYXJkIHRvIGdv IGRvd24gdG8gc29tZXdoZXJlIG5lYXIgMSUsIGJlY2F1c2Ugd2UgY2Fubm90IHBhcmFsbGVsaXpl IHRoZSBBRVMgb3BlcmF0aW9uIG9mIFBORSB3aXRoIHRoYXQgb2YgQUVBRCAoc2VlIGh0dHBzOi8v Z2l0aHViLmNvbS9vcGVuc3NsL29wZW5zc2wvYmxvYi9PcGVuU1NMXzFfMV8waC9jcnlwdG8vYWVz L2FzbS9hZXNuaS14ODZfNjQucGwjTDI0LUwzOTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZvcGVuc3Ns JTJGb3BlbnNzbCUyRmJsb2IlMkZPcGVuU1NMXzFfMV8waCUyRmNyeXB0byUyRmFlcyUyRmFzbSUy RmFlc25pLXg4Nl82NC5wbCUyM0wyNC1MMzkmZGF0YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jv c29mdC5jb20lN0MxMWQ1NWYxNzMzM2U0YTc5NWQ3MDA4ZDVkN2U2ZDkzYyU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTIzMDg4NDM5OTQxMzQmc2RhdGE9 a3FNejRTc04lMkYyRXJHSzA2UXo4WjB2VXpwbDRNaWlwbk5FMndBTVViNDZjJTNEJnJlc2VydmVk PTA+IGFib3V0IHRoZSBpbXBhY3Qgb2YgcGFyYWxsZWxpemF0aW9uKS4NCg0KSSBkbyBub3QgdGhp bmsgdGhhdCAyJSB0byA0JSBvZiBhZGRpdGlvbmFsIG92ZXJoZWFkIHRvIHRoZSBjcnlwdG8gaXMg YW4gaXNzdWUgZm9yIFFVSUMvSFRUUCwgYnV0IGN1cnJlbnQgb3ZlcmhlYWQgb2YgMTAlIGlzIHNv bWV0aGluZyB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZGVjcmVhc2UuIEkgYW0gZ2xhZCB0byBiZSBh YmxlIHRvIGxlYXJuIHRoYXQgbm93Lg0KDQoNCjIwMTgtMDYtMjIgNTo0OCBHTVQrMDk6MDAgTmlj ayBCYW5rcyA8bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOm5p YmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj46DQpIZWxsbyBRVUlDIFdHLA0K DQpJIHJlY2VudGx5IGltcGxlbWVudGVkIFBORSBmb3IgV2luUXVpYyAodXNpbmcgYmNyeXB0IEFQ SXMpIGFuZCBJIGRlY2lkZWQgdG8gZ2V0IHNvbWUgcGVyZm9ybWFuY2UgbnVtYmVycyB0byBzZWUg d2hhdCB0aGUgb3ZlcmhlYWQgb2YgUE5FIHdhcy4gSSBmaWd1cmVkIHRoZSByZXN0IG9mIHRoZSBX RyBtaWdodCBiZSBpbnRlcmVzdGVkLg0KDQpNeSB0ZXN0IGp1c3QgZW5jcnlwdHMgdGhlIHNhbWUg YnVmZmVyIChzaXplIGRlcGVuZGVudCBvbiB0aGUgdGVzdCBjYXNlKSAxMCwwMDAsMDAwIHRpbWVz IGFuZCBtZWFzdXJlZCB0aGUgdGltZSBpdCB0b29rLiBUaGUgdGVzdCB0aGVuIGRpZCB0aGUgc2Ft ZSB0aGluZywgYnV0IGFsc28gZW5jcnlwdGVkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHdlbGwuIEkg cmFuIGFsbCB0aGF0IDEwIHRpbWVzIGluIHRvdGFsLiBJIHRoZW4gY29sbGVjdGVkIHRoZSBiZXN0 IHRpbWVzIGZvciBlYWNoIGNhdGVnb3J5IHRvIHByb2R1Y2UgdGhlIGZvbGxvd2luZyBncmFwaHMg YW5kIHRhYmxlcyAoZnVsbCBleGNlbCBkb2MgYXR0YWNoZWQpOg0KDQoNCg0KDQpUaW1lIChtcykN Cg0KUmF0ZSAoTWJwcykNCg0KQnl0ZXMNCg0KTk8gUE5FDQoNClBORQ0KDQpQTkUgT3ZlcmhlYWQN Cg0KTm8gUE5FDQoNClBORQ0KDQo0DQoNCjIyODQuNjcxDQoNCjMwMjcuNjU3DQoNCjMzJQ0KDQox NDAuMDY0DQoNCjEwNS42OTINCg0KMTYNCg0KMjEwMi40MDINCg0KMjgyOC4yMDQNCg0KMzUlDQoN CjYwOC44MjcNCg0KNDUyLjU4NA0KDQo2NA0KDQoyMTk4Ljg4Mw0KDQoyOTA3LjU3Nw0KDQozMiUN Cg0KMjMyOC40NQ0KDQoxNzYwLjkyDQoNCjI1Ng0KDQoyNzU4LjMNCg0KMzQ5MC4yOA0KDQoyNyUN Cg0KNzQyNC44Ng0KDQo1ODY3LjcyDQoNCjYwMA0KDQo0NjY5LjI4Mw0KDQo1NDI0LjUzOQ0KDQox NiUNCg0KMTAyODANCg0KODg0OC42OA0KDQoxMDAwDQoNCjYxMzAuMTM5DQoNCjY5MDcuODA1DQoN CjEzJQ0KDQoxMzA1MC4zDQoNCjExNTgxLjENCg0KMTIwMA0KDQo2NDU4LjY3OQ0KDQo3MjI5LjY3 Mg0KDQoxMiUNCg0KMTQ4NjMuNw0KDQoxMzI3OC42DQoNCjE0NTANCg0KNzg3Ni4zMTINCg0KODY3 MC4xNg0KDQoxMCUNCg0KMTQ3MjcuNw0KDQoxMzM3OS4yDQoNCg0KSSB1c2VkIGEgc2VydmVyIGdy YWRlIGxhYiBtYWNoaW5lIEkgaGFkIGF0IG15IGRpc3Bvc2FsLCBydW5uaW5nIHRoZSBsYXRlc3Qg V2luZG93cyAxMCBTZXJ2ZXIgRGF0YUNlbnRlciBidWlsZC4gQWdhaW4sIHRoZXNlIG51bWJlcnMg YXJlIGZvciBjcnlwdG8gb25seS4gTm8gUVVJQyBvciBVRFAgaXMgaW5jbHVkZWQuDQoNClRoYW5r cywNCi0gTmljaw0KDQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQoNCg0KLS0NCkthenVobyBPa3UN Cg0KDQoNCi0tDQpLYXp1aG8gT2t1DQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQoNCg0KLS0NCkth enVobyBPa3UNCg== --_000_MW2PR2101MB0908B9F435EC23FB9152DC3BB3740MW2PR2101MB0908_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmdt YWlsLW02ODg2OTg2OTg5NjczMjk5MTg0bS04NDgyMjk2MzM5ODUyNTcxMjY5bS04NDA4ODQ3NDI3 MDkzMjIzNDc2bS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsLW1fNjg4Njk4Njk4OTY3MzI5OTE4NG0tODQ4MjI5NjMzOTg1MjU3MTI2OW0tODQwODg0NzQy NzA5MzIyMzQ3Nm0tNjI4MjQ5OTg2MTMzNDEwNDA1MWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBhZ3JlZSB0aGF0IHRoZSBudW1iZXJzIGZvciByZWFsIHdvcmsgbG9hZHMgd2lsbCBi ZSBpbnRlcmVzdGluZywgYnV0IEkgZG8gYmVsaWV2ZSB0aGF0IHJhdyBRVUlDIHN0YWNrIG51bWJl cnMgYXJlIGFsc28gaW1wb3J0YW50LiBUaGV5IHdpbGwgcmVwcmVzZW50IHlvdXIgYmVzdCBjYXNl IHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgbXkgdGVzdGluZywgSSBoYXZl IGEgZmFpcmx5IHNpbXBsZSB0ZXN0IG9mIG9wZW5pbmcgYSBzaW5nbGUgdW5pZGlyZWN0aW9uYWwg c3RyZWFtIGFuZCBqdXN0IGNvbnRpbnVhbGx5IHNlbmRpbmcgZGF0YSB1bnRpbCB0aGUgY29yZSBn ZXRzIHNhdHVyYXRlZC4gRnJvbSB0aGF0LCBJIGdyYWIgdGhlIHBlcmZvcm1hbmNlIHRyYWNlLCBh bmQgc3BlY2lmaWNhbGx5IGxvb2sgYXQgdGhlIGNvbXBvc2l0aW9uIG9mDQogdGhlIFFVSUMgc3Rh Y2vigJlzIHNlbmQgcGF0aC4gVGhlIHNlbmQgcGF0aCBjb25zdGl0dXRlcyBnZW5lcmFsbHkgYWxs IG9mIHRoZSBDUFUgZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uIGFueXdheXMgKHdpdGgganVzdCBh IGxpdHRsZSBvdmVyaGVhZCBzZWVuIGZyb20gcmVjZWl2aW5nIGFuZCBwcm9jZXNzaW5nIEFDS3Mp LiBUaGUgbWFjaGluZSBJIHVzZWQgd2FzIGFub3RoZXIgc2VydmVyIGdyYWRlIG1hY2hpbmUgcnVu bmluZyB0aGUgbGF0ZXN0IFdpbmRvd3MNCiAxMCBTZXJ2ZXIgRGF0YWNlbnRlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U28gdGhlIHBlcmNlbnRhZ2VzIEkgc2hhcmVkIGFyZSBmb3IganVzdCB0 aGUgUVVJQyBzZW5kIHBhdGggKGFnYWluLCBubyBQTkUgd2l0aCB0aGVzZSBudW1iZXJzKS4gVGhl IG51bWJlcnMgYXJlIGZvciB0aGUgcGVyY2VudGFnZSBvZiB0b3RhbCBDUFUgZm9yIGFsbCBwYWNr ZXRzIHNlbnQsIGJ1dCBzaW5jZSBhbGwgcGFja2V0cyB3ZXJlIHByZXR0eSBtdWNoIHRoZSBzYW1l IHNpemUsIHRoZSBudW1iZXJzIHNob3VsZA0KIHN0aWxsIGhvbGQgZm9yIGEgc2luZ2xlIHBhY2tl dC4gQW5kIGJvdHRvbSBsaW5lLCBlbmNyeXB0aW9uIGlzIGEgbG90IG1vcmUgb2YgYW4gaW1wYWN0 IHRoYW4gMTAlLiBBbmQgYXMgd2UgYnJpbmcgaW4gbW9yZSBwZXJmb3JtYW5jZSBpbXByb3ZlbWVu dHMgZm9yIFVEUCBzZW5kIHBhdGggaW4gV2luZG93cywgd2UgZXhwZWN0IGVuY3J5cHRpb24gdG8g YmUgaGlnaGVyIGFuZCBoaWdoZXIgcGVyY2VudGFnZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBLYXp1aG8gT2t1ICZs dDtrYXp1aG9va3VAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1 bmUgMjMsIDIwMTggMTI6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgQmFua3MgJmx0O25pYmFu a3NAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dl dHRAZ29vZ2xlLmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JSVVDLCBJYW4gc2hvdWxkIGJlIHRhbGtpbmcg YWJvdXQgcGVyZm9ybWFuY2UgbnVtYmVycyB0aGF0IHlvdSB3b3VsZCBzZWUgb24gYSBzZXJ2ZXIg dGhhdCBpcyBoYW5kbGluZyByZWFsIHdvcmtsb2FkLiBOb3QgdGhlIGJyZWFrZG93biBvZiBudW1i ZXJzIHdpdGhpbiB0aGUgUVVJQyBzdGFjay48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkxldCdzIHRhbGsgYWJvdXQgbmFub3NlY29uZHMgcGVyIHBhY2tldCBy YXRoZXIgdGhhbiB0aGUgcmF0aW8sIGJlY2F1c2UgcmF0aW8gZGVwZW5kcyBvbiB3aGF0IHlvdSB1 c2UgYXMgYSAmcXVvdDt0b3RhbCZxdW90OyBpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgYmVuY2htYXJrcyB0ZWxsIG1lIHRoYXQsIG9u IE9wZW5TU0wgMS4xLjAgcnVubmluZyBvbiBDb3JlIGk3IEAgMi41R0h6IChNYWNCb29rIFBybyAx NSZxdW90OyBNaWQgMjAxNSksIHRoZSBudW1iZXJzIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0aG91dC1QTkU6IDU4NW5zIC8gcGFj a2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53 aXRoLVBORTogNjA3bnMgLyBwYWNrZXQgKCogdGhpcyBpcyB0aGUgb3B0aW1pemVkIHZlcnNpb24g d2l0aCAzLjglIG92ZXJoZWFkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Bc3N1bWluZyB0aGF0IHlvdXIgcGVhayByYXRlIGlzIDFHYml0L0NQ VSBjb3JlICh3b3VsZCBiZSBlbm91Z2ggdG8gc2F0dXJhdGUgMjVHYiBFdGhlcm5ldCksIHRoZSBy YXRpbyBvZiBDUFUgY3ljbGVzIGZvciBydW5uaW5nIHRoZSBjcnlwdG8gd2lsbCBiZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxsIGNyeXB0 bzogMC4xMjVHQi9zZWMgLyAxMjgwYnl0ZXMvcGFja2V0ICogNjA3bnMvcGFja2V0ID0gNS45MyAl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QTkU6 IDAuMTI1R0Ivc2VjIC8gMTI4MGJ5dGVzL3BhY2tldCAqIDIyLjRucy9wYWNrZXQgPSAwLjIyICU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2Yg Y291cnNlLCB0aGVzZSBudW1iZXJzIGFyZSB3aGF0IGlzIGV4cGVjdGVkIHdoZW4gYSBzZXJ2ZXIg aXMgc2VuZGluZyBvciByZWNlaXZpbmcgZnVsbC1zaXplZCBwYWNrZXRzIGluIG9uZSBkaXJlY3Rp b24uIEluIHJlYWxpdHksIHRoZXJlIHdvdWxkIGJlIGF0IGxlYXN0IHNvbWUgZmxvdyBpbiB0aGUg b3Bwb3NpdGUgZGlyZWN0aW9uLCBzbyB0aGUgbnVtYmVyIHdpbGwgYmUgaGlnaGVyLCBidXQgbm90 IGFzIG11Y2gNCiBhcyAyeC4gT3IgaWYgeW91IGFyZSBzZW5kaW5nIHNtYWxsLXNpemVkIHBhY2tl dCBpbiAqYm90aCogZGlyZWN0aW9ucyAqYW5kKiBzYXR1cmF0aW5nIHRoZSBsaW5rLCB0aGUgcmF0 aW8gd2lsbCBiZSBoaWdoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CdXQgbG9va2luZyBhdCB0aGUgbnVtYmVycywgSSdkIGFzc3VtZSB0aGF0IDEwJSBp cyBhIGxvZ2ljYWwgbnVtYmVyIGZvciB3b3JrbG9hZCBJYW4gaGFzLCBhbmQgYWxzbyBmb3IgcGVv cGxlIHdobyBhcmUgaW52b2x2ZWQgaW4gY29udGVudCBkaXN0cmlidXRpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHNob3duLCBJIHRo aW5rIHRoYXQgc2hhcmluZyB0aGUgUFBTIGFuZCBhdmVyYWdlIHBhY2tldCBzaXplIHRoYXQgb3Vy IHdvcmtsb2FkIHdpbGwgaGF2ZSwgYWxvbmcgd2l0aCB0aGUgcmF3IG51bWJlcnMgb2YgdGhlIGNy eXB0byAoaS5lLiBuc2VjIC8gcGFja2V0KSB3aWxsIGdpdmUgdXMgYSBiZXR0ZXIgdW5kZXJzdGFu ZGluZyBvbiBob3cgbXVjaCB0aGUgYWN0dWFsIG92ZXJoZWFkIGlzLiBEbyB5b3UgbWluZA0KIHNo YXJpbmcgeW91ciBleHBlY3RhdGlvbnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yMDE4LTA2LTIzIDk6MzQgR01UJiM0MzswOTowMCBOaWNrIEJhbmtzICZs dDs8YSBocmVmPSJtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bmliYW5rc0BtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhleSBHdXlzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzcGVudCB0aGUgYmV0dGVyIHBhcnQgb2YgdGhlIGRheSBn ZXR0aW5nIHNvbWUgcGVyZm9ybWFuY2UgdHJhY2VzIG9mIFdpblF1aWMNCjxiPndpdGhvdXQgUE5F PC9iPi4gT3VyIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGJvdGggdXNlciBtb2RlIGFuZCBrZXJu ZWwgbW9kZSwgc28gSSBnb3QgbnVtYmVycyBmb3IgYm90aC4gVGhlIGZvbGxvd2luZyB0YWJsZSBz aG93cyB0aGUgcmVsYXRpdmUgQ1BVIGNvc3Qgb2YgZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBRVUlD IHNlbmQgcGF0aDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjJw dDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIx NzUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTMxLjRwdDtib3JkZXI6c29saWQgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjYzLjBwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBw dDtib3JkZXItbGVmdDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPlVzZXIgTW9kZTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9Ijk2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEuMGluO2JvcmRlcjpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+S2VybmVsIE1vZGU8L2I+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxpZ249InRv cCIgc3R5bGU9IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y ZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPlVEUCBTZW5kPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iODQiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NjMuMHB0O2JvcmRlci10b3A6bm9uZTti b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3Jk ZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj42NC43JTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iOTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MS4waW47Ym9yZGVyLXRv cDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQxLjQlPG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxpZ249InRvcCIgc3R5bGU9 IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpu b25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPkVuY3J5cHRpb248L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI4NCIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wcHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1s ZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdo dDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjIyLjUlPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdp ZHRoPSI5NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxLjBpbjtib3JkZXItdG9wOm5vbmU7 Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MzguNSU8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSIxNzUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 MTMxLjRwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+UGFj a2V0IEJ1aWxkaW5nL0ZyYW1pbmc8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI4NCIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wcHQ7Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjclPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI5NiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxLjBpbjtib3JkZXItdG9wOm5v bmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTUlPG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo OjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPk1p c2NlbGxhbmVvdXM8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI4NCIgdmFs aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wcHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0 Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjUuOCU8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9 Ijk2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEuMGluO2JvcmRlci10b3A6bm9uZTtib3Jk ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj41LjElPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlc2UgbnVtYmVycyBkZWZpbml0 ZWx5IHNob3cgdGhhdCBlbmNyeXB0aW9uIGlzIGEgbXVjaCBsYXJnZXIgcG9ydGlvbiBvZiBDUFUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIE5pY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5G cm9tOjwvYj4gS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjIsIDIwMTggNTowMiBQTTxicj4NCjxiPlRvOjwvYj4g SWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmlj ayBCYW5rcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm5pYmFua3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBQcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3Jn PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVy Zm9ybWFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+MjAxOC0wNi0yMyAzOjUxIEdNVCYjNDM7MDk6MDAgSWFuIFN3ZXR0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0 QGdvb2dsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBleHBlY3QgY3J5cHRvIHRvIGluY3JlYXNlIGFzIGEgZnJhY3Rpb24gb2YgQ1BVLCBidXQg SSBkb24ndCBleHBlY3QgaXQgdG8gZ28gbXVjaCBoaWdoZXIgdGhhbiAxMCUuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IHdobyBrbm93cywgbWF5 YmUgMiB5ZWFycyBmcm9tIG5vdyBldmVyeXRoaW5nIGVsc2Ugd2lsbCBiZSB2ZXJ5IG9wdGltaXpl ZCBhbmQgY3J5cHRvIHdpbGwgYmUgMTUlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JYW4sIHRo YW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgcHJvcG9ydGlvbiBvZiBDUFUgY3ljbGVzIHdlIGFyZSBs aWtlbHkgdG8gc3BlbmQgZm9yIGNyeXB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdXIgbnVtYmVycyByZWxpZXZlcyBtZSwgYmVj YXVzZSBldmVuIGlmIHRoZSBjb3N0IG9mIGNyeXB0byBnb2VzIHRvIDE1JSwgdGhlIG92ZXJoZWFk IG9mIFBORSB3aWxsIGJlIGxlc3MgdGhhbiAxJSAoMC4xNSowLjA0PTAuMDA2KS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQg YWxzbyBsaWtlIHRvIG5vdGUgdGhhdCBpdCBpcyBsaWtlbHkgdGhhdCBIeXBlclRocmVhZGluZywg d2hlbiB1c2VkLCB3aWxsIGVsaW1pbmF0ZSB0aGUgb3ZlcmhlYWQgb2YgUE5FLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyBi ZWNhdXNlIElJVUMgUE5FIGlzIGEgbWFyZ2luYWwgYWRkaXRpb25hbCB1c2Ugb2YgdGhlIEFFUy1O SSBlbmdpbmUsIHdoaWNoIGhhdmUgYmVlbiBtb3N0bHkgaWRsZS4gVGhlIG92ZXJoZWFkIG9mIGNy eXB0byBpcyBzbWFsbCAoaS5lLiAxNSUpIHRoYXQgd2Ugd2lsbCByYXJlbHkgc2VlIGNvbnRlbnRp b24NCiBvbiB0aGUgZW5naW5lLiBXaGlsZSBvbmUgaHlwZXJ0aHJlYWQgZG9lcyBBRVMsIHRoZSBv dGhlciBoeXBlcnRocmVhZCB3aWxsIHJ1biBhdCBmdWxsIHNwZWVkIGRvaW5nIG90aGVyIG9wZXJh dGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BbHNvIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgdGhlIG51bWJlciBvZiBDUFUg Y3ljbGVzIHNwZW50IHBlciBRVUlDIHBhY2tldCBkb2VzIG5vdCBjaGFuZ2UgYSBsb3Qgd2l0aCBQ TkUsIEkgd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWUgKm5vKiBkZWNyZWFzZSBvZiB0aHJv dWdocHV0IHdoZW4gUE5FDQogaXMgdXNlZCBvbiBhIEh5cGVyVGhyZWFkaW5nIGFyY2hpdGVjdHVy ZS4gSW4gc3VjaCBjYXNlLCB3aGF0IHdlIHdpbGwgb25seSBvYnNlcnZlIGlzIHRoZSByYWlzZSBv ZiB0aGUgdXRpbGl6YXRpb24gcmF0aW8gb2YgdGhlIEFFUy1OSSBlbmdpbmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEp1biAyMiwgMjAxOCBhdCAxMjozNCBQTSBO aWNrIEJhbmtzICZsdDtuaWJhbmtzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBqdXN0IHdhbnQg dG8gYWRkLCBteSBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5IHVzZXMgRUNCIGZyb20gYmNyeXB0IChh bmQgSSBkbyB0aGUgWE9SKSBhbHJlYWR5LiBCY3J5cHQgZG9lc27igJl0IGV4cG9zZSBDVFIgbW9k ZSBkaXJlY3RseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlbnQgZnJvbQ0KPGEgaHJl Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZnby5taWNyb3NvZnQuY29tJTJGZndsaW5rJTJGJTNGTGlua0lkJTNENTUwOTg2 JmFtcDtkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2U2ZWZhMzYzYmMy NTQ3MTY3YThjMDhkNWQ4OWM4MGU3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjY1MzA4OTA1OTI2ODgzNiZhbXA7c2RhdGE9YWVVN2o1bGhDSU0xOEtHNWM2 b3BHNHA3YW13aENXYlJuZm5tOHNEVzdoYyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxh bmsiPg0KTWFpbDwvYT4gZm9yIFdpbmRvd3MgMTA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBz aXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21h aWwtbV82ODg2OTg2OTg5NjczMjk5MTg0bV8tODQ4MjI5NjMzOTg1MjU3MTI2OW1fLTg0MDg4NDc0 MjcwOTMyMjM0NzZkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdW5lIDIyLCAyMDE4IDk6MjY6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IElhbiBTd2V0dDsgS2F6 dWhvIE9rdTxicj4NCjxiPkNjOjwvYj4gTmljayBCYW5rczsgSUVURiBRVUlDIFdHPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8L3Nw YW4+IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklhbiwgZG8geW91IGV4 cGVjdCB0aGF0IGZyYWN0aW9uIG9mIG92ZXJhbGwgY29zdCB0byBob2xkIG9uY2UgdGhlIFVEUCBz dGFjayBpcyBvcHRpbWl6ZWQ/IElzIHlvdXIgbWVhc3VyZW1lbnQgb24gdG9wIG9mIHRoZSByZWNl bnQga2VybmVsIGltcHJvdmVtZW50cz8gSSBleHBlY3QgY3J5cHRvIGZyYWN0aW9uDQogb2Ygb3Zl cmFsbCBjb3N0IHRvIGtlZXAgaW5jcmVhc2luZyBvdmVyIHRpbWUgYXMgdGhlIG5ldHdvcmsgc3Rh Y2sgYm90dGxlbmVja3MgYXJlIGVsaW1pbmF0ZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkthenVobywgc2hvdWxkIHRoZSBkcmFmdCBkZXNjcmliZSB0aGUgb3B0aW1pemF0aW9ucyB5 b3UgYXJlIG1ha2luZz8gT3IgYXJlIHRoZXNlIGFyZSB0b28gT3BlblNTTCBzcGVjaWZpYz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPklhbiBTd2V0dDxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjIsIDIwMTggNDo0NSBBTTxicj4NCjxiPlRvOjwvYj4g S2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE5p Y2sgQmFua3MgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5uaWJhbmtzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdHICZs dDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IE51bWJlciBFbmNy eXB0aW9uIFBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh bmtzIGZvciBkaWdnaW5nIGludG8gdGhlIGRldGFpbHMgb2YgdGhpcywgS2F6dWhvLiZuYnNwOyAm bHQ7NCUgaW5jcmVhc2UgaW4gY3J5cHRvIGNvc3QgaXMgYSBiaXQgbW9yZSB0aGFuIEkgb3JpZ2lu YWxseSBleHBlY3RlZCh+MiUpLCBidXQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUgb2YgbXkgQ1BV IHVzYWdlLCBzbw0KIGl0J3Mgc3RpbGwgbGVzcyB0aGFuIDAuNSUgdG90YWwsIHdoaWNoIGlzIGFj Y2VwdGFibGUgdG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKdW4gMjIsIDIw MTggYXQgMjo0NSBBTSBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MjAxOC0wNi0yMiAxMjoyMiBHTVQmIzQzOzA5OjAwIEthenVobyBPa3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+MjAxOC0wNi0yMiAxMTo1NCBHTVQmIzQzOzA5OjAwIE5pY2sgQmFua3MgJmx0OzxhIGhyZWY9 Im1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5uaWJhbmtzQG1p Y3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkhpIEthenVobyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBm b3Igc2hhcmluZyB5b3VyIG51bWJlcnMgYXMgd2VsbCEgSSdtIGJpdCBjb25mdXNlZCB3aGVyZSB5 b3Ugc2F5IHlvdSBjYW4gcmVkdWNlIHRoZSAxMCUgb3ZlcmhlYWQgdG8gMiUgdG8gNCUuIEhvdyBk byB5b3UgcGxhbiBvbiBkb2luZyB0aGF0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBzdGF0 ZWQgaW4gbXkgcHJldmlvdXMgbWFpbCwgdGhlIDEwJSBvZiBvdmVyaGVhZCBjb25zaXN0cyBvZiB0 aHJlZSBwYXJ0cywgZWFjaCBjb25zdW1pbmcgY29tcGFyYWJsZSBudW1iZXIgb2YgQ1BVIGN5Y2xl cy4gVGhlIHR3byBhbW9uZyB0aGUgdGhyZWUgaXMgcmVsYXRlZCB0byB0aGUgYWJzdHJhY3Rpb24N CiBsYXllciBhbmQgaG93IENUUiBpcyBpbXBsZW1lbnRlZCwgd2hpbGUgdGhlIG90aGVyIG9uZSBp cyB0aGUgY29yZSBBRVMtRUNCIG9wZXJhdGlvbiBjb3N0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgc2hvdWxkIGJlIGFibGUgdG8g cmVtb3ZlIHRoZSBjb3N0bHkgYWJzdHJhY3Rpb24gbGF5ZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBzaG91bGQgYWxzbyBiZSBw b3NzaWJsZSB0byByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiwgc2luY2UgaW4gUE5FLCB3ZSBu ZWVkIHRvIFhPUiBhdCBtb3N0IDQgb2N0ZXRzIChhcHBseWluZyBYT1IgaXMgdGhlIG9ubHkgZGlm ZmVyZW5jZSBiZXR3ZWVuIENUUiBhbmQgRUNCKS4gVGhhdCBjb3N0IHNob3VsZA0KIGJlIHNvbWV0 aGluZyB0aGF0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBiZSBudWxsaWZpZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db25zaWRlcmlu ZyB0aGVzZSBhc3BlY3RzLCBhbmQgYnkgbG9va2luZyBhdCB0aGUgbnVtYmVycyBvbiB0aGUgT3Bl blNTTCBzb3VyY2UgY29kZSAoYXMgd2VsbCBhcyBjb25zaWRlcmluZyB0aGUgb3ZlcmhlYWQgb2Yg R0NNKSwgbXkgZXhwZWN0YXRpb24gZ29lcyB0byAyJSB0byA0JS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3QgZGlkIHNvbWUgZXhwZXJpbWVudHMgYW5kIGl0IHNl ZW1zIHRoYXQgdGhlIGV4cGVjdGF0aW9uIHdhcyBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGJlbmNobWFya3MgdGVs bCBtZSB0aGF0IHRoZSBvdmVyaGVhZCBnb2VzIGRvd24gZnJvbSAxMC4wJSB0byAzLjglLCBieSBk b2luZyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+KiByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiBhYnN0cmFj dGlvbiAoaS5lLiB1c2UgdGhlIEVDQiBiYWNrZW5kIGFuZCBkbyBYT1IgYnkgb3Vyc2VsdmVzKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJl bW92ZSB0aGUgb3ZlcmhlYWQgb2YgdGhlIGFic3RyYWN0aW9uIGxheWVyIChpLmUuIGNhbGwgdGhl IG1ldGhvZCByZXR1cm5lZCBieSBFVlBfQ0lQSEVSX21ldGhfZ2V0X2RvX2NpcGhlciBpbnN0ZWFk IG9mIGNhbGxpbmcgRVZQX0VuY3J5cHRVcGRhdGUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PZiBjb3Vyc2UgdGhlIGNoYW5nZXMgYXJl IHNwZWNpZmljIHRvIE9wZW5TU0wsIGJ1dCBJIHdvdWxkIGV4cGVjdCB0aGF0IHlvdSBjYW4gZXhw ZWN0IHNpbWlsYXIgbnVtYmVycyBhc3N1bWluZyB0aGF0IHlvdSBoYXZlIGFjY2VzcyB0byBhbiBv cHRpbWl6ZWQgQUVTIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W0h4UyAtIDE1MjU0IC0gMTYuMC4x MDIyOC4yMDA3NV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTgl IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODg2OTg2OTg5Njcz Mjk5MTg0bV8tODQ4MjI5NjMzOTg1MjU3MTI2OW1fLTg0MDg4NDc0MjcwOTMyMjM0NzZtXy02Mjgy NDk5ODYxMzM0MTA0MDUxbV84NDcxMDcxMzU5ODE4MTM3MTA3bV8tNzc2Mjk4MTIxMzEzODc4Mzc0 ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IEth enVobyBPa3UgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208L2E+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDIxLCAyMDE4IDc6 MjE6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgQmFua3M8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bh bj48YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0 Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZTwvc3Bhbj4gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBOaWNrLA0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmsgeW91 IGZvciBicmluZ2luZyB0aGUgbnVtYmVycyB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBqdXN0IHJ1biBh IHNtYWxsIGJlbmNobWFyayB1c2luZyBRdWljbHksIGFuZCBJIHNlZSBjb21wYXJhYmxlIG51bWJl cnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UbyBiZSBwcmVjaXNlLCBJIHNlZSAxMC4wJSBpbmNyZWFzZSBvZiBDUFUgY3ljbGVzIHdo ZW4gZW5jcnlwdGluZyBhIEluaXRpYWwgcGFja2V0IG9mIDEsMjgwIG9jdGV0cy4gSSBleHBlY3Qg dGhhdCB3ZSB3aWxsIHNlZSBzaW1pbGFyIG51bWJlcnMgb24gb3RoZXIgUVVJQyBzdGFja3MgdGhh dCBhbHNvIHVzZQ0KIHBpY290bHMgKHdpdGggT3BlblNTTCBhcyBhIGJhY2tlbmQpLiBOb3RlIHRo YXQgdGhlIG51bWJlciBpcyBvbmx5IGNvbXBhcmluZyB0aGUgY29zdCBvZiBlbmNyeXB0aW9uLCB0 aGUgb3ZlcmhlYWQgcmF0aW8gd2lsbCBiZSBtdWNoIHNtYWxsZXIgaWYgd2UgbG9vayBhdCB0aGUg dG90YWwgbnVtYmVyIG9mIENQVSBjeWNsZXMgc3BlbnQgYnkgYSBRVUlDIHN0YWNrIGFzIGEgd2hv bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Mb29raW5nIGF0IHRoZSBwcm9maWxlLCB0aGUgb3ZlcmhlYWQgY29uc2lzdHMgb2YgdGhy ZWUgb3BlcmF0aW9ucyB0aGF0IGVhY2ggY29uc3VtZXMgY29tcGFyYWJsZSBDUFUgY3ljbGVzOiBj b3JlIEFFUyBvcGVyYXRpb24gKHVzaW5nIEFFUy1OSSksIENUUiBvcGVyYXRpb24gb3ZlcmhlYWQs IENUUiBpbml0aWFsaXphdGlvbi4NCiBOb3RlIHRoYXQgcGljb3RscyBhdCB0aGUgbW9tZW50IHBy b3ZpZGVzIGFjY2VzcyB0byBDVFIgY3J5cHRvIGJlbmVhdGggdGhlIEFFQUQgaW50ZXJmYWNlLCB3 aGljaCBpcyB0byBiZSB1c2VkIGJ5IHRoZSBRVUlDIHN0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgYXNzdW1lIHRo YXQgd2UgY2FuIGN1dCBkb3duIHRoZSBvdmVyaGVhZCB0byBzb21ld2hlcmUgYmV0d2VlbiAyJSB0 byA0JSwgYnV0IGl0IG1pZ2h0IGJlIGhhcmQgdG8gZ28gZG93biB0byBzb21ld2hlcmUgbmVhciAx JSwgYmVjYXVzZSB3ZSBjYW5ub3QgcGFyYWxsZWxpemUgdGhlIEFFUyBvcGVyYXRpb24NCiBvZiBQ TkUgd2l0aCB0aGF0IG9mIEFFQUQgKHNlZSA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZv cGVuc3NsJTJGb3BlbnNzbCUyRmJsb2IlMkZPcGVuU1NMXzFfMV8waCUyRmNyeXB0byUyRmFlcyUy RmFzbSUyRmFlc25pLXg4Nl82NC5wbCUyM0wyNC1MMzkmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFu a3MlNDBtaWNyb3NvZnQuY29tJTdDMTFkNTVmMTczMzNlNGE3OTVkNzAwOGQ1ZDdlNmQ5M2MlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjUyMzA4ODQzOTk0 MTM0JmFtcDtzZGF0YT1rcU16NFNzTiUyRjJFckdLMDZRejhaMHZVenBsNE1paXBuTkUyd0FNVWI0 NmMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNv bS9vcGVuc3NsL29wZW5zc2wvYmxvYi9PcGVuU1NMXzFfMV8waC9jcnlwdG8vYWVzL2FzbS9hZXNu aS14ODZfNjQucGwjTDI0LUwzOTwvYT4gYWJvdXQgdGhlIGltcGFjdCBvZiBwYXJhbGxlbGl6YXRp b24pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBkbyBub3QgdGhpbmsgdGhhdCAyJSB0byA0JSBvZiBhZGRpdGlvbmFsIG92ZXJoZWFk IHRvIHRoZSBjcnlwdG8gaXMgYW4gaXNzdWUgZm9yIFFVSUMvSFRUUCwgYnV0IGN1cnJlbnQgb3Zl cmhlYWQgb2YgMTAlIGlzIHNvbWV0aGluZyB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZGVjcmVhc2Uu IEkgYW0gZ2xhZCB0bw0KIGJlIGFibGUgdG8gbGVhcm4gdGhhdCBub3cuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxOC0wNi0yMiA1OjQ4IEdNVCYjNDM7MDk6MDAgTmljayBC YW5rcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvIFFVSUMgV0csPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIHJlY2VudGx5IGltcGxlbWVudGVkIFBORSBmb3IgV2luUXVp YyAodXNpbmcgYmNyeXB0IEFQSXMpIGFuZCBJIGRlY2lkZWQgdG8gZ2V0IHNvbWUgcGVyZm9ybWFu Y2UgbnVtYmVycyB0byBzZWUgd2hhdCB0aGUgb3ZlcmhlYWQgb2YgUE5FIHdhcy4gSSBmaWd1cmVk IHRoZSByZXN0IG9mIHRoZSBXRyBtaWdodA0KIGJlIGludGVyZXN0ZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5NeSB0ZXN0IGp1c3QgZW5jcnlwdHMgdGhlIHNhbWUgYnVmZmVyIChzaXpl IGRlcGVuZGVudCBvbiB0aGUgdGVzdCBjYXNlKSAxMCwwMDAsMDAwIHRpbWVzIGFuZCBtZWFzdXJl ZCB0aGUgdGltZSBpdCB0b29rLiBUaGUgdGVzdCB0aGVuIGRpZCB0aGUgc2FtZSB0aGluZywgYnV0 IGFsc28gZW5jcnlwdGVkIHRoZQ0KIHBhY2tldCBudW1iZXIgYXMgd2VsbC4gSSByYW4gYWxsIHRo YXQgMTAgdGltZXMgaW4gdG90YWwuIEkgdGhlbiBjb2xsZWN0ZWQgdGhlIGJlc3QgdGltZXMgZm9y IGVhY2ggY2F0ZWdvcnkgdG8gcHJvZHVjZSB0aGUgZm9sbG93aW5nIGdyYXBocyBhbmQgdGFibGVz IChmdWxsIGV4Y2VsIGRvYyBhdHRhY2hlZCk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MDEiIHN0 eWxlPSJ3aWR0aDozNzYuMHB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8 dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjEyOCIgbm93cmFwPSIiIGNvbHNw YW49IjIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6OTYuMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaW1lIChtcyk8L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHls ZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0 Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxl PSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQi Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTE5IiBub3dyYXA9IiIgY29sc3Bhbj0iMiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo4OS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlJhdGUgKE1icHMpPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0i IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Qnl0ZXM8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRo OjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tk8gUE5FPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlBORTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDgu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjEyNyIgbm93cmFwPSIiIGNvbHNwYW49IjIiIHZhbGlnbj0iYm90dG9tIiBzdHls ZT0id2lkdGg6OTUuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Q TkUgT3ZlcmhlYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i NTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5n OjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tm8gUE5FPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlBORTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjQ8L3NwYW4+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRv bSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu OnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjI4NC42NzE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9t IiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6 MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246 cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4zMDI3LjY1Nzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20i IHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDox NS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJp Z2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzMlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i d2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xNDAuMDY0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTA1LjY5Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+MTY8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ MjEwMi40MDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4y ODI4LjIwNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dy YXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzUl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj42MDguODI3PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxp Z249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0 ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NDUyLjU4NDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0 Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRo OjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NjQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRo OjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MjE5OC44ODM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6 NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4yOTA3LjU3Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MzIlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3 aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdp ZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4yMzI4LjQ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+MTc2MC45Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy IHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjU2PC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWdu PSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjI3NTguMzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h bGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjM0OTAuMjg8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90 dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWln aHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjI3JTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0 eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4w cHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NzQyNC44Njwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxl PSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjU4NjcuNzI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjYwMDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj40NjY5LjI4Mzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjU0MjQuNTM5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQi IG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBp biA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4xNiU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEwMjgw PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ODg0OC42ODwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUu MHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTAwMDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i d2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj42MTMwLjEzOTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjY5MDcuODA1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 L3RkPg0KPHRkIHdpZHRoPSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lk dGg6NDcuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMyU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDgu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41 cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjEzMDUwLjM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0 O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4xMTU4MS4xPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMjAwPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIg dmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGlu IDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjY0NTguNjc5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NzIyOS42NzI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEyJTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJv dHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTQ4NjMuNzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEzMjc4LjY8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQg d2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7 cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjE0NTA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBw dDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Nzg3Ni4zMTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0 O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj44NjcwLjE2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3 aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdp ZHRoPSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4xMCU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjE0NzI3Ljc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4xMzM3OS4yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB1c2VkIGEgc2VydmVyIGdyYWRl IGxhYiBtYWNoaW5lIEkgaGFkIGF0IG15IGRpc3Bvc2FsLCBydW5uaW5nIHRoZSBsYXRlc3QgV2lu ZG93cyAxMCBTZXJ2ZXIgRGF0YUNlbnRlciBidWlsZC4gQWdhaW4sIHRoZXNlIG51bWJlcnMgYXJl IGZvciBjcnlwdG8gb25seS4gTm8gUVVJQyBvciBVRFAgaXMgaW5jbHVkZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi0gTmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0i YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2F6dWhvIE9rdTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gY2xhc3M9ImdtYWlsLW02ODg2OTg2OTg5NjczMjk5MTg0bS04NDgyMjk2MzM5ODUyNTcx MjY5bS04NDA4ODQ3NDI3MDkzMjIzNDc2bS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0NCjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+S2F6dWhvIE9rdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkth enVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+S2F6dWhvIE9rdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW2PR2101MB0908B9F435EC23FB9152DC3BB3740MW2PR2101MB0908_-- From nobody Sat Jun 23 09:39:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C47131038 for ; Sat, 23 Jun 2018 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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 GhDs22dBINxz for ; Sat, 23 Jun 2018 09:39:27 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 2ECC9131032 for ; Sat, 23 Jun 2018 09:39:27 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id u4-v6so6928512itg.0 for ; Sat, 23 Jun 2018 09:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=S3ulyTR7PiJk5LeAWyzSAuz2o+wZJ7/+7I36Mx0JjxM=; b=rz37rrAR8jbdOv8oqsVn7M+FoD9joJjKzT7YNyDr4YaUMyIVSHv3M58G9ktOPN1Zru ohOVdBCqROgsdGgckb7i0w2SngCRiuv8hZzmtmTexzRlcdtRYEUA0K5X9c7bczYKicTt g3e0LOI16ahKLa5L4bv5EXBqNuupUulv3GtfxrEqg0m29dTOdx6qTrU0hhpjEVSNqCJD Ajy9rlpvWeU7h2egI9vn/EvXQTOWPE4XIccfV/Fb2rVBo6pG5E1PAQASPa5GiaoQcIKF o2YaPb+YHg2k/xiOwhEWQDoP4irgdsWV+RM26QYb1N8Ck2ZIaMq8czSM1Hm9KvHxPvpG xRLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=S3ulyTR7PiJk5LeAWyzSAuz2o+wZJ7/+7I36Mx0JjxM=; b=irgwephKk+rungTIumelHoVe+L4iM1nH0LoOXzrpGGnR4prFev9ZHWnb6POPnXHGNm q+Lx7Is/NRgxV0gP/CkVIJghIQAvu8QxiPt85yN8pVftpojzkreKVsCJu7dQkdG6T+Ps C/rtI3483sVUe5/V3o7EvObeA8Qw/tUsXXahG/qVvS+UsAG+YWh6OVvmM32jx9PdyCaF AkmIYiJJThIAvezsoK434KKRZgSG6gVc8vNxofhqa15PYZGKIqYU//J+ItFQoTfcXBec aZq02SysMGXTryU140b1+7I0Mb2XqQaf8Y/NrH5uud9KDi1wttSSpsUSC35uUn4DL7kZ IWDg== X-Gm-Message-State: APt69E16MTVuteLdfwMfdUuwKFDrmvqTqTTyYgyviAAau0GD28GgZlMY +x18lr8Iu7hak93ILKwBcaTBltd89Y/TTB1KlKxdYPOl X-Google-Smtp-Source: AAOMgpfad/ObOgUeoo35ihu/5y3WCma/urL3fZl9khgBtqphMWrm/wrVwr7X5wSb9FOOu3Og4uURsGjalbLrcjDDPS8= X-Received: by 2002:a24:5e82:: with SMTP id h124-v6mr5105188itb.80.1529771966057; Sat, 23 Jun 2018 09:39:26 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 23 Jun 2018 12:39:24 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 23 Jun 2018 12:39:24 -0400 Message-ID: Subject: RE: Packet Number Encryption Performance To: IETF QUIC WG , Nick Banks , Kazuho Oku Cc: Ian Swett , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="0000000000009fd1ad056f51cafc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 16:39:31 -0000 --0000000000009fd1ad056f51cafc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nick, how about numbers for small packets? So I presume the overhead of PNE will be much larger here because PNE does not pipeline while a 64 byte payload just about manages til an AES pipeline depending on arch. Mikkel On 23 June 2018 at 16.54.42, Nick Banks ( nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: I agree that the numbers for real work loads will be interesting, but I do believe that raw QUIC stack numbers are also important. They will represent your best case scenario. For my testing, I have a fairly simple test of opening a single unidirectional stream and just continually sending data until the core gets saturated. From that, I grab the performance trace, and specifically look at the composition of the QUIC stack=E2=80=99s send path. The send path con= stitutes generally all of the CPU for the whole connection anyways (with just a little overhead seen from receiving and processing ACKs). The machine I used was another server grade machine running the latest Windows 10 Server Datacenter. So the percentages I shared are for just the QUIC send path (again, no PNE with these numbers). The numbers are for the percentage of total CPU for all packets sent, but since all packets were pretty much the same size, the numbers should still hold for a single packet. And bottom line, encryption is a lot more of an impact than 10%. And as we bring in more performance improvements for UDP send path in Windows, we expect encryption to be higher and higher percentage. - Nick *From:* Kazuho Oku *Sent:* Saturday, June 23, 2018 12:00 AM *To:* Nick Banks *Cc:* Ian Swett ; IETF QUIC WG ; Praveen Balasubramanian *Subject:* Re: Packet Number Encryption Performance IIUC, Ian should be talking about performance numbers that you would see on a server that is handling real workload. Not the breakdown of numbers within the QUIC stack. Let's talk about nanoseconds per packet rather than the ratio, because ratio depends on what you use as a "total" is. My benchmarks tell me that, on OpenSSL 1.1.0 running on Core i7 @ 2.5GHz (MacBook Pro 15" Mid 2015), the numbers are: without-PNE: 585ns / packet with-PNE: 607ns / packet (* this is the optimized version with 3.8% overhead) Assuming that your peak rate is 1Gbit/CPU core (would be enough to saturate 25Gb Ethernet), the ratio of CPU cycles for running the crypto will be: all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/packet =3D 5.93 % PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet =3D 0.22 % Of course, these numbers are what is expected when a server is sending or receiving full-sized packets in one direction. In reality, there would be at least some flow in the opposite direction, so the number will be higher, but not as much as 2x. Or if you are sending small-sized packet in *both* directions *and* saturating the link, the ratio will be higher. But looking at the numbers, I'd assume that 10% is a logical number for workload Ian has, and also for people who are involved in content distribution. As shown, I think that sharing the PPS and average packet size that our workload will have, along with the raw numbers of the crypto (i.e. nsec / packet) will give us a better understanding on how much the actual overhead is. Do you mind sharing your expectations? 2018-06-23 9:34 GMT+09:00 Nick Banks : Hey Guys, I spent the better part of the day getting some performance traces of WinQuic *without PNE*. Our implementation supports both user mode and kernel mode, so I got numbers for both. The following table shows the relative CPU cost of different parts of the QUIC send path: *User Mode* *Kernel Mode* *UDP Send* 64.7% 41.4% *Encryption* 22.5% 38.5% *Packet Building/Framing* 7% 15% *Miscellaneous* 5.8% 5.1% These numbers definitely show that encryption is a much larger portion of CPU. - Nick *From:* Kazuho Oku *Sent:* Friday, June 22, 2018 5:02 PM *To:* Ian Swett *Cc:* Nick Banks ; Praveen Balasubramanian < pravb@microsoft.com>; IETF QUIC WG *Subject:* Re: Packet Number Encryption Performance 2018-06-23 3:51 GMT+09:00 Ian Swett : I expect crypto to increase as a fraction of CPU, but I don't expect it to go much higher than 10%. But who knows, maybe 2 years from now everything else will be very optimized and crypto will be 15%? Ian, thank you for sharing the proportion of CPU cycles we are likely to spend for crypto. Your numbers relieves me, because even if the cost of crypto goes to 15%, the overhead of PNE will be less than 1% (0.15*0.04=3D0.006). I would also like to note that it is likely that HyperThreading, when used, will eliminate the overhead of PNE. This is because IIUC PNE is a marginal additional use of the AES-NI engine, which have been mostly idle. The overhead of crypto is small (i.e. 15%) that we will rarely see contention on the engine. While one hyperthread does AES, the other hyperthread will run at full speed doing other operations. Also considering the fact that the number of CPU cycles spent per QUIC packet does not change a lot with PNE, I would not be surprised to see *no* decrease of throughput when PNE is used on a HyperThreading architecture. In such case, what we will only observe is the raise of the utilization ratio of the AES-NI engine. On Fri, Jun 22, 2018 at 12:34 PM Nick Banks wrote: I just want to add, my implementation already uses ECB from bcrypt (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directly. Sent from Mail for Windows 10 ------------------------------ *From:* Praveen Balasubramanian *Sent:* Friday, June 22, 2018 9:26:44 AM *To:* Ian Swett; Kazuho Oku *Cc:* Nick Banks; IETF QUIC WG *Subject:* RE: Packet Number Encryption Performance Ian, do you expect that fraction of overall cost to hold once the UDP stack is optimized? Is your measurement on top of the recent kernel improvements? I expect crypto fraction of overall cost to keep increasing over time as the network stack bottlenecks are eliminated. Kazuho, should the draft describe the optimizations you are making? Or are these are too OpenSSL specific? *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett *Sent:* Friday, June 22, 2018 4:45 AM *To:* Kazuho Oku *Cc:* Nick Banks ; IETF QUIC WG *Subject:* Re: Packet Number Encryption Performance Thanks for digging into the details of this, Kazuho. <4% increase in crypto cost is a bit more than I originally expected(~2%), but crypto is less than 10% of my CPU usage, so it's still less than 0.5% total, which is acceptable to me. On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: 2018-06-22 12:22 GMT+09:00 Kazuho Oku : 2018-06-22 11:54 GMT+09:00 Nick Banks : Hi Kazuho, Thanks for sharing your numbers as well! I'm bit confused where you say you can reduce the 10% overhead to 2% to 4%. How do you plan on doing that? As stated in my previous mail, the 10% of overhead consists of three parts, each consuming comparable number of CPU cycles. The two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB operation cost. It should be able to remove the costly abstraction layer. It should also be possible to remove the overhead of CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the only difference between CTR and ECB). That cost should be something that should be possible to be nullified. Considering these aspects, and by looking at the numbers on the OpenSSL source code (as well as considering the overhead of GCM), my expectation goes to 2% to 4%. Just did some experiments and it seems that the expectation was correct. The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by doing the following: * remove the overhead of CTR abstraction (i.e. use the ECB backend and do XOR by ourselves) * remove the overhead of the abstraction layer (i.e. call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calling EVP_EncryptUpdate) Of course the changes are specific to OpenSSL, but I would expect that you can expect similar numbers assuming that you have access to an optimized AES implementation. Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ------------------------------ *From:* Kazuho Oku *Sent:* Thursday, June 21, 2018 7:21:17 PM *To:* Nick Banks *Cc:* quic@ietf.org *Subject:* Re: Packet Number Encryption Performance Hi Nick, Thank you for bringing the numbers to the list. I have just run a small benchmark using Quicly, and I see comparable numbers. To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial packet of 1,280 octets. I expect that we will see similar numbers on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much smaller if we look at the total number of CPU cycles spent by a QUIC stack as a whole. Looking at the profile, the overhead consists of three operations that each consumes comparable CPU cycles: core AES operation (using AES-NI), CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC stacks. I would assume that we can cut down the overhead to somewhere between 2% to 4%, but it might be hard to go down to somewhere near 1%, because we cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization). I do not think that 2% to 4% of additional overhead to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is something that we might want to decrease. I am glad to be able to learn that now. 2018-06-22 5:48 GMT+09:00 Nick Banks : Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to get some performance numbers to see what the overhead of PNE was. I figured the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,000,000 times and measured the time it took. The test then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected the best times for each category to produce the following graphs and tables (full excel doc attached): *Time (ms)* *Rate (Mbps)* *Bytes* *NO PNE* *PNE* *PNE Overhead* *No PNE* *PNE* *4* 2284.671 3027.657 33% 140.064 105.692 *16* 2102.402 2828.204 35% 608.827 452.584 *64* 2198.883 2907.577 32% 2328.45 1760.92 *256* 2758.3 3490.28 27% 7424.86 5867.72 *600* 4669.283 5424.539 16% 10280 8848.68 *1000* 6130.139 6907.805 13% 13050.3 11581.1 *1200* 6458.679 7229.672 12% 14863.7 13278.6 *1450* 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest Windows 10 Server DataCenter build. Again, these numbers are for crypto only. No QUIC or UDP is included. Thanks, - Nick --=20 Kazuho Oku --=20 Kazuho Oku --=20 Kazuho Oku --=20 Kazuho Oku --=20 Kazuho Oku --0000000000009fd1ad056f51cafc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Hi Nick, how about n= umbers for small packets? So I presume the overhead of PNE will be much lar= ger here because PNE does not pipeline while a 64 byte payload just about m= anages til an AES pipeline depending on arch.

Mikkel

On 23 June 2018 at 16.54.42, Nick Banks= (nibanks=3D40m= icrosoft.com@dmarc.ietf.org) wrote:

I agree that the numbers for real work loads will be= interesting, but I do believe that raw QUIC stack numbers are also importa= nt. They will represent your best case scenario.

=C2=A0

For my testing, I have a fairly simple test of openi= ng a single unidirectional stream and just continually sending data until t= he core gets saturated. From that, I grab the performance trace, and specif= ically look at the composition of the QUIC stack=E2=80=99s send path. The send path constitutes generally al= l of the CPU for the whole connection anyways (with just a little overhead = seen from receiving and processing ACKs). The machine I used was another se= rver grade machine running the latest Windows 10 Server Datacenter.

=C2=A0

So the percentages I shared are for just the QUIC se= nd path (again, no PNE with these numbers). The numbers are for the percent= age of total CPU for all packets sent, but since all packets were pretty mu= ch the same size, the numbers should still hold for a single packet. And bottom line, encryption is a lot more = of an impact than 10%. And as we bring in more performance improvements for= UDP send path in Windows, we expect encryption to be higher and higher per= centage.

=C2=A0

- Nick

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Saturday, June 23, 2018 12:00 AM
To: Nick Banks <nibanks@= microsoft.com>
Cc: Ian Swett <ianswett@go= ogle.com>; IETF QUIC WG <quic@ie= tf.org>; Praveen Balasubramanian <pravb@microsoft.com>
Subject: Re: Packet Number Encryption Performance

=C2=A0

IIUC, Ian should be talking about performance number= s that you would see on a server that is handling real workload. Not the br= eakdown of numbers within the QUIC stack.

=C2=A0

Let's talk about nanoseconds per packet rather t= han the ratio, because ratio depends on what you use as a "total"= is.

=C2=A0

My benchmarks tell me that, on OpenSSL 1.1.0 running= on Core i7 @ 2.5GHz (MacBook Pro 15" Mid 2015), the numbers are:

=C2=A0

without-PNE: 585ns / packet

with-PNE: 607ns / packet (* this is the optimized ve= rsion with 3.8% overhead)

=C2=A0

Assuming that your peak rate is 1Gbit/CPU core (woul= d be enough to saturate 25Gb Ethernet), the ratio of CPU cycles for running= the crypto will be:

=C2=A0

all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/p= acket =3D 5.93 %

PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet = =3D 0.22 %

=C2=A0

Of course, these numbers are what is expected when a= server is sending or receiving full-sized packets in one direction. In rea= lity, there would be at least some flow in the opposite direction, so the n= umber will be higher, but not as much as 2x. Or if you are sending small-sized packet in *both* directions *and*= saturating the link, the ratio will be higher.

=C2=A0

But looking at the numbers, I'd assume that 10% = is a logical number for workload Ian has, and also for people who are invol= ved in content distribution.

=C2=A0

As shown, I think that sharing the PPS and average p= acket size that our workload will have, along with the raw numbers of the c= rypto (i.e. nsec / packet) will give us a better understanding on how much = the actual overhead is. Do you mind sharing your expectations?

=C2=A0

2018-06-23 9:34 GMT+09:00 Nick Banks <nibanks@microsoft.com&g= t;:

Hey Guys,

=C2=A0

I spent the better part of the day getting some performance traces= of WinQuic without PNE. Our implementation supports both user mode and kernel m= ode, so I got numbers for both. The following table shows the relative CPU = cost of different parts of the QUIC send path:

=C2=A0

=C2=A0

User Mode

Kernel Mode

UDP Send

64.7%

41.4%

Encryption

22.5%

38.5%

Packet Building/Framing

7%

15%

Miscellaneous

5.8%

5.1%

=C2=A0

These numbers definitely show that encryption is a much larger por= tion of CPU.

=C2=A0

- Nick

=C2=A0

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, June 22, 2018 5:02 PM
To: Ian Swett <ianswett@google.com>
Cc: Nick Banks <nibanks@microsoft.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <= quic@ietf.org>


Subject: Re: Packet Number Encryption Performance

=C2=A0

=C2=A0

=C2=A0

2018-06-23 3:51 GMT+09:00 Ian Swett <ianswett@google.com>:

I expect crypto to increase as a fraction of CPU, but I don't = expect it to go much higher than 10%.

=C2=A0

But who knows, maybe 2 years from now everything else will be very= optimized and crypto will be 15%?

=C2=A0

Ian, thank you for sharing the proportion of CPU cycles we are lik= ely to spend for crypto.

=C2=A0

Your numbers relieves me, because even if the cost of crypto goes = to 15%, the overhead of PNE will be less than 1% (0.15*0.04=3D0.006).

=C2=A0

I would also like to note that it is likely that HyperThreading, w= hen used, will eliminate the overhead of PNE.

=C2=A0

This is because IIUC PNE is a marginal additional use of the AES-N= I engine, which have been mostly idle. The overhead of crypto is small (i.e= . 15%) that we will rarely see contention on the engine. While one hyperthread does AES, the other hyperthread will = run at full speed doing other operations.

=C2=A0

Also considering the fact that the number of CPU cycles spent per = QUIC packet does not change a lot with PNE, I would not be surprised to see= *no* decrease of throughput when PNE is used on a HyperThreading architecture. In such case, what we will only = observe is the raise of the utilization ratio of the AES-NI engine.

=C2=A0

=C2=A0

On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <nibanks=3D40microsoft.co= m@dmarc.ietf.org> wrote:

I just want to add, my implementation already uses ECB from bcrypt= (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directl= y.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance

=C2=A0

Ian, do you expect that fraction of overall cost to hold once the = UDP stack is optimized? Is your measurement on top of the recent kernel imp= rovements? I expect crypto fraction of overall cost to keep increasing over time as the network stack bottlene= cks are eliminated.

=C2=A0

Kazuho, should the draft describe the optimizations you are making= ? Or are these are too OpenSSL specific?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

=C2=A0

Thanks for digging into the details of this, Kazuho.=C2=A0 <4% = increase in crypto cost is a bit more than I originally expected(~2%), but = crypto is less than 10% of my CPU usage, so it's still less than 0.5% total, which is acceptable to me.

=C2=A0

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

=C2=A0

=C2=A0

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:

=C2=A0

=C2=A0

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit confused wher= e you say you can reduce the 10% overhead to 2% to 4%. How do you plan on d= oing that?

=C2=A0

As stated in my previous mail, the 10% of overhead consists of thr= ee parts, each consuming comparable number of CPU cycles. The two among the= three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB = operation cost.

=C2=A0

It should be able to remove the costly abstraction layer.

=C2=A0

It should also be possible to remove the overhead of CTR, since in= PNE, we need to XOR at most 4 octets (applying XOR is the only difference = between CTR and ECB). That cost should be something that should be possible to be nullified.

=C2=A0

Considering these aspects, and by looking at the numbers on the Op= enSSL source code (as well as considering the overhead of GCM), my expectat= ion goes to 2% to 4%.

=C2=A0

Just did some experiments and it seems that the expectation was co= rrect.

=C2=A0

The benchmarks tell me that the overhead goes down from 10.0% to 3= .8%, by doing the following:

=C2=A0

* remove the overhead of CTR abstraction (i.e. use the ECB backend= and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e. call the meth= od returned by EVP_CIPHER_meth_get_do_cipher instead of calling EVP_Encrypt= Update)

=C2=A0

Of course the changes are specific to OpenSSL, but I would expect = that you can expect similar numbers assuming that you have access to an opt= imized AES implementation.

=C2=A0

=C2=A0

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance

=C2=A0

Hi Nick,

=C2=A0

Thank you for bringing the numbers to the list.

=C2=A0

I have just run a small benchmark using Quicly, and I see comparab= le numbers.

=C2=A0

To be precise, I see 10.0% increase of CPU cycles when encrypting = a Initial packet of 1,280 octets. I expect that we will see similar numbers= on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparin= g the cost of encryption, the overhead ratio will be much smaller if we loo= k at the total number of CPU cycles spent by a QUIC stack as a whole.

=C2=A0

Looking at the profile, the overhead consists of three operations = that each consumes comparable CPU cycles: core AES operation (using AES-NI)= , CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the = AEAD interface, which is to be used by the QUIC stacks.

=C2=A0

I would assume that we can cut down the overhead to somewhere betw= een 2% to 4%, but it might be hard to go down to somewhere near 1%, because= we cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni= -x86_64.pl#L24-L39 about the impact of parallelization).

=C2=A0

I do not think that 2% to 4% of additional overhead to the crypto = is an issue for QUIC/HTTP, but current overhead of 10% is something that we= might want to decrease. I am glad to be able to learn that now.

=C2=A0

=C2=A0

2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=3D40microsoft.= com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt APIs) and I d= ecided to get some performance numbers to see what the overhead of PNE was.= I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependent on the test = case) 10,000,000 times and measured the time it took. The test then did the= same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

=C2=A0

=C2=A0

=C2=A0

Time (ms)

Rate (Mbps)

Bytes

NO PNE

PNE

PNE Overhead

No PNE

PNE

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my disposal, running th= e latest Windows 10 Server DataCenter build. Again, these numbers are for c= rypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku

--0000000000009fd1ad056f51cafc-- From nobody Sat Jun 23 09:49:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF090131038 for ; Sat, 23 Jun 2018 09:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXM4Ob6Qu4pY for ; Sat, 23 Jun 2018 09:49:24 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2191130E96 for ; Sat, 23 Jun 2018 09:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QPdfp5IMRD/loZSoeIFEPbFgDL7Y8Fyrf/CYX4BFTHI=; b=HnU9+gL724lCEaua8aMk1R+Rcj/qy6W0aqewJjaFr0SR0GxapyMaXG1ziWPWWKevf+py0PADcnl+oq1i0V3iZ9Vb8F8rxhNtSgB4ohV/4e92kLY61cZ6xbT/gU1ehQVb0F4dubVjVnym1pML/NJFRb8pHEnib/D0Xk1sJjOJ3PQ= Received: from MW2PR2101MB0908.namprd21.prod.outlook.com (52.132.152.28) by MW2PR2101MB1002.namprd21.prod.outlook.com (52.132.146.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.2; Sat, 23 Jun 2018 16:49:20 +0000 Received: from MW2PR2101MB0908.namprd21.prod.outlook.com ([fe80::b10b:34e9:2e4d:839d]) by MW2PR2101MB0908.namprd21.prod.outlook.com ([fe80::b10b:34e9:2e4d:839d%5]) with mapi id 15.20.0930.004; Sat, 23 Jun 2018 16:49:20 +0000 From: Nick Banks To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Kazuho Oku CC: Ian Swett , Praveen Balasubramanian Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgAAAjosmAATQHgAACtMrgAABFu2QAA2HWoAAECJDgAAEGKMAAABGCwA= Date: Sat, 23 Jun 2018 16:49:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-23T16:49:18.3052145Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8:656c:bd3d:ead:b82f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB1002; 7:EBKG3zcgwUxfvILOfNXikSq9tzwe2Mhy7Kxbc4xROXpDwh51lwwTZ2hOmVLFDY/v9RY1tLHACTe1ev20PhOu6h4BEs8yWrxlefmUYUb1wAS9fN1pRBWuRxdKAjznPX9ZvzY20/T7nfTlPBjL7m0dWCvKd6dy9/UQP/PC1zYArMhQYFV4MgvbRBHWhNyRrG7sLZf33V06W4R1FEi+vqlq9OpmMCimWLl0J+/X50vfh95uEZ84xt7t9cE5kZBk7bll x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 12ce812c-d13b-4000-d0a6-08d5d9294462 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR2101MB1002; x-ms-traffictypediagnostic: MW2PR2101MB1002: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(211936372134217)(153496737603132)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MW2PR2101MB1002; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB1002; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(39380400002)(346002)(376002)(199004)(189003)(51444003)(10090500001)(476003)(33656002)(446003)(68736007)(102836004)(11346002)(106356001)(186003)(316002)(966005)(54906003)(107886003)(110136005)(486006)(606006)(46003)(99286004)(105586002)(440504004)(10290500003)(517774005)(25786009)(7736002)(74316002)(4326008)(39060400002)(14454004)(478600001)(3280700002)(6246003)(6436002)(19609705001)(55016002)(229853002)(3660700001)(5250100002)(5660300001)(561924002)(6116002)(8676002)(8936002)(790700001)(2906002)(8990500004)(53946003)(5890100001)(16200700003)(76176011)(59450400001)(81166006)(86612001)(53936002)(7696005)(81156014)(97736004)(6306002)(54896002)(22452003)(2900100001)(93886005)(53546011)(345774005)(86362001)(6506007)(5070765005)(3480700004)(9686003)(236005)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1002; H:MW2PR2101MB0908.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5uEoPQ63XFivdS4CqjO7Qxc/l0IZ+yguQVq2OCcuXj0DKWUBXtF7RZ2GxOw3+kumfqneDyH1n6WxfPbftwwjrsrmjab9ZYGESjumN7h+ddZnSZ2zD3EuHzjpDF5pxTKy9/ZNxXbtpw+YYwRTiFFDA2zaz2/0O9yifcUsdlx5wUZX0dPpa41AMn2AyvQSGnpmttBuEpF9ulyzUeVvjIMed/OMxM7eqCwzq1LJ4PoTBIQBjaeEqpgEBZ+MqkqBR3edGYzBGmao5lYDYxtyiL8Jes05lL1SG4GpKMakWAPzXW042LsCQ0EudaIQGbkCMN5On1/IslKupHJL4MoJutHk/1zn4q17BrGv5ldu2Cxgj5U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB090823CCBAE4C835E8F866ACB3740MW2PR2101MB0908_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12ce812c-d13b-4000-d0a6-08d5d9294462 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 16:49:20.6255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1002 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 16:49:30 -0000 --_000_MW2PR2101MB090823CCBAE4C835E8F866ACB3740MW2PR2101MB0908_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaWRu4oCZdCBydW4gYW55IFFVSUMgZW5kLXRvLWVuZCBtZWFzdXJlbWVudHMgZm9yIHNlbmRp bmcgc21hbGwgcGFja2V0cywgc28gSSBjYW5ub3QgZGVmaW5pdGVseSBzYXkgd2hhdCB0aGUgb3Zl cmhlYWQgaXMsIHBlcmNlbnRhZ2Utd2lzZSwgb2YgZW5jcnlwdGlvbiwgYnV0IEkgZG8gdGhpbmsg aXQgd291bGQgYmUgaGlnaGVyLg0KDQotIE5pY2sNCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KU2VudDogU2F0dXJkYXksIEp1bmUgMjMsIDIw MTggOTozOSBBTQ0KVG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE5pY2sgQmFua3Mg PG5pYmFua3NAbWljcm9zb2Z0LmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+ DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgUHJhdmVlbiBCYWxhc3VicmFt YW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSRTogUGFja2V0IE51bWJlciBF bmNyeXB0aW9uIFBlcmZvcm1hbmNlDQoNCkhpIE5pY2ssIGhvdyBhYm91dCBudW1iZXJzIGZvciBz bWFsbCBwYWNrZXRzPyBTbyBJIHByZXN1bWUgdGhlIG92ZXJoZWFkIG9mIFBORSB3aWxsIGJlIG11 Y2ggbGFyZ2VyIGhlcmUgYmVjYXVzZSBQTkUgZG9lcyBub3QgcGlwZWxpbmUgd2hpbGUgYSA2NCBi eXRlIHBheWxvYWQganVzdCBhYm91dCBtYW5hZ2VzIHRpbCBhbiBBRVMgcGlwZWxpbmUgZGVwZW5k aW5nIG9uIGFyY2guDQoNCk1pa2tlbA0KDQoNCk9uIDIzIEp1bmUgMjAxOCBhdCAxNi41NC40Miwg TmljayBCYW5rcyAobmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv Om5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPikgd3JvdGU6DQpJIGFncmVl IHRoYXQgdGhlIG51bWJlcnMgZm9yIHJlYWwgd29yayBsb2FkcyB3aWxsIGJlIGludGVyZXN0aW5n LCBidXQgSSBkbyBiZWxpZXZlIHRoYXQgcmF3IFFVSUMgc3RhY2sgbnVtYmVycyBhcmUgYWxzbyBp bXBvcnRhbnQuIFRoZXkgd2lsbCByZXByZXNlbnQgeW91ciBiZXN0IGNhc2Ugc2NlbmFyaW8uDQoN CkZvciBteSB0ZXN0aW5nLCBJIGhhdmUgYSBmYWlybHkgc2ltcGxlIHRlc3Qgb2Ygb3BlbmluZyBh IHNpbmdsZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW0gYW5kIGp1c3QgY29udGludWFsbHkgc2VuZGlu ZyBkYXRhIHVudGlsIHRoZSBjb3JlIGdldHMgc2F0dXJhdGVkLiBGcm9tIHRoYXQsIEkgZ3JhYiB0 aGUgcGVyZm9ybWFuY2UgdHJhY2UsIGFuZCBzcGVjaWZpY2FsbHkgbG9vayBhdCB0aGUgY29tcG9z aXRpb24gb2YgdGhlIFFVSUMgc3RhY2vigJlzIHNlbmQgcGF0aC4gVGhlIHNlbmQgcGF0aCBjb25z dGl0dXRlcyBnZW5lcmFsbHkgYWxsIG9mIHRoZSBDUFUgZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9u IGFueXdheXMgKHdpdGgganVzdCBhIGxpdHRsZSBvdmVyaGVhZCBzZWVuIGZyb20gcmVjZWl2aW5n IGFuZCBwcm9jZXNzaW5nIEFDS3MpLiBUaGUgbWFjaGluZSBJIHVzZWQgd2FzIGFub3RoZXIgc2Vy dmVyIGdyYWRlIG1hY2hpbmUgcnVubmluZyB0aGUgbGF0ZXN0IFdpbmRvd3MgMTAgU2VydmVyIERh dGFjZW50ZXIuDQoNClNvIHRoZSBwZXJjZW50YWdlcyBJIHNoYXJlZCBhcmUgZm9yIGp1c3QgdGhl IFFVSUMgc2VuZCBwYXRoIChhZ2Fpbiwgbm8gUE5FIHdpdGggdGhlc2UgbnVtYmVycykuIFRoZSBu dW1iZXJzIGFyZSBmb3IgdGhlIHBlcmNlbnRhZ2Ugb2YgdG90YWwgQ1BVIGZvciBhbGwgcGFja2V0 cyBzZW50LCBidXQgc2luY2UgYWxsIHBhY2tldHMgd2VyZSBwcmV0dHkgbXVjaCB0aGUgc2FtZSBz aXplLCB0aGUgbnVtYmVycyBzaG91bGQgc3RpbGwgaG9sZCBmb3IgYSBzaW5nbGUgcGFja2V0LiBB bmQgYm90dG9tIGxpbmUsIGVuY3J5cHRpb24gaXMgYSBsb3QgbW9yZSBvZiBhbiBpbXBhY3QgdGhh biAxMCUuIEFuZCBhcyB3ZSBicmluZyBpbiBtb3JlIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyBm b3IgVURQIHNlbmQgcGF0aCBpbiBXaW5kb3dzLCB3ZSBleHBlY3QgZW5jcnlwdGlvbiB0byBiZSBo aWdoZXIgYW5kIGhpZ2hlciBwZXJjZW50YWdlLg0KDQotIE5pY2sNCg0KRnJvbTogS2F6dWhvIE9r dSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpTZW50 OiBTYXR1cmRheSwgSnVuZSAyMywgMjAxOCAxMjowMCBBTQ0KVG86IE5pY2sgQmFua3MgPG5pYmFu a3NAbWljcm9zb2Z0LmNvbTxtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBJYW4g U3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+Pjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNy b3NvZnQuY29tPj4NClN1YmplY3Q6IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9y bWFuY2UNCg0KSUlVQywgSWFuIHNob3VsZCBiZSB0YWxraW5nIGFib3V0IHBlcmZvcm1hbmNlIG51 bWJlcnMgdGhhdCB5b3Ugd291bGQgc2VlIG9uIGEgc2VydmVyIHRoYXQgaXMgaGFuZGxpbmcgcmVh bCB3b3JrbG9hZC4gTm90IHRoZSBicmVha2Rvd24gb2YgbnVtYmVycyB3aXRoaW4gdGhlIFFVSUMg c3RhY2suDQoNCkxldCdzIHRhbGsgYWJvdXQgbmFub3NlY29uZHMgcGVyIHBhY2tldCByYXRoZXIg dGhhbiB0aGUgcmF0aW8sIGJlY2F1c2UgcmF0aW8gZGVwZW5kcyBvbiB3aGF0IHlvdSB1c2UgYXMg YSAidG90YWwiIGlzLg0KDQpNeSBiZW5jaG1hcmtzIHRlbGwgbWUgdGhhdCwgb24gT3BlblNTTCAx LjEuMCBydW5uaW5nIG9uIENvcmUgaTcgQCAyLjVHSHogKE1hY0Jvb2sgUHJvIDE1IiBNaWQgMjAx NSksIHRoZSBudW1iZXJzIGFyZToNCg0Kd2l0aG91dC1QTkU6IDU4NW5zIC8gcGFja2V0DQp3aXRo LVBORTogNjA3bnMgLyBwYWNrZXQgKCogdGhpcyBpcyB0aGUgb3B0aW1pemVkIHZlcnNpb24gd2l0 aCAzLjglIG92ZXJoZWFkKQ0KDQpBc3N1bWluZyB0aGF0IHlvdXIgcGVhayByYXRlIGlzIDFHYml0 L0NQVSBjb3JlICh3b3VsZCBiZSBlbm91Z2ggdG8gc2F0dXJhdGUgMjVHYiBFdGhlcm5ldCksIHRo ZSByYXRpbyBvZiBDUFUgY3ljbGVzIGZvciBydW5uaW5nIHRoZSBjcnlwdG8gd2lsbCBiZToNCg0K YWxsIGNyeXB0bzogMC4xMjVHQi9zZWMgLyAxMjgwYnl0ZXMvcGFja2V0ICogNjA3bnMvcGFja2V0 ID0gNS45MyAlDQpQTkU6IDAuMTI1R0Ivc2VjIC8gMTI4MGJ5dGVzL3BhY2tldCAqIDIyLjRucy9w YWNrZXQgPSAwLjIyICUNCg0KT2YgY291cnNlLCB0aGVzZSBudW1iZXJzIGFyZSB3aGF0IGlzIGV4 cGVjdGVkIHdoZW4gYSBzZXJ2ZXIgaXMgc2VuZGluZyBvciByZWNlaXZpbmcgZnVsbC1zaXplZCBw YWNrZXRzIGluIG9uZSBkaXJlY3Rpb24uIEluIHJlYWxpdHksIHRoZXJlIHdvdWxkIGJlIGF0IGxl YXN0IHNvbWUgZmxvdyBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLCBzbyB0aGUgbnVtYmVyIHdp bGwgYmUgaGlnaGVyLCBidXQgbm90IGFzIG11Y2ggYXMgMnguIE9yIGlmIHlvdSBhcmUgc2VuZGlu ZyBzbWFsbC1zaXplZCBwYWNrZXQgaW4gKmJvdGgqIGRpcmVjdGlvbnMgKmFuZCogc2F0dXJhdGlu ZyB0aGUgbGluaywgdGhlIHJhdGlvIHdpbGwgYmUgaGlnaGVyLg0KDQpCdXQgbG9va2luZyBhdCB0 aGUgbnVtYmVycywgSSdkIGFzc3VtZSB0aGF0IDEwJSBpcyBhIGxvZ2ljYWwgbnVtYmVyIGZvciB3 b3JrbG9hZCBJYW4gaGFzLCBhbmQgYWxzbyBmb3IgcGVvcGxlIHdobyBhcmUgaW52b2x2ZWQgaW4g Y29udGVudCBkaXN0cmlidXRpb24uDQoNCkFzIHNob3duLCBJIHRoaW5rIHRoYXQgc2hhcmluZyB0 aGUgUFBTIGFuZCBhdmVyYWdlIHBhY2tldCBzaXplIHRoYXQgb3VyIHdvcmtsb2FkIHdpbGwgaGF2 ZSwgYWxvbmcgd2l0aCB0aGUgcmF3IG51bWJlcnMgb2YgdGhlIGNyeXB0byAoaS5lLiBuc2VjIC8g cGFja2V0KSB3aWxsIGdpdmUgdXMgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvbiBob3cgbXVjaCB0 aGUgYWN0dWFsIG92ZXJoZWFkIGlzLiBEbyB5b3UgbWluZCBzaGFyaW5nIHlvdXIgZXhwZWN0YXRp b25zPw0KDQoyMDE4LTA2LTIzIDk6MzQgR01UKzA5OjAwIE5pY2sgQmFua3MgPG5pYmFua3NAbWlj cm9zb2Z0LmNvbTxtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tPj46DQpIZXkgR3V5cywNCg0K SSBzcGVudCB0aGUgYmV0dGVyIHBhcnQgb2YgdGhlIGRheSBnZXR0aW5nIHNvbWUgcGVyZm9ybWFu Y2UgdHJhY2VzIG9mIFdpblF1aWMgd2l0aG91dCBQTkUuIE91ciBpbXBsZW1lbnRhdGlvbiBzdXBw b3J0cyBib3RoIHVzZXIgbW9kZSBhbmQga2VybmVsIG1vZGUsIHNvIEkgZ290IG51bWJlcnMgZm9y IGJvdGguIFRoZSBmb2xsb3dpbmcgdGFibGUgc2hvd3MgdGhlIHJlbGF0aXZlIENQVSBjb3N0IG9m IGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgUVVJQyBzZW5kIHBhdGg6DQoNCg0KDQpVc2VyIE1vZGUN Cg0KS2VybmVsIE1vZGUNCg0KVURQIFNlbmQNCg0KNjQuNyUNCg0KNDEuNCUNCg0KRW5jcnlwdGlv bg0KDQoyMi41JQ0KDQozOC41JQ0KDQpQYWNrZXQgQnVpbGRpbmcvRnJhbWluZw0KDQo3JQ0KDQox NSUNCg0KTWlzY2VsbGFuZW91cw0KDQo1LjglDQoNCjUuMSUNCg0KDQpUaGVzZSBudW1iZXJzIGRl ZmluaXRlbHkgc2hvdyB0aGF0IGVuY3J5cHRpb24gaXMgYSBtdWNoIGxhcmdlciBwb3J0aW9uIG9m IENQVS4NCg0KLSBOaWNrDQoNCg0KRnJvbTogS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNv bTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpTZW50OiBGcmlkYXksIEp1bmUgMjIsIDIw MTggNTowMiBQTQ0KVG86IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbT4+DQpDYzogTmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29t PG1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20+PjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g PHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NCg0KU3ViamVjdDog UmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5jZQ0KDQoNCg0KMjAxOC0wNi0y MyAzOjUxIEdNVCswOTowMCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlh bnN3ZXR0QGdvb2dsZS5jb20+PjoNCkkgZXhwZWN0IGNyeXB0byB0byBpbmNyZWFzZSBhcyBhIGZy YWN0aW9uIG9mIENQVSwgYnV0IEkgZG9uJ3QgZXhwZWN0IGl0IHRvIGdvIG11Y2ggaGlnaGVyIHRo YW4gMTAlLg0KDQpCdXQgd2hvIGtub3dzLCBtYXliZSAyIHllYXJzIGZyb20gbm93IGV2ZXJ5dGhp bmcgZWxzZSB3aWxsIGJlIHZlcnkgb3B0aW1pemVkIGFuZCBjcnlwdG8gd2lsbCBiZSAxNSU/DQoN CklhbiwgdGhhbmsgeW91IGZvciBzaGFyaW5nIHRoZSBwcm9wb3J0aW9uIG9mIENQVSBjeWNsZXMg d2UgYXJlIGxpa2VseSB0byBzcGVuZCBmb3IgY3J5cHRvLg0KDQpZb3VyIG51bWJlcnMgcmVsaWV2 ZXMgbWUsIGJlY2F1c2UgZXZlbiBpZiB0aGUgY29zdCBvZiBjcnlwdG8gZ29lcyB0byAxNSUsIHRo ZSBvdmVyaGVhZCBvZiBQTkUgd2lsbCBiZSBsZXNzIHRoYW4gMSUgKDAuMTUqMC4wND0wLjAwNiku DQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIG5vdGUgdGhhdCBpdCBpcyBsaWtlbHkgdGhhdCBIeXBl clRocmVhZGluZywgd2hlbiB1c2VkLCB3aWxsIGVsaW1pbmF0ZSB0aGUgb3ZlcmhlYWQgb2YgUE5F Lg0KDQpUaGlzIGlzIGJlY2F1c2UgSUlVQyBQTkUgaXMgYSBtYXJnaW5hbCBhZGRpdGlvbmFsIHVz ZSBvZiB0aGUgQUVTLU5JIGVuZ2luZSwgd2hpY2ggaGF2ZSBiZWVuIG1vc3RseSBpZGxlLiBUaGUg b3ZlcmhlYWQgb2YgY3J5cHRvIGlzIHNtYWxsIChpLmUuLiAxNSUpIHRoYXQgd2Ugd2lsbCByYXJl bHkgc2VlIGNvbnRlbnRpb24gb24gdGhlIGVuZ2luZS4gV2hpbGUgb25lIGh5cGVydGhyZWFkIGRv ZXMgQUVTLCB0aGUgb3RoZXIgaHlwZXJ0aHJlYWQgd2lsbCBydW4gYXQgZnVsbCBzcGVlZCBkb2lu ZyBvdGhlciBvcGVyYXRpb25zLg0KDQpBbHNvIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgdGhl IG51bWJlciBvZiBDUFUgY3ljbGVzIHNwZW50IHBlciBRVUlDIHBhY2tldCBkb2VzIG5vdCBjaGFu Z2UgYSBsb3Qgd2l0aCBQTkUsIEkgd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWUgKm5vKiBk ZWNyZWFzZSBvZiB0aHJvdWdocHV0IHdoZW4gUE5FIGlzIHVzZWQgb24gYSBIeXBlclRocmVhZGlu ZyBhcmNoaXRlY3R1cmUuIEluIHN1Y2ggY2FzZSwgd2hhdCB3ZSB3aWxsIG9ubHkgb2JzZXJ2ZSBp cyB0aGUgcmFpc2Ugb2YgdGhlIHV0aWxpemF0aW9uIHJhdGlvIG9mIHRoZSBBRVMtTkkgZW5naW5l Lg0KDQoNCk9uIEZyaSwgSnVuIDIyLCAyMDE4IGF0IDEyOjM0IFBNIE5pY2sgQmFua3MgPG5pYmFu a3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkganVzdCB3YW50IHRvIGFkZCwgbXkgaW1wbGVtZW50 YXRpb24gYWxyZWFkeSB1c2VzIEVDQiBmcm9tIGJjcnlwdCAoYW5kIEkgZG8gdGhlIFhPUikgYWxy ZWFkeS4gQmNyeXB0IGRvZXNu4oCZdCBleHBvc2UgQ1RSIG1vZGUgZGlyZWN0bHkuDQoNClNlbnQg ZnJvbSBNYWlsPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGZ28ubWljcm9zb2Z0LmNvbSUyRmZ3bGluayUyRiUzRkxpbmtJZCUz RDU1MDk4NiZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2U2ZWZhMzYz YmMyNTQ3MTY3YThjMDhkNWQ4OWM4MGU3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjY1MzA4OTA1OTI2ODgzNiZzZGF0YT1hZVU3ajVsaENJTTE4S0c1YzZv cEc0cDdhbXdoQ1diUm5mbm04c0RXN2hjJTNEJnJlc2VydmVkPTA+IGZvciBXaW5kb3dzIDEwDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBQcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbg0KU2VudDogRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDk6MjY6NDQgQU0NClRvOiBJYW4g U3dldHQ7IEthenVobyBPa3UNCkNjOiBOaWNrIEJhbmtzOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6 IFJFOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2UNCg0KSWFuLCBkbyB5b3Ug ZXhwZWN0IHRoYXQgZnJhY3Rpb24gb2Ygb3ZlcmFsbCBjb3N0IHRvIGhvbGQgb25jZSB0aGUgVURQ IHN0YWNrIGlzIG9wdGltaXplZD8gSXMgeW91ciBtZWFzdXJlbWVudCBvbiB0b3Agb2YgdGhlIHJl Y2VudCBrZXJuZWwgaW1wcm92ZW1lbnRzPyBJIGV4cGVjdCBjcnlwdG8gZnJhY3Rpb24gb2Ygb3Zl cmFsbCBjb3N0IHRvIGtlZXAgaW5jcmVhc2luZyBvdmVyIHRpbWUgYXMgdGhlIG5ldHdvcmsgc3Rh Y2sgYm90dGxlbmVja3MgYXJlIGVsaW1pbmF0ZWQuDQoNCkthenVobywgc2hvdWxkIHRoZSBkcmFm dCBkZXNjcmliZSB0aGUgb3B0aW1pemF0aW9ucyB5b3UgYXJlIG1ha2luZz8gT3IgYXJlIHRoZXNl IGFyZSB0b28gT3BlblNTTCBzcGVjaWZpYz8NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IElhbiBTd2V0dA0KU2VudDogRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDQ6NDUgQU0NClRvOiBLYXp1 aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4N CkNjOiBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb208bWFpbHRvOm5pYmFua3NAbWlj cm9zb2Z0LmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBQZXJmb3JtYW5j ZQ0KDQpUaGFua3MgZm9yIGRpZ2dpbmcgaW50byB0aGUgZGV0YWlscyBvZiB0aGlzLCBLYXp1aG8u ICA8NCUgaW5jcmVhc2UgaW4gY3J5cHRvIGNvc3QgaXMgYSBiaXQgbW9yZSB0aGFuIEkgb3JpZ2lu YWxseSBleHBlY3RlZCh+MiUpLCBidXQgY3J5cHRvIGlzIGxlc3MgdGhhbiAxMCUgb2YgbXkgQ1BV IHVzYWdlLCBzbyBpdCdzIHN0aWxsIGxlc3MgdGhhbiAwLjUlIHRvdGFsLCB3aGljaCBpcyBhY2Nl cHRhYmxlIHRvIG1lLg0KDQpPbiBGcmksIEp1biAyMiwgMjAxOCBhdCAyOjQ1IEFNIEthenVobyBP a3UgPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KDQoyMDE4LTA2LTIyIDEyOjIyIEdNVCswOTowMCBLYXp1aG8gT2t1IDxrYXp1aG9va3VA Z21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj46DQoNCg0KMjAxOC0wNi0yMiAx MTo1NCBHTVQrMDk6MDAgTmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPG1haWx0bzpu aWJhbmtzQG1pY3Jvc29mdC5jb20+PjoNCkhpIEthenVobywNCg0KVGhhbmtzIGZvciBzaGFyaW5n IHlvdXIgbnVtYmVycyBhcyB3ZWxsISBJJ20gYml0IGNvbmZ1c2VkIHdoZXJlIHlvdSBzYXkgeW91 IGNhbiByZWR1Y2UgdGhlIDEwJSBvdmVyaGVhZCB0byAyJSB0byA0JS4gSG93IGRvIHlvdSBwbGFu IG9uIGRvaW5nIHRoYXQ/DQoNCkFzIHN0YXRlZCBpbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgMTAl IG9mIG92ZXJoZWFkIGNvbnNpc3RzIG9mIHRocmVlIHBhcnRzLCBlYWNoIGNvbnN1bWluZyBjb21w YXJhYmxlIG51bWJlciBvZiBDUFUgY3ljbGVzLiBUaGUgdHdvIGFtb25nIHRoZSB0aHJlZSBpcyBy ZWxhdGVkIHRvIHRoZSBhYnN0cmFjdGlvbiBsYXllciBhbmQgaG93IENUUiBpcyBpbXBsZW1lbnRl ZCwgd2hpbGUgdGhlIG90aGVyIG9uZSBpcyB0aGUgY29yZSBBRVMtRUNCIG9wZXJhdGlvbiBjb3N0 Lg0KDQpJdCBzaG91bGQgYmUgYWJsZSB0byByZW1vdmUgdGhlIGNvc3RseSBhYnN0cmFjdGlvbiBs YXllci4NCg0KSXQgc2hvdWxkIGFsc28gYmUgcG9zc2libGUgdG8gcmVtb3ZlIHRoZSBvdmVyaGVh ZCBvZiBDVFIsIHNpbmNlIGluIFBORSwgd2UgbmVlZCB0byBYT1IgYXQgbW9zdCA0IG9jdGV0cyAo YXBwbHlpbmcgWE9SIGlzIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiBDVFIgYW5kIEVDQiku IFRoYXQgY29zdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRv IGJlIG51bGxpZmllZC4NCg0KQ29uc2lkZXJpbmcgdGhlc2UgYXNwZWN0cywgYW5kIGJ5IGxvb2tp bmcgYXQgdGhlIG51bWJlcnMgb24gdGhlIE9wZW5TU0wgc291cmNlIGNvZGUgKGFzIHdlbGwgYXMg Y29uc2lkZXJpbmcgdGhlIG92ZXJoZWFkIG9mIEdDTSksIG15IGV4cGVjdGF0aW9uIGdvZXMgdG8g MiUgdG8gNCUuDQoNCkp1c3QgZGlkIHNvbWUgZXhwZXJpbWVudHMgYW5kIGl0IHNlZW1zIHRoYXQg dGhlIGV4cGVjdGF0aW9uIHdhcyBjb3JyZWN0Lg0KDQpUaGUgYmVuY2htYXJrcyB0ZWxsIG1lIHRo YXQgdGhlIG92ZXJoZWFkIGdvZXMgZG93biBmcm9tIDEwLjAlIHRvIDMuLjglLCBieSBkb2luZyB0 aGUgZm9sbG93aW5nOg0KDQoqIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2YgQ1RSIGFic3RyYWN0aW9u IChpLmUuIHVzZSB0aGUgRUNCIGJhY2tlbmQgYW5kIGRvIFhPUiBieSBvdXJzZWx2ZXMpDQoqIHJl bW92ZSB0aGUgb3ZlcmhlYWQgb2YgdGhlIGFic3RyYWN0aW9uIGxheWVyIChpLmUuIGNhbGwgdGhl IG1ldGhvZCByZXR1cm5lZCBieSBFVlBfQ0lQSEVSX21ldGhfZ2V0X2RvX2NpcGhlciBpbnN0ZWFk IG9mIGNhbGxpbmcgRVZQX0VuY3J5cHRVcGRhdGUpDQoNCk9mIGNvdXJzZSB0aGUgY2hhbmdlcyBh cmUgc3BlY2lmaWMgdG8gT3BlblNTTCwgYnV0IEkgd291bGQgZXhwZWN0IHRoYXQgeW91IGNhbiBl eHBlY3Qgc2ltaWxhciBudW1iZXJzIGFzc3VtaW5nIHRoYXQgeW91IGhhdmUgYWNjZXNzIHRvIGFu IG9wdGltaXplZCBBRVMgaW1wbGVtZW50YXRpb24uDQoNCg0KDQpTZW50IGZyb20gbXkgV2luZG93 cyAxMCBwaG9uZQ0KW0h4UyAtIDE1MjU0IC0gMTYuMC4xMDIyOC4yMDA3NV0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEthenVobyBPa3UgPGthenVob29rdUBnbWFp bC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEp1bmUg MjEsIDIwMTggNzoyMToxNyBQTQ0KVG86IE5pY2sgQmFua3MNCkNjOiBxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlv biBQZXJmb3JtYW5jZQ0KDQpIaSBOaWNrLA0KDQpUaGFuayB5b3UgZm9yIGJyaW5naW5nIHRoZSBu dW1iZXJzIHRvIHRoZSBsaXN0Lg0KDQpJIGhhdmUganVzdCBydW4gYSBzbWFsbCBiZW5jaG1hcmsg dXNpbmcgUXVpY2x5LCBhbmQgSSBzZWUgY29tcGFyYWJsZSBudW1iZXJzLg0KDQpUbyBiZSBwcmVj aXNlLCBJIHNlZSAxMC4wJSBpbmNyZWFzZSBvZiBDUFUgY3ljbGVzIHdoZW4gZW5jcnlwdGluZyBh IEluaXRpYWwgcGFja2V0IG9mIDEsMjgwIG9jdGV0cy4gSSBleHBlY3QgdGhhdCB3ZSB3aWxsIHNl ZSBzaW1pbGFyIG51bWJlcnMgb24gb3RoZXIgUVVJQyBzdGFja3MgdGhhdCBhbHNvIHVzZSBwaWNv dGxzICh3aXRoIE9wZW5TU0wgYXMgYSBiYWNrZW5kKS4gTm90ZSB0aGF0IHRoZSBudW1iZXIgaXMg b25seSBjb21wYXJpbmcgdGhlIGNvc3Qgb2YgZW5jcnlwdGlvbiwgdGhlIG92ZXJoZWFkIHJhdGlv IHdpbGwgYmUgbXVjaCBzbWFsbGVyIGlmIHdlIGxvb2sgYXQgdGhlIHRvdGFsIG51bWJlciBvZiBD UFUgY3ljbGVzIHNwZW50IGJ5IGEgUVVJQyBzdGFjayBhcyBhIHdob2xlLg0KDQpMb29raW5nIGF0 IHRoZSBwcm9maWxlLCB0aGUgb3ZlcmhlYWQgY29uc2lzdHMgb2YgdGhyZWUgb3BlcmF0aW9ucyB0 aGF0IGVhY2ggY29uc3VtZXMgY29tcGFyYWJsZSBDUFUgY3ljbGVzOiBjb3JlIEFFUyBvcGVyYXRp b24gKHVzaW5nIEFFUy1OSSksIENUUiBvcGVyYXRpb24gb3ZlcmhlYWQsIENUUiBpbml0aWFsaXph dGlvbi4gTm90ZSB0aGF0IHBpY290bHMgYXQgdGhlIG1vbWVudCBwcm92aWRlcyBhY2Nlc3MgdG8g Q1RSIGNyeXB0byBiZW5lYXRoIHRoZSBBRUFEIGludGVyZmFjZSwgd2hpY2ggaXMgdG8gYmUgdXNl ZCBieSB0aGUgUVVJQyBzdGFja3MuDQoNCkkgd291bGQgYXNzdW1lIHRoYXQgd2UgY2FuIGN1dCBk b3duIHRoZSBvdmVyaGVhZCB0byBzb21ld2hlcmUgYmV0d2VlbiAyJSB0byA0JSwgYnV0IGl0IG1p Z2h0IGJlIGhhcmQgdG8gZ28gZG93biB0byBzb21ld2hlcmUgbmVhciAxJSwgYmVjYXVzZSB3ZSBj YW5ub3QgcGFyYWxsZWxpemUgdGhlIEFFUyBvcGVyYXRpb24gb2YgUE5FIHdpdGggdGhhdCBvZiBB RUFEIChzZWUgaHR0cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9ibG9iL09wZW5TU0xf MV8xXzBoL2NyeXB0by9hZXMvYXNtL2Flc25pLXg4Nl82NC5wbCNMMjQtTDM5PGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi4ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZvcGVuc3NsJTJGb3BlbnNzbCUyRmJsb2IlMkZPcGVuU1NMXzFfMV8waCUyRmNy eXB0byUyRmFlcyUyRmFzbSUyRmFlc25pLXg4Nl82NC5wbCUyM0wyNC1MMzkmZGF0YT0wMiU3QzAx JTdDbmliYW5rcyU0MG1pY3Jvc29mdC5jb20lN0MxMWQ1NWYxNzMzM2U0YTc5NWQ3MDA4ZDVkN2U2 ZDkzYyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTIz MDg4NDM5OTQxMzQmc2RhdGE9a3FNejRTc04lMkYyRXJHSzA2UXo4WjB2VXpwbDRNaWlwbk5FMndB TVViNDZjJTNEJnJlc2VydmVkPTA+IGFib3V0IHRoZSBpbXBhY3Qgb2YgcGFyYWxsZWxpemF0aW9u KS4NCg0KSSBkbyBub3QgdGhpbmsgdGhhdCAyJSB0byA0JSBvZiBhZGRpdGlvbmFsIG92ZXJoZWFk IHRvIHRoZSBjcnlwdG8gaXMgYW4gaXNzdWUgZm9yIFFVSUMvSFRUUCwgYnV0IGN1cnJlbnQgb3Zl cmhlYWQgb2YgMTAlIGlzIHNvbWV0aGluZyB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZGVjcmVhc2Uu IEkgYW0gZ2xhZCB0byBiZSBhYmxlIHRvIGxlYXJuIHRoYXQgbm93Lg0KDQoNCjIwMTgtMDYtMjIg NTo0OCBHTVQrMDk6MDAgTmljayBCYW5rcyA8bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOm5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj46 DQpIZWxsbyBRVUlDIFdHLA0KDQpJIHJlY2VudGx5IGltcGxlbWVudGVkIFBORSBmb3IgV2luUXVp YyAodXNpbmcgYmNyeXB0IEFQSXMpIGFuZCBJIGRlY2lkZWQgdG8gZ2V0IHNvbWUgcGVyZm9ybWFu Y2UgbnVtYmVycyB0byBzZWUgd2hhdCB0aGUgb3ZlcmhlYWQgb2YgUE5FIHdhcy4gSSBmaWd1cmVk IHRoZSByZXN0IG9mIHRoZSBXRyBtaWdodCBiZSBpbnRlcmVzdGVkLg0KDQpNeSB0ZXN0IGp1c3Qg ZW5jcnlwdHMgdGhlIHNhbWUgYnVmZmVyIChzaXplIGRlcGVuZGVudCBvbiB0aGUgdGVzdCBjYXNl KSAxMCwwMDAsMDAwIHRpbWVzIGFuZCBtZWFzdXJlZCB0aGUgdGltZSBpdCB0b29rLiBUaGUgdGVz dCB0aGVuIGRpZCB0aGUgc2FtZSB0aGluZywgYnV0IGFsc28gZW5jcnlwdGVkIHRoZSBwYWNrZXQg bnVtYmVyIGFzIHdlbGwuIEkgcmFuIGFsbCB0aGF0IDEwIHRpbWVzIGluIHRvdGFsLiBJIHRoZW4g Y29sbGVjdGVkIHRoZSBiZXN0IHRpbWVzIGZvciBlYWNoIGNhdGVnb3J5IHRvIHByb2R1Y2UgdGhl IGZvbGxvd2luZyBncmFwaHMgYW5kIHRhYmxlcyAoZnVsbCBleGNlbCBkb2MgYXR0YWNoZWQpOg0K DQoNCg0KDQpUaW1lIChtcykNCg0KUmF0ZSAoTWJwcykNCg0KQnl0ZXMNCg0KTk8gUE5FDQoNClBO RQ0KDQpQTkUgT3ZlcmhlYWQNCg0KTm8gUE5FDQoNClBORQ0KDQo0DQoNCjIyODQuNjcxDQoNCjMw MjcuNjU3DQoNCjMzJQ0KDQoxNDAuMDY0DQoNCjEwNS42OTINCg0KMTYNCg0KMjEwMi40MDINCg0K MjgyOC4yMDQNCg0KMzUlDQoNCjYwOC44MjcNCg0KNDUyLjU4NA0KDQo2NA0KDQoyMTk4Ljg4Mw0K DQoyOTA3LjU3Nw0KDQozMiUNCg0KMjMyOC40NQ0KDQoxNzYwLjkyDQoNCjI1Ng0KDQoyNzU4LjMN Cg0KMzQ5MC4yOA0KDQoyNyUNCg0KNzQyNC44Ng0KDQo1ODY3LjcyDQoNCjYwMA0KDQo0NjY5LjI4 Mw0KDQo1NDI0LjUzOQ0KDQoxNiUNCg0KMTAyODANCg0KODg0OC42OA0KDQoxMDAwDQoNCjYxMzAu MTM5DQoNCjY5MDcuODA1DQoNCjEzJQ0KDQoxMzA1MC4zDQoNCjExNTgxLjENCg0KMTIwMA0KDQo2 NDU4LjY3OQ0KDQo3MjI5LjY3Mg0KDQoxMiUNCg0KMTQ4NjMuNw0KDQoxMzI3OC42DQoNCjE0NTAN Cg0KNzg3Ni4zMTINCg0KODY3MC4xNg0KDQoxMCUNCg0KMTQ3MjcuNw0KDQoxMzM3OS4yDQoNCg0K SSB1c2VkIGEgc2VydmVyIGdyYWRlIGxhYiBtYWNoaW5lIEkgaGFkIGF0IG15IGRpc3Bvc2FsLCBy dW5uaW5nIHRoZSBsYXRlc3QgV2luZG93cyAxMCBTZXJ2ZXIgRGF0YUNlbnRlciBidWlsZC4gQWdh aW4sIHRoZXNlIG51bWJlcnMgYXJlIGZvciBjcnlwdG8gb25seS4gTm8gUVVJQyBvciBVRFAgaXMg aW5jbHVkZWQuDQoNClRoYW5rcywNCi0gTmljaw0KDQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQoN Cg0KLS0NCkthenVobyBPa3UNCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQoNCg0KDQotLQ0KS2F6dWhv IE9rdQ0KDQoNCg0KLS0NCkthenVobyBPa3UNCg== --_000_MW2PR2101MB090823CCBAE4C835E8F866ACB3740MW2PR2101MB0908_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1z dHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLmdtYWlsLW02ODg2OTg2OTg5NjczMjk5MTg0bS04NDgyMjk2MzM5ODUyNTcxMjY5 bS04NDA4ODQ3NDI3MDkzMjIzNDc2bS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsLW02ODg2OTg2OTg5NjczMjk5MTg0bS04NDgyMjk2MzM5ODUyNTcxMjY5 bS04NDA4ODQ3NDI3MDkzMjIzNDc2bS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZGlkbuKAmXQgcnVuIGFueSBRVUlDIGVuZC10by1lbmQgbWVhc3VyZW1lbnRzIGZvciBzZW5k aW5nIHNtYWxsIHBhY2tldHMsIHNvIEkgY2Fubm90IGRlZmluaXRlbHkgc2F5IHdoYXQgdGhlIG92 ZXJoZWFkIGlzLCBwZXJjZW50YWdlLXdpc2UsIG9mIGVuY3J5cHRpb24sIGJ1dCBJIGRvIHRoaW5r IGl0IHdvdWxkIGJlIGhpZ2hlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBOaWNrPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29t Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bmUgMjMsIDIwMTggOTozOSBBTTxi cj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTmljayBC YW5rcyAmbHQ7bmliYW5rc0BtaWNyb3NvZnQuY29tJmd0OzsgS2F6dWhvIE9rdSAmbHQ7a2F6dWhv b2t1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRA Z29vZ2xlLmNvbSZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IE51bWJlciBFbmNyeXB0 aW9uIFBlcmZvcm1hbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaSBOaWNrLCBo b3cgYWJvdXQgbnVtYmVycyBmb3Igc21hbGwgcGFja2V0cz8gU28gSSBwcmVzdW1lIHRoZSBvdmVy aGVhZCBvZiBQTkUgd2lsbCBiZSBtdWNoIGxhcmdlciBoZXJlIGJlY2F1c2UgUE5FIGRvZXMgbm90 IHBpcGVsaW5lIHdoaWxlIGEgNjQgYnl0ZSBwYXlsb2FkIGp1c3QgYWJvdXQgbWFuYWdlcw0KIHRp bCBhbiBBRVMgcGlwZWxpbmUgZGVwZW5kaW5nIG9uIGFyY2guPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1Mjk3NzE4NTM5MzU5NjQxNjAiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+TWlra2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ T24gMjMgSnVuZSAyMDE4IGF0IDE2LjU0LjQyLCBOaWNrIEJhbmtzICg8YSBocmVmPSJtYWlsdG86 bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPm5pYmFua3M9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JIGFncmVlIHRoYXQgdGhlIG51bWJlcnMgZm9yIHJlYWwgd29yayBsb2FkcyB3aWxs IGJlIGludGVyZXN0aW5nLCBidXQgSSBkbyBiZWxpZXZlIHRoYXQgcmF3IFFVSUMgc3RhY2sgbnVt YmVycw0KIGFyZSBhbHNvIGltcG9ydGFudC4gVGhleSB3aWxsIHJlcHJlc2VudCB5b3VyIGJlc3Qg Y2FzZSBzY2VuYXJpby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgbXkgdGVzdGluZywgSSBo YXZlIGEgZmFpcmx5IHNpbXBsZSB0ZXN0IG9mIG9wZW5pbmcgYSBzaW5nbGUgdW5pZGlyZWN0aW9u YWwgc3RyZWFtIGFuZCBqdXN0IGNvbnRpbnVhbGx5IHNlbmRpbmcNCiBkYXRhIHVudGlsIHRoZSBj b3JlIGdldHMgc2F0dXJhdGVkLiBGcm9tIHRoYXQsIEkgZ3JhYiB0aGUgcGVyZm9ybWFuY2UgdHJh Y2UsIGFuZCBzcGVjaWZpY2FsbHkgbG9vayBhdCB0aGUgY29tcG9zaXRpb24gb2YgdGhlIFFVSUMg c3RhY2vigJlzIHNlbmQgcGF0aC4gVGhlIHNlbmQgcGF0aCBjb25zdGl0dXRlcyBnZW5lcmFsbHkg YWxsIG9mIHRoZSBDUFUgZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uIGFueXdheXMgKHdpdGgganVz dCBhIGxpdHRsZSBvdmVyaGVhZA0KIHNlZW4gZnJvbSByZWNlaXZpbmcgYW5kIHByb2Nlc3Npbmcg QUNLcykuIFRoZSBtYWNoaW5lIEkgdXNlZCB3YXMgYW5vdGhlciBzZXJ2ZXIgZ3JhZGUgbWFjaGlu ZSBydW5uaW5nIHRoZSBsYXRlc3QgV2luZG93cyAxMCBTZXJ2ZXIgRGF0YWNlbnRlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5TbyB0aGUgcGVyY2VudGFnZXMgSSBzaGFyZWQgYXJlIGZvciBqdXN0 IHRoZSBRVUlDIHNlbmQgcGF0aCAoYWdhaW4sIG5vIFBORSB3aXRoIHRoZXNlIG51bWJlcnMpLiBU aGUgbnVtYmVycyBhcmUNCiBmb3IgdGhlIHBlcmNlbnRhZ2Ugb2YgdG90YWwgQ1BVIGZvciBhbGwg cGFja2V0cyBzZW50LCBidXQgc2luY2UgYWxsIHBhY2tldHMgd2VyZSBwcmV0dHkgbXVjaCB0aGUg c2FtZSBzaXplLCB0aGUgbnVtYmVycyBzaG91bGQgc3RpbGwgaG9sZCBmb3IgYSBzaW5nbGUgcGFj a2V0LiBBbmQgYm90dG9tIGxpbmUsIGVuY3J5cHRpb24gaXMgYSBsb3QgbW9yZSBvZiBhbiBpbXBh Y3QgdGhhbiAxMCUuIEFuZCBhcyB3ZSBicmluZyBpbiBtb3JlIHBlcmZvcm1hbmNlDQogaW1wcm92 ZW1lbnRzIGZvciBVRFAgc2VuZCBwYXRoIGluIFdpbmRvd3MsIHdlIGV4cGVjdCBlbmNyeXB0aW9u IHRvIGJlIGhpZ2hlciBhbmQgaGlnaGVyIHBlcmNlbnRhZ2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+LSBOaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4gS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBn bWFpbC5jb20iPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+ IFNhdHVyZGF5LCBKdW5lIDIzLCAyMDE4IDEyOjAwIEFNPGJyPg0KPGI+VG86PC9iPiBOaWNrIEJh bmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tIj5uaWJhbmtzQG1p Y3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVm PSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7 OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll dGYub3JnPC9hPiZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWls dG86cHJhdmJAbWljcm9zb2Z0LmNvbSI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SUlVQywgSWFuIHNob3VsZCBiZSB0YWxraW5n IGFib3V0IHBlcmZvcm1hbmNlIG51bWJlcnMgdGhhdCB5b3Ugd291bGQgc2VlIG9uIGEgc2VydmVy IHRoYXQgaXMgaGFuZGxpbmcgcmVhbCB3b3JrbG9hZC4NCiBOb3QgdGhlIGJyZWFrZG93biBvZiBu dW1iZXJzIHdpdGhpbiB0aGUgUVVJQyBzdGFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+TGV0J3MgdGFsayBhYm91dCBuYW5vc2Vjb25kcyBwZXIgcGFja2V0 IHJhdGhlciB0aGFuIHRoZSByYXRpbywgYmVjYXVzZSByYXRpbyBkZXBlbmRzIG9uIHdoYXQgeW91 IHVzZSBhcyBhICZxdW90O3RvdGFsJnF1b3Q7DQogaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgYmVuY2htYXJrcyB0ZWxsIG1lIHRoYXQs IG9uIE9wZW5TU0wgMS4xLjAgcnVubmluZyBvbiBDb3JlIGk3IEAgMi41R0h6IChNYWNCb29rIFBy byAxNSZxdW90OyBNaWQgMjAxNSksIHRoZSBudW1iZXJzDQogYXJlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPndpdGhvdXQtUE5FOiA1ODVucyAv IHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPndpdGgtUE5FOiA2MDducyAvIHBhY2tldCAo KiB0aGlzIGlzIHRoZSBvcHRpbWl6ZWQgdmVyc2lvbiB3aXRoIDMuOCUgb3ZlcmhlYWQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXNzdW1pbmcg dGhhdCB5b3VyIHBlYWsgcmF0ZSBpcyAxR2JpdC9DUFUgY29yZSAod291bGQgYmUgZW5vdWdoIHRv IHNhdHVyYXRlIDI1R2IgRXRoZXJuZXQpLCB0aGUgcmF0aW8gb2YgQ1BVIGN5Y2xlcw0KIGZvciBy dW5uaW5nIHRoZSBjcnlwdG8gd2lsbCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5hbGwgY3J5cHRvOiAwLjEyNUdCL3NlYyAvIDEyODBieXRl cy9wYWNrZXQgKiA2MDducy9wYWNrZXQgPSA1LjkzICU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Q TkU6IDAuMTI1R0Ivc2VjIC8gMTI4MGJ5dGVzL3BhY2tldCAqIDIyLjRucy9wYWNrZXQgPSAwLjIy ICU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5P ZiBjb3Vyc2UsIHRoZXNlIG51bWJlcnMgYXJlIHdoYXQgaXMgZXhwZWN0ZWQgd2hlbiBhIHNlcnZl ciBpcyBzZW5kaW5nIG9yIHJlY2VpdmluZyBmdWxsLXNpemVkIHBhY2tldHMgaW4gb25lIGRpcmVj dGlvbi4NCiBJbiByZWFsaXR5LCB0aGVyZSB3b3VsZCBiZSBhdCBsZWFzdCBzb21lIGZsb3cgaW4g dGhlIG9wcG9zaXRlIGRpcmVjdGlvbiwgc28gdGhlIG51bWJlciB3aWxsIGJlIGhpZ2hlciwgYnV0 IG5vdCBhcyBtdWNoIGFzIDJ4LiBPciBpZiB5b3UgYXJlIHNlbmRpbmcgc21hbGwtc2l6ZWQgcGFj a2V0IGluICpib3RoKiBkaXJlY3Rpb25zICphbmQqIHNhdHVyYXRpbmcgdGhlIGxpbmssIHRoZSBy YXRpbyB3aWxsIGJlIGhpZ2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QnV0IGxvb2tpbmcgYXQgdGhlIG51bWJlcnMsIEknZCBhc3N1bWUgdGhhdCAxMCUg aXMgYSBsb2dpY2FsIG51bWJlciBmb3Igd29ya2xvYWQgSWFuIGhhcywgYW5kIGFsc28gZm9yIHBl b3BsZSB3aG8NCiBhcmUgaW52b2x2ZWQgaW4gY29udGVudCBkaXN0cmlidXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXMgc2hvd24sIEkg dGhpbmsgdGhhdCBzaGFyaW5nIHRoZSBQUFMgYW5kIGF2ZXJhZ2UgcGFja2V0IHNpemUgdGhhdCBv dXIgd29ya2xvYWQgd2lsbCBoYXZlLCBhbG9uZyB3aXRoIHRoZSByYXcNCiBudW1iZXJzIG9mIHRo ZSBjcnlwdG8gKGkuZS4gbnNlYyAvIHBhY2tldCkgd2lsbCBnaXZlIHVzIGEgYmV0dGVyIHVuZGVy c3RhbmRpbmcgb24gaG93IG11Y2ggdGhlIGFjdHVhbCBvdmVyaGVhZCBpcy4gRG8geW91IG1pbmQg c2hhcmluZyB5b3VyIGV4cGVjdGF0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+MjAxOC0wNi0yMyA5OjM0IEdNVCYjNDM7MDk6MDAgTmljayBCYW5rcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm5pYmFua3NAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IZXkgR3V5cyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHNwZW50IHRoZSBiZXR0ZXIgcGFydCBvZiB0aGUgZGF5 IGdldHRpbmcgc29tZSBwZXJmb3JtYW5jZSB0cmFjZXMgb2YgV2luUXVpYw0KPGI+d2l0aG91dCBQ TkU8L2I+LiBPdXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgYm90aCB1c2VyIG1vZGUgYW5kIGtl cm5lbCBtb2RlLCBzbyBJIGdvdCBudW1iZXJzIGZvciBib3RoLiBUaGUgZm9sbG93aW5nIHRhYmxl IHNob3dzIHRoZSByZWxhdGl2ZSBDUFUgY29zdCBvZiBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIFFV SUMgc2VuZCBwYXRoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMnB0O2JvcmRlci1jb2xsYXBzZTpjb2xs YXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjE3NSIgdmFsaWduPSJ0b3AiIHN0eWxl PSJ3aWR0aDoxMzEuNHB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI4NCIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo2My4wcHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VXNlciBNb2RlPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iOTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MS4waW47Ym9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2Vy bmVsIE1vZGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxpZ249InRvcCIgc3R5 bGU9IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv cDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5VRFAgU2VuZDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjYzLjBwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6 bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjY0LjclPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iOTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 MS4waW47Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj40MS40JTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkIHdpZHRoPSIxNzUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTMxLjRwdDti b3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkVuY3J5cHRpb248L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI4NCIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3 aWR0aDo2My4wcHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRv bTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4yMi41JTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9Ijk2IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEuMGluO2JvcmRlci10b3A6 bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBw dDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mzgu NSU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0i MTc1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5QYWNrZXQgQnVp bGRpbmcvRnJhbWluZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijg0IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo OjYzLjBwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjclPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iOTYiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MS4waW47Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4xNSU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTc1IiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjEzMS40cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaXNjZWxsYW5lb3VzPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iODQiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NjMuMHB0O2JvcmRlci10b3A6 bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBw dDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+NS44 JTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijk2IiB2YWxpZ249InRv cCIgc3R5bGU9IndpZHRoOjEuMGluO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv cmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+NS4xJTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGVzZSBudW1iZXJzIGRlZmluaXRl bHkgc2hvdyB0aGF0IGVuY3J5cHRpb24gaXMgYSBtdWNoIGxhcmdlciBwb3J0aW9uIG9mIENQVS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIE5pY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiBLYXp1aG8g T2t1ICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgSnVuZSAyMiwgMjAxOCA1OjAyIFBNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQgJmx0Ozxh IGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dl dHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOaWNrIEJhbmtzICZsdDs8YSBo cmVmPSJtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmliYW5r c0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBo cmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1p Y3Jvc29mdC5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgTnVtYmVyIEVu Y3J5cHRpb24gUGVyZm9ybWFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4yMDE4LTA2LTIzIDM6NTEgR01UJiM0MzswOTowMCBJYW4gU3dldHQgJmx0Ozxh IGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dl dHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZXhwZWN0IGNyeXB0byB0byBpbmNyZWFz ZSBhcyBhIGZyYWN0aW9uIG9mIENQVSwgYnV0IEkgZG9uJ3QgZXhwZWN0IGl0IHRvIGdvIG11Y2gg aGlnaGVyIHRoYW4gMTAlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5CdXQgd2hvIGtub3dzLCBtYXliZSAyIHllYXJzIGZyb20gbm93IGV2ZXJ5dGhpbmcgZWxz ZSB3aWxsIGJlIHZlcnkgb3B0aW1pemVkIGFuZCBjcnlwdG8gd2lsbCBiZSAxNSU/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5JYW4sIHRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgcHJvcG9ydGlvbiBvZiBD UFUgY3ljbGVzIHdlIGFyZSBsaWtlbHkgdG8gc3BlbmQgZm9yIGNyeXB0by48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Zb3VyIG51bWJlcnMgcmVs aWV2ZXMgbWUsIGJlY2F1c2UgZXZlbiBpZiB0aGUgY29zdCBvZiBjcnlwdG8gZ29lcyB0byAxNSUs IHRoZSBvdmVyaGVhZCBvZiBQTkUgd2lsbCBiZSBsZXNzIHRoYW4NCiAxJSAoMC4xNSowLjA0PTAu MDA2KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5JIHdvdWxkIGFsc28gbGlrZSB0byBub3RlIHRoYXQgaXQgaXMgbGlrZWx5IHRoYXQgSHlwZXJU aHJlYWRpbmcsIHdoZW4gdXNlZCwgd2lsbCBlbGltaW5hdGUgdGhlIG92ZXJoZWFkIG9mIFBORS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlz IGlzIGJlY2F1c2UgSUlVQyBQTkUgaXMgYSBtYXJnaW5hbCBhZGRpdGlvbmFsIHVzZSBvZiB0aGUg QUVTLU5JIGVuZ2luZSwgd2hpY2ggaGF2ZSBiZWVuIG1vc3RseSBpZGxlLiBUaGUgb3ZlcmhlYWQN CiBvZiBjcnlwdG8gaXMgc21hbGwgKGkuZS4uIDE1JSkgdGhhdCB3ZSB3aWxsIHJhcmVseSBzZWUg Y29udGVudGlvbiBvbiB0aGUgZW5naW5lLiBXaGlsZSBvbmUgaHlwZXJ0aHJlYWQgZG9lcyBBRVMs IHRoZSBvdGhlciBoeXBlcnRocmVhZCB3aWxsIHJ1biBhdCBmdWxsIHNwZWVkIGRvaW5nIG90aGVy IG9wZXJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QWxzbyBjb25zaWRlcmluZyB0aGUgZmFjdCB0aGF0IHRoZSBudW1iZXIgb2YgQ1BV IGN5Y2xlcyBzcGVudCBwZXIgUVVJQyBwYWNrZXQgZG9lcyBub3QgY2hhbmdlIGEgbG90IHdpdGgg UE5FLCBJDQogd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWUgKm5vKiBkZWNyZWFzZSBvZiB0 aHJvdWdocHV0IHdoZW4gUE5FIGlzIHVzZWQgb24gYSBIeXBlclRocmVhZGluZyBhcmNoaXRlY3R1 cmUuIEluIHN1Y2ggY2FzZSwgd2hhdCB3ZSB3aWxsIG9ubHkgb2JzZXJ2ZSBpcyB0aGUgcmFpc2Ug b2YgdGhlIHV0aWxpemF0aW9uIHJhdGlvIG9mIHRoZSBBRVMtTkkgZW5naW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gRnJpLCBKdW4g MjIsIDIwMTggYXQgMTI6MzQgUE0gTmljayBCYW5rcyAmbHQ7bmliYW5rcz08YSBocmVmPSJtYWls dG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNy b3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGp1c3Qgd2FudCB0byBhZGQs IG15IGltcGxlbWVudGF0aW9uIGFscmVhZHkgdXNlcyBFQ0IgZnJvbSBiY3J5cHQgKGFuZCBJIGRv IHRoZSBYT1IpIGFscmVhZHkuIEJjcnlwdCBkb2VzbuKAmXQgZXhwb3NlDQogQ1RSIG1vZGUgZGly ZWN0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U2VudCBmcm9tDQo8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmdvLm1pY3Jvc29mdC5jb20lMkZmd2xpbmslMkYlM0ZMaW5rSWQlM0Q1NTA5ODYmYW1wO2RhdGE9 MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDZTZlZmEzNjNiYzI1NDcxNjdhOGMw OGQ1ZDg5YzgwZTclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NjUzMDg5MDU5MjY4ODM2JmFtcDtzZGF0YT1hZVU3ajVsaENJTTE4S0c1YzZvcEc0cDdhbXdo Q1diUm5mbm04c0RXN2hjJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpNYWls PC9hPiBmb3IgV2luZG93cyAxMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0i OTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjg4 Njk4Njk4OTY3MzI5OTE4NG1fLTg0ODIyOTYzMzk4NTI1NzEyNjltXy04NDA4ODQ3NDI3MDkzMjIz NDc2ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiBQcmF2ZWVuDQogQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgSnVuZSAyMiwgMjAxOCA5OjI2OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQ7 IEthenVobyBPa3U8YnI+DQo8Yj5DYzo8L2I+IE5pY2sgQmFua3M7IElFVEYgUVVJQyBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1hbmNl PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JYW4sIGRvIHlvdSBleHBlY3QgdGhhdCBmcmFjdGlvbiBvZiBvdmVyYWxsIGNvc3QgdG8g aG9sZCBvbmNlIHRoZSBVRFAgc3RhY2sgaXMgb3B0aW1pemVkPyBJcyB5b3VyIG1lYXN1cmVtZW50 IG9uDQogdG9wIG9mIHRoZSByZWNlbnQga2VybmVsIGltcHJvdmVtZW50cz8gSSBleHBlY3QgY3J5 cHRvIGZyYWN0aW9uIG9mIG92ZXJhbGwgY29zdCB0byBrZWVwIGluY3JlYXNpbmcgb3ZlciB0aW1l IGFzIHRoZSBuZXR3b3JrIHN0YWNrIGJvdHRsZW5lY2tzIGFyZSBlbGltaW5hdGVkLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+S2F6dWhvLCBzaG91bGQgdGhlIGRyYWZ0IGRlc2NyaWJlIHRoZSBv cHRpbWl6YXRpb25zIHlvdSBhcmUgbWFraW5nPyBPciBhcmUgdGhlc2UgYXJlIHRvbyBPcGVuU1NM IHNwZWNpZmljPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVu ZSAyMiwgMjAxOCA0OjQ1IEFNPGJyPg0KPGI+VG86PC9iPiBLYXp1aG8gT2t1ICZsdDs8YSBocmVm PSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmljayBCYW5rcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5pYmFua3NAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5pYmFua3NAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgTnVtYmVyIEVuY3J5cHRpb24gUGVyZm9ybWFuY2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciBkaWdnaW5nIGludG8gdGhlIGRl dGFpbHMgb2YgdGhpcywgS2F6dWhvLiZuYnNwOyAmbHQ7NCUgaW5jcmVhc2UgaW4gY3J5cHRvIGNv c3QgaXMgYSBiaXQgbW9yZSB0aGFuIEkgb3JpZ2luYWxseQ0KIGV4cGVjdGVkKH4yJSksIGJ1dCBj cnlwdG8gaXMgbGVzcyB0aGFuIDEwJSBvZiBteSBDUFUgdXNhZ2UsIHNvIGl0J3Mgc3RpbGwgbGVz cyB0aGFuIDAuNSUgdG90YWwsIHdoaWNoIGlzIGFjY2VwdGFibGUgdG8gbWUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIEZyaSwgSnVuIDIyLCAyMDE4IGF0IDI6NDUgQU0gS2F6dWhvIE9rdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9v a3VAZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+MjAxOC0wNi0yMiAxMjoyMiBHTVQmIzQzOzA5OjAwIEthenVobyBPa3UgJmx0OzxhIGhy ZWY9Im1haWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1 QGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+MjAxOC0wNi0yMiAxMTo1NCBHTVQmIzQzOzA5OjAwIE5pY2sgQmFua3Mg Jmx0OzxhIGhyZWY9Im1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5uaWJhbmtzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgS2F6dWhv LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIG51bWJlcnMg YXMgd2VsbCEgSSdtIGJpdCBjb25mdXNlZCB3aGVyZSB5b3Ugc2F5IHlvdSBjYW4gcmVkdWNlIHRo ZSAxMCUgb3ZlcmhlYWQgdG8gMiUgdG8NCiA0JS4gSG93IGRvIHlvdSBwbGFuIG9uIGRvaW5nIHRo YXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBzdGF0ZWQgaW4gbXkgcHJldmlvdXMgbWFpbCwgdGhl IDEwJSBvZiBvdmVyaGVhZCBjb25zaXN0cyBvZiB0aHJlZSBwYXJ0cywgZWFjaCBjb25zdW1pbmcg Y29tcGFyYWJsZSBudW1iZXIgb2YNCiBDUFUgY3ljbGVzLiBUaGUgdHdvIGFtb25nIHRoZSB0aHJl ZSBpcyByZWxhdGVkIHRvIHRoZSBhYnN0cmFjdGlvbiBsYXllciBhbmQgaG93IENUUiBpcyBpbXBs ZW1lbnRlZCwgd2hpbGUgdGhlIG90aGVyIG9uZSBpcyB0aGUgY29yZSBBRVMtRUNCIG9wZXJhdGlv biBjb3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkl0IHNob3VsZCBiZSBhYmxlIHRvIHJlbW92ZSB0aGUgY29zdGx5IGFic3RyYWN0aW9uIGxh eWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pkl0IHNob3VsZCBhbHNvIGJlIHBvc3NpYmxlIHRvIHJlbW92ZSB0aGUgb3ZlcmhlYWQgb2YgQ1RS LCBzaW5jZSBpbiBQTkUsIHdlIG5lZWQgdG8gWE9SIGF0IG1vc3QgNCBvY3RldHMgKGFwcGx5aW5n DQogWE9SIGlzIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiBDVFIgYW5kIEVDQikuIFRoYXQg Y29zdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGJlIG51 bGxpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5Db25zaWRlcmluZyB0aGVzZSBhc3BlY3RzLCBhbmQgYnkgbG9va2luZyBhdCB0aGUgbnVt YmVycyBvbiB0aGUgT3BlblNTTCBzb3VyY2UgY29kZSAoYXMgd2VsbCBhcyBjb25zaWRlcmluZyB0 aGUNCiBvdmVyaGVhZCBvZiBHQ00pLCBteSBleHBlY3RhdGlvbiBnb2VzIHRvIDIlIHRvIDQlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkp1c3QgZGlkIHNvbWUgZXhwZXJpbWVu dHMgYW5kIGl0IHNlZW1zIHRoYXQgdGhlIGV4cGVjdGF0aW9uIHdhcyBjb3JyZWN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBiZW5jaG1h cmtzIHRlbGwgbWUgdGhhdCB0aGUgb3ZlcmhlYWQgZ29lcyBkb3duIGZyb20gMTAuMCUgdG8gMy4u OCUsIGJ5IGRvaW5nIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KiByZW1vdmUgdGhlIG92ZXJoZWFkIG9mIENUUiBhYnN0 cmFjdGlvbiAoaS5lLiB1c2UgdGhlIEVDQiBiYWNrZW5kIGFuZCBkbyBYT1IgYnkgb3Vyc2VsdmVz KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiogcmVtb3ZlIHRoZSBvdmVyaGVhZCBvZiB0aGUgYWJz dHJhY3Rpb24gbGF5ZXIgKGkuZS4gY2FsbCB0aGUgbWV0aG9kIHJldHVybmVkIGJ5IEVWUF9DSVBI RVJfbWV0aF9nZXRfZG9fY2lwaGVyDQogaW5zdGVhZCBvZiBjYWxsaW5nIEVWUF9FbmNyeXB0VXBk YXRlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pk9mIGNvdXJzZSB0aGUgY2hhbmdlcyBhcmUgc3BlY2lmaWMgdG8gT3BlblNTTCwgYnV0IEkgd291 bGQgZXhwZWN0IHRoYXQgeW91IGNhbiBleHBlY3Qgc2ltaWxhciBudW1iZXJzIGFzc3VtaW5nDQog dGhhdCB5b3UgaGF2ZSBhY2Nlc3MgdG8gYW4gb3B0aW1pemVkIEFFUyBpbXBsZW1lbnRhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U2VudCBmcm9tIG15IFdp bmRvd3MgMTAgcGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5bSHhTIC0gMTUyNTQgLSAxNi4wLjEwMjI4LjIwMDc1XTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjg4Njk4Njk4OTY3MzI5OTE4NG1fLTg0 ODIyOTYzMzk4NTI1NzEyNjltXy04NDA4ODQ3NDI3MDkzMjIzNDc2bV8tNjI4MjQ5OTg2MTMzNDEw NDA1MW1fODQ3MTA3MTM1OTgxODEzNzEwN21fLTc3NjI5ODEyMTMxMzg3ODM3NGRpdlJwbHlGd2RN c2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gS2F6 dWhvDQogT2t1ICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpr YXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwv YT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEp1bmUgMjEsIDIwMTggNzoyMToxNyBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBCYW5rczxi cj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IE51bWJlciBFbmNyeXB0aW9uIFBlcmZvcm1h bmNlPC9zcGFuPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5IaSBOaWNrLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlRoYW5rIHlvdSBmb3IgYnJpbmdpbmcgdGhlIG51bWJlcnMgdG8gdGhlIGxpc3QuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGp1c3Qg cnVuIGEgc21hbGwgYmVuY2htYXJrIHVzaW5nIFF1aWNseSwgYW5kIEkgc2VlIGNvbXBhcmFibGUg bnVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5UbyBiZSBwcmVjaXNlLCBJIHNlZSAxMC4wJSBpbmNyZWFzZSBvZiBDUFUgY3ljbGVzIHdo ZW4gZW5jcnlwdGluZyBhIEluaXRpYWwgcGFja2V0IG9mIDEsMjgwIG9jdGV0cy4gSSBleHBlY3Qg dGhhdA0KIHdlIHdpbGwgc2VlIHNpbWlsYXIgbnVtYmVycyBvbiBvdGhlciBRVUlDIHN0YWNrcyB0 aGF0IGFsc28gdXNlIHBpY290bHMgKHdpdGggT3BlblNTTCBhcyBhIGJhY2tlbmQpLiBOb3RlIHRo YXQgdGhlIG51bWJlciBpcyBvbmx5IGNvbXBhcmluZyB0aGUgY29zdCBvZiBlbmNyeXB0aW9uLCB0 aGUgb3ZlcmhlYWQgcmF0aW8gd2lsbCBiZSBtdWNoIHNtYWxsZXIgaWYgd2UgbG9vayBhdCB0aGUg dG90YWwgbnVtYmVyIG9mIENQVSBjeWNsZXMgc3BlbnQgYnkNCiBhIFFVSUMgc3RhY2sgYXMgYSB3 aG9sZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5Mb29raW5nIGF0IHRoZSBwcm9maWxlLCB0aGUgb3ZlcmhlYWQgY29uc2lzdHMgb2YgdGhyZWUg b3BlcmF0aW9ucyB0aGF0IGVhY2ggY29uc3VtZXMgY29tcGFyYWJsZSBDUFUgY3ljbGVzOiBjb3Jl DQogQUVTIG9wZXJhdGlvbiAodXNpbmcgQUVTLU5JKSwgQ1RSIG9wZXJhdGlvbiBvdmVyaGVhZCwg Q1RSIGluaXRpYWxpemF0aW9uLiBOb3RlIHRoYXQgcGljb3RscyBhdCB0aGUgbW9tZW50IHByb3Zp ZGVzIGFjY2VzcyB0byBDVFIgY3J5cHRvIGJlbmVhdGggdGhlIEFFQUQgaW50ZXJmYWNlLCB3aGlj aCBpcyB0byBiZSB1c2VkIGJ5IHRoZSBRVUlDIHN0YWNrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHdvdWxkIGFzc3VtZSB0aGF0IHdlIGNh biBjdXQgZG93biB0aGUgb3ZlcmhlYWQgdG8gc29tZXdoZXJlIGJldHdlZW4gMiUgdG8gNCUsIGJ1 dCBpdCBtaWdodCBiZSBoYXJkIHRvIGdvIGRvd24NCiB0byBzb21ld2hlcmUgbmVhciAxJSwgYmVj YXVzZSB3ZSBjYW5ub3QgcGFyYWxsZWxpemUgdGhlIEFFUyBvcGVyYXRpb24gb2YgUE5FIHdpdGgg dGhhdCBvZiBBRUFEIChzZWUNCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi4ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZvcGVuc3Ns JTJGb3BlbnNzbCUyRmJsb2IlMkZPcGVuU1NMXzFfMV8waCUyRmNyeXB0byUyRmFlcyUyRmFzbSUy RmFlc25pLXg4Nl82NC5wbCUyM0wyNC1MMzkmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFua3MlNDBt aWNyb3NvZnQuY29tJTdDMTFkNTVmMTczMzNlNGE3OTVkNzAwOGQ1ZDdlNmQ5M2MlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjUyMzA4ODQzOTk0MTM0JmFt cDtzZGF0YT1rcU16NFNzTiUyRjJFckdLMDZRejhaMHZVenBsNE1paXBuTkUyd0FNVWI0NmMlM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9vcGVu c3NsL29wZW5zc2wvYmxvYi9PcGVuU1NMXzFfMV8waC9jcnlwdG8vYWVzL2FzbS9hZXNuaS14ODZf NjQucGwjTDI0LUwzOTwvYT4gYWJvdXQgdGhlIGltcGFjdCBvZiBwYXJhbGxlbGl6YXRpb24pLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8g bm90IHRoaW5rIHRoYXQgMiUgdG8gNCUgb2YgYWRkaXRpb25hbCBvdmVyaGVhZCB0byB0aGUgY3J5 cHRvIGlzIGFuIGlzc3VlIGZvciBRVUlDL0hUVFAsIGJ1dCBjdXJyZW50IG92ZXJoZWFkDQogb2Yg MTAlIGlzIHNvbWV0aGluZyB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZGVjcmVhc2UuIEkgYW0gZ2xh ZCB0byBiZSBhYmxlIHRvIGxlYXJuIHRoYXQgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIwMTgtMDYtMjIgNTo0OCBHTVQmIzQzOzA5 OjAwIE5pY2sgQmFua3MgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWJhbmtzPTQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5pYmFua3M9NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkhlbGxvIFFVSUMgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSByZWNl bnRseSBpbXBsZW1lbnRlZCBQTkUgZm9yIFdpblF1aWMgKHVzaW5nIGJjcnlwdCBBUElzKSBhbmQg SSBkZWNpZGVkIHRvIGdldCBzb21lIHBlcmZvcm1hbmNlIG51bWJlcnMgdG8gc2VlDQogd2hhdCB0 aGUgb3ZlcmhlYWQgb2YgUE5FIHdhcy4gSSBmaWd1cmVkIHRoZSByZXN0IG9mIHRoZSBXRyBtaWdo dCBiZSBpbnRlcmVzdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IHRlc3QganVzdCBlbmNy eXB0cyB0aGUgc2FtZSBidWZmZXIgKHNpemUgZGVwZW5kZW50IG9uIHRoZSB0ZXN0IGNhc2UpIDEw LDAwMCwwMDAgdGltZXMgYW5kIG1lYXN1cmVkIHRoZSB0aW1lDQogaXQgdG9vay4gVGhlIHRlc3Qg dGhlbiBkaWQgdGhlIHNhbWUgdGhpbmcsIGJ1dCBhbHNvIGVuY3J5cHRlZCB0aGUgcGFja2V0IG51 bWJlciBhcyB3ZWxsLiBJIHJhbiBhbGwgdGhhdCAxMCB0aW1lcyBpbiB0b3RhbC4gSSB0aGVuIGNv bGxlY3RlZCB0aGUgYmVzdCB0aW1lcyBmb3IgZWFjaCBjYXRlZ29yeSB0byBwcm9kdWNlIHRoZSBm b2xsb3dpbmcgZ3JhcGhzIGFuZCB0YWJsZXMgKGZ1bGwgZXhjZWwgZG9jIGF0dGFjaGVkKTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MDEiIHN0eWxl PSJ3aWR0aDozNzYuMHB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHIg c3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0i Ym90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDto ZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjEyOCIgbm93cmFwPSIiIGNvbHNwYW49 IjIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6OTYuMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRpbWUgKG1zKTwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBu b3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjExOSIgbm93 cmFwPSIiIGNvbHNwYW49IjIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6ODkuMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJhdGUgKE1icHMpPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkJ5dGVzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5OTyBQTkU8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlBORTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dy YXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTI3IiBub3dy YXA9IiIgY29sc3Bhbj0iMiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo5NS4wcHQ7cGFk ZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UE5FIE92ZXJoZWFkPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0 LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ObyBQTkU8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6 NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlBORTwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yMjg0LjY3MTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5v d3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1 LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4zMDI3LjY1Nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5 bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBw dCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHls ZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjMzJTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFw PSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0 IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy aWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjE0MC4wNjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTA1LjY5Mjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Imhl aWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjE2PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i NjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5n OjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4yMTAyLjQwMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRv bSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu OnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yODI4LjIwNDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0 aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRk aW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRo PSI2MyIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjM1JTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6NDQuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjYwOC44Mjc8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+NDUyLjU4NDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdp ZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjY0PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yMTk4Ljg4Mzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0 ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBw dDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4yOTA3LjU3Nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxp Z249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdpZHRoPSI2MyIgbm93cmFwPSIiIHZhbGln bj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDcuMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRw dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjMyJTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3 aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtw YWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8L3RkPg0KPHRkIHdp ZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0O3Bh ZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjIzMjguNDU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h bGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTc2MC45Mjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZh bGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1 LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjI1 Njwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0 aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Mjc1OC4zPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIi IHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBp biA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjM0 OTAuMjg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0 aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90 ZD4NCjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRo OjQ3LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yNyU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxp Z249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40 cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0 ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj43NDI0Ljg2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQu NXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjU4NjcuNzI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUu MHB0Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9Indp ZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj42MDA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjQ2NjkuMjgzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHls ZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjU0MjQuNTM5PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBu b3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4g NS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+MTYlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i d2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4N CjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3 aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTAyODA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9 IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQg MGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ ODg0OC42ODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSI2NCIg bm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjEwMDA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9t IiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6 MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246 cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjYxMzAuMTM5PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRo PSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRp bmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjY5MDcuODA1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90 dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWln aHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dyYXA9IiIgdmFsaWduPSJib3R0 b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdo dDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTMlPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2 NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjU5 IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0NC41cHQ7cGFkZGluZzow aW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+MTMwNTAuMzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIg c3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJp Z2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xMTU4MS4xPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz dHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJi b3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h bGlnbjpyaWdodCI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTIwMDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4w cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+NjQ1OC42Nzk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+NzIyOS42 NzI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0 OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4N Cjx0ZCB3aWR0aD0iNjMiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ3 LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xMiU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0IiBub3dyYXA9IiIgdmFsaWdu PSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0OC4wcHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0 O2hlaWdodDoxNS4wcHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0iIiB2YWxpZ249 ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xNDg2My43PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRk IHdpZHRoPSI1OSIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDQuNXB0 O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjEzMjc4LjY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0 Ij4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRo OjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xNDUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3Jh cD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij43ODc2LjMxMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjQiIG5vd3JhcD0iIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 IndpZHRoOjQ4LjBwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj44NjcwLjE2PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93 cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lkdGg6NDguMHB0O3BhZGRpbmc6MGluIDUu NHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwvdGQ+DQo8dGQgd2lkdGg9IjYzIiBub3dy YXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDo0Ny4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+MTAlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPHRkIHdpZHRoPSI2NCIgbm93cmFwPSIiIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0id2lk dGg6NDguMHB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMHB0Ij4NCjwv dGQ+DQo8dGQgd2lkdGg9IjU5IiBub3dyYXA9IiIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0 aDo0NC41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUuNHB0O2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpyaWdodCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTQ3MjcuNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTkiIG5vd3JhcD0i IiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjQ0LjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmln aHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4x MzM3OS4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHVzZWQgYSBz ZXJ2ZXIgZ3JhZGUgbGFiIG1hY2hpbmUgSSBoYWQgYXQgbXkgZGlzcG9zYWwsIHJ1bm5pbmcgdGhl IGxhdGVzdCBXaW5kb3dzIDEwIFNlcnZlciBEYXRhQ2VudGVyIGJ1aWxkLg0KIEFnYWluLCB0aGVz ZSBudW1iZXJzIGFyZSBmb3IgY3J5cHRvIG9ubHkuIE5vIFFVSUMgb3IgVURQIGlzIGluY2x1ZGVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIE5pY2s8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LYXp1aG8gT2t1PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48YnI+DQo8YnIgY2xl YXI9ImFsbCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gY2xhc3M9ImdtYWlsLW02ODg2OTg2OTg5NjczMjk5MTg0bS04NDgyMjk2MzM5ODUyNTcx MjY5bS04NDA4ODQ3NDI3MDkzMjIzNDc2bS02MjgyNDk5ODYxMzM0MTA0MDUxaG9lbnpiIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4tLQ0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+S2F6dWhvIE9rdTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkthenVobyBPa3U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LYXp1aG8g T2t1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LYXp1aG8gT2t1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_MW2PR2101MB090823CCBAE4C835E8F866ACB3740MW2PR2101MB0908_-- From nobody Sat Jun 23 15:10:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257F6130F00 for ; Sat, 23 Jun 2018 15:10:41 -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 YLaxRbRJM9z7 for ; Sat, 23 Jun 2018 15:10:35 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 9BFD9130EF8 for ; Sat, 23 Jun 2018 15:10:35 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id u16-v6so983158pfh.3 for ; Sat, 23 Jun 2018 15:10:35 -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=Futd3ehDf4gvH6VLaYSbHTp8RpiCgVwzgwpOvXbMHCY=; b=YHrYaYJk+nn+vjKj7kuj+3HtScGHwdyhudWRD6exJ73Bo0S2gRCfYYbkO+q6KoVwEL C8FmwB7oEHNFapo1OiPHnk+2ZYHy8Stq9t3rfB8jJTSuxmE/5aBJNlcvi1y+5K0j8FqG YDdQ49Gftpp0LKdmwX0qos2xsMHbtVlTmIpCILKfbmeZT31dd5FLyrUcc4N7QGcWvfxb AyGHXeFh34g8zkGqVyiXaTSopxglR/suTStLSib5tWF15hQiaLn/sVV25HWZrIwFXV1F eHZ/oV+KKEvB8kaOEu+a9mrd0Ad2GmfxX/ubBIompFi4kAijSPC+A7zmmRAgpmLvB8zd 6ppg== 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=Futd3ehDf4gvH6VLaYSbHTp8RpiCgVwzgwpOvXbMHCY=; b=Pl9cekpGNU4uyPptc4O/uVP9M9Toc5zDA/W8mpAxwvEoCbMMkr9oKbXVb4C6NPYMQI o+fY9oeceCqs35neXg6cp/w92Iu0Cgrh573HnjLUgn+K3t6/870CA8CfC3y1GWJniqj2 ++GDhdeWd0/qBbB94Lz7zDjxQhOiH2m6+KHxdAOEQaosSjB2k93OFCsnOs3pvh1wWvp8 4aAnfB/LqldeAGc4/2x101XQKgrPrTeWuyWrQcfSgYlTgrwEnczM6jltdxynJwN1LEX7 4fbNwWLhq9KrnUFqHe5IVL30iUjWazpUxyHP90t7SoULPG6bJ2KtlNBiMRAnxe5COxuA Pzrw== X-Gm-Message-State: APt69E323bxyKL2vqM2vkIyAXnfPUVeK2+tw7dvnxFe6NHmGhGoTuTI7 wyaw16c0EVr+XE3IQ6AXR7VyDmDYqIhKgo//5J4= X-Google-Smtp-Source: ADUXVKKXAmhC/4T+3jLSaRC95TIb9UikWA6FfJtI8le1pVhbyY7qFoO+cgaujMitng32z3s22uOvHOBxykiWhKeZrRo= X-Received: by 2002:a63:b305:: with SMTP id i5-v6mr5885084pgf.370.1529791834843; Sat, 23 Jun 2018 15:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sat, 23 Jun 2018 15:10:33 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Sun, 24 Jun 2018 07:10:33 +0900 Message-ID: Subject: Re: Packet Number Encryption Performance To: Nick Banks Cc: IETF QUIC WG , Ian Swett , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="000000000000e57101056f566a74" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 22:10:42 -0000 --000000000000e57101056f566a74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-06-23 23:54 GMT+09:00 Nick Banks : > I agree that the numbers for real work loads will be interesting, but I d= o > believe that raw QUIC stack numbers are also important. They will represe= nt > your best case scenario. > > > To clarify, the reason I asked about the raw numbers and the use-case is because without that I do not know how to interpret your numbers. My understanding is that your benchmark is about encrypting and sending large QUIC packets. Assuming that BCRYPT provides comparable performance to OpenSSL, the numbers you show (i.e. 22.5% in user-mode, 38.5% in kernel-mode) means that you want to reduce crypto cost when a single CPU core is emitting somewhere between 5Gbps to 8 Gbps. I wonder how much we would be interested in such case. Let me explain why. Assuming that we have many connections, each CPU core will only handle somewhere around 1Gbps to saturate a 25Gbps link. As I have stated in my previous mail, the crypto cost will be around or less than 10% in such case= . Assuming that we are interested in utilizing a 25Gbps link for a single connection (or a small number of connections), I think that we would be generally considering of distributing both UDP send and encryption to multiple CPU cores, because even without crypto, it is hard to utilize the entire bandwidth using just one core (the same goes for the receive side). And if you distribute the load to your CPU cores, the crypto cost becomes somewhere around or below 10%. This is my understanding. But I also understand that it could well be the case that I do not understand what your workload looks like. That's why I wonder if you could share the raw numbers and the use-case. For my testing, I have a fairly simple test of opening a single > unidirectional stream and just continually sending data until the core ge= ts > saturated. From that, I grab the performance trace, and specifically look > at the composition of the QUIC stack=E2=80=99s send path. The send path c= onstitutes > generally all of the CPU for the whole connection anyways (with just a > little overhead seen from receiving and processing ACKs). The machine I > used was another server grade machine running the latest Windows 10 Serve= r > Datacenter. > > > > So the percentages I shared are for just the QUIC send path (again, no PN= E > with these numbers). The numbers are for the percentage of total CPU for > all packets sent, but since all packets were pretty much the same size, t= he > numbers should still hold for a single packet. And bottom line, encryptio= n > is a lot more of an impact than 10%. And as we bring in more performance > improvements for UDP send path in Windows, we expect encryption to be > higher and higher percentage. > > > > - Nick > > > > *From:* Kazuho Oku > *Sent:* Saturday, June 23, 2018 12:00 AM > *To:* Nick Banks > *Cc:* Ian Swett ; IETF QUIC WG ; > Praveen Balasubramanian > > *Subject:* Re: Packet Number Encryption Performance > > > > IIUC, Ian should be talking about performance numbers that you would see > on a server that is handling real workload. Not the breakdown of numbers > within the QUIC stack. > > > > Let's talk about nanoseconds per packet rather than the ratio, because > ratio depends on what you use as a "total" is. > > > > My benchmarks tell me that, on OpenSSL 1.1.0 running on Core i7 @ 2.5GHz > (MacBook Pro 15" Mid 2015), the numbers are: > > > > without-PNE: 585ns / packet > > with-PNE: 607ns / packet (* this is the optimized version with 3.8% > overhead) > > > > Assuming that your peak rate is 1Gbit/CPU core (would be enough to > saturate 25Gb Ethernet), the ratio of CPU cycles for running the crypto > will be: > > > > all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/packet =3D 5.93 % > > PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet =3D 0.22 % > > > > Of course, these numbers are what is expected when a server is sending or > receiving full-sized packets in one direction. In reality, there would be > at least some flow in the opposite direction, so the number will be highe= r, > but not as much as 2x. Or if you are sending small-sized packet in *both* > directions *and* saturating the link, the ratio will be higher. > > > > But looking at the numbers, I'd assume that 10% is a logical number for > workload Ian has, and also for people who are involved in content > distribution. > > > > As shown, I think that sharing the PPS and average packet size that our > workload will have, along with the raw numbers of the crypto (i.e. nsec / > packet) will give us a better understanding on how much the actual overhe= ad > is. Do you mind sharing your expectations? > > > > 2018-06-23 9:34 GMT+09:00 Nick Banks : > > Hey Guys, > > > > I spent the better part of the day getting some performance traces of > WinQuic *without PNE*. Our implementation supports both user mode and > kernel mode, so I got numbers for both. The following table shows the > relative CPU cost of different parts of the QUIC send path: > > > > > > *User Mode* > > *Kernel Mode* > > *UDP Send* > > 64.7% > > 41.4% > > *Encryption* > > 22.5% > > 38.5% > > *Packet Building/Framing* > > 7% > > 15% > > *Miscellaneous* > > 5.8% > > 5.1% > > > > These numbers definitely show that encryption is a much larger portion of > CPU. > > > > - Nick > > > > > > *From:* Kazuho Oku > *Sent:* Friday, June 22, 2018 5:02 PM > *To:* Ian Swett > *Cc:* Nick Banks ; Praveen Balasubramanian < > pravb@microsoft.com>; IETF QUIC WG > > > *Subject:* Re: Packet Number Encryption Performance > > > > > > > > 2018-06-23 3:51 GMT+09:00 Ian Swett : > > I expect crypto to increase as a fraction of CPU, but I don't expect it t= o > go much higher than 10%. > > > > But who knows, maybe 2 years from now everything else will be very > optimized and crypto will be 15%? > > > > Ian, thank you for sharing the proportion of CPU cycles we are likely to > spend for crypto. > > > > Your numbers relieves me, because even if the cost of crypto goes to 15%, > the overhead of PNE will be less than 1% (0.15*0.04=3D0.006). > > > > I would also like to note that it is likely that HyperThreading, when > used, will eliminate the overhead of PNE. > > > > This is because IIUC PNE is a marginal additional use of the AES-NI > engine, which have been mostly idle. The overhead of crypto is small (i.e= . > 15%) that we will rarely see contention on the engine. While one > hyperthread does AES, the other hyperthread will run at full speed doing > other operations. > > > > Also considering the fact that the number of CPU cycles spent per QUIC > packet does not change a lot with PNE, I would not be surprised to see *n= o* > decrease of throughput when PNE is used on a HyperThreading architecture. > In such case, what we will only observe is the raise of the utilization > ratio of the AES-NI engine. > > > > > > On Fri, Jun 22, 2018 at 12:34 PM Nick Banks dmarc.ietf.org> wrote: > > I just want to add, my implementation already uses ECB from bcrypt (and I > do the XOR) already. Bcrypt doesn=E2=80=99t expose CTR mode directly. > > > > Sent from Mail > > for Windows 10 > > > ------------------------------ > > *From:* Praveen Balasubramanian > *Sent:* Friday, June 22, 2018 9:26:44 AM > *To:* Ian Swett; Kazuho Oku > *Cc:* Nick Banks; IETF QUIC WG > *Subject:* RE: Packet Number Encryption Performance > > > > Ian, do you expect that fraction of overall cost to hold once the UDP > stack is optimized? Is your measurement on top of the recent kernel > improvements? I expect crypto fraction of overall cost to keep increasing > over time as the network stack bottlenecks are eliminated. > > > > Kazuho, should the draft describe the optimizations you are making? Or ar= e > these are too OpenSSL specific? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Friday, June 22, 2018 4:45 AM > *To:* Kazuho Oku > *Cc:* Nick Banks ; IETF QUIC WG > *Subject:* Re: Packet Number Encryption Performance > > > > Thanks for digging into the details of this, Kazuho. <4% increase in > crypto cost is a bit more than I originally expected(~2%), but crypto is > less than 10% of my CPU usage, so it's still less than 0.5% total, which = is > acceptable to me. > > > > On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku wrote: > > > > > > 2018-06-22 12:22 GMT+09:00 Kazuho Oku : > > > > > > 2018-06-22 11:54 GMT+09:00 Nick Banks : > > Hi Kazuho, > > > > Thanks for sharing your numbers as well! I'm bit confused where you say > you can reduce the 10% overhead to 2% to 4%. How do you plan on doing tha= t? > > > > As stated in my previous mail, the 10% of overhead consists of three > parts, each consuming comparable number of CPU cycles. The two among the > three is related to the abstraction layer and how CTR is implemented, whi= le > the other one is the core AES-ECB operation cost. > > > > It should be able to remove the costly abstraction layer. > > > > It should also be possible to remove the overhead of CTR, since in PNE, w= e > need to XOR at most 4 octets (applying XOR is the only difference between > CTR and ECB). That cost should be something that should be possible to be > nullified. > > > > Considering these aspects, and by looking at the numbers on the OpenSSL > source code (as well as considering the overhead of GCM), my expectation > goes to 2% to 4%. > > > > Just did some experiments and it seems that the expectation was correct. > > > > The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by > doing the following: > > > > * remove the overhead of CTR abstraction (i.e. use the ECB backend and do > XOR by ourselves) > > * remove the overhead of the abstraction layer (i.e. call the method > returned by EVP_CIPHER_meth_get_do_cipher instead of calling > EVP_EncryptUpdate) > > > > Of course the changes are specific to OpenSSL, but I would expect that yo= u > can expect similar numbers assuming that you have access to an optimized > AES implementation. > > > > > > > > Sent from my Windows 10 phone > > [HxS - 15254 - 16.0.10228.20075] > > > ------------------------------ > > *From:* Kazuho Oku > *Sent:* Thursday, June 21, 2018 7:21:17 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Packet Number Encryption Performance > > > > Hi Nick, > > > > Thank you for bringing the numbers to the list. > > > > I have just run a small benchmark using Quicly, and I see comparable > numbers. > > > > To be precise, I see 10.0% increase of CPU cycles when encrypting a > Initial packet of 1,280 octets. I expect that we will see similar numbers > on other QUIC stacks that also use picotls (with OpenSSL as a backend). > Note that the number is only comparing the cost of encryption, the overhe= ad > ratio will be much smaller if we look at the total number of CPU cycles > spent by a QUIC stack as a whole. > > > > Looking at the profile, the overhead consists of three operations that > each consumes comparable CPU cycles: core AES operation (using AES-NI), C= TR > operation overhead, CTR initialization. Note that picotls at the moment > provides access to CTR crypto beneath the AEAD interface, which is to be > used by the QUIC stacks. > > > > I would assume that we can cut down the overhead to somewhere between 2% > to 4%, but it might be hard to go down to somewhere near 1%, because we > cannot parallelize the AES operation of PNE with that of AEAD (see > https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/ > crypto/aes/asm/aesni-x86_64.pl#L24-L39 > > about the impact of parallelization). > > > > I do not think that 2% to 4% of additional overhead to the crypto is an > issue for QUIC/HTTP, but current overhead of 10% is something that we mig= ht > want to decrease. I am glad to be able to learn that now. > > > > > > 2018-06-22 5:48 GMT+09:00 Nick Banks dmarc.ietf.org>: > > Hello QUIC WG, > > > > I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided > to get some performance numbers to see what the overhead of PNE was. I > figured the rest of the WG might be interested. > > > > My test just encrypts the same buffer (size dependent on the test case) > 10,000,000 times and measured the time it took. The test then did the sam= e > thing, but also encrypted the packet number as well. I ran all that 10 > times in total. I then collected the best times for each category to > produce the following graphs and tables (full excel doc attached): > > > > > > > > *Time (ms)* > > *Rate (Mbps)* > > *Bytes* > > *NO PNE* > > *PNE* > > *PNE Overhead* > > *No PNE* > > *PNE* > > *4* > > 2284.671 > > 3027.657 > > 33% > > 140.064 > > 105.692 > > *16* > > 2102.402 > > 2828.204 > > 35% > > 608.827 > > 452.584 > > *64* > > 2198.883 > > 2907.577 > > 32% > > 2328.45 > > 1760.92 > > *256* > > 2758.3 > > 3490.28 > > 27% > > 7424.86 > > 5867.72 > > *600* > > 4669.283 > > 5424.539 > > 16% > > 10280 > > 8848.68 > > *1000* > > 6130.139 > > 6907.805 > > 13% > > 13050.3 > > 11581.1 > > *1200* > > 6458.679 > > 7229.672 > > 12% > > 14863.7 > > 13278.6 > > *1450* > > 7876.312 > > 8670.16 > > 10% > > 14727.7 > > 13379.2 > > > > I used a server grade lab machine I had at my disposal, running the lates= t > Windows 10 Server DataCenter build. Again, these numbers are for crypto > only. No QUIC or UDP is included. > > > > Thanks, > > - Nick > > > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > > > > > > -- > > Kazuho Oku > --=20 Kazuho Oku --000000000000e57101056f566a74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-06-23 23:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&g= t;:

I agree that the numbers for real work loads will be= interesting, but I do believe that raw QUIC stack numbers are also importa= nt. They will represent your best case scenario.

=C2=A0


<= /div>
To clarify, the reason I asked about the raw numbers and the use-= case is because without that I do not know how to interpret your numbers.

My understanding is that your benchmark is about en= crypting and sending large QUIC packets.

Assuming = that BCRYPT provides comparable performance to OpenSSL, the numbers you sho= w (i.e. 22.5% in user-mode, 38.5% in kernel-mode) means that you want to re= duce crypto cost when a single CPU core is emitting somewhere between 5Gbps= to 8 Gbps.

I wonder how much we would be interest= ed in such case. Let me explain why.

Assuming that= we have many connections, each CPU core will only handle somewhere around = 1Gbps to saturate a 25Gbps link. As I have stated in my previous mail, the = crypto cost will be around or less than 10% in such case.

Assuming that we are interested in utilizing a 25Gbps link for a si= ngle connection (or a small number of connections), I think that we would b= e generally considering of distributing both UDP send and encryption to mul= tiple CPU cores, because even without crypto, it is hard to utilize the ent= ire bandwidth using just one core (the same goes for the receive side). And= if you distribute the load to your CPU cores, the crypto cost becomes some= where around or below 10%.

This is my understandin= g. But I also understand that it could well be the case that I do not under= stand what your workload looks like. That's why I wonder if you could s= hare the raw numbers and the use-case.

For my testing, I have a fairly simple test of openi= ng a single unidirectional stream and just continually sending data until t= he core gets saturated. From that, I grab the performance trace, and specif= ically look at the composition of the QUIC stack=E2=80=99s send path. The send path constitutes generally al= l of the CPU for the whole connection anyways (with just a little overhead = seen from receiving and processing ACKs). The machine I used was another se= rver grade machine running the latest Windows 10 Server Datacenter.

=C2=A0

So the percentages I shared are for just the QUIC se= nd path (again, no PNE with these numbers). The numbers are for the percent= age of total CPU for all packets sent, but since all packets were pretty mu= ch the same size, the numbers should still hold for a single packet. And bottom line, encryption is a lot more = of an impact than 10%. And as we bring in more performance improvements for= UDP send path in Windows, we expect encryption to be higher and higher per= centage.

=C2=A0

- Nick

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Saturday, June 23, 2018 12:00 AM
To: Nick Banks <nibanks@microsoft.com>
Cc: Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>; Praveen Balasubramanian= <pravb@microso= ft.com>


Subject: Re: Packet Number Encryption Performance

=C2=A0

IIUC, Ian should be talking about performance number= s that you would see on a server that is handling real workload. Not the br= eakdown of numbers within the QUIC stack.

=C2=A0

Let's talk about nanoseconds per packet rather t= han the ratio, because ratio depends on what you use as a "total"= is.

=C2=A0

My benchmarks tell me that, on OpenSSL 1.1.0 running= on Core i7 @ 2.5GHz (MacBook Pro 15" Mid 2015), the numbers are:

=C2=A0

without-PNE: 585ns / packet

with-PNE: 607ns / packet (* this is the optimized ve= rsion with 3.8% overhead)

=C2=A0

Assuming that your peak rate is 1Gbit/CPU core (woul= d be enough to saturate 25Gb Ethernet), the ratio of CPU cycles for running= the crypto will be:

=C2=A0

all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/p= acket =3D 5.93 %

PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet = =3D 0.22 %

=C2=A0

Of course, these numbers are what is expected when a= server is sending or receiving full-sized packets in one direction. In rea= lity, there would be at least some flow in the opposite direction, so the n= umber will be higher, but not as much as 2x. Or if you are sending small-sized packet in *both* directions *and*= saturating the link, the ratio will be higher.

=C2=A0

But looking at the numbers, I'd assume that 10% = is a logical number for workload Ian has, and also for people who are invol= ved in content distribution.

=C2=A0

As shown, I think that sharing the PPS and average p= acket size that our workload will have, along with the raw numbers of the c= rypto (i.e. nsec / packet) will give us a better understanding on how much = the actual overhead is. Do you mind sharing your expectations?

=C2=A0

2018-06-23 9:34 GMT+09:00 Nick Banks <nibanks@microsoft.com&g= t;:

Hey Guys,

=C2=A0

I spent the better part of the day getting some perf= ormance traces of WinQuic without PNE. Our implementation supports both user mode and kernel m= ode, so I got numbers for both. The following table shows the relative CPU = cost of different parts of the QUIC send path:

=C2=A0

=C2=A0

User Mode

Kernel Mode

UDP Send

64.7%

41.4%

Encryption

22.5%

38.5%

Packet Building/Framing

7%

15%

Miscellaneous

5.8%

5.1%

=C2=A0

These numbers definitely show that encryption is a m= uch larger portion of CPU.

=C2=A0

- Nick

=C2=A0

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, June 22, 2018 5:02 PM
To: Ian Swett <ianswett@google.com>
Cc: Nick Banks <nibanks@microsoft.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <= quic@ietf.org>


Subject: Re: Packet Number Encryption Performance

=C2=A0

=C2=A0

=C2=A0

2018-06-23 3:51 GMT+09:00 Ian Swett <ianswett@google.com>:

I expect crypto to increase as a fraction of CPU, bu= t I don't expect it to go much higher than 10%.

=C2=A0

But who knows, maybe 2 years from now everything els= e will be very optimized and crypto will be 15%?

=C2=A0

Ian, thank you for sharing the proportion of CPU cyc= les we are likely to spend for crypto.

=C2=A0

Your numbers relieves me, because even if the cost o= f crypto goes to 15%, the overhead of PNE will be less than 1% (0.15*0.04= =3D0.006).

=C2=A0

I would also like to note that it is likely that Hyp= erThreading, when used, will eliminate the overhead of PNE.

=C2=A0

This is because IIUC PNE is a marginal additional us= e of the AES-NI engine, which have been mostly idle. The overhead of crypto= is small (i.e. 15%) that we will rarely see contention on the engine. While one hyperthread does AES, the other hyperthread will = run at full speed doing other operations.

=C2=A0

Also considering the fact that the number of CPU cyc= les spent per QUIC packet does not change a lot with PNE, I would not be su= rprised to see *no* decrease of throughput when PNE is used on a HyperThreading architecture. In such case, what we will only = observe is the raise of the utilization ratio of the AES-NI engine.<= u>

=C2=A0

=C2=A0

On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <niba= nks=3D4= 0microsoft.com@dmarc.ietf.org> wrote:

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=E2=80=99t expose CT= R mode directly.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance <= /u>

=C2=A0

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep increasing over time as the network stack bottlene= cks are eliminated.

=C2=A0

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

=C2=A0

Thanks for digging into the details of this, Kazuho.= =C2=A0 <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still less than 0.5% total, which is acceptable to me.<= /u>

=C2=A0

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com= > wrote:

=C2=A0

=C2=A0

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:=

=C2=A0

=C2=A0

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com&= gt;:

Hi Kazuho,

=C2=A0

Thanks for sharing your numbers as well! I'm bit= confused where you say you can reduce the 10% overhead to 2% to 4%. How do= you plan on doing that?

=C2=A0

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is implemented, while the other one is the core AES-ECB = operation cost.

=C2=A0

It should be able to remove the costly abstraction l= ayer.

=C2=A0

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that should be possible to be nullified.

=C2=A0

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

=C2=A0

Just did some experiments and it seems that the expe= ctation was correct.

=C2=A0

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

=C2=A0

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

=C2=A0

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

=C2=A0

=C2=A0

=C2=A0

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.10228.20075]

=C2=A0

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, June 21, 2018 7:21:17 PM
To: Nick Banks
Cc: quic@i= etf.org
Subject: Re: Packet Number Encryption Performance <= /u>

=C2=A0

Hi Nick,

=C2=A0

Thank you for bringing the numbers to the list.

=C2=A0

I have just run a small benchmark using Quicly, and = I see comparable numbers.

=C2=A0

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as a backend). Note that the number is only comparin= g the cost of encryption, the overhead ratio will be much smaller if we loo= k at the total number of CPU cycles spent by a QUIC stack as a whole.

=C2=A0

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picotls at the moment provides access to CTR crypto beneath the = AEAD interface, which is to be used by the QUIC stacks.

=C2=A0

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

=C2=A0

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that now.

=C2=A0

=C2=A0

2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks= =3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

=C2=A0

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.

=C2=A0

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I ran all that 10 times in total. I then collected = the best times for each category to produce the following graphs and tables= (full excel doc attached):

=C2=A0

=C2=A0

=C2=A0

Time (ms)<= u>

Rate (Mbps)

Bytes

NO PNE<= /u>

PNE=

PNE Overhead

No PNE<= /u>

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

=C2=A0

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

=C2=A0

Thanks,

- Nick

=C2=A0



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku



=C2=A0

--

Kazuho Oku




--
Kazuho Oku
--000000000000e57101056f566a74-- From nobody Sat Jun 23 17:45:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481B01310E5 for ; Sat, 23 Jun 2018 17:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=wTGiogog; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Srdzfki7 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 RjJ4ACsihEVM for ; Sat, 23 Jun 2018 17:45:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92DB130F1A for ; Sat, 23 Jun 2018 17:45:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1386320E5F for ; Sat, 23 Jun 2018 20:45:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 23 Jun 2018 20:45:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=q6yP+avAoK6dxrgML d2C/R83aICtICq78eMbQgFHh0E=; b=wTGiogogStGyMucbXB6q7gjE3F+xTT7TJ 5dE8tFzaIQ+pyNv9hf11YH/Vb64sXqewTR80/4ULBOMcc/Ty2mDDptNUAgoVP+QE zFMsiqvvClliDvokstni06sC2qh90LrvgG8s2CUBJlnVewEksB84SMpc5AAL4Kdt snIitciPve8uwPdW1lz0irnO0i+HtEE5Jq76WkjRIGgi3gEm7eOJ14QDsFV2k7eu t4yiakW69awrXTG3p5EgL3JJcnenP8tAl17HJfHmCYWuWfE6w28amnTqYifScHm8 FzP6f32Rn99u4ugRGwDJp1RSV1o1gCPzwoe0FQ8NUxjemXbNqc0JQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=q6yP+avAoK6dxrgMLd2C/R83aICtICq78eMbQgFHh0E=; b=Srdzfki7 +2hbsLTof7iOy2fWGSP84Zq/WzQ4zKgNsQsBAJzt0+Yyn3xhelp/tMUaqF/4YSIz u6OmWAeT3NTCDTOSTbqei0WE132ScZpJevpnpxpF1Pb2LWqodSDB/v5GimS41Bj3 f0EDmakzvBB2Bl+LXyoNKzwwrpCzo54rsi1MBgnuAUm+YSTafs5d5Scj0jV7eVGm t57gKkb952AJuB1Q9qIuRlfx4XsjvzNPSgECOnIhsb3bzod7kAVNS7K3DB7w8MhC F3njNHq+ITPP7rTBeseJE5Kp4E6BIH7MJ/Hbc1tVIs1/zXZ7ePKF4UINSLIITJvs 5njuBfmWvU9IWQ== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 20398E44F1 for ; Sat, 23 Jun 2018 20:45:23 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 71275CE94D for ; Sun, 24 Jun 2018 00:45:20 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4275627610875478939==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180624004520.71275CE94D@cloud.mnot.net> Date: Sun, 24 Jun 2018 00:45:20 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 00:45:29 -0000 --===============4275627610875478939== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+5/-3/=F0=9F=92=AC78) 5 issues created: - QPACK instruction code points are inconsistent (by afrind) https://github.com/quicwg/base-drafts/issues/1471 = - Prevent connection ID exhaustion (by martinthomson) https://github.com/quicwg/base-drafts/issues/1468 [-transport] [design] = - Confusion about number of outstanding CIDs (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1464 [-transport] [design] = - Duplicate STREAM/CRYPTO_HS in the same packet (by rpaulo) https://github.com/quicwg/base-drafts/issues/1463 = - hq: Are h2 pseudo-header requirements applicable (by LPardue) https://github.com/quicwg/base-drafts/issues/1461 = 13 issues received 78 new comments: - #1451 Looping with multiple Retry packets (40 by kazuho, mikkelfj, ians= wett, martinthomson, nibanks, ekr, MikeBishop) https://github.com/quicwg/base-drafts/issues/1451 [-transport] [design] = - #1443 Stateless Reset Eternal Ping Pong (6 by kazuho, mikkelfj, MikeBis= hop) https://github.com/quicwg/base-drafts/issues/1443 [-transport] [design] = - #1464 Confusion about number of outstanding CIDs (6 by kazuho, mikkelfj= , nibanks, martinthomson, MikeBishop, ekr) https://github.com/quicwg/base-drafts/issues/1464 [-transport] [design] = - #1463 Duplicate STREAM/CRYPTO_HS in the same packet (5 by martinthomson= , ekr, mikkelfj) https://github.com/quicwg/base-drafts/issues/1463 = - #1458 Coalesced packets and handshake packet limiting (3 by janaiyengar= , ekr, ianswett) https://github.com/quicwg/base-drafts/issues/1458 [-transport] [design] = - #1456 Support for multiplexing middleboxes by requiring SNI (3 by janai= yengar, martinthomson, jmtilli) https://github.com/quicwg/base-drafts/issues/1456 = - #1271 Connection migration optional? (3 by erickinnear, janaiyengar) https://github.com/quicwg/base-drafts/issues/1271 [-transport] [has-pro= posal] = - #795 SNI encryption (3 by jmtilli, larseggert, ekr) https://github.com/quicwg/base-drafts/issues/795 [-tls] [design] [parke= d] = - #1468 Prevent connection ID exhaustion (3 by kazuho, MikeBishop) https://github.com/quicwg/base-drafts/issues/1468 [-transport] [design] = - #1138 QPACK encoding requires two passes (2 by hvenev, MikeBishop) https://github.com/quicwg/base-drafts/issues/1138 [-qpack] [design] = - #1439 Improve ACK_ECN frame encoding (e.g., use bit-vector) (2 by gloin= ul, kazuho) https://github.com/quicwg/base-drafts/issues/1439 = - #1461 hq: Are h2 pseudo-header requirements applicable (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1461 = - #1471 QPACK instruction code points are inconsistent (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1471 [-qpack] = 3 issues closed: - Largest Reference too big https://github.com/quicwg/base-drafts/issues/= 1404 [-qpack] [design] [editor-ready] = - Support for multiplexing middleboxes by requiring SNI https://github.co= m/quicwg/base-drafts/issues/1456 = - Exhausting a supply of connection IDs https://github.com/quicwg/base-dr= afts/issues/1276 [-transport] [editor-ready] = Pull requests ------------- * quicwg/base-drafts (+8/-5/=F0=9F=92=AC6) 8 pull requests submitted: - Modify codepoints on decoder and request/push streams for consistency (= by afrind) https://github.com/quicwg/base-drafts/pull/1472 [-qpack] = - Fix bug in QPACK sample code (by afrind) https://github.com/quicwg/base-drafts/pull/1470 = - Decoder MAY error on an incorrect largest reference (by afrind) https://github.com/quicwg/base-drafts/pull/1469 = - Define the contents of QPACK Encoder and Decoder streams (by afrind) https://github.com/quicwg/base-drafts/pull/1467 = - Allow non-RFC6066 methods for indicating server domain (by janaiyengar) https://github.com/quicwg/base-drafts/pull/1466 = - Restore CID sequence numbers (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1465 [-transport] [design] = - Enable SNI encryption (by janaiyengar) https://github.com/quicwg/base-drafts/pull/1462 = - ECN Proposal with only two counters (by gloinul) https://github.com/quicwg/base-drafts/pull/1460 = 4 pull requests received 6 new comments: - #1447 TP to disable migration (3 by erickinnear, rpaulo, janaiyengar) https://github.com/quicwg/base-drafts/pull/1447 [-transport] [design] = - #1450 Stream0 dt output for merge (1 by ekr) https://github.com/quicwg/base-drafts/pull/1450 = - #1462 Allow SNI encryption (1 by ekr) https://github.com/quicwg/base-drafts/pull/1462 = - #1465 Restore CID sequence numbers (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1465 [-transport] [design] = 5 pull requests merged: - Decoder MAY error on an incorrect largest reference https://github.com/quicwg/base-drafts/pull/1469 [-qpack] [design] = - Fix bug in QPACK sample code https://github.com/quicwg/base-drafts/pull/1470 = - Allow non-RFC6066 methods for indicating server domain https://github.com/quicwg/base-drafts/pull/1466 = - Allow SNI encryption https://github.com/quicwg/base-drafts/pull/1462 = - Expand CID ratchet text https://github.com/quicwg/base-drafts/pull/1453 [-transport] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============4275627610875478939== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 24, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+5/-3/=F0=9F=92=AC78)

5 issues created:

13 issues received 78 new comments:

3 issues closed:

Pull requests

quicwg/base-drafts (+8/-5/=F0=9F=92=AC6)

8 pull requests submitted:

4 pull requests received 6 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============4275627610875478939==-- From nobody Sun Jun 24 08:55:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756FF130E0A for ; Sun, 24 Jun 2018 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmlF8IQTwNOC for ; Sun, 24 Jun 2018 08:55:26 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A358F129C6B for ; Sun, 24 Jun 2018 08:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wvgUzl7JyHcR4AjXrsWO2n2WeW9la/+M+/SwEo0ii3c=; b=DxwkKbCWTJG0DcbaYP7KEdGhw8aATjQpuvnmaKdpEWIMaVYBU9NDYOa9QYK+laBWBufpBdOwPv5i78pbSCHDtJAApCd1mQ7EhWtcuT4dTfu3ejurqouJkpLox5DpGc9i8ROGFbpHxvoxb2slfRxRz0n6DcudigSyLLZfnprA4MA= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1062.namprd21.prod.outlook.com (52.132.128.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.5; Sun, 24 Jun 2018 15:55:24 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9cbd:940b:ae62:4031%8]) with mapi id 15.20.0930.005; Sun, 24 Jun 2018 15:55:24 +0000 From: Nick Banks To: Kazuho Oku CC: IETF QUIC WG , Ian Swett , Praveen Balasubramanian Subject: RE: Packet Number Encryption Performance Thread-Topic: Packet Number Encryption Performance Thread-Index: AdQJn5UDP5dBCj8oST6dWmAQqIW3NwAMB4yAAAEQQOUAARRpgAAHDxAAAAp/RwAACYTCgAAAjosmAATQHgAACtMrgAABFu2QAA2HWoAAECJDgAAPqVqAACSY/as= Date: Sun, 24 Jun 2018 15:55:24 +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: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1062; 7:3hsLoFCWV0prO3keFrRe8ML9EDCYM8sz3nGHaK3hAuPnpkSka1YZV9KVtkWu/58zHbn6eZTH9mzsSBvsI87vp48wPPdDrSWzNy8k0SxARF0IL7j4oqdwyPY/7Pb1GHgtdkGe1yExb4uz3vmk0pnFjc+sMQL+mCzmywltnKA1qc0epp1/tMJIZPw19mvkJ3vABhZndM2GpP3hIDHSkVoaXVKnkFNdW9ksa1/9ggnEwMTj+EdqKnvREBnGedOC2hrf x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 26888f72-ca85-4669-62d9-08d5d9eae5ce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1062; x-ms-traffictypediagnostic: DM5PR2101MB1062: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(190756311086443)(158342451672863)(156600954879566)(89211679590171)(166708455590820)(189930954265078)(85827821059158)(211936372134217)(153496737603132); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1062; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1062; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(366004)(39380400002)(189003)(199004)(51444003)(54094003)(9686003)(6436002)(54906003)(55016002)(22452003)(478600001)(54896002)(6306002)(236005)(86362001)(446003)(11346002)(561924002)(59450400001)(99286004)(316002)(76176011)(7696005)(14454004)(486006)(476003)(66066001)(966005)(5250100002)(97736004)(5890100001)(86612001)(10290500003)(74316002)(2900100001)(7736002)(8936002)(53936002)(8990500004)(3660700001)(107886003)(6246003)(606006)(4326008)(39060400002)(3280700002)(6916009)(3480700004)(105586002)(229853002)(53546011)(102836004)(26005)(6506007)(93886005)(186003)(106356001)(5070765005)(1411001)(5660300001)(10090500001)(68736007)(33656002)(3846002)(6116002)(2906002)(81166006)(8676002)(345774005)(53946003)(25786009)(81156014)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1062; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: M6oZVZ/zO9cZGBUnkqFWCLlftqr6o/ctvUMtgHLB0tHasFtM0+dazvMbCY73laYcMEXogkjYjYvbYt9jKaCff7/ApVJaUqLdoIh/uzJ7/NcW7x/WLsu/vpJI+6YgBwDPMA1xHG+ceD5bXlId3pvexrwlDUQgFwRp3KQixLGf9z+aCtvPtwU8gg6AouHfj7LpPp7XCJ6YhJPz2XkXjaXcYV8LyuxeaPmoraTC/rl757ZoW/qGpxgCToLwsILqF0te0HCiaL+GxbnlN6gKzw7KMqNU0WE/R/2EOEUbMHoMzO7rhISKZQ8nn/ThJQRXZdwxUIUkz1scUeRI4BGYSdxvRmRAy1cndsLDeTJ9wrhlnLs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB09014E479732F8F3E980AE5EB34B0DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26888f72-ca85-4669-62d9-08d5d9eae5ce X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2018 15:55:24.2805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1062 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 15:55:32 -0000 --_000_DM5PR2101MB09014E479732F8F3E980AE5EB34B0DM5PR2101MB0901_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kazuho, WinQuic will be a generic QUIC transport, with HTTP being just one of the s= cenarios we have planned for it. The goal for the transport is always to pr= ovide the most performant solution possible, using as few CPU cycles as pos= sible, so the higher layers can have them. The test I used would most close= ly mimic a large file transfer over QUIC, were most of the CPU would end up= being used by the QUIC transport. So again, the goal here is to measure the cost of encryption (and eventuall= y PNE) compared to other QUIC transport layer work. That will give us the b= aseline we can provide to other layers on top of us. Obviously, the total C= PU percentage of encryption will be smaller when you include other layers o= n top of QUIC, but that will be dependent on the different protocols built = on QUIC, and the particular work load / scenario being executed. We shouldn= =92t assume any particular protocol/scenario and say we are fine with using= too much CPU at the lower layer, because the higher layer will be using ev= en more CPU anyways. As far as raw numbers, we are not prepared to share them at this time. Thanks, - Nick Sent from Mail for Window= s 10 ________________________________ From: Kazuho Oku Sent: Saturday, June 23, 2018 3:10:33 PM To: Nick Banks Cc: IETF QUIC WG; Ian Swett; Praveen Balasubramanian Subject: Re: Packet Number Encryption Performance 2018-06-23 23:54 GMT+09:00 Nick Banks >: I agree that the numbers for real work loads will be interesting, but I do = believe that raw QUIC stack numbers are also important. They will represent= your best case scenario. To clarify, the reason I asked about the raw numbers and the use-case is be= cause without that I do not know how to interpret your numbers. My understanding is that your benchmark is about encrypting and sending lar= ge QUIC packets. Assuming that BCRYPT provides comparable performance to OpenSSL, the number= s you show (i.e. 22.5% in user-mode, 38.5% in kernel-mode) means that you w= ant to reduce crypto cost when a single CPU core is emitting somewhere betw= een 5Gbps to 8 Gbps. I wonder how much we would be interested in such case. Let me explain why. Assuming that we have many connections, each CPU core will only handle some= where around 1Gbps to saturate a 25Gbps link. As I have stated in my previo= us mail, the crypto cost will be around or less than 10% in such case. Assuming that we are interested in utilizing a 25Gbps link for a single con= nection (or a small number of connections), I think that we would be genera= lly considering of distributing both UDP send and encryption to multiple CP= U cores, because even without crypto, it is hard to utilize the entire band= width using just one core (the same goes for the receive side). And if you = distribute the load to your CPU cores, the crypto cost becomes somewhere ar= ound or below 10%. This is my understanding. But I also understand that it could well be the c= ase that I do not understand what your workload looks like. That's why I wo= nder if you could share the raw numbers and the use-case. For my testing, I have a fairly simple test of opening a single unidirectio= nal stream and just continually sending data until the core gets saturated.= From that, I grab the performance trace, and specifically look at the comp= osition of the QUIC stack=92s send path. The send path constitutes generall= y all of the CPU for the whole connection anyways (with just a little overh= ead seen from receiving and processing ACKs). The machine I used was anothe= r server grade machine running the latest Windows 10 Server Datacenter. So the percentages I shared are for just the QUIC send path (again, no PNE = with these numbers). The numbers are for the percentage of total CPU for al= l packets sent, but since all packets were pretty much the same size, the n= umbers should still hold for a single packet. And bottom line, encryption i= s a lot more of an impact than 10%. And as we bring in more performance imp= rovements for UDP send path in Windows, we expect encryption to be higher a= nd higher percentage. - Nick From: Kazuho Oku > Sent: Saturday, June 23, 2018 12:00 AM To: Nick Banks > Cc: Ian Swett >; IETF QUIC = WG >; Praveen Balasubramanian > Subject: Re: Packet Number Encryption Performance IIUC, Ian should be talking about performance numbers that you would see on= a server that is handling real workload. Not the breakdown of numbers with= in the QUIC stack. Let's talk about nanoseconds per packet rather than the ratio, because rati= o depends on what you use as a "total" is. My benchmarks tell me that, on OpenSSL 1.1.0 running on Core i7 @ 2.5GHz (M= acBook Pro 15" Mid 2015), the numbers are: without-PNE: 585ns / packet with-PNE: 607ns / packet (* this is the optimized version with 3.8% overhea= d) Assuming that your peak rate is 1Gbit/CPU core (would be enough to saturate= 25Gb Ethernet), the ratio of CPU cycles for running the crypto will be: all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/packet =3D 5.93 % PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet =3D 0.22 % Of course, these numbers are what is expected when a server is sending or r= eceiving full-sized packets in one direction. In reality, there would be at= least some flow in the opposite direction, so the number will be higher, b= ut not as much as 2x. Or if you are sending small-sized packet in *both* di= rections *and* saturating the link, the ratio will be higher. But looking at the numbers, I'd assume that 10% is a logical number for wor= kload Ian has, and also for people who are involved in content distribution= . As shown, I think that sharing the PPS and average packet size that our wor= kload will have, along with the raw numbers of the crypto (i.e. nsec / pack= et) will give us a better understanding on how much the actual overhead is.= Do you mind sharing your expectations? 2018-06-23 9:34 GMT+09:00 Nick Banks >: Hey Guys, I spent the better part of the day getting some performance traces of WinQu= ic without PNE. Our implementation supports both user mode and kernel mode,= so I got numbers for both. The following table shows the relative CPU cost= of different parts of the QUIC send path: User Mode Kernel Mode UDP Send 64.7% 41.4% Encryption 22.5% 38.5% Packet Building/Framing 7% 15% Miscellaneous 5.8% 5.1% These numbers definitely show that encryption is a much larger portion of C= PU. - Nick From: Kazuho Oku > Sent: Friday, June 22, 2018 5:02 PM To: Ian Swett > Cc: Nick Banks >; Prave= en Balasubramanian >; IETF = QUIC WG > Subject: Re: Packet Number Encryption Performance 2018-06-23 3:51 GMT+09:00 Ian Swett >: I expect crypto to increase as a fraction of CPU, but I don't expect it to = go much higher than 10%. But who knows, maybe 2 years from now everything else will be very optimize= d and crypto will be 15%? Ian, thank you for sharing the proportion of CPU cycles we are likely to sp= end for crypto. Your numbers relieves me, because even if the cost of crypto goes to 15%, t= he overhead of PNE will be less than 1% (0.15*0.04=3D0.006). I would also like to note that it is likely that HyperThreading, when used,= will eliminate the overhead of PNE. This is because IIUC PNE is a marginal additional use of the AES-NI engine,= which have been mostly idle. The overhead of crypto is small (i.e. 15%) th= at we will rarely see contention on the engine. While one hyperthread does = AES, the other hyperthread will run at full speed doing other operations. Also considering the fact that the number of CPU cycles spent per QUIC pack= et does not change a lot with PNE, I would not be surprised to see *no* dec= rease of throughput when PNE is used on a HyperThreading architecture. In s= uch case, what we will only observe is the raise of the utilization ratio o= f the AES-NI engine. On Fri, Jun 22, 2018 at 12:34 PM Nick Banks > wrote: I just want to add, my implementation already uses ECB from bcrypt (and I d= o the XOR) already. Bcrypt doesn=92t expose CTR mode directly. Sent from Mail for Windows 10 ________________________________ From: Praveen Balasubramanian Sent: Friday, June 22, 2018 9:26:44 AM To: Ian Swett; Kazuho Oku Cc: Nick Banks; IETF QUIC WG Subject: RE: Packet Number Encryption Performance Ian, do you expect that fraction of overall cost to hold once the UDP stack= is optimized? Is your measurement on top of the recent kernel improvements= ? I expect crypto fraction of overall cost to keep increasing over time as = the network stack bottlenecks are eliminated. Kazuho, should the draft describe the optimizations you are making? Or are = these are too OpenSSL specific? From: QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Ian Swett Sent: Friday, June 22, 2018 4:45 AM To: Kazuho Oku > Cc: Nick Banks >; IETF = QUIC WG > Subject: Re: Packet Number Encryption Performance Thanks for digging into the details of this, Kazuho. <4% increase in crypt= o cost is a bit more than I originally expected(~2%), but crypto is less th= an 10% of my CPU usage, so it's still less than 0.5% total, which is accept= able to me. On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku > wrote: 2018-06-22 12:22 GMT+09:00 Kazuho Oku >: 2018-06-22 11:54 GMT+09:00 Nick Banks >: Hi Kazuho, Thanks for sharing your numbers as well! I'm bit confused where you say you= can reduce the 10% overhead to 2% to 4%. How do you plan on doing that? As stated in my previous mail, the 10% of overhead consists of three parts,= each consuming comparable number of CPU cycles. The two among the three is= related to the abstraction layer and how CTR is implemented, while the oth= er one is the core AES-ECB operation cost. It should be able to remove the costly abstraction layer. It should also be possible to remove the overhead of CTR, since in PNE, we = need to XOR at most 4 octets (applying XOR is the only difference between C= TR and ECB). That cost should be something that should be possible to be nu= llified. Considering these aspects, and by looking at the numbers on the OpenSSL sou= rce code (as well as considering the overhead of GCM), my expectation goes = to 2% to 4%. Just did some experiments and it seems that the expectation was correct. The benchmarks tell me that the overhead goes down from 10.0% to 3.8%, by d= oing the following: * remove the overhead of CTR abstraction (i.e. use the ECB backend and do X= OR by ourselves) * remove the overhead of the abstraction layer (i.e. call the method return= ed by EVP_CIPHER_meth_get_do_cipher instead of calling EVP_EncryptUpdate) Of course the changes are specific to OpenSSL, but I would expect that you = can expect similar numbers assuming that you have access to an optimized AE= S implementation. Sent from my Windows 10 phone [HxS - 15254 - 16.0.10228.20075] ________________________________ From: Kazuho Oku > Sent: Thursday, June 21, 2018 7:21:17 PM To: Nick Banks Cc: quic@ietf.org Subject: Re: Packet Number Encryption Performance Hi Nick, Thank you for bringing the numbers to the list. I have just run a small benchmark using Quicly, and I see comparable number= s. To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial= packet of 1,280 octets. I expect that we will see similar numbers on other= QUIC stacks that also use picotls (with OpenSSL as a backend). Note that t= he number is only comparing the cost of encryption, the overhead ratio will= be much smaller if we look at the total number of CPU cycles spent by a QU= IC stack as a whole. Looking at the profile, the overhead consists of three operations that each= consumes comparable CPU cycles: core AES operation (using AES-NI), CTR ope= ration overhead, CTR initialization. Note that picotls at the moment provid= es access to CTR crypto beneath the AEAD interface, which is to be used by = the QUIC stacks. I would assume that we can cut down the overhead to somewhere between 2% to= 4%, but it might be hard to go down to somewhere near 1%, because we canno= t parallelize the AES operation of PNE with that of AEAD (see https://githu= b.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L2= 4-L39 about the impact of parallelization). I do not think that 2% to 4% of additional overhead to the crypto is an iss= ue for QUIC/HTTP, but current overhead of 10% is something that we might wa= nt to decrease. I am glad to be able to learn that now. 2018-06-22 5:48 GMT+09:00 Nick Banks >: Hello QUIC WG, I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided to= get some performance numbers to see what the overhead of PNE was. I figure= d the rest of the WG might be interested. My test just encrypts the same buffer (size dependent on the test case) 10,= 000,000 times and measured the time it took. The test then did the same thi= ng, but also encrypted the packet number as well. I ran all that 10 times i= n total. I then collected the best times for each category to produce the f= ollowing graphs and tables (full excel doc attached): Time (ms) Rate (Mbps) Bytes NO PNE PNE PNE Overhead No PNE PNE 4 2284.671 3027.657 33% 140.064 105.692 16 2102.402 2828.204 35% 608.827 452.584 64 2198.883 2907.577 32% 2328.45 1760.92 256 2758.3 3490.28 27% 7424.86 5867.72 600 4669.283 5424.539 16% 10280 8848.68 1000 6130.139 6907.805 13% 13050.3 11581.1 1200 6458.679 7229.672 12% 14863.7 13278.6 1450 7876.312 8670.16 10% 14727.7 13379.2 I used a server grade lab machine I had at my disposal, running the latest = Windows 10 Server DataCenter build. Again, these numbers are for crypto onl= y. No QUIC or UDP is included. Thanks, - Nick -- Kazuho Oku -- Kazuho Oku -- Kazuho Oku -- Kazuho Oku -- Kazuho Oku -- Kazuho Oku --_000_DM5PR2101MB09014E479732F8F3E980AE5EB34B0DM5PR2101MB0901_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Kazuho,

 

WinQuic will be a generic QUIC transport, with HTTP = being just one of the scenarios we have planned for it. The goal for the tr= ansport is always to provide the most performant solution possible, using a= s few CPU cycles as possible, so the higher layers can have them. The test I used would most closely mimic a la= rge file transfer over QUIC, were most of the CPU would end up being used b= y the QUIC transport.

 

So again, the goal here is to measure the cost of en= cryption (and eventually PNE) compared to other QUIC transport layer work. = That will give us the baseline we can provide to other layers on top of us.= Obviously, the total CPU percentage of encryption will be smaller when you include other layers on top of QUIC= , but that will be dependent on the different protocols built on QUIC, and = the particular work load / scenario being executed. We shouldn=92t assume a= ny particular protocol/scenario and say we are fine with using too much CPU at the lower layer, because the hi= gher layer will be using even more CPU anyways.

 

As far as raw numbers, we are not prepared to share = them at this time.

 

Thanks,

- Nick

 

Sent from Mail for Windows 10

 

From: Kazuho Oku <kazuho= oku@gmail.com>
Sent: Saturday, June 23, 2018 3:10:33 PM
To: Nick Banks
Cc: IETF QUIC WG; Ian Swett; Praveen Balasubramanian
Subject: Re: Packet Number Encryption Performance
 


2018-06-23 23:54 GMT+09:00 Nick Banks <= nibanks@microsoft.com>:

I agree that the numbers for real work loads will be= interesting, but I do believe that raw QUIC stack numbers are also importa= nt. They will represent your best case scenario.

 


To clarify, the reason I asked about the raw numbers and the use-case = is because without that I do not know how to interpret your numbers.

My understanding is that your benchmark is about encrypting and sendin= g large QUIC packets.

Assuming that BCRYPT provides comparable performance to OpenSSL, the n= umbers you show (i.e. 22.5% in user-mode, 38.5% in kernel-mode) means that = you want to reduce crypto cost when a single CPU core is emitting somewhere= between 5Gbps to 8 Gbps.

I wonder how much we would be interested in such case. Let me explain = why.

Assuming that we have many connections, each CPU core will only handle= somewhere around 1Gbps to saturate a 25Gbps link. As I have stated in my p= revious mail, the crypto cost will be around or less than 10% in such case.=

Assuming that we are interested in utilizing a 25Gbps link for a singl= e connection (or a small number of connections), I think that we would be g= enerally considering of distributing both UDP send and encryption to multip= le CPU cores, because even without crypto, it is hard to utilize the entire bandwidth using just one core (th= e same goes for the receive side). And if you distribute the load to your C= PU cores, the crypto cost becomes somewhere around or below 10%.

This is my understanding. But I also understand that it could well be = the case that I do not understand what your workload looks like. That's why= I wonder if you could share the raw numbers and the use-case.

For my testing, I have a fairly simple test of openi= ng a single unidirectional stream and just continually sending data until t= he core gets saturated. From that, I grab the performance trace, and specif= ically look at the composition of the QUIC stack=92s send path. The send path constitutes generally all of t= he CPU for the whole connection anyways (with just a little overhead seen f= rom receiving and processing ACKs). The machine I used was another server g= rade machine running the latest Windows 10 Server Datacenter.

 

So the percentages I shared are for just the QUIC se= nd path (again, no PNE with these numbers). The numbers are for the percent= age of total CPU for all packets sent, but since all packets were pretty mu= ch the same size, the numbers should still hold for a single packet. And bottom line, encryption is a lot more = of an impact than 10%. And as we bring in more performance improvements for= UDP send path in Windows, we expect encryption to be higher and higher per= centage.

 

- Nick

 

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Saturday, June 23, 2018 12:00 AM
To: Nick Banks <nibanks@microsoft.com>
Cc: Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>; Praveen Balasubramanian= <pravb@microso= ft.com>


Subject: Re: Packet Number Encryption Performance

 

IIUC, Ian should be talking about performance number= s that you would see on a server that is handling real workload. Not the br= eakdown of numbers within the QUIC stack.

 

Let's talk about nanoseconds per packet rather than = the ratio, because ratio depends on what you use as a "total" is.=

 

My benchmarks tell me that, on OpenSSL 1.1.0 running= on Core i7 @ 2.5GHz (MacBook Pro 15" Mid 2015), the numbers are:

 

without-PNE: 585ns / packet

with-PNE: 607ns / packet (* this is the optimized ve= rsion with 3.8% overhead)

 

Assuming that your peak rate is 1Gbit/CPU core (woul= d be enough to saturate 25Gb Ethernet), the ratio of CPU cycles for running= the crypto will be:

 

all crypto: 0.125GB/sec / 1280bytes/packet * 607ns/p= acket =3D 5.93 %

PNE: 0.125GB/sec / 1280bytes/packet * 22.4ns/packet = =3D 0.22 %

 

Of course, these numbers are what is expected when a= server is sending or receiving full-sized packets in one direction. In rea= lity, there would be at least some flow in the opposite direction, so the n= umber will be higher, but not as much as 2x. Or if you are sending small-sized packet in *both* directions *and*= saturating the link, the ratio will be higher.

 

But looking at the numbers, I'd assume that 10% is a= logical number for workload Ian has, and also for people who are involved = in content distribution.

 

As shown, I think that sharing the PPS and average p= acket size that our workload will have, along with the raw numbers of the c= rypto (i.e. nsec / packet) will give us a better understanding on how much = the actual overhead is. Do you mind sharing your expectations?

 

2018-06-23 9:34 GMT+09:00 Nick Banks <nibanks@microsoft.com>:

Hey Guys,

 

I spent the better part of the day getting some perf= ormance traces of WinQuic without PNE. Our implementation supports both user mode and kernel m= ode, so I got numbers for both. The following table shows the relative CPU = cost of different parts of the QUIC send path:

 

 

User Mode

Kernel Mode

UDP Send

64.7%

41.4%

Encryption

22.5%

38.5%

Packet Building/Framing

7%

15%

Miscellaneous

5.8%

5.1%

 

These numbers definitely show that encryption is a m= uch larger portion of CPU.

 

- Nick

 

 

From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Friday, June 22, 2018 5:02 PM
To: Ian Swett <ianswett@google.com>
Cc: Nick Banks <nibanks@microsoft.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <= quic@ietf.org>


Subject: Re: Packet Number Encryption Performance

 

 

 

2018-06-23 3:51 GMT+09:00 Ian Swett <ianswett@google.com&g= t;:

I expect crypto to increase as a fraction of CPU, bu= t I don't expect it to go much higher than 10%.

 

But who knows, maybe 2 years from now everything els= e will be very optimized and crypto will be 15%?

 

Ian, thank you for sharing the proportion of CPU cyc= les we are likely to spend for crypto.

 

Your numbers relieves me, because even if the cost o= f crypto goes to 15%, the overhead of PNE will be less than 1% (0.15*0.04= =3D0.006).

 

I would also like to note that it is likely that Hyp= erThreading, when used, will eliminate the overhead of PNE.

 

This is because IIUC PNE is a marginal additional us= e of the AES-NI engine, which have been mostly idle. The overhead of crypto= is small (i.e. 15%) that we will rarely see contention on the engine. Whil= e one hyperthread does AES, the other hyperthread will run at full speed doing other operations.

 

Also considering the fact that the number of CPU cyc= les spent per QUIC packet does not change a lot with PNE, I would not be su= rprised to see *no* decrease of throughput when PNE is used on a HyperThrea= ding architecture. In such case, what we will only observe is the raise of the utilization ratio of the AES-NI e= ngine.

 

 

On Fri, Jun 22, 2018 at 12:34 PM Nick Banks <niba= nks=3D4= 0microsoft.com@dmarc.ietf.org> wrote:

I just want to add, my implementation already uses E= CB from bcrypt (and I do the XOR) already. Bcrypt doesn=92t expose CTR mode= directly.

 

Sent from Mail for Windows 10

 

From: Praveen Balasubramanian
Sent: Friday, June 22, 2018 9:26:44 AM
To: Ian Swett; Kazuho Oku
Cc: Nick Banks; IETF QUIC WG
Subject: RE: Packet Number Encryption Performance <= /u>

 

Ian, do you expect that fraction of overall cost to = hold once the UDP stack is optimized? Is your measurement on top of the rec= ent kernel improvements? I expect crypto fraction of overall cost to keep i= ncreasing over time as the network stack bottlenecks are eliminated.

 

Kazuho, should the draft describe the optimizations = you are making? Or are these are too OpenSSL specific?

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Friday, June 22, 2018 4:45 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Packet Number Encryption Performance

 

Thanks for digging into the details of this, Kazuho.=   <4% increase in crypto cost is a bit more than I originally expec= ted(~2%), but crypto is less than 10% of my CPU usage, so it's still less t= han 0.5% total, which is acceptable to me.

 

On Fri, Jun 22, 2018 at 2:45 AM Kazuho Oku <kazuhooku@gmail.com= > wrote:

 

 

2018-06-22 12:22 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com&= gt;:

 

 

2018-06-22 11:54 GMT+09:00 Nick Banks <nibanks@microsoft.com<= /a>>:

Hi Kazuho,

 

Thanks for sharing your numbers as well! I'm bit con= fused where you say you can reduce the 10% overhead to 2% to 4%. How do you= plan on doing that?

 

As stated in my previous mail, the 10% of overhead c= onsists of three parts, each consuming comparable number of CPU cycles. The= two among the three is related to the abstraction layer and how CTR is imp= lemented, while the other one is the core AES-ECB operation cost.

 

It should be able to remove the costly abstraction l= ayer.

 

It should also be possible to remove the overhead of= CTR, since in PNE, we need to XOR at most 4 octets (applying XOR is the on= ly difference between CTR and ECB). That cost should be something that shou= ld be possible to be nullified.

 

Considering these aspects, and by looking at the num= bers on the OpenSSL source code (as well as considering the overhead of GCM= ), my expectation goes to 2% to 4%.

 

Just did some experiments and it seems that the expe= ctation was correct.

 

The benchmarks tell me that the overhead goes down f= rom 10.0% to 3.8%, by doing the following:

 

* remove the overhead of CTR abstraction (i.e. use t= he ECB backend and do XOR by ourselves)

* remove the overhead of the abstraction layer (i.e.= call the method returned by EVP_CIPHER_meth_get_do_cipher instead of calli= ng EVP_EncryptUpdate)

 

Of course the changes are specific to OpenSSL, but I= would expect that you can expect similar numbers assuming that you have ac= cess to an optimized AES implementation.

 

 

Hi Nick,

 

Thank you for bringing the numbers to the list.

 

I have just run a small benchmark using Quicly, and = I see comparable numbers.

 

To be precise, I see 10.0% increase of CPU cycles wh= en encrypting a Initial packet of 1,280 octets. I expect that we will see s= imilar numbers on other QUIC stacks that also use picotls (with OpenSSL as = a backend). Note that the number is only comparing the cost of encryption, the overhead ratio will be much sma= ller if we look at the total number of CPU cycles spent by a QUIC stack as = a whole.

 

Looking at the profile, the overhead consists of thr= ee operations that each consumes comparable CPU cycles: core AES operation = (using AES-NI), CTR operation overhead, CTR initialization. Note that picot= ls at the moment provides access to CTR crypto beneath the AEAD interface, which is to be used by the QUIC sta= cks.

 

I would assume that we can cut down the overhead to = somewhere between 2% to 4%, but it might be hard to go down to somewhere ne= ar 1%, because we cannot parallelize the AES operation of PNE with that of = AEAD (see https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes= /asm/aesni-x86_64.pl#L24-L39 about the impact of parallelization).=

 

I do not think that 2% to 4% of additional overhead = to the crypto is an issue for QUIC/HTTP, but current overhead of 10% is som= ething that we might want to decrease. I am glad to be able to learn that n= ow.

 

 

2018-06-22 5:48 GMT+09:00 Nick Banks <niba= nks=3D40microsoft.com@dmarc.ietf.org>:

Hello QUIC WG,

 

I recently implemented PNE for WinQuic (using bcrypt= APIs) and I decided to get some performance numbers to see what the overhe= ad of PNE was. I figured the rest of the WG might be interested.<= /u>

 

My test just encrypts the same buffer (size dependen= t on the test case) 10,000,000 times and measured the time it took. The tes= t then did the same thing, but also encrypted the packet number as well. I = ran all that 10 times in total. I then collected the best times for each category to produce the following g= raphs and tables (full excel doc attached):

 

 

 

Time (ms)<= u>

Rate (Mbps)

Bytes

NO PNE<= /u>

PNE=

PNE Overhead

No PNE<= /u>

PNE=

4

2284.671

3027.657

33%

140.064

105.692

16

2102.402

2828.204

35%

608.827

452.584

64

2198.883

2907.577

32%

2328.45

1760.92

256

2758.3

3490.28

27%

7424.86

5867.72

600

4669.283

5424.539

16%

10280

8848.68

1000

6130.139

6907.805

13%

13050.3

11581.1

1200

6458.679

7229.672

12%

14863.7

13278.6

1450

7876.312

8670.16

10%

14727.7

13379.2

 

I used a server grade lab machine I had at my dispos= al, running the latest Windows 10 Server DataCenter build. Again, these num= bers are for crypto only. No QUIC or UDP is included.

 

Thanks,

- Nick

 



 

--

Kazuho Oku



 

--

Kazuho Oku



 

--

Kazuho Oku



 

--

Kazuho Oku



 

--

Kazuho Oku




--
Kazuho Ok= u
--_000_DM5PR2101MB09014E479732F8F3E980AE5EB34B0DM5PR2101MB0901_-- From nobody Mon Jun 25 10:52:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42E6130EC1 for ; Mon, 25 Jun 2018 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 bx2VlO119G0V for ; Mon, 25 Jun 2018 10:52:48 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 115B8130E13 for ; Mon, 25 Jun 2018 10:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529949167; x=2393862767; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: 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=R9hrCWf4zzPD4f5rr8pF8g4c4hR91ibz25wT9jpsho4=; b=LO/s6qZ0p9WdhvAGudd2/6Z5jWGGn5wx3nXhqlTYxwoNXACNPgTmV+VvCdpNaeXS oYJTXlbDQUty1ZFhrnax/IFffc350Gwgw7MlHfgyNfFm7f0QW4kxnYtvIxMLA6tU Q34uh9yKDigbsr1WXLNg8nFg7uOzHhVpcI1qXjC/byNLqyAU4mGhKkEirgubqAle wJqiDxOEUnCcdDjpsDRDSV5b14U2wKSUfPALetOPxDtmuHb4dhtAskQrixrixfWF eS9ZsAL6d6iCL++Pc4N2iNfWzNb1io1BrTvvItjoK2eomSCY859t1njzUzj3zh1Y h6/+Fseg/fSislCsA+dodg==; X-AuditID: 11973e12-ef58c9e0000010b7-e3-5b312bef4384 Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 34.CD.04279.FEB213B5; Mon, 25 Jun 2018 10:52:47 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PAW00CCF4BYR5I0@ma1-mtap-s03.corp.apple.com>; Mon, 25 Jun 2018 10:52:46 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAW00B0046DQA00@nwk-mmpp-sz13.apple.com>; Mon, 25 Jun 2018 10:52:46 -0700 (PDT) X-V-A: X-V-T-CD: a73ada5d95d0e12dfbe5201d786457f4 X-V-E-CD: 447fd55bf8410002e977a0029a011f6b X-V-R-CD: 578b4df02a3facc6f923c580edfa6be9 X-V-CD: 0 X-V-ID: b4e49f5e-ccd3-42ad-8751-ad61a913563f Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAW00B0046YQK00@nwk-mmpp-sz13.apple.com>; Mon, 25 Jun 2018 10:52:39 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-25_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from rui-imac.scv.apple.com ([17.192.155.24]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAW006CE4BRSH20@nwk-mmpp-sz13.apple.com>; Mon, 25 Jun 2018 10:52:39 -0700 (PDT) Sender: rpaulo@apple.com Subject: Re: Packet Number Encryption Performance From: Rui Paulo In-reply-to: Date: Mon, 25 Jun 2018 10:52:39 -0700 Cc: Ian Swett , Praveen Balasubramanian , Nick Banks , IETF QUIC WG Content-transfer-encoding: quoted-printable Message-id: <0AE1339A-3267-44CE-8EC1-D730A523F962@apple.com> References: To: Kazuho Oku X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUiqOHDrvte2zDa4N9WXYuf93ayWrz92M5q MW/PJnaL1z2PGS16FnA7sHqcWHaF1WPnrLvsHgs2lXosWfKTyaN1x1/2ANYoLpuU1JzMstQi fbsErowDD+wKJrNXHG17yNzAeI21i5GTQ0LAROLLqf/MXYxcHEIC+5gkTj5cxgiS4BUQlPgx +R5LFyMHB7OAusSUKbkQNRuZJH4veM0O4XQxSWz9944NYhKbxPoTS5ggbC2JiWvvMcLYN/9d ZIGx9/9cyw5hc0qc/zKRHWSBhICOxN+/tSBhIYFOJom5rTYQJdkSW26cYYQoCZbY/1YZYu0E JolHk2aArRIWkJDYf/IhO4RtKHHt5llmEJtNQEniWd8JsDgnUO+fxZfA6lkEVCXe/d/HCDKI WWA1o8SvxuvgkGAW0JZ48u4CK8TzNhI/fv6Fhkovm8TKA1PBnhERUJF4c3g+1ANqEvNvv2Cd wCg9CynAZiECbBaSsQsYmVcxCuUmZuboZuaZ6CUWFOSk6iXn525iBEX0dDuhHYynVlkdYhTg YFTi4WV4YxAtxJpYVlyZe4hRmoNFSZx3+m+gkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZL Tol5Pqu1jqw95vjLKlG2UO4Mx68c0/XTdHftMkxMPD9JeMu+z2kCG+0tPI58rcr4951pVq79 gkN/RW6o2MUfFXZn2NhdrDJ/4QLljGmOee5FZrsFgzSefVtvNfvRuwdxgvney1o8mBhUJ0pf WZSk/aas8+ervsqnkwIVWzvehl22rZOY66vEUpyRaKjFXFScCACOG8jSyQIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 17:52:51 -0000 On Jun 22, 2018, at 17:01, Kazuho Oku wrote: >=20 > This is because IIUC PNE is a marginal additional use of the AES-NI = engine, which have been mostly idle. The overhead of crypto is small = (i.e. 15%) that we will rarely see contention on the engine. While one = hyperthread does AES, the other hyperthread will run at full speed doing = other operations. >=20 > Also considering the fact that the number of CPU cycles spent per QUIC = packet does not change a lot with PNE, I would not be surprised to see = *no* decrease of throughput when PNE is used on a HyperThreading = architecture. In such case, what we will only observe is the raise of = the utilization ratio of the AES-NI engine. I don=E2=80=99t disagree but this is a very brand/model specific claim = and we can=E2=80=99t assume the cost of PNE will be reasonable = everywhere. =E2=80=94 Rui Paulo From nobody Mon Jun 25 20:02:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633801277BB for ; Mon, 25 Jun 2018 20:02:10 -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 GPd8NhLmPZPp for ; Mon, 25 Jun 2018 20:02:08 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 3BB3F12785F for ; Mon, 25 Jun 2018 20:02:08 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id c13-v6so5626864wrq.2 for ; Mon, 25 Jun 2018 20:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xsANbO8gf3nIu2ObKzqfui0Q/lix/fLmWL38qk2bMyg=; b=Ljk43QrQb2RvWTJeQy39wMdjH4gJWsoY41yhPncm/rrMjt6PNHcBfAYdxqy24Tz0Zo FMvHANdRhmlfs4fBszBFRtIDRdRQs3LKEu2siODiU7LKS8ZHwNIVsGHFOPSYyDpcv5bD OWT2M0rNcpUBtlr4GqFJ5zxAXiFhh25OMaISMYJ7wBVno9jzoSyCA7p7SP7OnXxHFGhU CR0TIUItrDzRa+6Z3fmU/rc6FI6IL4mOgQwqLUZtbXlLbEQKNbE2gLyBtV94SFcJMHRw NrTAaVcuTAz2bMm/r6viPb0JpM8kesS4RziWRsjDoIMY/juYdFr8sVM5oDlsM61Z8xDm RlCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xsANbO8gf3nIu2ObKzqfui0Q/lix/fLmWL38qk2bMyg=; b=JT8XkzEkaiQNXsWKHv+bPQlKNPAtgS8g7F7EPenk7POQBRu9WEqQ3x182U3XwN98Wd 4+iStpKEa75V/dyxu88dG/t4h+mutOItMcHZsWHBrHH8T3mAUJY7oWPE6HgDWZVZ8zEU Ag7/mn18V67mVef3A7l30pmF06awJdgmbfQjzFaV1nmCWXSvqecqlaicYV56tYP7UZvw /udXnF5xNGfy4+6P+tmwvXzzxk+wWrvqmYreKHN+Bmiz2uJUbidZ4Cc3IrkwYGe3cFt+ krzPq4/AaE4scvJ4VYdj2VKYzaZtzypFd9HiDgcHZWHXK6u2vI4NIb7/6y+XxvCLKW2P Mpsw== X-Gm-Message-State: APt69E3qUp5nczwz7/V1zzE3lIKug5zVRaCu1fSiDuowGYpx39/VguaK Z+jJ4JKII2jyuRztnXqNBGtHtzXaL7NpYgorx2A= X-Google-Smtp-Source: AAOMgpcfHuaotl4u5rChjUm34aJRHYnhfQjtG1obgwDe1p3CrpWqORn/p/WtWxVDroysPPcCoJq5FvClF+y8M8w8MbQ= X-Received: by 2002:adf:9a0b:: with SMTP id z11-v6mr353243wrb.47.1529982126393; Mon, 25 Jun 2018 20:02:06 -0700 (PDT) MIME-Version: 1.0 References: <20180608153916.GC13418@ubuntu-dmitri> In-Reply-To: From: Martin Duke Date: Mon, 25 Jun 2018 20:01:54 -0700 Message-ID: Subject: Re: What was the QUIC Load Balancers resolution? To: Mike Bishop Cc: Dmitri Tikhonov , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000280f74056f82b9f1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 03:02:11 -0000 --000000000000280f74056f82b9f1 Content-Type: text/plain; charset="UTF-8" Yes, there was no firm conclusion. There were some recommendations on what the side channel should be, general agreement that this was a good thing to be working on, and general reluctance for the QUIC WG to do much work here. That said, there are some email discussions going on and we're going to continue work on the draft Dmitri, would you like to be a part of this? On Fri, Jun 8, 2018 at 8:44 AM Mike Bishop wrote: > It wasn't a resolution, just a discussion -- Martin presented the work > he's been doing and asked for people interested in working with him to get > in touch. > > -----Original Message----- > From: QUIC On Behalf Of Dmitri Tikhonov > Sent: Friday, June 8, 2018 9:39 AM > To: IETF QUIC WG > Subject: What was the QUIC Load Balancers resolution? > > All, > > What was the WG resolution with regard to the QUIC Load Balancers > proposal? I failed to grasp the outcome of the discussion and the minutes > [1] do not have it. > > Thanks, > > - Dmitri. > > 1. > https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0RBe9y4c/edit#heading=h.jlkx7yo7rr9h > > --000000000000280f74056f82b9f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, there was no firm conclusion. There were some recomme= ndations on what the side channel should be, general agreement that this wa= s a good thing to be working on, and general reluctance for the QUIC WG to = do much work here.

That said, there are some email discu= ssions going on and we're going to continue work on the draft Dmitri, w= ould you like to be a part of this?

On Fri, Jun 8, 2018 at 8:44 AM Mike Bishop <mbishop@evequefou.be> wrote:
It wasn't a resolution, just a discus= sion -- Martin presented the work he's been doing and asked for people = interested in working with him to get in touch.

-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Dmitri Tikhonov
Sent: Friday, June 8, 2018 9:39 AM
To: IETF QUIC WG <qui= c@ietf.org>
Subject: What was the QUIC Load Balancers resolution?

All,

What was the WG resolution with regard to the QUIC Load Balancers proposal?= =C2=A0 I failed to grasp the outcome of the discussion and the minutes [1] = do not have it.

Thanks,

=C2=A0 - Dmitri.

1. https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0E= f_gp3dJo0RBe9y4c/edit#heading=3Dh.jlkx7yo7rr9h

--000000000000280f74056f82b9f1-- From nobody Tue Jun 26 11:25:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE72131054 for ; Tue, 26 Jun 2018 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qVVYwFPJVGhW for ; Tue, 26 Jun 2018 11:25:28 -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 BAEB0130E20 for ; Tue, 26 Jun 2018 11:25:28 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u4-v6so3761271itg.0 for ; Tue, 26 Jun 2018 11:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j/ebsQOL2UJ/WHbetmFDFLxTu1+PN22nUQchLF+KyBY=; b=A0fSkNs8pY0KGgkelFqRkfR6wtFhkhzUgtwZzRVLTFnJKk2tfjjxKsaqvQYz+oCvFt Iu8FqcRNIBNjiO1CGql621BOMe3HSXjNyJE+RWhwYIY38JElnagyTV5FiD4X6HvaipY+ OoInRyM5yScENtXPwesRB/Sty4tmySWuxDsvxtnOJdemysJdYSzVulViypRlIOKbIkyU gF7EBoP1eYhmKLEosmYlkZJ1q1eCSDJFC/eQMOm1uAOsvxX/BOmnXg1Ss8q5UNqvBfEr +UXyIy7++uJO4BTFX+r8TOQvIV+S+wnvH2a5UQoPVQxyLJWOD5jiNcB8aGmlF8cgwjqV hbqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j/ebsQOL2UJ/WHbetmFDFLxTu1+PN22nUQchLF+KyBY=; b=dak+dl+fLsA8adpEneu1P5lm6lhuXudtjllxexRXYy4rxCWnteWsquZJFaGyOX41kv VB/PCbNwzRZt7NxDQKr9iDRVky395Tmp2oPF2KPdHIEJDgaugRAp7XO0PpUuoSfSkysp YgICoDhe0pbMD29vUq3cRJZvMbUzWNlsQ3zwMNpkM2dJlmvJtYtimNqECy/HnSY0q42u D3zL/S5HbMRfwHfccM+SOzoRjU6ZW9Gnddh8HRreBcYD+dFdEv+LXugT4twHDO0kT1Zh pJiGoZSPDuTFcMrim2A43Ebj/tQUdoGhOdnO2qAFiZKQjgpd3NofNlNUQE70tN9JD8zU CUqQ== X-Gm-Message-State: APt69E3EMIGxNlqy0qIaoDGjuc5KedRGXRXKZ3QxI6jLBduMhP8GTKXj 5C+U6M6Y2PVKfWzHSGU1YhreUgKknSncIZdLyLg= X-Google-Smtp-Source: AAOMgpfEeqop5U3GJkhieJCzc1DO2OfRKREdoefgRyywX4jIDJPnO4hxuGrRfaGVYcLNvfGdMeR7cqFBDozrLDW2GzI= X-Received: by 2002:a24:5594:: with SMTP id e142-v6mr2343386itb.46.1530037528037; Tue, 26 Jun 2018 11:25:28 -0700 (PDT) MIME-Version: 1.0 References: <0AE1339A-3267-44CE-8EC1-D730A523F962@apple.com> In-Reply-To: <0AE1339A-3267-44CE-8EC1-D730A523F962@apple.com> From: Jana Iyengar Date: Tue, 26 Jun 2018 11:25:16 -0700 Message-ID: Subject: Re: Packet Number Encryption Performance To: Rui Paulo Cc: Kazuho Oku , Praveen Balasubramanian , Ian Swett , nibanks=40microsoft.com@dmarc.ietf.org, QUIC WG Content-Type: multipart/alternative; boundary="0000000000005a0f81056f8f9fcb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:25:31 -0000 --0000000000005a0f81056f8f9fcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A higher order thought. Crypto and PNE cost CPU. The only interesting question is if the relative cost of PNE is "too high" for deployment in particular use cases. The relative cost of crypto and PNE will change as the workload changes, as the average connection throughput changes, as the application protocol changes, as the underlying platform changes, and as the cost of the rest of the send path changes. We do not have enough deployment experience to determine that the cost of PNE is going to be too high for the HTTP use case. And until we have deployment experience, contextualizing these raw numbers will be difficult and will provide limited insight. For non-HTTP and DC-like use cases, it is perfectly reasonable to roll a local version to learn more about the dominant costs in those environments. I would caution against diving too deep into arguments about cost without actual deployment experience, especially for DC-like workloads. I'm keen to see how these numbers move as the implementation matures and how it changes in test/real deployments serving HTTP workloads. On Mon, Jun 25, 2018 at 10:53 AM Rui Paulo wrote: > On Jun 22, 2018, at 17:01, Kazuho Oku wrote: > > > > This is because IIUC PNE is a marginal additional use of the AES-NI > engine, which have been mostly idle. The overhead of crypto is small (i.e= . > 15%) that we will rarely see contention on the engine. While one > hyperthread does AES, the other hyperthread will run at full speed doing > other operations. > > > > Also considering the fact that the number of CPU cycles spent per QUIC > packet does not change a lot with PNE, I would not be surprised to see *n= o* > decrease of throughput when PNE is used on a HyperThreading architecture. > In such case, what we will only observe is the raise of the utilization > ratio of the AES-NI engine. > > I don=E2=80=99t disagree but this is a very brand/model specific claim an= d we > can=E2=80=99t assume the cost of PNE will be reasonable everywhere. > > =E2=80=94 > Rui Paulo > > > > --0000000000005a0f81056f8f9fcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A higher order thought.

Cryp= to and PNE cost CPU. The only interesting question is if the relative cost = of PNE is "too high" for deployment in particular use cases.
= =C2=A0
The relative cost of crypto and PNE will change as the wor= kload changes, as the average connection throughput changes, as the applica= tion protocol changes, as the underlying platform changes, and as the cost = of the rest of the send path changes.=C2=A0We do not have enough deployment= experience to determine that the cost of PNE is going to be too high for t= he HTTP use case.=C2=A0And until we have deployment experience, contextualizing these raw= numbers will be difficult and will provide limited insight.

For non-HTTP and DC-like use cases, it is perfectly reasonable to ro= ll a local version to learn more about the dominant costs in those environm= ents. I would caution against diving too deep into arguments about cost wit= hout actual deployment experience, especially for DC-like workloads.

I'm keen to see how these numbers move as the im= plementation matures and how it changes in test/real deployments serving HT= TP workloads.



On Mon, Jun 25, 2018 at 10:53 AM Rui Paulo <= rpaulo@apple.com> wrote:
On Jun 22, 2018, at 17:01, Kazuho Oku <= kazuhooku@gmail.co= m> wrote:
>
> This is because IIUC PNE is a marginal additional use of the AES-NI en= gine, which have been mostly idle. The overhead of crypto is small (i.e. 15= %) that we will rarely see contention on the engine. While one hyperthread = does AES, the other hyperthread will run at full speed doing other operatio= ns.
>
> Also considering the fact that the number of CPU cycles spent per QUIC= packet does not change a lot with PNE, I would not be surprised to see *no= * decrease of throughput when PNE is used on a HyperThreading architecture.= In such case, what we will only observe is the raise of the utilization ra= tio of the AES-NI engine.

I don=E2=80=99t disagree but this is a very brand/model specific claim and = we can=E2=80=99t assume the cost of PNE will be reasonable everywhere.

=E2=80=94
Rui Paulo



--0000000000005a0f81056f8f9fcb-- From nobody Wed Jun 27 01:35:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00312872C for ; Wed, 27 Jun 2018 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 s1RKcXC1e294 for ; Wed, 27 Jun 2018 01:35:04 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551171277D2 for ; Wed, 27 Jun 2018 01:35:04 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 69-v6so4469151wmf.3 for ; Wed, 27 Jun 2018 01:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XgRxAvZpPysLOYMN9QOg+BqH2tHIsTQIHfjjVVwnnaI=; b=HXjo45Vg/M7Z4YaeKy5lobY+trrfG4wggwJ47ZqgKEJcudEcjqr9rR6JMkztC20fiK u4j+n68VxoFqH+HHwggNhPZHAD8rxGogwBh1oE655azbkhKBhzE9yj8gqpQ2I6CiscIF S5XpSzWPRLxUvuCaO7UHOGEdD5RK72TKDjepoNQVOtk8ijK0D0JCN1GR1cgqqz9VctTp 9KtR1KrfPnaRG/dHXcRtzjx0Iai+4/uYyDdnQETUyyk9EUtK80t1xKVO5x0K8YFR24zc lt14OPE/rjUbTDno9subF8ODd7xTkI5nFhHHVwwd9kL6GiNvMcsNb+3GB0XE39sdvngi W0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=XgRxAvZpPysLOYMN9QOg+BqH2tHIsTQIHfjjVVwnnaI=; b=J93ASzSLM4Sf67fOAviN5RwuRdj+dRGkqCwjIn0/UnH7NGlprprUH4aXvCMrcJY/0b 9s+aTExPVoN5siwrX2Fj9onWg5XRKE+VmUuz9QhbzA83AdAzSknvi4mWUPBau6Uo8PFM gjv/N0eF4xrJiKZnET0vC8+6Jwl+V8FBnA7eTk6dnaP07hiasLRT9L09Gm5eIoJCbxGO WadGNFhsFB19XT5VnOW9tz754bIaBg/7DFJb0o2Tr4Dj/YS0oEAVxcNNQlyVawdbLufZ hdTuuxUQrbXq9ukBdBplb3k8sbTrbJZ5KndFWExdLgRJN88r4qq0O6N1qmqv9KXzx2OD MHig== X-Gm-Message-State: APt69E0VwZ5cVlKBv59ArkEml1WETOEvWI1UFL+s6HDeCOUazfKjkoK2 O5DHrV7fE6zqlCnzRycoGg3U/w== X-Google-Smtp-Source: AAOMgpe/ima42GAc31K2nWLOVP+mx6aKLzu0qVCii8FwLfkDNi2waiBzRSNJ4tiDkEUM38yT/UywOw== X-Received: by 2002:a1c:dcd:: with SMTP id 196-v6mr4192546wmn.131.1530088502860; Wed, 27 Jun 2018 01:35:02 -0700 (PDT) Received: from ubuntu-dmitri ([62.214.4.67]) by smtp.gmail.com with ESMTPSA id b16-v6sm4429522wrm.15.2018.06.27.01.35.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 01:35:02 -0700 (PDT) Date: Wed, 27 Jun 2018 04:34:51 -0400 From: Dmitri Tikhonov To: Martin Duke Cc: Mike Bishop , IETF QUIC WG Subject: Re: What was the QUIC Load Balancers resolution? Message-ID: <20180627083450.GA15604@ubuntu-dmitri> Mail-Followup-To: Martin Duke , Mike Bishop , IETF QUIC WG References: <20180608153916.GC13418@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:35:06 -0000 On Mon, Jun 25, 2018 at 08:01:54PM -0700, Martin Duke wrote: > Yes, there was no firm conclusion. There were some recommendations on what > the side channel should be, general agreement that this was a good thing to > be working on, and general reluctance for the QUIC WG to do much work here. > > That said, there are some email discussions going on and we're going to > continue work on the draft Dmitri, would you like to be a part of this? Yes, I would -- please count me in. - Dmitri. From nobody Wed Jun 27 13:36:39 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E298130E35 for ; Wed, 27 Jun 2018 13:36:37 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 CIzgWh6WhhAK for ; Wed, 27 Jun 2018 13:36:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C5887130E29 for ; Wed, 27 Jun 2018 13:36:34 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5RKVd2h026546; Wed, 27 Jun 2018 21:36:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=GWqtqp5AmCKxgxIGKIz5+Uer22UiL/HCb6IrY4ZdmMI=; b=WKeP/1EUJfgIC5P0WRSnuZWQ91Fw11KsmKmXCZZwTo0zhd6x9vHBQb7mZHMoGKWSzYj1 7aqu5N9cKvMGt4isIY/3XcY5m4E3a9a9oytPWFFlCOqfdbdSacO8uracE+LOKNC1+MPt JicpFYgCF086aeegnyhJH/eyklMRIMhK9oTk5DBs6RTCLGI6sE9+jrZaqISgxSZBDdM5 zgiX7MboPSfP9Z6AnPthnTBBgoOt5+017RZ5hKVl4N5J72fmPJOB3G7Ku2tktsxlY8Ar FuyoxEP1kOpAcs6vyNP+WLN6ZBg4gbRMVJQ8FlPtxwUwuEJthZ3xCshxy2fV9PY4bfVK ZQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2jvc8m8vut-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 21:36:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5RKZrQ3027986; Wed, 27 Jun 2018 16:36:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ju9caavyy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 16:36:30 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 27 Jun 2018 15:36:29 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Wed, 27 Jun 2018 15:36:29 -0500 From: "Lubashev, Igor" To: Martin Duke , IETF QUIC WG Subject: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5w== Date: Wed, 27 Jun 2018 20:36:29 +0000 Message-ID: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.89] Content-Type: multipart/alternative; boundary="_000_924fbd75dbcf4d62a9062570b0d2ba5austx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=902 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270217 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=823 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270217 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 20:36:37 -0000 --_000_924fbd75dbcf4d62a9062570b0d2ba5austx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-= drafts/pull/1412). Many thanks to those who gave me ample feedback (both substantive and edito= rial). I've tried to incorporate it all. There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big sign= al) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC482= 1) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD proce= ss. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself i= s a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the = ICMP part, and this is ok albeit unfortunate; and this also points to SHOUL= D (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU redu= ction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not = reduce but send PLPMTUD probes. Since this is very likely a valid signal, = I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M= , where 1280 =98 M =98 1500. Once the reduction takes place, the endpoint = can use PLPMTUD recommendations to see if it can probe a larger PMTU. If t= his sounds reasonable, then the question is picking M. I picked 1392 rathe= r arbitrarily (GRE over IPsec + a few MPLS labels). If the requested reduc= tion is 1280 =98 X < M, then the recommendation is not to reduce but send P= LPMTUD probes. Does this make sense, or should we have M=3D1280 and simpli= fy things? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reductio= n in PMTU up to 1280. It is hard to forge these, and the benefit of the ef= fort for the attacker is minimal (slightly lower efficiency of the transpor= t). So it is less likely that we'll see forged ICMP w/ on-path proof. Any feedback is very welcome. * Igor --_000_924fbd75dbcf4d62a9062570b0d2ba5austx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

I have a PR for treatment of ICMP for PMTU (https://github.com/qui= cwg/base-drafts/pull/1412).

Many thanks to those who gave me ample feedback (bot= h substantive and editorial).  I’ve tried to incorporate it all.=

 

There are two technical issues that @Martin Duke and I believe deserve a broader discussion wit= h the group.

 

  1. Is processing ICM= P signals (and, especially, ICMP Packet Too Big signal) a MAY or a SHOULD?<= o:p>

 

In the WG draft, processing ICMP is a MAY, but imple= menting PLPMTUD (RFC4821) is a SHOULD.

However, PLPMTUD claims itself to be an extension of= ICMP-based PMTUD process. So it makes sense to me that if PLPMTUD is a SHO= ULD, then ICMP itself is a SHOULD.

QUIC implementations w/o access to ICMP would not be= able to implement the ICMP part, and this is ok albeit unfortunate; and th= is also points to SHOULD (skipping on MAY is not "unfortunate").<= o:p>

 

 

  1. What to do, when = an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)= ?

 

There are three main options: ignore it, reduce your= PMTU estimate, do not reduce but send PLPMTUD probes.  Since this is = very likely a valid signal, I do not like to ignore in the common case.

 

Hence, the proposal is to allow an immediate PMTU re= duction to up to some M, where 1280 =98 M =98 1500.  Once the reductio= n takes place, the endpoint can use PLPMTUD recommendations to see if it ca= n probe a larger PMTU.  If this sounds reasonable, then the question is picking M.  I picked 1392 rather arbitrarily (GR= E over IPsec + a few MPLS labels).  If the requested reduction is = 1280 =98 X < M, then the recommendation is not to reduce but send PLPMTU= D probes.  Does this make sense, or should we have M=3D1280 and simplify things?

 

Note: for ICMP w/ on-path proof, I think it makes se= nse to allow a reduction in PMTU up to 1280.  It is hard to forge thes= e, and the benefit of the effort for the attacker is minimal (slightly lowe= r efficiency of the transport).  So it is less likely that we’ll see forged ICMP w/ on-path proof.

 

 

Any feedback is very welcome.

 

  • Igor

 

--_000_924fbd75dbcf4d62a9062570b0d2ba5austx2exdag1mb5msgcorpak_-- From nobody Wed Jun 27 14:26:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D320130E33 for ; Wed, 27 Jun 2018 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 IoVSL-4zQJYq for ; Wed, 27 Jun 2018 14:26:40 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02815130E2A for ; Wed, 27 Jun 2018 14:26:39 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5RLQZDP015496; Wed, 27 Jun 2018 22:26:35 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0389.001; Wed, 27 Jun 2018 22:26:35 +0100 From: Lucas Pardue To: "Lubashev, Igor" , Martin Duke , IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5 Date: Wed, 27 Jun 2018 21:26:34 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DCbgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:26:42 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DCbgb01xud1012_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgSWdvciwNCg0KSWYgd2UgY29uc2lkZXIgdHVubmVsbGluZyBvZiBRVUlDIHdpdGhpbiBRVUlD IGJ5IG1lYW5zIG9mIGEgcHJveHkgKG5vdCBjdXJyZW50bHkgc3BlY2NlZCBhbnl3aGVyZSBidXQg ZmVhc2libGUpLCB0aGUgdHVubmVsbGVkIChlbmQtdG8tZW5kKSBwYXRoIE1UVSBpcyBsaWtlbHkg dG8gYmUgc21hbGxlciB0aGFuIHRoZSBob3AtYnktaG9wIHBhdGggTVRVcy4gSXQgbWF5IG5vdCBi ZSBwb3NzaWJsZSBmb3IgdGhlIHByb3hpZXMgdG8gcGFzcyBvbiBJQ01QIGluIGEgd2F5IHRoYXQg dGhlIHRoZSB0dW5uZWxsZWQgUVVJQyBpbXBsZW1lbnRhdGlvbiBjYW4gYWNjZXNzIGl0LiAoRClQ TFBNVFVEIHNlZW1zIHRvIGZpdCB0aGlzIGNhc2UgbmljZWx5IGFzIHRoZXJlIGNhbiBiZSB0d28g b3IgbW9yZSBQTFBNVFVEIGNvbnRleHRzL3ZhbHVlcyAob25lIGZvciB0aGUgY29ubmVjdGlvbiB0 byB0aGUgcHJveHksIG9uZSBmb3IgZWFjaCB0dW5uZWwgd2l0aGluIHRoaXMgY29ubmVjdGlvbiku DQoNCkx1Y2FzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUVVJQyBb cXVpYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgTHViYXNoZXYsIElnb3IgW2lsdWJh c2hlPTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZ10NClNlbnQ6IDI3IEp1bmUgMjAxOCAyMToz Ng0KVG86IE1hcnRpbiBEdWtlOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFRyZWF0bWVudCBvZiBJ Q01QIGZvciBQTVRVDQoNCkkgaGF2ZSBhIFBSIGZvciB0cmVhdG1lbnQgb2YgSUNNUCBmb3IgUE1U VSAoaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzE0MTIpLg0KTWFu eSB0aGFua3MgdG8gdGhvc2Ugd2hvIGdhdmUgbWUgYW1wbGUgZmVlZGJhY2sgKGJvdGggc3Vic3Rh bnRpdmUgYW5kIGVkaXRvcmlhbCkuICBJoa92ZSB0cmllZCB0byBpbmNvcnBvcmF0ZSBpdCBhbGwu DQoNClRoZXJlIGFyZSB0d28gdGVjaG5pY2FsIGlzc3VlcyB0aGF0IEBNYXJ0aW4gRHVrZTxtYWls dG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+IGFuZCBJIGJlbGlldmUgZGVzZXJ2ZSBhIGJyb2Fk ZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSBncm91cC4NCg0KDQogIDEuICBJcyBwcm9jZXNzaW5nIElD TVAgc2lnbmFscyAoYW5kLCBlc3BlY2lhbGx5LCBJQ01QIFBhY2tldCBUb28gQmlnIHNpZ25hbCkg YSBNQVkgb3IgYSBTSE9VTEQ/DQoNCkluIHRoZSBXRyBkcmFmdCwgcHJvY2Vzc2luZyBJQ01QIGlz IGEgTUFZLCBidXQgaW1wbGVtZW50aW5nIFBMUE1UVUQgKFJGQzQ4MjEpIGlzIGEgU0hPVUxELg0K SG93ZXZlciwgUExQTVRVRCBjbGFpbXMgaXRzZWxmIHRvIGJlIGFuIGV4dGVuc2lvbiBvZiBJQ01Q LWJhc2VkIFBNVFVEIHByb2Nlc3MuIFNvIGl0IG1ha2VzIHNlbnNlIHRvIG1lIHRoYXQgaWYgUExQ TVRVRCBpcyBhIFNIT1VMRCwgdGhlbiBJQ01QIGl0c2VsZiBpcyBhIFNIT1VMRC4NClFVSUMgaW1w bGVtZW50YXRpb25zIHcvbyBhY2Nlc3MgdG8gSUNNUCB3b3VsZCBub3QgYmUgYWJsZSB0byBpbXBs ZW1lbnQgdGhlIElDTVAgcGFydCwgYW5kIHRoaXMgaXMgb2sgYWxiZWl0IHVuZm9ydHVuYXRlOyBh bmQgdGhpcyBhbHNvIHBvaW50cyB0byBTSE9VTEQgKHNraXBwaW5nIG9uIE1BWSBpcyBub3QgInVu Zm9ydHVuYXRlIikuDQoNCg0KDQogIDEuICBXaGF0IHRvIGRvLCB3aGVuIGFuIElQdjQgSUNNUCAo dy9vIG9uLXBhdGggcHJvb2YpIHJlcXVlc3QgYSBQTVRVIHJlZHVjdGlvbiAoYWZ0ZXIgaGFuZHNo YWtlKT8NCg0KVGhlcmUgYXJlIHRocmVlIG1haW4gb3B0aW9uczogaWdub3JlIGl0LCByZWR1Y2Ug eW91ciBQTVRVIGVzdGltYXRlLCBkbyBub3QgcmVkdWNlIGJ1dCBzZW5kIFBMUE1UVUQgcHJvYmVz LiAgU2luY2UgdGhpcyBpcyB2ZXJ5IGxpa2VseSBhIHZhbGlkIHNpZ25hbCwgSSBkbyBub3QgbGlr ZSB0byBpZ25vcmUgaW4gdGhlIGNvbW1vbiBjYXNlLg0KDQpIZW5jZSwgdGhlIHByb3Bvc2FsIGlz IHRvIGFsbG93IGFuIGltbWVkaWF0ZSBQTVRVIHJlZHVjdGlvbiB0byB1cCB0byBzb21lIE0sIHdo ZXJlIDEyODAgocIgTSChwiAxNTAwLiAgT25jZSB0aGUgcmVkdWN0aW9uIHRha2VzIHBsYWNlLCB0 aGUgZW5kcG9pbnQgY2FuIHVzZSBQTFBNVFVEIHJlY29tbWVuZGF0aW9ucyB0byBzZWUgaWYgaXQg Y2FuIHByb2JlIGEgbGFyZ2VyIFBNVFUuICBJZiB0aGlzIHNvdW5kcyByZWFzb25hYmxlLCB0aGVu IHRoZSBxdWVzdGlvbiBpcyBwaWNraW5nIE0uICBJIHBpY2tlZCAxMzkyIHJhdGhlciBhcmJpdHJh cmlseSAoR1JFIG92ZXIgSVBzZWMgKyBhIGZldyBNUExTIGxhYmVscykuICBJZiB0aGUgcmVxdWVz dGVkIHJlZHVjdGlvbiBpcyAxMjgwIKHCIFggPCBNLCB0aGVuIHRoZSByZWNvbW1lbmRhdGlvbiBp cyBub3QgdG8gcmVkdWNlIGJ1dCBzZW5kIFBMUE1UVUQgcHJvYmVzLiAgRG9lcyB0aGlzIG1ha2Ug c2Vuc2UsIG9yIHNob3VsZCB3ZSBoYXZlIE09MTI4MCBhbmQgc2ltcGxpZnkgdGhpbmdzPw0KDQpO b3RlOiBmb3IgSUNNUCB3LyBvbi1wYXRoIHByb29mLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRv IGFsbG93IGEgcmVkdWN0aW9uIGluIFBNVFUgdXAgdG8gMTI4MC4gIEl0IGlzIGhhcmQgdG8gZm9y Z2UgdGhlc2UsIGFuZCB0aGUgYmVuZWZpdCBvZiB0aGUgZWZmb3J0IGZvciB0aGUgYXR0YWNrZXIg aXMgbWluaW1hbCAoc2xpZ2h0bHkgbG93ZXIgZWZmaWNpZW5jeSBvZiB0aGUgdHJhbnNwb3J0KS4g IFNvIGl0IGlzIGxlc3MgbGlrZWx5IHRoYXQgd2Whr2xsIHNlZSBmb3JnZWQgSUNNUCB3LyBvbi1w YXRoIHByb29mLg0KDQoNCkFueSBmZWVkYmFjayBpcyB2ZXJ5IHdlbGNvbWUuDQoNCg0KICAqICAg SWdvcg0KDQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DCbgb01xud1012_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi Igor,

If we consider tunnelling of QUIC within QUIC by means of a proxy (not= currently specced anywhere but feasible), the tunnelled (end-to-end) path = MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be po= ssible for the proxies to pass on ICMP in a way that the the tunnelled QUIC implementation can access it. (D= )PLPMTUD seems to fit this case nicely as there can be two or more PLPMTUD = contexts/values (one for the connection to the proxy, one for each tunnel w= ithin this connection).

Lucas
From: QUIC [quic-bounces@ietf.org] on beh= alf of Lubashev, Igor [ilubashe=3D40akamai.com@dmarc.ietf.org]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU

I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-drafts/pull/1412).

Many thanks to those who gave me ample feedback (bot= h substantive and editorial).  I=A1=AFve tried to incorporate it all.<= /p>

 

There are two technical issues that @Martin Duke and I believe deserve a broader discussion wi= th the group.

 

  1. Is processing ICMP signals (and, especia= lly, ICMP Packet Too Big signal) a MAY or a SHOULD?

 

In the WG draft, processing ICMP is a MAY, but imple= menting PLPMTUD (RFC4821) is a SHOULD.

However, PLPMTUD claims itself to be an extension of= ICMP-based PMTUD process. So it makes sense to me that if PLPMTUD is a SHO= ULD, then ICMP itself is a SHOULD.

QUIC implementations w/o access to ICMP would not be= able to implement the ICMP part, and this is ok albeit unfortunate; and th= is also points to SHOULD (skipping on MAY is not "unfortunate").<= /p>

 

 

  1. What to do, when an IPv4 ICMP (w/o on-pa= th proof) request a PMTU reduction (after handshake)?

 

There are three main options: ignore it, reduce your= PMTU estimate, do not reduce but send PLPMTUD probes.  Since this is = very likely a valid signal, I do not like to ignore in the common case.

 

Hence, the proposal is to allow an immediate PMTU re= duction to up to some M, where 1280 =A1=C2 M =A1=C2 1500.  Once the re= duction takes place, the endpoint can use PLPMTUD recommendations to see if= it can probe a larger PMTU.  If this sounds reasonable, then the question is picking M.  I picked 1392 rather arbitrarily (GR= E over IPsec + a few MPLS labels).  If the requested reduction is = 1280 =A1=C2 X < M, then the recommendation is not to reduce but send PLP= MTUD probes.  Does this make sense, or should we have M=3D1280 and simplify things?

 

Note: for ICMP w/ on-path proof, I think it makes se= nse to allow a reduction in PMTU up to 1280.  It is hard to forge thes= e, and the benefit of the effort for the attacker is minimal (slightly lowe= r efficiency of the transport).  So it is less likely that we=A1=AFll see forged ICMP w/ on-path proof.

 

 

Any feedback is very welcome.

 

  • Igor

 

--_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DCbgb01xud1012_-- From nobody Wed Jun 27 16:10:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4131130E3C for ; Wed, 27 Jun 2018 16:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bPIMoYtnxBmN for ; Wed, 27 Jun 2018 16:10:07 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F27FF130E3B for ; Wed, 27 Jun 2018 16:10:06 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5RN6b9w018429; Thu, 28 Jun 2018 00:10:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=A9XPR09ZkqFTIyhKi3N5+y+0FOltyXwV40bHmLhPvnQ=; b=iKc6pJhJ6hOpukDPlA9mFpOCF7iCMEUGte1GeDJuzutj88WfHuTItv6OObdQL0uTZqCa vSjBYEXSZx7GivWCMYbSydUjh1MNQ+RS2YtADSA+8KZaDrClRQ+YgW7CQuI+lIBkHQiF MZ8WR42scON9T7+OZeuG0cqeUTdyk91kccExbsOfGMXMPm7RpNzkTz+DkjCGZtSKjvpq GoniK+kfXRLmJk0j75dqUKnA103QVTQRlmjy7Yk0TRrjt9pqewKKaiXwthNFbzcha7Hp +CjgFqQn+RLwyA/kgqky0D5Ktb3YtZYvjsYYVxOuhqiYO+tkap4i4FG+vXYESq9F/VAI HA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2jvk1hr4dc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 00:10:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5RN6SWf030872; Wed, 27 Jun 2018 19:10:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bvqrvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 19:10:00 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 27 Jun 2018 18:09:59 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Wed, 27 Jun 2018 18:10:00 -0500 From: "Lubashev, Igor" To: Lucas Pardue , Martin Duke , IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0A= Date: Wed, 27 Jun 2018 23:09:59 +0000 Message-ID: <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.89] Content-Type: multipart/alternative; boundary="_000_2f0e251a9b274272968a8b3053d3a3a5ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=905 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270243 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=826 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270243 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:10:10 -0000 --_000_2f0e251a9b274272968a8b3053d3a3a5ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi Lucas, How is this different from PMTUD in IP-in-IP case? The endpoint computes a= nd caches PMTU per endpoint. PMTU for connections to proxy is kept separat= ely from PMTUs for connections to endpoints that go via the proxy. The proxy itself can learn PMTU between itself and the endpoints, subtract = the overhead, and send ICMP to the sender of the proxied QUIC flow. I see the common case of QUIC implementation not being able to make use of = ICMP is when QUIC is implemented in userspace on a platform that does not e= xpose ICMP to the application. QUIC's desire to receive ICMP will likely c= ause vendors of such platforms to add the missing functionality. * Igor From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] Sent: Wednesday, June 27, 2018 5:27 PM To: Lubashev, Igor ; Martin Duke ; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Igor, If we consider tunnelling of QUIC within QUIC by means of a proxy (not curr= ently specced anywhere but feasible), the tunnelled (end-to-end) path MTU i= s likely to be smaller than the hop-by-hop path MTUs. It may not be possibl= e for the proxies to pass on ICMP in a way that the the tunnelled QUIC impl= ementation can access it. (D)PLPMTUD seems to fit this case nicely as there= can be two or more PLPMTUD contexts/values (one for the connection to the = proxy, one for each tunnel within this connection). Lucas ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=3D= 40akamai.com@dmarc.ietf.org] Sent: 27 June 2018 21:36 To: Martin Duke; IETF QUIC WG Subject: Treatment of ICMP for PMTU I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-= drafts/pull/1412). Many thanks to those who gave me ample feedback (both substantive and edito= rial). I've tried to incorporate it all. There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big sign= al) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC482= 1) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD proce= ss. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself i= s a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the = ICMP part, and this is ok albeit unfortunate; and this also points to SHOUL= D (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU redu= ction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not = reduce but send PLPMTUD probes. Since this is very likely a valid signal, = I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M= , where 1280 =98 M =98 1500. Once the reduction takes place, the endpoint = can use PLPMTUD recommendations to see if it can probe a larger PMTU. If t= his sounds reasonable, then the question is picking M. I picked 1392 rathe= r arbitrarily (GRE over IPsec + a few MPLS labels). If the requested reduc= tion is 1280 =98 X < M, then the recommendation is not to reduce but send P= LPMTUD probes. Does this make sense, or should we have M=3D1280 and simpli= fy things? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reductio= n in PMTU up to 1280. It is hard to forge these, and the benefit of the ef= fort for the attacker is minimal (slightly lower efficiency of the transpor= t). So it is less likely that we'll see forged ICMP w/ on-path proof. Any feedback is very welcome. * Igor --_000_2f0e251a9b274272968a8b3053d3a3a5ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hi Lucas,<= /o:p>

&nbs= p;

How is th= is different from PMTUD in IP-in-IP case?  The endpoint computes and c= aches PMTU per endpoint.  PMTU for connections to proxy is kept separa= tely from PMTUs for connections to endpoints that go via the proxy.

&nbs= p;

The proxy= itself can learn PMTU between itself and the endpoints, subtract the overh= ead, and send ICMP to the sender of the proxied QUIC flow.

&nbs= p;

I see the= common case of QUIC implementation not being able to make use of ICMP is w= hen QUIC is implemented in userspace on a platform that does not expose ICM= P to the application.  QUIC’s desire to receive ICMP will likely cause vendors of such platforms to add the mis= sing functionality.

&nbs= p;

  • Igor

&nbs= p;

&nbs= p;

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.c= o.uk]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Martin Duke <mart= in.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

 

Hi Igor,

 

If we consider tunnelling of QUIC within= QUIC by means of a proxy (not currently specced anywhere but feasible), th= e tunnelled (end-to-end) path MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be possible for the p= roxies to pass on ICMP in a way that the the tunnelled QUIC implementation = can access it. (D)PLPMTUD seems to fit this case nicely as there can be two= or more PLPMTUD contexts/values (one for the connection to the proxy, one for each tunnel within this conn= ection).

 

Lucas

From:<= /span> QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=3D40akamai.com@dmarc.ietf.org]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU

I have a PR for treatmen= t of ICMP for PMTU (https://github.= com/quicwg/base-drafts/pull/1412).

Many thanks to those who= gave me ample feedback (both substantive and editorial).  I’ve = tried to incorporate it all.

 =

There are two technical = issues that @Martin Duke and I believe deserve a broader discussion wit= h the group.

 =

  1. Is pr= ocessing ICMP signals (and, especially, ICMP Packet Too Big signal) a MAY o= r a SHOULD?

 =

In the WG draft, process= ing ICMP is a MAY, but implementing PLPMTUD (RFC4821) is a SHOULD.

However, PLPMTUD claims = itself to be an extension of ICMP-based PMTUD process. So it makes sense to= me that if PLPMTUD is a SHOULD, then ICMP itself is a SHOULD.

QUIC implementations w/o= access to ICMP would not be able to implement the ICMP part, and this is o= k albeit unfortunate; and this also points to SHOULD (skipping on MAY is no= t "unfortunate").

 =

 =

  1. What = to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (afte= r handshake)?

 =

There are three main opt= ions: ignore it, reduce your PMTU estimate, do not reduce but send PLPMTUD = probes.  Since this is very likely a valid signal, I do not like to ig= nore in the common case.

 =

Hence, the proposal is t= o allow an immediate PMTU reduction to up to some M, where 1280 =98 M =98 1= 500.  Once the reduction takes place, the endpoint can use PLPMTUD rec= ommendations to see if it can probe a larger PMTU.  If this sounds reasonable, then the question is picking M.&nbs= p; I picked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels= ).  If the requested reduction is 1280 =98 X < M, then the recommen= dation is not to reduce but send PLPMTUD probes.  Does this make sense, or should we have M=3D1280 and simplify things?

 =

Note: for ICMP w/ on-pat= h proof, I think it makes sense to allow a reduction in PMTU up to 1280.&nb= sp; It is hard to forge these, and the benefit of the effort for the attack= er is minimal (slightly lower efficiency of the transport).  So it is less likely that we’ll see forged = ICMP w/ on-path proof.

 =

 =

Any feedback is very wel= come.

 =

  • Igor<= o:p>

 =

--_000_2f0e251a9b274272968a8b3053d3a3a5ustx2exdag1mb5msgcorpak_-- From nobody Wed Jun 27 17:40:41 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3381E130E5F; Wed, 27 Jun 2018 17:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153014643315.15418.6844056795185627046@ietfa.amsl.com> Date: Wed, 27 Jun 2018 17:40:33 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 00:40:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-13.txt Pages : 29 Date : 2018-06-27 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-tls [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-13 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-13 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 Wed Jun 27 17:43:53 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF36130E53; Wed, 27 Jun 2018 17:43:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153014662573.15452.16688433002546953076@ietfa.amsl.com> Date: Wed, 27 Jun 2018 17:43:45 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 00:43:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-13.txt Pages : 120 Date : 2018-06-27 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-13 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-13 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 Wed Jun 27 17:47:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3B130E57 for ; Wed, 27 Jun 2018 17:47:56 -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 twsDiv8uHjgW for ; Wed, 27 Jun 2018 17:47:55 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA420130E53 for ; Wed, 27 Jun 2018 17:47:54 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id r16-v6so3085951oie.3 for ; Wed, 27 Jun 2018 17:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6WohepU/5H7Lpm8v5TXbXOxYB+Cj5OA5Z0yQPD+Feho=; b=UaiXomWDovZKsuv0dO8qqkm3+gILu9blDNhUbPIhYfndbfLClPdjhgF5cMRF5LYpAD T4gRxVCxbJS1kDExDNVLjk9h09hIqqFQRJuMP0egb5RJbKZyl0a+fCj8q5MjX+wnnbLA asYITHT+wGDXb1tcxOjZ3fBXKRmUvUNld/8ZCmK4ZZwRP7G943tWpPTTq7kuzbGE0KzR lTtIcUBZViaJhpVe3PkK0+soawZ8bIUkrXZvnTxB63QZxoUToWm47LmFkrVuGyQjcfs2 nLGo5F7l8U0oDS+ZM4w+CLpZ9EY1UAWEVh6+v5+lSjJWCOq3swto/zUbQykF+5C7Kgyx XJxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6WohepU/5H7Lpm8v5TXbXOxYB+Cj5OA5Z0yQPD+Feho=; b=aDnp31hcSyx9X9dTxPjWpKyvJMXQpn+1lLh2B5DB13ySiY0q81wJkp1K0dDSB6jsef TbZ0QfAuzkcLKV/Ef7u99gHvfPdfzDqZwH5vMfC+PqMOJ9QWS+ftFkVWsQyfLiX7m1dw v7sF5hSTEUrkkohr6AjQVniU7NMsdVRzCc1hZxHZ85GQ/s9T4jvTy+8QKxj0LUj3vntc Y91c2Yki/3qgBiaYvGXTfDG+KtgwDiG9C70chxmkhsFPc/1+rC2T3FSXnW/+w8Jw7AG3 xgXWntbwIHTsBVbZzJs4jxI7R/7KBEcsvfbGpUhM2B5EQ5h7OtkvnivqJb1ntdjNI+jU i+fA== X-Gm-Message-State: APt69E2q8/+ZtSMy4V4jPZ+LqXD6R0iObyNINkw0/rrpzK93oniMCUhL s5iRcNdKaQIl4OySUK2cqh4n28F5TlpaHjalFIK4QQ== X-Google-Smtp-Source: AAOMgpc0HYcLVUbDk697gQDx4PtP3GYNJ+A565jhOMQ2AjhvnWJJzkMDX+zFhQsL8OC4x2h4JtlVrMYO87cmkzV51Xc= X-Received: by 2002:aca:745:: with SMTP id 66-v6mr4310300oih.295.1530146874020; Wed, 27 Jun 2018 17:47:54 -0700 (PDT) MIME-Version: 1.0 References: <153014662573.15452.16688433002546953076@ietfa.amsl.com> In-Reply-To: <153014662573.15452.16688433002546953076@ietfa.amsl.com> From: Martin Thomson Date: Thu, 28 Jun 2018 10:47:45 +1000 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-transport-13.txt To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 00:47:57 -0000 Lucky draft 13 is here. It's a big one, thanks mainly to the efforts of the stream 0 folks. It includes a bunch of the things we agreed at the interim in Kista as well. The change logs should be accurate. Expect the rest of the drafts to trickle in as the other editors approve them. On Thu, Jun 28, 2018 at 10:44 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the QUIC WG of the IETF. > > Title : QUIC: A UDP-Based Multiplexed and Secure Transport > Authors : Jana Iyengar > Martin Thomson > Filename : draft-ietf-quic-transport-13.txt > Pages : 120 > Date : 2018-06-27 > > Abstract: > This document defines the core of the QUIC transport protocol. This > document describes connection establishment, packet format, > multiplexing and reliability. Accompanying documents describe the > cryptographic handshake and loss detection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-transport-13 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-13 > > > 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 Wed Jun 27 18:09:56 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97274130E6D; Wed, 27 Jun 2018 18:09:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153014819454.15370.17991878357748119918@ietfa.amsl.com> Date: Wed, 27 Jun 2018 18:09:54 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:09:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-13.txt Pages : 33 Date : 2018-06-27 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-13 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-13 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 Wed Jun 27 18:22:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9E130EC1 for ; Wed, 27 Jun 2018 18:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajDdDcX1a03R for ; Wed, 27 Jun 2018 18:22:38 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3477130EB9 for ; Wed, 27 Jun 2018 18:22:37 -0700 (PDT) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5S1MWxX015638; Thu, 28 Jun 2018 02:22:32 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.03.0389.001; Thu, 28 Jun 2018 02:22:32 +0100 From: Lucas Pardue To: "Lubashev, Igor" , Martin Duke , IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsg== Date: Thu, 28 Jun 2018 01:22:32 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012>, <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23934.003 x-tm-as-result: No-20.879000-8.000000-10 x-tmase-matchedrid: /77LoUQXvQ+7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p19WQH9y/pSXfWn L2FmW8ATdQqTbpe1xWF8ITOczeFr11EwRhIfWnCeqJst3mlmdq4UkWvaqUqLH6xp9wUsWVTUoud 5cX9BENOgkWbzM/ib1a8gi8Y9jxVVseEPHIpTNp6vThHXboayJxmyTBaqiJvcbcPp/oilsshzgv QLMIFUtcSC6D6Lu66p0BXik57JdeRgKrQzWYxW23tItsHAduPxonoEax/KaSxcKZwALwMGsxk7F ptWm8VXZgeF+dVIoFyIASjTsUolM9h8848Kmd8C6rBZUF8y6+j4qCLIu0mtIAX6AL3anSeXDrwv r/xfmnlyC511Aa/rrke+fpoWHnEIBtmNRQ2CPJLtP6Pv+A+w80uPZoKNA6vuauHKE5Laxl8+Hcg NxnR6oUkVdovDQz9o5SgyFhNJWrKj6Cc82+ys1sDORqgKKiYqLi2dwKiMR9zI9EDAP/dptouyXZ 8/ROb4xKEVSa834HUWhWW6/pSK7KRxb5HXXW4zUSn3o+eoUmxUiWnfOQltVXhzjDugGMVdSsaAZ zuu+FF9dCA2RYLmL5sH5r9LRSzottMzDo2HdqnC+o4YGuB7e+HQ21j8RtplkR+/pTNS9t07ORyV GjG4B0qPc09xLrm/ZNu93+0rP2AfE8yM4pjsD2CU2Hzp95M8ftwZ3X11IV0= x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--20.879000-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23934.003 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:22:41 -0000 SGkgSWdvciwNCg0KVGhlIGRpZmZlcmVuY2UgYXMgSSBzZWUgaXQgaXMsIGlmIHdlIHdlcmUgdG8g Zm9sbG93IGEgbW9kZWwgc2ltaWxhciB0byBob3cgQ09OTkVDVCBpcyBkZWZpbmVkIGluIHRoZSBI VFRQL1FVSUMgbWFwcGluZywgdGhlbiBRVUlDIHR1bm5lbHMgYXJlIGFzc2lnbmVkIHRvIGRpZmZl cmVudCBzdHJlYW1zICh0dW5uZWwtc3RyZWFtcykgd2l0aGluIGEgc2luZ2xlIGNvbm5lY3Rpb24u IFJlbWFpbmluZyBzdHJlYW1zIGFyZSB1c2VkIGZvciBjbGllbnQtcHJveHkgY29tbXVuaWNhdGlv bnMgKGNvbnRyb2wgc3RyZWFtcywgcmVxdWVzdC9yZXNwb25zZSBldGMpDQoNCk9uIHN1Y2ggYSB0 dW5uZWwtc3RyZWFtLCBpZiB3ZSBmb2xsb3cgdGhlIENPTk5FQ1QgbW9kZWwgb2YgZW5jYXBzdWxh dGlvbiwgdGhlIGNsaWVudCBzZW5kcy9yZWNlaXZlcyBvbmx5IFFVSUMgcGFja2V0cy4gSXQgaXMg dGhlIHByb3h5J3Mgam9iIHRvIHJlYWQvd3JpdGUgSVAuDQoNClRoaXMgbGVhZHMgbWUgdG8gdGhp bmtpbmcgdGhhdCBhIHByb3h5IGNhbm5vdCByZXR1cm4gSUNNUCBvbiB0aGUgdHVubmVsLXN0cmVh bSwgYW5kIGFueSBJQ01QIGNhbm5vdCBiZSBkaXNhbWJpZ3VhdGVkLg0KDQpPciwgcGVyaGFwcyBJ J20gbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KS2luZCByZWdhcmRzDQpMdWNhcw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTHViYXNoZXYsIElnb3Ig W2lsdWJhc2hlQGFrYW1haS5jb21dDQpTZW50OiAyOCBKdW5lIDIwMTggMDA6MDkNClRvOiBMdWNh cyBQYXJkdWU7IE1hcnRpbiBEdWtlOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFJFOiBUcmVhdG1l bnQgb2YgSUNNUCBmb3IgUE1UVQ0KDQpIaSBMdWNhcywNCg0KSG93IGlzIHRoaXMgZGlmZmVyZW50 IGZyb20gUE1UVUQgaW4gSVAtaW4tSVAgY2FzZT8gIFRoZSBlbmRwb2ludCBjb21wdXRlcyBhbmQg Y2FjaGVzIFBNVFUgcGVyIGVuZHBvaW50LiAgUE1UVSBmb3IgY29ubmVjdGlvbnMgdG8gcHJveHkg aXMga2VwdCBzZXBhcmF0ZWx5IGZyb20gUE1UVXMgZm9yIGNvbm5lY3Rpb25zIHRvIGVuZHBvaW50 cyB0aGF0IGdvIHZpYSB0aGUgcHJveHkuDQoNClRoZSBwcm94eSBpdHNlbGYgY2FuIGxlYXJuIFBN VFUgYmV0d2VlbiBpdHNlbGYgYW5kIHRoZSBlbmRwb2ludHMsIHN1YnRyYWN0IHRoZSBvdmVyaGVh ZCwgYW5kIHNlbmQgSUNNUCB0byB0aGUgc2VuZGVyIG9mIHRoZSBwcm94aWVkIFFVSUMgZmxvdy4N Cg0KSSBzZWUgdGhlIGNvbW1vbiBjYXNlIG9mIFFVSUMgaW1wbGVtZW50YXRpb24gbm90IGJlaW5n IGFibGUgdG8gbWFrZSB1c2Ugb2YgSUNNUCBpcyB3aGVuIFFVSUMgaXMgaW1wbGVtZW50ZWQgaW4g dXNlcnNwYWNlIG9uIGEgcGxhdGZvcm0gdGhhdCBkb2VzIG5vdCBleHBvc2UgSUNNUCB0byB0aGUg YXBwbGljYXRpb24uICBRVUlDoa9zIGRlc2lyZSB0byByZWNlaXZlIElDTVAgd2lsbCBsaWtlbHkg Y2F1c2UgdmVuZG9ycyBvZiBzdWNoIHBsYXRmb3JtcyB0byBhZGQgdGhlIG1pc3NpbmcgZnVuY3Rp b25hbGl0eS4NCg0KDQogICogICBJZ29yDQoNCg0KRnJvbTogTHVjYXMgUGFyZHVlIFttYWlsdG86 THVjYXMuUGFyZHVlQGJiYy5jby51a10NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNywgMjAxOCA1 OjI3IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBNYXJ0aW4g RHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogVHJlYXRtZW50IG9mIElDTVAgZm9yIFBNVFUNCg0KSGkgSWdvciwN Cg0KSWYgd2UgY29uc2lkZXIgdHVubmVsbGluZyBvZiBRVUlDIHdpdGhpbiBRVUlDIGJ5IG1lYW5z IG9mIGEgcHJveHkgKG5vdCBjdXJyZW50bHkgc3BlY2NlZCBhbnl3aGVyZSBidXQgZmVhc2libGUp LCB0aGUgdHVubmVsbGVkIChlbmQtdG8tZW5kKSBwYXRoIE1UVSBpcyBsaWtlbHkgdG8gYmUgc21h bGxlciB0aGFuIHRoZSBob3AtYnktaG9wIHBhdGggTVRVcy4gSXQgbWF5IG5vdCBiZSBwb3NzaWJs ZSBmb3IgdGhlIHByb3hpZXMgdG8gcGFzcyBvbiBJQ01QIGluIGEgd2F5IHRoYXQgdGhlIHRoZSB0 dW5uZWxsZWQgUVVJQyBpbXBsZW1lbnRhdGlvbiBjYW4gYWNjZXNzIGl0LiAoRClQTFBNVFVEIHNl ZW1zIHRvIGZpdCB0aGlzIGNhc2UgbmljZWx5IGFzIHRoZXJlIGNhbiBiZSB0d28gb3IgbW9yZSBQ TFBNVFVEIGNvbnRleHRzL3ZhbHVlcyAob25lIGZvciB0aGUgY29ubmVjdGlvbiB0byB0aGUgcHJv eHksIG9uZSBmb3IgZWFjaCB0dW5uZWwgd2l0aGluIHRoaXMgY29ubmVjdGlvbikuDQoNCkx1Y2Fz DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUVVJQyBbcXVpYy1ib3Vu Y2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgTHViYXNoZXYsIElnb3IgW2lsdWJhc2hlPTQwYWth bWFpLmNvbUBkbWFyYy5pZXRmLm9yZ10NClNlbnQ6IDI3IEp1bmUgMjAxOCAyMTozNg0KVG86IE1h cnRpbiBEdWtlOyBJRVRGIFFVSUMgV0cNClN1YmplY3Q6IFRyZWF0bWVudCBvZiBJQ01QIGZvciBQ TVRVDQpJIGhhdmUgYSBQUiBmb3IgdHJlYXRtZW50IG9mIElDTVAgZm9yIFBNVFUgKGh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8xNDEyPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFz ZS0yRGRyYWZ0c19wdWxsXzE0MTImZD1Ed01GSXcmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9 RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPVo4Snp0ZW0wOVdo bjh1cjN1NENJWHlkUTJiRmN4VDdKOFJQXzVFSXFxTjAmcz1HZkZIaFotSXNMZld6cmMzRGQ4M2tf X0k2R29seHhkM1cyTGR1VEhZY19JJmU9PikuDQpNYW55IHRoYW5rcyB0byB0aG9zZSB3aG8gZ2F2 ZSBtZSBhbXBsZSBmZWVkYmFjayAoYm90aCBzdWJzdGFudGl2ZSBhbmQgZWRpdG9yaWFsKS4gIEmh r3ZlIHRyaWVkIHRvIGluY29ycG9yYXRlIGl0IGFsbC4NCg0KVGhlcmUgYXJlIHR3byB0ZWNobmlj YWwgaXNzdWVzIHRoYXQgQE1hcnRpbiBEdWtlPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNv bT4gYW5kIEkgYmVsaWV2ZSBkZXNlcnZlIGEgYnJvYWRlciBkaXNjdXNzaW9uIHdpdGggdGhlIGdy b3VwLg0KDQoNCiAgMS4gIElzIHByb2Nlc3NpbmcgSUNNUCBzaWduYWxzIChhbmQsIGVzcGVjaWFs bHksIElDTVAgUGFja2V0IFRvbyBCaWcgc2lnbmFsKSBhIE1BWSBvciBhIFNIT1VMRD8NCg0KSW4g dGhlIFdHIGRyYWZ0LCBwcm9jZXNzaW5nIElDTVAgaXMgYSBNQVksIGJ1dCBpbXBsZW1lbnRpbmcg UExQTVRVRCAoUkZDNDgyMSkgaXMgYSBTSE9VTEQuDQpIb3dldmVyLCBQTFBNVFVEIGNsYWltcyBp dHNlbGYgdG8gYmUgYW4gZXh0ZW5zaW9uIG9mIElDTVAtYmFzZWQgUE1UVUQgcHJvY2Vzcy4gU28g aXQgbWFrZXMgc2Vuc2UgdG8gbWUgdGhhdCBpZiBQTFBNVFVEIGlzIGEgU0hPVUxELCB0aGVuIElD TVAgaXRzZWxmIGlzIGEgU0hPVUxELg0KUVVJQyBpbXBsZW1lbnRhdGlvbnMgdy9vIGFjY2VzcyB0 byBJQ01QIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGltcGxlbWVudCB0aGUgSUNNUCBwYXJ0LCBhbmQg dGhpcyBpcyBvayBhbGJlaXQgdW5mb3J0dW5hdGU7IGFuZCB0aGlzIGFsc28gcG9pbnRzIHRvIFNI T1VMRCAoc2tpcHBpbmcgb24gTUFZIGlzIG5vdCAidW5mb3J0dW5hdGUiKS4NCg0KDQoNCiAgMS4g IFdoYXQgdG8gZG8sIHdoZW4gYW4gSVB2NCBJQ01QICh3L28gb24tcGF0aCBwcm9vZikgcmVxdWVz dCBhIFBNVFUgcmVkdWN0aW9uIChhZnRlciBoYW5kc2hha2UpPw0KDQpUaGVyZSBhcmUgdGhyZWUg bWFpbiBvcHRpb25zOiBpZ25vcmUgaXQsIHJlZHVjZSB5b3VyIFBNVFUgZXN0aW1hdGUsIGRvIG5v dCByZWR1Y2UgYnV0IHNlbmQgUExQTVRVRCBwcm9iZXMuICBTaW5jZSB0aGlzIGlzIHZlcnkgbGlr ZWx5IGEgdmFsaWQgc2lnbmFsLCBJIGRvIG5vdCBsaWtlIHRvIGlnbm9yZSBpbiB0aGUgY29tbW9u IGNhc2UuDQoNCkhlbmNlLCB0aGUgcHJvcG9zYWwgaXMgdG8gYWxsb3cgYW4gaW1tZWRpYXRlIFBN VFUgcmVkdWN0aW9uIHRvIHVwIHRvIHNvbWUgTSwgd2hlcmUgMTI4MCChwiBNIKHCIDE1MDAuICBP bmNlIHRoZSByZWR1Y3Rpb24gdGFrZXMgcGxhY2UsIHRoZSBlbmRwb2ludCBjYW4gdXNlIFBMUE1U VUQgcmVjb21tZW5kYXRpb25zIHRvIHNlZSBpZiBpdCBjYW4gcHJvYmUgYSBsYXJnZXIgUE1UVS4g IElmIHRoaXMgc291bmRzIHJlYXNvbmFibGUsIHRoZW4gdGhlIHF1ZXN0aW9uIGlzIHBpY2tpbmcg TS4gIEkgcGlja2VkIDEzOTIgcmF0aGVyIGFyYml0cmFyaWx5IChHUkUgb3ZlciBJUHNlYyArIGEg ZmV3IE1QTFMgbGFiZWxzKS4gIElmIHRoZSByZXF1ZXN0ZWQgcmVkdWN0aW9uIGlzIDEyODAgocIg WCA8IE0sIHRoZW4gdGhlIHJlY29tbWVuZGF0aW9uIGlzIG5vdCB0byByZWR1Y2UgYnV0IHNlbmQg UExQTVRVRCBwcm9iZXMuICBEb2VzIHRoaXMgbWFrZSBzZW5zZSwgb3Igc2hvdWxkIHdlIGhhdmUg TT0xMjgwIGFuZCBzaW1wbGlmeSB0aGluZ3M/DQoNCk5vdGU6IGZvciBJQ01QIHcvIG9uLXBhdGgg cHJvb2YsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gYWxsb3cgYSByZWR1Y3Rpb24gaW4gUE1U VSB1cCB0byAxMjgwLiAgSXQgaXMgaGFyZCB0byBmb3JnZSB0aGVzZSwgYW5kIHRoZSBiZW5lZml0 IG9mIHRoZSBlZmZvcnQgZm9yIHRoZSBhdHRhY2tlciBpcyBtaW5pbWFsIChzbGlnaHRseSBsb3dl ciBlZmZpY2llbmN5IG9mIHRoZSB0cmFuc3BvcnQpLiAgU28gaXQgaXMgbGVzcyBsaWtlbHkgdGhh dCB3ZaGvbGwgc2VlIGZvcmdlZCBJQ01QIHcvIG9uLXBhdGggcHJvb2YuDQoNCg0KQW55IGZlZWRi YWNrIGlzIHZlcnkgd2VsY29tZS4NCg0KDQogICogICBJZ29yDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KaHR0cDovL3d3dy5iYmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQg YW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kDQptYXkgY29udGFpbiBwZXJzb25h bCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZp Y2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4NCmVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3Nl IHRoZQ0KaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFu ZCBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBC QkMgbW9uaXRvcnMgZS1tYWlscw0Kc2VudCBvciByZWNlaXZlZC4NCkZ1cnRoZXIgY29tbXVuaWNh dGlvbiB3aWxsIHNpZ25pZnkgeW91ciBjb25zZW50IHRvDQp0aGlzLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg== From nobody Wed Jun 27 19:18:53 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C140B130EF1; Wed, 27 Jun 2018 19:18:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153015232475.15338.17784465551833797052@ietfa.amsl.com> Date: Wed, 27 Jun 2018 19:18:44 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 02:18:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-13.txt Pages : 43 Date : 2018-06-27 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-13 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-13 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 Wed Jun 27 21:22:45 2018 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A70130F25; Wed, 27 Jun 2018 21:22:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-qpack-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153015975842.15346.8407387696616666160@ietfa.amsl.com> Date: Wed, 27 Jun 2018 21:22:38 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 04:22:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QPACK: Header Compression for HTTP over QUIC Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-01.txt Pages : 25 Date : 2018-06-27 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP over QUIC. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-01 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-01 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 Wed Jun 27 22:28:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEB130E98 for ; Wed, 27 Jun 2018 22:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 G38U_pMiw8QY for ; Wed, 27 Jun 2018 22:28:20 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 10762130E10 for ; Wed, 27 Jun 2018 22:28:20 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id l16-v6so9957810ita.0 for ; Wed, 27 Jun 2018 22:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=ixnmXDgAtnIvrZfcL1u7co08t0LJin3dAU1VOeETApg=; b=AJyG/yO+usaLaH4UMcdyyNaRexAI2IFvHL6JhHogwOCpWVAvxzXFgnXxMmQwjPF1b9 tSa5Ej1XJjAwksiofPgxrjSRj7KGN2a0CDherBBuNR8TPaGS1vHoWhrWucUVYCr8zlIh 08r9rvRW3J0qxEB53uhIe5H3DhrfqQJymHd695Jw8rs60ZUKM3AmxoZc9czbxogXQGGN amJqwrMCwoBOZ3ckGGcGspp2cvnD9TfrqMCQOTviTT4wB7DY9/8RamZkaB4Xf1Rm8mFa HM+Q3KhykX5VLP0IIid0OLR58ZsUHDyQMu9kBCFwxGqYYTkGJYmtcWd9DV2jz2l3ook8 aTfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=ixnmXDgAtnIvrZfcL1u7co08t0LJin3dAU1VOeETApg=; b=ZD+rossucwsXCw6UWnLoqQlpc2rfuELjF2164I0LUA+NoopRZQBPFyx5LT0W2sYyvn jOjCKKwLDM9U0x6JKebb1h8Ml9woQZiOiAyFPjfzhfzaJydBnoBjb9O760xx87lWzksC DbK/sU2xb4p0uvQ2CnuHHqjzfDUbIPAe2uS4bTHycSqPNwk5h3k03v7ebEXeZ0NEh8Me WCdBvGmApE3zI4aycZC13vGaLWlbrw+6eE1KBKdYQ88X0Ca/4kg4O2/8xQeGgVPKIGJx IRK7D7AXgh21pZPMXt3CNUrjVkKFNE2D6Ia7heyojjcMi/D6wuUgkUrm2H98A9RC6tmJ zz0w== X-Gm-Message-State: APt69E2WZETPbbfyMr0//l7mNytVpYCuoe+aRXd/LhYn7OEjU176cRSp CRjmQUP5TKKCSsVbinQLkbkQE04fFy6UdmZPxDo= X-Google-Smtp-Source: AAOMgpdpS+R7dAYFGauV12ept8WzMz1Y/bTKJd66NECfsGAKhhTz16E0YrTIsVJ297e4gqqHuums7A4Qayv+84U/4eE= X-Received: by 2002:a02:9833:: with SMTP id t48-v6mr7496378jaj.111.1530163699368; Wed, 27 Jun 2018 22:28:19 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 28 Jun 2018 01:28:18 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 28 Jun 2018 01:28:18 -0400 Message-ID: Subject: RE: Treatment of ICMP for PMTU To: Lucas Pardue , IETF QUIC WG , Martin Duke , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="000000000000bfc80c056facffef" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 05:28:24 -0000 --000000000000bfc80c056facffef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wrt tunnelling, see also https://github.com/quicwg/base-drafts/issues/1209 which was unceremoniously shut down on the argument that a path below 1280 is not a QUIC path. I see a concrete use case for smaller PMTU=E2=80=99s: a high performance coordination node forwards packets to peer nodes for consensus. The consensus requires adding a signature on forwarding, but repackaging the packet is too slow and might go against the proof being made. Here PNE is also annoying. On tunneling QUIC in QUIC in QUIC streams: that would add HOL, enough to not make it QUIC. Mikkel On 28 June 2018 at 03.22.54, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Hi Igor, The difference as I see it is, if we were to follow a model similar to how CONNECT is defined in the HTTP/QUIC mapping, then QUIC tunnels are assigned to different streams (tunnel-streams) within a single connection. Remaining streams are used for client-proxy communications (control streams, request/response etc) On such a tunnel-stream, if we follow the CONNECT model of encapsulation, the client sends/receives only QUIC packets. It is the proxy's job to read/write IP. This leads me to thinking that a proxy cannot return ICMP on the tunnel-stream, and any ICMP cannot be disambiguated. Or, perhaps I'm missing something here? Kind regards Lucas ________________________________________ From: Lubashev, Igor [ilubashe@akamai.com] Sent: 28 June 2018 00:09 To: Lucas Pardue; Martin Duke; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Lucas, How is this different from PMTUD in IP-in-IP case? The endpoint computes and caches PMTU per endpoint. PMTU for connections to proxy is kept separately from PMTUs for connections to endpoints that go via the proxy. The proxy itself can learn PMTU between itself and the endpoints, subtract the overhead, and send ICMP to the sender of the proxied QUIC flow. I see the common case of QUIC implementation not being able to make use of ICMP is when QUIC is implemented in userspace on a platform that does not expose ICMP to the application. QUIC=E2=80=99s desire to receive ICMP will = likely cause vendors of such platforms to add the missing functionality. * Igor From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] Sent: Wednesday, June 27, 2018 5:27 PM To: Lubashev, Igor ; Martin Duke < martin.h.duke@gmail.com>; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Igor, If we consider tunnelling of QUIC within QUIC by means of a proxy (not currently specced anywhere but feasible), the tunnelled (end-to-end) path MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be possible for the proxies to pass on ICMP in a way that the the tunnelled QUIC implementation can access it. (D)PLPMTUD seems to fit this case nicely as there can be two or more PLPMTUD contexts/values (one for the connection to the proxy, one for each tunnel within this connection). Lucas ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=3D 40akamai.com@dmarc.ietf.org] Sent: 27 June 2018 21:36 To: Martin Duke; IETF QUIC WG Subject: Treatment of ICMP for PMTU I have a PR for treatment of ICMP for PMTU ( https://github.com/quicwg/base-drafts/pull/1412< https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_quicwg_ba= se-2Ddrafts_pull_1412&d=3DDwMFIw&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DDjn3bQ5uNJD= PM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=3DZ8Jztem09Whn8ur3u4CIXydQ2bFcxT7J8RP_5E= IqqN0&s=3DGfFHhZ-IsLfWzrc3Dd83k__I6Golxxd3W2LduTHYc_I&e=3D>). Many thanks to those who gave me ample feedback (both substantive and editorial). I=E2=80=99ve tried to incorporate it all. There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big signal) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC4821) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD process. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself is a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the ICMP part, and this is ok albeit unfortunate; and this also points to SHOULD (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not reduce but send PLPMTUD probes. Since this is very likely a valid signal, I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M, where 1280 =E2=89=A4 M =E2=89=A4 1500. Once the reduction takes place, t= he endpoint can use PLPMTUD recommendations to see if it can probe a larger PMTU. If this sounds reasonable, then the question is picking M. I picked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels). If the requested reduction is 1280 =E2=89=A4 X < M, then the recommendation is not to reduce= but send PLPMTUD probes. Does this make sense, or should we have M=3D1280 and simplify things? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280. It is hard to forge these, and the benefit of the effort for the attacker is minimal (slightly lower efficiency of the transport). So it is less likely that we=E2=80=99ll see forged ICMP w/ on-p= ath proof. Any feedback is very welcome. * Igor ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --000000000000bfc80c056facffef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Wrt tunnelling, see = also


which was unceremoniously shu= t down on the argument that a path below 1280 is not a QUIC path.

<= /div>
I see a concrete use case for smaller PMTU=E2=80=99s: a high perf= ormance coordination node forwards packets to peer nodes for consensus. The= consensus requires adding a signature on forwarding, but repackaging the p= acket is too slow and might go against the proof being made. Here PNE is al= so annoying.

On tunneling QUIC in QUIC in QUIC strea= ms: that would add HOL, enough to not make it QUIC.

Mikkel

On 28 June 2018 at 03.22.54, Lucas= Pardue (lucas.pardue@bbc.co.uk) wrote:

Hi Igor,

The difference as I see it is, if we were to follow a model similar to = how CONNECT is defined in the HTTP/QUIC mapping, then QUIC tunnels are assi= gned to different streams (tunnel-streams) within a single connection. Rema= ining streams are used for client-proxy communications (control streams, re= quest/response etc)

On such a tunnel-stream, if we follow the CONNECT model of encapsulatio= n, the client sends/receives only QUIC packets. It is the proxy's job t= o read/write IP.

This leads me to thinking that a proxy cannot return ICMP on the tunnel= -stream, and any ICMP cannot be disambiguated.

Or, perhaps I'm missing something here?

Kind regards
Lucas
________________________________________
From: Lubashev, Igor [ilubashe@a= kamai.com]
Sent: 28 June 2018 00:09
To: Lucas Pardue; Martin Duke; IETF QUIC WG
Subject: RE: Treatment of ICMP for PMTU

Hi Lucas,

How is this different from PMTUD in IP-in-IP case? The endpoint comput= es and caches PMTU per endpoint. PMTU for connections to proxy is kept sep= arately from PMTUs for connections to endpoints that go via the proxy.

The proxy itself can learn PMTU between itself and the endpoints, subtr= act the overhead, and send ICMP to the sender of the proxied QUIC flow.

I see the common case of QUIC implementation not being able to make use= of ICMP is when QUIC is implemented in userspace on a platform that does n= ot expose ICMP to the application. QUIC=E2=80=99s desire to receive ICMP w= ill likely cause vendors of such platforms to add the missing functionality= .


* Igor


From: Lucas Pardue [mailto:Lu= cas.Pardue@bbc.co.uk]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <ilubashe@= akamai.com>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

If we consider tunnelling of QUIC within QUIC by means of a proxy (not = currently specced anywhere but feasible), the tunnelled (end-to-end) path M= TU is likely to be smaller than the hop-by-hop path MTUs. It may not be pos= sible for the proxies to pass on ICMP in a way that the the tunnelled QUIC = implementation can access it. (D)PLPMTUD seems to fit this case nicely as t= here can be two or more PLPMTUD contexts/values (one for the connection to = the proxy, one for each tunnel within this connection).

Lucas
________________________________
From: QUIC [quic-bounces@ietf.= org] on behalf of Lubashev, Igor [ilubashe=3D40akamai.com@dmarc.ietf.org]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU
I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-drafts/pull= /1412<https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__github.com_quicwg_base-2Ddrafts_pull_1412&d=3DDwMFIw&= c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KP= mlo&m=3DZ8Jztem09Whn8ur3u4CIXydQ2bFcxT7J8RP_5EIqqN0&s=3DGfFHhZ-IsLf= Wzrc3Dd83k__I6Golxxd3W2LduTHYc_I&e=3D>).
Many thanks to those who gave me ample feedback (both substantive and e= ditorial). I=E2=80=99ve tried to incorporate it all.

There are two technical issues that @Martin Duke<mailto:martin.h.duke@gmail.com> and I believ= e deserve a broader discussion with the group.


1. Is processing ICMP signals (and, especially, ICMP Packet Too Big = signal) a MAY or a SHOULD?

In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RF= C4821) is a SHOULD.
However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD p= rocess. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itse= lf is a SHOULD.
QUIC implementations w/o access to ICMP would not be able to implement = the ICMP part, and this is ok albeit unfortunate; and this also points to S= HOULD (skipping on MAY is not "unfortunate").



1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU = reduction (after handshake)?

There are three main options: ignore it, reduce your PMTU estimate, do = not reduce but send PLPMTUD probes. Since this is very likely a valid sign= al, I do not like to ignore in the common case.

Hence, the proposal is to allow an immediate PMTU reduction to up to so= me M, where 1280 =E2=89=A4 M =E2=89=A4 1500. Once the reduction takes plac= e, the endpoint can use PLPMTUD recommendations to see if it can probe a la= rger PMTU. If this sounds reasonable, then the question is picking M. I p= icked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels). If the= requested reduction is 1280 =E2=89=A4 X < M, then the recommendation is= not to reduce but send PLPMTUD probes. Does this make sense, or should we= have M=3D1280 and simplify things?

Note: for ICMP w/ on-path proof, I think it makes sense to allow a redu= ction in PMTU up to 1280. It is hard to forge these, and the benefit of th= e effort for the attacker is minimal (slightly lower efficiency of the tran= sport). So it is less likely that we=E2=80=99ll see forged ICMP w/ on-path= proof.


Any feedback is very welcome.


* Igor



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless sp= ecifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
--000000000000bfc80c056facffef-- From nobody Wed Jun 27 23:11:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A47130E06 for ; Wed, 27 Jun 2018 23:11:30 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 eR53HvVa7JV6 for ; Wed, 27 Jun 2018 23:11:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 B7F19126F72 for ; Wed, 27 Jun 2018 23:11:27 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5S67Q1l031401; Thu, 28 Jun 2018 07:11:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hpVCh4/gkrDoxR3E/6lkN9keQEConJLU2DYoXEiX4I4=; b=hnGCTBylCr7EyMyqaydHjZyeYi4IXOFEmhRbabcPRpmnaUL2acv95ek/cRmQiuQ7eE7m kwZ61gh5FEefVD0+j2AMVk9Ng98ppflIcz6YXODRHxWGAUe1KvY4UaWbMA+tEGMnawAN 7ePvFh3SGJjOyUv2HA4Iwn1Gpyv5XS/ENfIII9eAf7/YF/QXwpbBjmSKqRGnoJpBLKAE tB+KrT43LN9keXMU+wvf4nALYNorE/cwaIfUoA9GDdeqgVUAEIQYjTKbCEHVRI6rz0tR Al0uyHsEc0K9nEgAY+sw21IQp5bWG+kIX4Sh7ZqqSLFK0oGLNY0+hIlzCyi1Rm/8VPW1 kA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jvk1jh0vg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 07:11:22 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5S6Acqg021331; Thu, 28 Jun 2018 02:11:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bvrq03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 02:11:21 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 28 Jun 2018 01:11:20 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Thu, 28 Jun 2018 01:11:20 -0500 From: "Lubashev, Igor" To: Lucas Pardue , Martin Duke , IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAJFrAw Date: Thu, 28 Jun 2018 06:11:20 +0000 Message-ID: <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012>, <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.160] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280068 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 06:11:31 -0000 I think I see what you are talking about. At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward= data streams, not packets. Hence, MTU concept on a tunnel-stream is meani= ngless. The text says it explicitly: "Note that the size and number of TCP= segments is not guaranteed to map predictably to the size and number of HT= TP DATA or QUIC STREAM frames." From the client's perspective there is onl= y one PMTU that is relevant -- the one to the proxy. The proxy will keep t= racks of the PMTUs to the CONNECT endpoints itself and will generate TCP se= gments accordingly. Trying to design a CONNECT-like method to proxy an entire QUIC connection o= ver a single QUIC stream would create HOLB for QUIC packets to and from the= proxy. Some sort of a partially reliable QUIC stream could help here. This proxying scheme would require an extension to CONNECT to open a UDP/IP= tunnel instead of a TCP/IP tunnel. That extension would also mandate that= HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it would = be a very good idea for such a proxy to add a new frame for providing ICMP-= like explicit PMTU feedback to the sender (why leave the sender guessing an= d probing, if the PMTU is already known to the proxy?). - Igor -----Original Message----- From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20 Sent: Wednesday, June 27, 2018 9:23 PM To: Lubashev, Igor ; Martin Duke ; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Igor, The difference as I see it is, if we were to follow a model similar to how = CONNECT is defined in the HTTP/QUIC mapping, then QUIC tunnels are assigned= to different streams (tunnel-streams) within a single connection. Remainin= g streams are used for client-proxy communications (control streams, reques= t/response etc) On such a tunnel-stream, if we follow the CONNECT model of encapsulation, t= he client sends/receives only QUIC packets. It is the proxy's job to read/w= rite IP. This leads me to thinking that a proxy cannot return ICMP on the tunnel-str= eam, and any ICMP cannot be disambiguated. Or, perhaps I'm missing something here? Kind regards Lucas ________________________________________ From: Lubashev, Igor [ilubashe@akamai.com] Sent: 28 June 2018 00:09 To: Lucas Pardue; Martin Duke; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Lucas, How is this different from PMTUD in IP-in-IP case? The endpoint computes a= nd caches PMTU per endpoint. PMTU for connections to proxy is kept separat= ely from PMTUs for connections to endpoints that go via the proxy. The proxy itself can learn PMTU between itself and the endpoints, subtract = the overhead, and send ICMP to the sender of the proxied QUIC flow. I see the common case of QUIC implementation not being able to make use of = ICMP is when QUIC is implemented in userspace on a platform that does not e= xpose ICMP to the application. QUIC's desire to receive ICMP will likely c= ause vendors of such platforms to add the missing functionality. * Igor From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] Sent: Wednesday, June 27, 2018 5:27 PM To: Lubashev, Igor ; Martin Duke ; IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Hi Igor, If we consider tunnelling of QUIC within QUIC by means of a proxy (not curr= ently specced anywhere but feasible), the tunnelled (end-to-end) path MTU i= s likely to be smaller than the hop-by-hop path MTUs. It may not be possibl= e for the proxies to pass on ICMP in a way that the the tunnelled QUIC impl= ementation can access it. (D)PLPMTUD seems to fit this case nicely as there= can be two or more PLPMTUD contexts/values (one for the connection to the = proxy, one for each tunnel within this connection). Lucas ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=3D= 40akamai.com@dmarc.ietf.org] Sent: 27 June 2018 21:36 To: Martin Duke; IETF QUIC WG Subject: Treatment of ICMP for PMTU I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-= drafts/pull/1412). Many thanks to those who gave me ample feedback (both substantive and edito= rial). I've tried to incorporate it all. There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big sign= al) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC482= 1) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD proce= ss. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself i= s a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the = ICMP part, and this is ok albeit unfortunate; and this also points to SHOUL= D (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU redu= ction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not = reduce but send PLPMTUD probes. Since this is very likely a valid signal, = I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M= , where 1280 =98 M =98 1500. Once the reduction takes place, the endpoint = can use PLPMTUD recommendations to see if it can probe a larger PMTU. If t= his sounds reasonable, then the question is picking M. I picked 1392 rathe= r arbitrarily (GRE over IPsec + a few MPLS labels). If the requested reduc= tion is 1280 =98 X < M, then the recommendation is not to reduce but send P= LPMTUD probes. Does this make sense, or should we have M=3D1280 and simpli= fy things? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reductio= n in PMTU up to 1280. It is hard to forge these, and the benefit of the ef= fort for the attacker is minimal (slightly lower efficiency of the transpor= t). So it is less likely that we'll see forged ICMP w/ on-path proof. Any feedback is very welcome. * Igor ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal = views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender imme= diately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Thu Jun 28 00:03:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99D6130E22 for ; Thu, 28 Jun 2018 00:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.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 uqk2ZPexWotE for ; Thu, 28 Jun 2018 00:03:22 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D66512F1AC for ; Thu, 28 Jun 2018 00:03:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,282,1526367600"; d="asc'?scan'208";a="283198628" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 28 Jun 2018 00:03:21 -0700 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 28 Jun 2018 00:03:21 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 28 Jun 2018 00:03:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNXYcUdVGopxz+Nxg7l7ctWzESgWLgORgISrWukZIQk=; b=OiTnRZpFjk+80AcHz+S4agrpwGpgS0lu0izyEWYM3/2r6ZinkRVhITxZc8HVRBOtFfR23y+J9EDr5vLQ7yL8QQynsoFaNUguAx+Z+LyuDqKcQJSlg3XGKS7TyiGwUgzRujlGWZCNf2tK9dYcLlI4xm/GJpMkEnhFTbKOZETvrLw= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB289.namprd06.prod.outlook.com (10.141.23.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.906.23; Thu, 28 Jun 2018 07:03:17 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::f983:bf6c:8b8f:c82c]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::f983:bf6c:8b8f:c82c%6]) with mapi id 15.20.0906.023; Thu, 28 Jun 2018 07:03:16 +0000 From: "Eggert, Lars" To: "Lubashev, Igor" CC: Martin Duke , IETF QUIC WG Subject: Re: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wAV77aA Date: Thu, 28 Jun 2018 07:03:16 +0000 Message-ID: <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [192.76.146.51] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB289; 7:+hPkEvtuhFy3RJmHa3utH7CYgUW4rIOdsTztqV0IBFYyib1I8A0wHwaOKcPLTfbRD0yULUHw4QDXizssJJlfgv+LCHvKkqjVFcuUhY8NqwQlIQSEmG/fjwcpd70x8oHre43jXOkRq5FkdEr4SzC7S4aq1uoIaYj0FljOR1xE4EnW8HfOi8Dnl/pJZgjWdLu4QMdGEYmI+46DQWs0Qls8tSJKyeFfDkB19bnzdjmGJr9NVAtKD8fLxd5hyLbFrQQf x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5a19e878-3852-471e-444c-08d5dcc53939 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB289; x-ms-traffictypediagnostic: BLUPR06MB289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BLUPR06MB289; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB289; x-forefront-prvs: 0717E25089 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(39860400002)(366004)(199004)(189003)(256004)(83716003)(486006)(478600001)(476003)(6436002)(6486002)(6512007)(4326008)(39060400002)(36756003)(53936002)(66066001)(6246003)(446003)(11346002)(229853002)(4001150100001)(50226002)(97736004)(57306001)(14454004)(14444005)(5250100002)(6116002)(3846002)(6506007)(102836004)(99936001)(53546011)(186003)(5660300001)(76176011)(2900100001)(26005)(7736002)(54906003)(82746002)(2616005)(305945005)(99286004)(2906002)(8936002)(81166006)(8676002)(105586002)(81156014)(86362001)(316002)(25786009)(68736007)(106356001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB289; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5qOywTfFIPRIMA/eVMx1s8+GWX8wlXZGHQkeIVl/MQGfQdALEvqjxQTdXOebuOOO80AtkdADd/cnugT1gGrDqyS+uc56R4kWvqQTxh7PKBeorSJ2a5aih/uEyOOg9ZjwtRtPz4sBBPNarLFECTgUcZXa7QOChhH3LE7OZWWG/zlccuyIXLTyTo02A+DGduSUURG82NRMj6OVbxp3qFrwsAHiAIqDqmpkuwshaeler24381WujD+YwOSducEzj/y+9NTJF0RWemzqwQC5u/Q/tbNcrwCFNLTzmq0aRjSykTc9HsHSBnmg0JDR9orrNEJM5spGGy76cC3qN04JL/7KcEoppOqM7YkPww54NoHXTYM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_96431A64-FABF-44D2-B150-27B67CCE861A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5a19e878-3852-471e-444c-08d5dcc53939 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2018 07:03:16.8784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB289 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 07:03:25 -0000 --Apple-Mail=_96431A64-FABF-44D2-B150-27B67CCE861A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2018-6-27, at 22:36, Lubashev, Igor = wrote: > =E2=80=A2 Is processing ICMP signals (and, especially, ICMP = Packet Too Big signal) a MAY or a SHOULD? >=20 > In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD = (RFC4821) is a SHOULD. > However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD = process. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP = itself is a SHOULD. > QUIC implementations w/o access to ICMP would not be able to implement = the ICMP part, and this is ok albeit unfortunate; and this also points = to SHOULD (skipping on MAY is not "unfortunate"). 4821 is an extension of 1191/1981 in the sense that it provides similar = functionality in an Internet where ICMP delivery is unreliable - i.e., = the only Internet we have. Because 4821 works without any ICMP delivery = (its convergence is improved by it, but that is an optimization), the = two need not be at the same requirements level. As an individual, I'd argue that 4821 must be a SHOULD (and actually = should be a MUST, except that we probably want to allow for inefficient = stacks that send fixed-sized small packets). Given the current state of ICMP blockage, I don't really care what we = say about 1191/1981. A MAY is fine; a SHOULD seems overkill given the = unreliability of ICMP, but I could live with it. > =E2=80=A2 What to do, when an IPv4 ICMP (w/o on-path proof) = request a PMTU reduction (after handshake)? Isn't this sufficiently covered in 4821? Lars PS: Chair hat off. --Apple-Mail=_96431A64-FABF-44D2-B150-27B67CCE861A 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAls0iDMACgkQVLXDCb9w wVfisg//ZYIPEH8R/iio0ItWKODNScuCIWdWLlec4HmhSA/rgYE/AUVTvaio4r+L nlzLfq0TMdt7U4uODTtVgIqzNNDTp+bvi9aNMwT+7WQrgfIN922j5MqaIc8hJZL5 oP3ZN9VlIF0Hpm8IWol1kN60OGIqZiF87m8L03v251iGNfSxXcAfY02VNIKfa0LF /8vtOUUB/zt1dcDWH32+Mqrpu3xyAkJraqMFDJCGM2Mv1h/TitsFHgXyJbfceP8Q CE4/StMD+lzv84StWiVwqM7iAgHhFmFqDvdgidzG5zMI4+46M4MReBecv8RgRKrz 7YOmLuf4DCXm5YUdN9Z8OVj3TpACJxdoBOVR7ZIeOoaV5WBL+tn4WeQ/z74abqUl JOz2MA+fn8d7IuNWillzJhqK5gH7nKNl+KYwCK7vuaJlMRk3yF5usDs2vkvNiaaf YZhno6gDydBzSzAKNj7tfV8LaFxBKNpzg5E5GLAXWv0XHjlo3R98zrWsYabAhbcC 0z0GsirBO1IfD1wEBKvOy1fTAF2sJo/vMfyXliJ2lK1GuXjhJwt5OyIqeX08l84t sv0XLsC31BTr7noEyGfaKXrkJvQYHLDrpDSZWIasPCVqoowUPwNlfW0NVdpA88RK HSxddqyVJ3EB4wP5Ch7wROUrTcUFfqD9rOv4ilSyq68XkXg7zaM= =m3XX -----END PGP SIGNATURE----- --Apple-Mail=_96431A64-FABF-44D2-B150-27B67CCE861A-- From nobody Thu Jun 28 02:10:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9628B130F1F for ; Thu, 28 Jun 2018 02:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RibjGI3brjuM for ; Thu, 28 Jun 2018 02:10:11 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF83130F0B for ; Thu, 28 Jun 2018 02:10:11 -0700 (PDT) Received: from BGB01XI1010.national.core.bbc.co.uk (bgb01xi1010.national.core.bbc.co.uk [10.161.14.14]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5S9A6nU026262; Thu, 28 Jun 2018 10:10:06 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1010.national.core.bbc.co.uk ([10.161.14.14]) with mapi id 14.03.0389.001; Thu, 28 Jun 2018 10:10:06 +0100 From: Lucas Pardue To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Martin Duke , "Lubashev, Igor" Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAHCjoAAAm8dnA= Date: Thu, 28 Jun 2018 09:10:06 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA81@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23934.005 x-tm-as-result: No-17.796600-8.000000-10 x-tmase-matchedrid: X4bcv0S75KlEXwnTCGfm3f0peXGEEBlvmHAp2UJ8+TxXG3yI9k2vbCWe OHilL0WHP5mpBtPr/e4BZOsOGHKpoUjlo2JU8qCxmHJeAYKlcpNxtWYlDuRQpY9osn8JrdJPaOL TgTM6NjgX8KBmsUzf6qdCIx24gQ82oXHg+KoW2UYiPTMUjkOgki1RIwMdx4yupOwTxn+Ouv6nvg 2KCDOgGHy4Qb9B9i9z7YaSfIt4lQJ5DFcHFDIB+y/YTQ49mwcHOyAvntOeAd6Rl9Ydphffeu/bF 9CSQF3djaOMlOGY7eHdiQFYcUCYxzRn2xdwrsXpHcQQBuf4ZFu+F//Mn3a2w0S/boWSGMtd0XkQ QQE/sODCEqUCZFLXWv2+R30vCSgA6t1guSoQ4UOeAiCmPx4NwFkMvWAuahr8LzP5snaeb1TTlOj yZSxJ4m4RojVxFH9b57CCZXpr4JBycZ7hsClWWBCVr5v48c4t54yn0DmLPJ0= x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--17.796600-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23934.005 Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5BA81bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:10:14 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5BA81bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlra2VsLA0KDQpUaGFua3MgZm9yIGhpZ2hsaWdodGluZyB0aGF0IGlzc3VlLCBJ4oCZZCBs b3N0IHNpZ2h0IG9mIGl0Lg0KDQpJ4oCZbGwgcmVzcG9uZCB0byB0aGUgSE9MIGJsb2NraW5nIG9u IElnb3LigJlzIHRocmVhZC4NCg0KTHVjYXMNCg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NClNlbnQ6IDI4IEp1bmUgMjAxOCAwNjoy OA0KVG86IEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51az47IElFVEYgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT47 IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KU3ViamVjdDogUkU6IFRyZWF0 bWVudCBvZiBJQ01QIGZvciBQTVRVDQoNCldydCB0dW5uZWxsaW5nLCBzZWUgYWxzbw0KDQpodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xMjA5DQoNCndoaWNoIHdh cyB1bmNlcmVtb25pb3VzbHkgc2h1dCBkb3duIG9uIHRoZSBhcmd1bWVudCB0aGF0IGEgcGF0aCBi ZWxvdyAxMjgwIGlzIG5vdCBhIFFVSUMgcGF0aC4NCg0KSSBzZWUgYSBjb25jcmV0ZSB1c2UgY2Fz ZSBmb3Igc21hbGxlciBQTVRV4oCZczogYSBoaWdoIHBlcmZvcm1hbmNlIGNvb3JkaW5hdGlvbiBu b2RlIGZvcndhcmRzIHBhY2tldHMgdG8gcGVlciBub2RlcyBmb3IgY29uc2Vuc3VzLiBUaGUgY29u c2Vuc3VzIHJlcXVpcmVzIGFkZGluZyBhIHNpZ25hdHVyZSBvbiBmb3J3YXJkaW5nLCBidXQgcmVw YWNrYWdpbmcgdGhlIHBhY2tldCBpcyB0b28gc2xvdyBhbmQgbWlnaHQgZ28gYWdhaW5zdCB0aGUg cHJvb2YgYmVpbmcgbWFkZS4gSGVyZSBQTkUgaXMgYWxzbyBhbm5veWluZy4NCg0KT24gdHVubmVs aW5nIFFVSUMgaW4gUVVJQyBpbiBRVUlDIHN0cmVhbXM6IHRoYXQgd291bGQgYWRkIEhPTCwgZW5v dWdoIHRvIG5vdCBtYWtlIGl0IFFVSUMuDQoNCk1pa2tlbA0K --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5BA81bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNaWtrZWwsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5r cyBmb3IgaGlnaGxpZ2h0aW5nIHRoYXQgaXNzdWUsIEnigJlkIGxvc3Qgc2lnaHQgb2YgaXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPknigJlsbCByZXNwb25kIHRvIHRoZSBIT0wgYmxvY2tpbmcgb24gSWdvcuKAmXMgdGhyZWFk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5MdWNhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAy OCBKdW5lIDIwMTggMDY6Mjg8YnI+DQo8Yj5Ubzo8L2I+IEx1Y2FzIFBhcmR1ZSAmbHQ7THVjYXMu UGFyZHVlQGJiYy5jby51ayZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7 IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSZndDs7IEx1YmFzaGV2LCBJ Z29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog VHJlYXRtZW50IG9mIElDTVAgZm9yIFBNVFU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5XcnQgdHVubmVsbGluZywgc2VlIGFsc288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0 cy9pc3N1ZXMvMTIwOSI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1 ZXMvMTIwOTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+d2hp Y2ggd2FzIHVuY2VyZW1vbmlvdXNseSBzaHV0IGRvd24gb24gdGhlIGFyZ3VtZW50IHRoYXQgYSBw YXRoIGJlbG93IDEyODAgaXMgbm90IGEgUVVJQyBwYXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkkgc2VlIGEgY29uY3JldGUgdXNlIGNhc2UgZm9yIHNtYWxsZXIg UE1UVeKAmXM6IGEgaGlnaCBwZXJmb3JtYW5jZSBjb29yZGluYXRpb24gbm9kZSBmb3J3YXJkcyBw YWNrZXRzIHRvIHBlZXIgbm9kZXMgZm9yIGNvbnNlbnN1cy4gVGhlIGNvbnNlbnN1cyByZXF1aXJl cyBhZGRpbmcgYSBzaWduYXR1cmUNCiBvbiBmb3J3YXJkaW5nLCBidXQgcmVwYWNrYWdpbmcgdGhl IHBhY2tldCBpcyB0b28gc2xvdyBhbmQgbWlnaHQgZ28gYWdhaW5zdCB0aGUgcHJvb2YgYmVpbmcg bWFkZS4gSGVyZSBQTkUgaXMgYWxzbyBhbm5veWluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5PbiB0dW5uZWxpbmcgUVVJQyBpbiBRVUlDIGluIFFVSUMgc3RyZWFt czogdGhhdCB3b3VsZCBhZGQgSE9MLCBlbm91Z2ggdG8gbm90IG1ha2UgaXQgUVVJQy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+TWlra2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5BA81bgb01xud1012_-- From nobody Thu Jun 28 02:25:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0724130F96 for ; Thu, 28 Jun 2018 02:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iexD6tvKy9e6 for ; Thu, 28 Jun 2018 02:25:22 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580E7130F7F for ; Thu, 28 Jun 2018 02:25:22 -0700 (PDT) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5S9PIiL023861; Thu, 28 Jun 2018 10:25:18 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0389.001; Thu, 28 Jun 2018 10:25:18 +0100 From: Lucas Pardue To: "Lubashev, Igor" , Martin Duke , IETF QUIC WG CC: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAJFrAwAAfLncA= Date: Thu, 28 Jun 2018 09:25:17 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012>, <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23934.005 x-tm-as-result: No-9.217100-8.000000-10 x-tmase-matchedrid: u7Yf2n7Ca/27lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p0NcckEPxfz2CU7 43HF3fJ15mb/1jYDTsq1rPg9k9RUkvMCf0EO7H1tDPhWwJzVhb6H7D1bP/FcOkENV4Lwnu7BM8b 8oRjLE5qFImf5EUPaDWIgk3Pw6FVn8HqrNSteiYTRc75iroKqApl/lu28zzkBnl2JZEArQgITBr T5FMhW3UT6WqzBWLOQpC0s6RzU0dr+hembQ23/aLai7SkVQxg5jiWciALpTNOW6aHRAuYExtEzI JFzSdhjj5h4B4zE00JBsJaf/YUTGPUZjbWnwyrhXP5rFAucBUEz7HWSgiz9ppsoi2XrUn/JmTDw p0zM3zoqtq5d3cxkNeAajwyO32wXIbER0cGW5hAQPPgi9B8ygvVI+Cgm6c3wbXqtS8jRZKs= x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-tmase-result: 10--9.217100-8.000000 x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23934.005 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:25:28 -0000 Igor Lubashev wrote: >I think I see what you are talking about. > >At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forwar= d >data streams, not packets. Hence, MTU concept on a tunnel-stream is >meaningless. The text says it explicitly: "Note that the size and number = of TCP >segments is not guaranteed to map predictably to the size and number of >HTTP DATA or QUIC STREAM frames." From the client's perspective there is >only one PMTU that is relevant -- the one to the proxy. The proxy will ke= ep >tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP >segments accordingly. Right, that's how I was seeing it. >Trying to design a CONNECT-like method to proxy an entire QUIC connection >over a single QUIC stream would create HOLB for QUIC packets to and from >the proxy. Some sort of a partially reliable QUIC stream could help here. Both you and Mikkel have identified HOL as something that needs more though= t. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is en= ough to make QUIC not QUIC". I've taken the view that it may be desirable t= o tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL= avoidance as an optimisation rather than a requirement. Partial reliabilit= y (of streams, or of some new frame type) could help solve that puzzle. Now= I think about it, a complimentary mitigation could be to reserve a set of = tunnel-streams to provide some basic multiplexing. However, the complexity = of that might not be worth it. >This proxying scheme would require an extension to CONNECT to open a >UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also manda= te >that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it >would be a very good idea for such a proxy to add a new frame for providin= g >ICMP-like explicit PMTU feedback to the sender (why leave the sender >guessing and probing, if the PMTU is already known to the proxy?). This is good feedback. Thanks! Kind regards Lucas From nobody Thu Jun 28 03:07:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA4130EA4 for ; Thu, 28 Jun 2018 03:07:33 -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, UNPARSEABLE_RELAY=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 OE9kniFIoLXF for ; Thu, 28 Jun 2018 03:07:31 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE86130934 for ; Thu, 28 Jun 2018 03:07:31 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g7-v6so4682401ioh.11 for ; Thu, 28 Jun 2018 03:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=46ozSSg9HdHO6RWshyDeyIzlTHrKuuphMvDvMXk3/2g=; b=M3UfM0VPSV74lDZcJAWdiohZdham2PVBqHMLtSsJxjmgp9hGy0uDJdZCJu+JM6mA8d O6JZb0qqB6TA05//v4e9iQqGBBkGuDwp/S3Og7SKE1roJhOP7+RW+3vF8XmNlEV4h6kC Y6yfJ7chVB3Y0fy7VOiY5JXAejYuzr3lJ0dhnzgYnU/EnmSX1kZiCjUdjpT3m9lqJgWz /THJnYFs0gTCXd9VVDsP0l9P5nqgzw+Fe5bqK+AaAuKV3YR3dxy0KNEGvgPK5S2KlR/B 2SUL+udrD/U0WQ9QOHwEl7xyvK6up0ufc5lq/1KNVeUYw6/Dy5C218qXe2CYm1EZ+vKn HaaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=46ozSSg9HdHO6RWshyDeyIzlTHrKuuphMvDvMXk3/2g=; b=fLa6RGKetTnkK0BIiHNNwD95NKrP/Jcbh9PZJ4Pq+nNcmWrqReqt8QF4DOXHueBLCx KsP88SXg1+mJvQmfC9z+D7fHer5iMTShxuvxxkSrTlahJzH5bd7JYHmfgbcJ5ENYaJuU ekvjkd4cTu8daniY7f1AYVq8CsVCF/EcAZp1YijRU0NtMbMWo+dTOWjQsppnBeP1M1LY 6LEX4CXEEgqBfAkPFZlLkpTM0dSak22lgJd56fQYcwwK+MsO2j0GZi+sEthaK/z6OG6+ amJh0sz5b+ys61CzhzqziwuZuCl6nTWKZ43M9Jy1LO0Uq1H0JDqH8CvlVGcYOKmA8Tzk YJnA== X-Gm-Message-State: APt69E3QiSsHTliDEP+61Q+mJxRBpXbykqCp6Ksi6pkvq49zWf1Fsdh2 QwiBjIGKKDpXMbo1Y6K/8BFTra9eDaWoCzkLEm4= X-Google-Smtp-Source: AAOMgpe2T5sXRrIIdFtwSOHddHZa3FgGWHqcEnz1seEqlphZOnD/nFSD2LV7qyjpjJq/1N26dxIVurhCsHLrxD2oS1Y= X-Received: by 2002:a6b:b78b:: with SMTP id h133-v6mr7760244iof.274.1530180450793; Thu, 28 Jun 2018 03:07:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 28 Jun 2018 06:07:29 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 28 Jun 2018 06:07:29 -0400 Message-ID: Subject: RE: Treatment of ICMP for PMTU To: Lucas Pardue , IETF QUIC WG , Martin Duke , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="000000000000363dda056fb0e673" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 10:07:34 -0000 --000000000000363dda056fb0e673 Content-Type: text/plain; charset="UTF-8" I think QUIC needs a tunnel extension frame. On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Igor Lubashev wrote: >I think I see what you are talking about. > >At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward >data streams, not packets. Hence, MTU concept on a tunnel-stream is >meaningless. The text says it explicitly: "Note that the size and number of TCP >segments is not guaranteed to map predictably to the size and number of >HTTP DATA or QUIC STREAM frames." From the client's perspective there is >only one PMTU that is relevant -- the one to the proxy. The proxy will keep >tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP >segments accordingly. Right, that's how I was seeing it. >Trying to design a CONNECT-like method to proxy an entire QUIC connection >over a single QUIC stream would create HOLB for QUIC packets to and from >the proxy. Some sort of a partially reliable QUIC stream could help here. Both you and Mikkel have identified HOL as something that needs more thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is enough to make QUIC not QUIC". I've taken the view that it may be desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL avoidance as an optimisation rather than a requirement. Partial reliability (of streams, or of some new frame type) could help solve that puzzle. Now I think about it, a complimentary mitigation could be to reserve a set of tunnel-streams to provide some basic multiplexing. However, the complexity of that might not be worth it. >This proxying scheme would require an extension to CONNECT to open a >UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandate >that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it >would be a very good idea for such a proxy to add a new frame for providing >ICMP-like explicit PMTU feedback to the sender (why leave the sender >guessing and probing, if the PMTU is already known to the proxy?). This is good feedback. Thanks! Kind regards Lucas --000000000000363dda056fb0e673 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I think QUIC needs a= tunnel extension frame.

= On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies= forward
>data streams, not packets. Hence, MTU concept on a tunnel-stream i= s
>meaningless. The text says it explicitly: "Note that the size= and number of TCP
>segments is not guaranteed to map predictably to the size and numbe= r of
>HTTP DATA or QUIC STREAM frames." From the client's persp= ective there is
>only one PMTU that is relevant -- the one to the proxy. The proxy = will keep
>tracks of the PMTUs to the CONNECT endpoints itself and will genera= te TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC conn= ection
>over a single QUIC stream would create HOLB for QUIC packets to and= from
>the proxy. Some sort of a partially reliable QUIC stream could hel= p here.

Both you and Mikkel have identified HOL as something that needs more th= ought. Thanks. Mikkel's view is a little more extreme, to paraphrase &q= uot;HOL is enough to make QUIC not QUIC". I've taken the view that= it may be desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 = frames), so I view HOL avoidance as an optimisation rather than a requireme= nt. Partial reliability (of streams, or of some new frame type) could help = solve that puzzle. Now I think about it, a complimentary mitigation could b= e to reserve a set of tunnel-streams to provide some basic multiplexing. Ho= wever, the complexity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open = a
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would als= o mandate
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect th= at it
>would be a very good idea for such a proxy to add a new frame for p= roviding
>ICMP-like explicit PMTU feedback to the sender (why leave the sende= r
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas

--000000000000363dda056fb0e673-- From nobody Thu Jun 28 08:34:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FD3130DC8 for ; Thu, 28 Jun 2018 08:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 UjuhMBduwcJE for ; Thu, 28 Jun 2018 08:34:07 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 102C1130DC7 for ; Thu, 28 Jun 2018 08:34:07 -0700 (PDT) Received: from [10.237.55.4] (unknown [85.255.236.63]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A2E4B1B00281; Thu, 28 Jun 2018 15:40:33 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-D382A5B5-6B62-4A0B-B9A7-2E87E920C506 Mime-Version: 1.0 (1.0) Subject: Re: Treatment of ICMP for PMTU From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Thu, 28 Jun 2018 16:40:27 +0200 Cc: Lucas Pardue , IETF QUIC WG , Martin Duke , "Lubashev, Igor" Content-Transfer-Encoding: 7bit Message-Id: <71164BBA-551D-4281-9E46-B4759401351E@erg.abdn.ac.uk> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 15:34:11 -0000 --Apple-Mail-D382A5B5-6B62-4A0B-B9A7-2E87E920C506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 28 Jun 2018, at 12:07, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >=20 > I think QUIC needs a tunnel extension frame. >=20 >> On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:= >>=20 >> Igor Lubashev wrote:=20 >>=20 >> >I think I see what you are talking about.=20 >> >=20 >> >At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forw= ard=20 >> >data streams, not packets. Hence, MTU concept on a tunnel-stream is=20 >> >meaningless. The text says it explicitly: "Note that the size and number= of TCP=20 >> >segments is not guaranteed to map predictably to the size and number of=20= >> >HTTP DATA or QUIC STREAM frames." =46rom the client's perspective there i= s=20 >> >only one PMTU that is relevant -- the one to the proxy. The proxy will k= eep=20 >> >tracks of the PMTUs to the CONNECT endpoints itself and will generate TC= P=20 >> >segments accordingly.=20 >>=20 >> Right, that's how I was seeing it.=20 >>=20 >> >Trying to design a CONNECT-like method to proxy an entire QUIC connectio= n=20 >> >over a single QUIC stream would create HOLB for QUIC packets to and from= =20 >> >the proxy. Some sort of a partially reliable QUIC stream could help here= .=20 >>=20 >> Both you and Mikkel have identified HOL as something that needs more thou= ght. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is e= nough to make QUIC not QUIC". I've taken the view that it may be desirable t= o tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL a= voidance as an optimisation rather than a requirement. Partial reliability (= of streams, or of some new frame type) could help solve that puzzle. Now I t= hink about it, a complimentary mitigation could be to reserve a set of tunne= l-streams to provide some basic multiplexing. However, the complexity of tha= t might not be worth it.=20 >>=20 >> >This proxying scheme would require an extension to CONNECT to open a=20 >> >UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mand= ate=20 >> >that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it=20= >> >would be a very good idea for such a proxy to add a new frame for provid= ing=20 >> >ICMP-like explicit PMTU feedback to the sender (why leave the sender=20 >> >guessing and probing, if the PMTU is already known to the proxy?).=20 >>=20 >> This is good feedback. Thanks!=20 >>=20 >> Kind regards=20 >> Lucas=20 >>=20 And when you say: =E2=80=9C for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PM= TU up to 1280.=E2=80=9D =20 - I agree the values could be trusted. - what then also happens when PTB message indicated less than 1280, does the= sender close the connection? Or ignore the message and wait to see if there= is a timeout? Gorry=20 --Apple-Mail-D382A5B5-6B62-4A0B-B9A7-2E87E920C506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 28 Ju= n 2018, at 12:07, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

Hi Lucas,

 

How is this different from PMTUD in IP-in-IP case?  The endpoint computes and caches PMTU per endpoint.  PMTU for connections to proxy is kept separately from PMTUs for connections to endpoints that go via the proxy.

 

The proxy itself can learn PMTU between itself and the endpoints, subtract the overhead, and send ICMP to the sender of the proxied QUIC flow.

 

I see the common case of QUIC implementation not being able to make use of ICMP is when QUIC is implemented in userspace on a platform that does not expose ICMP to the application.  QUIC’s desire to receive ICMP will likely cause vendors of such platforms to add the missing functionality.

It's quite hard to insure that icmp emitted by on path devices to the same anycast or load balanced destination. you're far better off with the inband 4821 style signal.

 

  • Igor

 

 

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

 

Hi Igor,

 

If we consider tunnelling of QUIC within QUIC by means of a proxy (not currently specced anywhere but feasible), the tunnelled (end-to-end) path MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be possible for the proxies to pass on ICMP in a way that the the tunnelled QUIC implementation can access it. (D)PLPMTUD seems to fit this case nicely as there can be two or more PLPMTUD contexts/values (one for the connection to the proxy, one for each tunnel within this connection).

 

Lucas

From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=40akamai.com@dmarc.ietf.org]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU

I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-drafts/pull/1412).

Many thanks to those who gave me ample feedback (both substantive and editorial).  I’ve tried to incorporate it all.

 

There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group.

 

  1. Is processing ICMP signals (and, especially, ICMP Packet Too Big signal) a MAY or a SHOULD?

 

In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC4821) is a SHOULD.

However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD process. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself is a SHOULD.

QUIC implementations w/o access to ICMP would not be able to implement the ICMP part, and this is ok albeit unfortunate; and this also points to SHOULD (skipping on MAY is not "unfortunate").

 

 

  1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)?

 

There are three main options: ignore it, reduce your PMTU estimate, do not reduce but send PLPMTUD probes.  Since this is very likely a valid signal, I do not like to ignore in the common case.

 

Hence, the proposal is to allow an immediate PMTU reduction to up to some M, where 1280 ≤ M ≤ 1500.  Once the reduction takes place, the endpoint can use PLPMTUD recommendations to see if it can probe a larger PMTU.  If this sounds reasonable, then the question is picking M.  I picked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels).  If the requested reduction is 1280 ≤ X < M, then the recommendation is not to reduce but send PLPMTUD probes.  Does this make sense, or should we have M=1280 and simplify things?

 

Note: for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280.  It is hard to forge these, and the benefit of the effort for the attacker is minimal (slightly lower efficiency of the transport).  So it is less likely that we’ll see forged ICMP w/ on-path proof.

 

 

Any feedback is very welcome.

 

  • Igor

 


--------------2F55367C3042C1D9F2821398-- From nobody Thu Jun 28 11:32:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A19131026 for ; Thu, 28 Jun 2018 11:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 oH4tq_V_vlCC for ; Thu, 28 Jun 2018 11:32:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 72DDE130E03 for ; Thu, 28 Jun 2018 11:32:31 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5SIQM1f019484; Thu, 28 Jun 2018 19:31:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=qr7+1+XrUjJfuT7WJz21tkuR3Oact0aqSbZEoe00J2Q=; b=SKSwUAS4yhSv8mnT70zehUG9f70IxyjpFyh7ahrix8lExbl9qXtF9NTWI6c7sHItZO3N dGVoTe2M9/LQMV6Nh3wCXGFPmjtDkqBCt6MTA9Z5NKni4au1lcYdpAVHsDPvmu7HK8EG 2y+apqTzawMJ8pHXDd7WJDUgQ2NAGp1NOjdFliXuZBtgiv2wAaUfEcizORy+hW/acDNu 42qPl8TQUYedvviUyAWJuR8vbdad14z0tnaBd3lCOB/a7eBK+rFeMf7j+HYXSx8DaZZM LcKjn0wKqrzhnP7XYyljRdZK7zuSZPVusTKmIfu74+zwla4Lzxhfk0kyYps4jmaY8mqF Ng== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jvk1kjx99-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 19:31:34 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5SIV7ih001520; Thu, 28 Jun 2018 14:31:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ju9bvtv60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 14:31:33 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 28 Jun 2018 13:31:32 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Thu, 28 Jun 2018 13:31:32 -0500 From: "Lubashev, Igor" To: "mikkelfj@gmail.com" , "gorry@erg.abdn.ac.uk" CC: "quic@ietf.org" , "lucas.pardue@bbc.co.uk" , "martin.h.duke@gmail.com" Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAJFrAwAAfLncAADHqsgAAJiIOA///svv4= Date: Thu, 28 Jun 2018 18:31:31 +0000 Message-ID: References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012> , <71164BBA-551D-4281-9E46-B4759401351E@erg.abdn.ac.uk> In-Reply-To: <71164BBA-551D-4281-9E46-B4759401351E@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_f40cfa3f20c84ffba8faa6b2c36fb71eustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=799 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280207 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=720 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280206 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 18:32:35 -0000 --_000_f40cfa3f20c84ffba8faa6b2c36fb71eustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the PR, I say to ignore the signal, if it comes after the handshake. I d= o not want an effective way for a man-on-a-side to DoS connections in progr= ess. When this happens during handshake, there is a much more nuanced decision. = Basically, sever ignores such signals. However, client abandons this server= or QUIC entirely, if it has an alternative server IP to try or protocol to= fall over to. This is because a man-on-a-side attacker interested in dispu= ting QUIC handshake could already do it via spoofed version negotiation pac= kets. - Igor -----Original Message----- From: Gorry (erg) [gorry@erg.abdn.ac.uk] Received: Thursday, 28 Jun 2018, 10:41AM To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com] CC: Lucas Pardue [lucas.pardue@bbc.co.uk]; IETF QUIC WG [quic@ietf.org]; Ma= rtin Duke [martin.h.duke@gmail.com]; Lubashev, Igor [ilubashe@akamai.com] Subject: Re: Treatment of ICMP for PMTU On 28 Jun 2018, at 12:07, Mikkel Fahn=F8e J=F8rgensen > wrote: I think QUIC needs a tunnel extension frame. On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Igor Lubashev wrote: >I think I see what you are talking about. > >At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forwar= d >data streams, not packets. Hence, MTU concept on a tunnel-stream is >meaningless. The text says it explicitly: "Note that the size and number o= f TCP >segments is not guaranteed to map predictably to the size and number of >HTTP DATA or QUIC STREAM frames." From the client's perspective there is >only one PMTU that is relevant -- the one to the proxy. The proxy will kee= p >tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP >segments accordingly. Right, that's how I was seeing it. >Trying to design a CONNECT-like method to proxy an entire QUIC connection >over a single QUIC stream would create HOLB for QUIC packets to and from >the proxy. Some sort of a partially reliable QUIC stream could help here. Both you and Mikkel have identified HOL as something that needs more though= t. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is en= ough to make QUIC not QUIC". I've taken the view that it may be desirable t= o tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL= avoidance as an optimisation rather than a requirement. Partial reliabilit= y (of streams, or of some new frame type) could help solve that puzzle. Now= I think about it, a complimentary mitigation could be to reserve a set of = tunnel-streams to provide some basic multiplexing. However, the complexity = of that might not be worth it. >This proxying scheme would require an extension to CONNECT to open a >UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandat= e >that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it >would be a very good idea for such a proxy to add a new frame for providin= g >ICMP-like explicit PMTU feedback to the sender (why leave the sender >guessing and probing, if the PMTU is already known to the proxy?). This is good feedback. Thanks! Kind regards Lucas And when you say: " for ICMP w/ on-path proof, I think it makes sense to allow a reduction in P= MTU up to 1280." - I agree the values could be trusted. - what then also happens when PTB message indicated less than 1280, does th= e sender close the connection? Or ignore the message and wait to see if the= re is a timeout? Gorry --_000_f40cfa3f20c84ffba8faa6b2c36fb71eustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the PR, I say to ignore the signal, if it comes after t= he handshake. I do not want an effective way for a man-on-a-side to DoS con= nections in progress.

When this happens during handshake, there is a much more nuanced decision. = Basically, sever ignores such signals. However, client abandons this server= or QUIC entirely, if it has an alternative server IP to try or protocol to= fall over to. This is because a man-on-a-side attacker interested in disputing QUIC handshake could alread= y do it via spoofed version negotiation packets.

- Igor

-----Original Message-----
From: Gorry (erg) [gorry@erg.abdn.ac.uk]
Received: Thursday, 28 Jun 2018, 10:41AM
To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]
CC: Lucas Pardue [lucas.pardue@bbc.co.uk]; IETF QUIC WG [quic@ietf.o= rg]; Martin Duke [martin.h.duke@gmail.com]; Lubashev, Igor [ilubashe@akamai= .com]
Subject: Re: Treatment of ICMP for PMTU


On 28 Jun 2018, at 12:07, Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com> wrote:

I think QUIC needs a tunnel extension frame.

On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies for= ward
>data streams, not packets. Hence, MTU concept on a tunnel-stream is >meaningless. The text says it explicitly: "Note that the size and = number of TCP
>segments is not guaranteed to map predictably to the size and number of=
>HTTP DATA or QUIC STREAM frames." From the client's perspective th= ere is
>only one PMTU that is relevant -- the one to the proxy. The proxy will = keep
>tracks of the PMTUs to the CONNECT endpoints itself and will generate T= CP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connecti= on
>over a single QUIC stream would create HOLB for QUIC packets to and fro= m
>the proxy. Some sort of a partially reliable QUIC stream could help her= e.

Both you and Mikkel have identified HOL as something that needs more though= t. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL = is enough to make QUIC not QUIC". I've taken the view that it may be d= esirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL avoidance as an optimisation rather th= an a requirement. Partial reliability (of streams, or of some new frame typ= e) could help solve that puzzle. Now I think about it, a complimentary miti= gation could be to reserve a set of tunnel-streams to provide some basic multiplexing. However, the complex= ity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a >UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also man= date
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it=
>would be a very good idea for such a proxy to add a new frame for provi= ding
>ICMP-like explicit PMTU feedback to the sender (why leave the sender >guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas


And when you say:
“
for ICMP w/ on-path proof, I think it makes sense to = allow a reduction in PMTU up to 1280.”  
- I agree the values could be trusted.
- what then also happens when PTB message indicated l= ess than 1280, does the sender close the connection? Or ignore the message = and wait to see if there is a timeout?

Gorry 

--_000_f40cfa3f20c84ffba8faa6b2c36fb71eustx2exdag1mb5msgcorpak_-- From nobody Thu Jun 28 11:50:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C7E13102B for ; Thu, 28 Jun 2018 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 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, HTTPS_HTTP_MISMATCH=1.989, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 v89Kid97otiO for ; Thu, 28 Jun 2018 11:50:07 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 65F18130E01 for ; Thu, 28 Jun 2018 11:50:07 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5SIlHkc010247; Thu, 28 Jun 2018 19:50:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Hsmhfv6KB0WSjAxdJUekPVX2VkOYw0JETt6jA/HWPTQ=; b=jP4aTznspxO9gR374LolZGdwco3XN2Ju/jb/cVnDoAWXRqjC82nIhFH92k+fT8V1PrAK 1x4WvPmZdTgaltMSXK/Gi0QSbNenHPEi0aT4RY5DuKGTxWy0Ea1Qs+AOcgC94ibkvv+i cBcpIvWWh+ygVgRQaHyt3Xrua6BwipDXre8U5kaN77w2PZmyk+JfZ+SYwc2VRhB6F2wA slgNYCAo0S6h7SPwMKgaCYe2QLWkVyGWsCQg1jPfNLt/Im/VmHyLZ/CjJN68geFYUe7g /x78Rn8KvGYSYtgl4V1Fgt8p9wQ70x6CAxDuKE4zi47UX4Tb4kpKnm3xWI3tr5MmKNdI AQ== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jvk1j2rbn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 19:50:00 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5SIkGme004279; Thu, 28 Jun 2018 14:49:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bvtx5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 14:49:59 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 28 Jun 2018 13:49:58 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Thu, 28 Jun 2018 13:49:58 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "joelja@bogus.com" , "Lucas.Pardue@bbc.co.uk" , "martin.h.duke@gmail.com" Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AAMCDUgP//zWhR Date: Thu, 28 Jun 2018 18:49:58 +0000 Message-ID: References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_abd319b50271456ab712e26eec85d726ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=940 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=861 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280210 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 18:50:11 -0000 --_000_abd319b50271456ab712e26eec85d726ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > It's quite hard to insure that icmp emitted by on path devices to the sam= e anycast or load balanced destination. you're far better off with the inba= nd 4821 style signal. You are 100% right about cases when CID is used for routing, such as load b= alancing. (I do want to point out that 4821 and ICMP are not alternatives. = They are complimentary.) Once we land this "how to use ICMP signals", I will do a PR on "how to impl= ement 4821 to elicit useful ICMP for cases that require server CID for rout= ing". - Igor -----Original Message----- From: joel jaeggli [joelja@bogus.com] Received: Thursday, 28 Jun 2018, 12:51PM To: Lubashev, Igor [ilubashe@akamai.com]; Lucas Pardue [Lucas.Pardue@bbc.co= .uk]; Martin Duke [martin.h.duke@gmail.com]; IETF QUIC WG [quic@ietf.org] Subject: Re: Treatment of ICMP for PMTU On 6/27/18 4:09 PM, Lubashev, Igor wrote: Hi Lucas, How is this different from PMTUD in IP-in-IP case? The endpoint computes a= nd caches PMTU per endpoint. PMTU for connections to proxy is kept separat= ely from PMTUs for connections to endpoints that go via the proxy. The proxy itself can learn PMTU between itself and the endpoints, subtract = the overhead, and send ICMP to the sender of the proxied QUIC flow. I see the common case of QUIC implementation not being able to make use of = ICMP is when QUIC is implemented in userspace on a platform that does not e= xpose ICMP to the application. QUIC's desire to receive ICMP will likely c= ause vendors of such platforms to add the missing functionality. It's quite hard to insure that icmp emitted by on path devices to the same = anycast or load balanced destination. you're far better off with the inband= 4821 style signal. * Igor From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] Sent: Wednesday, June 27, 2018 5:27 PM To: Lubashev, Igor ; Marti= n Duke ; IETF QUIC= WG Subject: RE: Treatment of ICMP for PMTU Hi Igor, If we consider tunnelling of QUIC within QUIC by means of a proxy (not curr= ently specced anywhere but feasible), the tunnelled (end-to-end) path MTU i= s likely to be smaller than the hop-by-hop path MTUs. It may not be possibl= e for the proxies to pass on ICMP in a way that the the tunnelled QUIC impl= ementation can access it. (D)PLPMTUD seems to fit this case nicely as there= can be two or more PLPMTUD contexts/values (one for the connection to the = proxy, one for each tunnel within this connection). Lucas ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf = of Lubashev, Igor [ilubashe=3D40akamai.com@dmarc.ietf.org] Sent: 27 June 2018 21:36 To: Martin Duke; IETF QUIC WG Subject: Treatment of ICMP for PMTU I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-= drafts/pull/1412). Many thanks to those who gave me ample feedback (both substantive and edito= rial). I've tried to incorporate it all. There are two technical issues that @Martin Duke and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big sign= al) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC482= 1) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD proce= ss. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself i= s a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the = ICMP part, and this is ok albeit unfortunate; and this also points to SHOUL= D (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU redu= ction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not = reduce but send PLPMTUD probes. Since this is very likely a valid signal, = I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M= , where 1280 ? M ? 1500. Once the reduction takes place, the endpoint can = use PLPMTUD recommendations to see if it can probe a larger PMTU. If this = sounds reasonable, then the question is picking M. I picked 1392 rather ar= bitrarily (GRE over IPsec + a few MPLS labels). If the requested reduction= is 1280 ? X < M, then the recommendation is not to reduce but send PLPMTUD= probes. Does this make sense, or should we have M=3D1280 and simplify thi= ngs? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reductio= n in PMTU up to 1280. It is hard to forge these, and the benefit of the ef= fort for the attacker is minimal (slightly lower efficiency of the transpor= t). So it is less likely that we'll see forged ICMP w/ on-path proof. Any feedback is very welcome. * Igor --_000_abd319b50271456ab712e26eec85d726ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > It's quite hard to insure that icmp emitted by on pat= h devices to the same anycast or load balanced destination. you're far bett= er off with the inband 4821 style signal.

You are 100% right about cases when CID is used for routing, such as load b= alancing. (I do want to point out that 4821 and ICMP are not alternatives. = They are complimentary.)

Once we land this "how to use ICMP signals", I will do a PR on &q= uot;how to implement 4821 to elicit useful ICMP for cases that require serv= er CID for routing".

- Igor

-----Original Message-----
From: joel jaeggli [joelja@bogus.com]
Received: Thursday, 28 Jun 2018, 12:51PM
To: Lubashev, Igor [ilubashe@akamai.com]; Lucas Pardue [Lucas.Pardue= @bbc.co.uk]; Martin Duke [martin.h.duke@gmail.com]; IETF QUIC WG [quic@ietf= .org]
Subject: Re: Treatment of ICMP for PMTU



On 6/27/18 4:09 PM, Lubashev, Igor wrote:

Hi Lucas,

 

How is this different from PMTUD in= IP-in-IP case?  The endpoint computes and caches PMTU per endpoint.&n= bsp; PMTU for connections to proxy is kept separately from PMTUs for connec= tions to endpoints that go via the proxy.

 

The proxy itself can learn PMTU bet= ween itself and the endpoints, subtract the overhead, and send ICMP to the = sender of the proxied QUIC flow.

 

I see the common case of QUIC imple= mentation not being able to make use of ICMP is when QUIC is implemented in= userspace on a platform that does not expose ICMP to the application. = ; QUIC’s desire to receive ICMP will likely cause vendors of such platforms to add the missing functionality.

It's quite hard to insure that icmp emitted by on path devices to the same = anycast or load balanced destination. you're far better off with the inband= 4821 style signal.

 

  • I= gor

 

 

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co= .uk]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

 

Hi Igor,

 

If we consider tunnelling of QUIC with= in QUIC by means of a proxy (not currently specced anywhere but feasible), = the tunnelled (end-to-end) path MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be possible for th= e proxies to pass on ICMP in a way that the the tunnelled QUIC implementati= on can access it. (D)PLPMTUD seems to fit this case nicely as there can be = two or more PLPMTUD contexts/values (one for the connection to the proxy, one for each tunnel within this conn= ection).

 

Lucas

From= : QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=3D40akamai.com@dma= rc.ietf.org]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU

I have a PR for treatmen= t of ICMP for PMTU (https://github.= com/quicwg/base-drafts/pull/1412).

Many thanks to those who= gave me ample feedback (both substantive and editorial).  I’ve = tried to incorporate it all.

 

There are two technical = issues that @Martin Duke and I believe deserve a broader discussion wi= th the group.

 

  1. Is processing ICMP signals (a= nd, especially, ICMP Packet Too Big signal) a MAY or a SHOULD?

 

In the WG draft, process= ing ICMP is a MAY, but implementing PLPMTUD (RFC4821) is a SHOULD.

However, PLPMTUD claims = itself to be an extension of ICMP-based PMTUD process. So it makes sense to= me that if PLPMTUD is a SHOULD, then ICMP itself is a SHOULD.

QUIC implementations w/o= access to ICMP would not be able to implement the ICMP part, and this is o= k albeit unfortunate; and this also points to SHOULD (skipping on MAY is no= t "unfortunate").

 

 

  1. What to do, when an IPv4 ICMP= (w/o on-path proof) request a PMTU reduction (after handshake)?

 

There are three main opt= ions: ignore it, reduce your PMTU estimate, do not reduce but send PLPMTUD = probes.  Since this is very likely a valid signal, I do not like to ig= nore in the common case.

 

Hence, the proposal is t= o allow an immediate PMTU reduction to up to some M, where 1280 ≤ M &= #8804; 1500.  Once the reduction takes place, the endpoint can use PLP= MTUD recommendations to see if it can probe a larger PMTU.  If this sounds reasonable, then the question is picking M.&nbs= p; I picked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels= ).  If the requested reduction is 1280 ≤ X < M, then the reco= mmendation is not to reduce but send PLPMTUD probes.  Does this make sense, or should we have M=3D1280 and simplify things?

 

Note: for ICMP w/ on-pat= h proof, I think it makes sense to allow a reduction in PMTU up to 1280.&nb= sp; It is hard to forge these, and the benefit of the effort for the attack= er is minimal (slightly lower efficiency of the transport).  So it is less likely that we’ll see forged = ICMP w/ on-path proof.

 

 

Any feedback is very wel= come.

 

  • Igor

 


--_000_abd319b50271456ab712e26eec85d726ustx2exdag1mb5msgcorpak_-- From nobody Thu Jun 28 17:31:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B78130E42 for ; Thu, 28 Jun 2018 17:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 eLz82M6b73bD for ; Thu, 28 Jun 2018 17:31:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 3ED08130E40 for ; Thu, 28 Jun 2018 17:31:02 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5T0RMXv011243; Fri, 29 Jun 2018 01:31:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QFQgGtNyAD47qYHoJGGtJ7ruVhxZRfO99k0JO6ZL78w=; b=UvIM0INDZ8YbkOmHX5uYsUo+BnDsfMoyoSKd8FSZCOCg5mpjNFCWnJxG+gwr9QhPLwak Lm/6PnkX+cu5k4AfSaEnChLmr5JXyQXOvW4iLXpxKqhssdfrg7mw4JsR0m10AD7BjwjC /HV7Oa+yKB1BTNCzzM2lfVwWzUGYMAVPl2bvvO5C9dqg59x9tdaE9Fh6XBkz11BVLQpi 3y9+Yjs49udQNt9uTJHnX7hU0q+XH/5jFqBr/QpVJZSWJ/xBdorvU6M59e+uf+zQVadq NOadfBwBRpCpJDR9e5ChIz7IYThgX3Q1wuoyQtBr3O+Opg5WP/f1Q1ToySckkr/IZcEt OA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2jvk1kkqy3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jun 2018 01:30:59 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5T0LtJk030397; Thu, 28 Jun 2018 20:30:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ju9buh7d7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 20:30:58 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 28 Jun 2018 17:30:57 -0700 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Thu, 28 Jun 2018 19:30:57 -0500 From: "Lubashev, Igor" To: "Eggert, Lars" CC: Martin Duke , IETF QUIC WG Subject: RE: Treatment of ICMP for PMTU Thread-Topic: Treatment of ICMP for PMTU Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wAV77aAAAI9IOA= Date: Fri, 29 Jun 2018 00:30:57 +0000 Message-ID: <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> In-Reply-To: <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=526 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806290002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=442 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806290003 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:31:05 -0000 VGhhbmtzLCBMYXJzIQ0KDQpSRkM0ODIxIGNsYWltcyB0aGF0ICJJdCBpcyBtb3N0IGVmZmljaWVu dCB3aGVuIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgSUNNUC1iYXNlZCBQYXRoIE1UVSBE aXNjb3ZlcnkgbWVjaGFuaXNtIGFzIHNwZWNpZmllZCBpbiBSRkMgMTE5MSBhbmQgUkZDIDE5ODEs IFsuLl0iLiAgU2luY2Ugd2UgdmVyeSBoaWdobHkgcmVjb21tZW5kIGltcGxlbWVudGluZyA0ODIx LCB3ZSBzaG91bGQgYWxzbyByZWNvbW1lbmQgaW1wbGVtZW50aW5nIDQ4MjEgZWZmaWNpZW50bHku ICAoUkZDNDgyMSB0aGVuIGNvbnRpbnVlcyB0byBzYXkgdGhhdCBpdCByZXNvbHZlcyBhIHByb2Js ZW0gb2YgSUNNUCBibG9ja2FnZSwgc2luY2UgaXQgZG9lcyBub3QgcmVxdWlyZSBJQ01QIGZvciB3 b3JraW5nLikNCg0KPj4gIOKAoiBXaGF0IHRvIGRvLCB3aGVuIGFuIElQdjQgSUNNUCAody9vIG9u LXBhdGggcHJvb2YpIHJlcXVlc3QgYSBQTVRVIHJlZHVjdGlvbiAoYWZ0ZXIgaGFuZHNoYWtlKT8N Cj4NCj4gSXNuJ3QgdGhpcyBzdWZmaWNpZW50bHkgY292ZXJlZCBpbiA0ODIxPw0KDQpOb3QgcmVh bGx5LiAgT3IsIGF0IGxlYXN0IEkgY291bGQgbm90IGZpbmQgYW55dGhpbmcgbW9yZSB1c2VmdWwg dGhlcmUgdGhlbjogIklmIGFuIElDTVAgUFRCIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgbWF0Y2hpbmcg dGhlIHByb2JlIHBhY2tldCwgdGhlbiBzZWFyY2hfaGlnaCBhbmQgZWZmX3BtdHUgTUFZIGJlIHNl dCBmcm9tIHRoZSBNVFUgdmFsdWUgaW5kaWNhdGVkIGluIHRoZSBtZXNzYWdlLiIgIFNvIDQ4MjEg c2VlbXMgc2lsZW50IG9uIHdoYXQgdG8gZG8gaWYgSUNNUCBpcyByZWNlaXZlZCBmb3IgYSBub24t cHJvYmUgcGFja2V0LCBhbmQgaXQgc2VlbXMgc2lsZW50IG9uIGhvdyBvbmUgY291bGQgZGVjaWRl IHdoZXRoZXIgdG8gc2V0IHNlYXJjaF9oaWdoIGFuZCBlZmZfcG10dSBmcm9tIHRoZSBNVFUgaW4g SUNNUCBvciBub3QgKHNheWluZyAiTUFZIiBkb2VzIG5vdCByZWFsbHkgaGVscCBoZXJlKS4gIFRo ZXNlIHF1ZXN0aW9ucyBhcmUgd2hhdCBJIGFtIHRyeWluZyB0byBhZGRyZXNzIGZvciBRVUlDLg0K DQo0ODIxIHVzZXMgTUFZIGluIHRoZSBzZW50ZW5jZSBhYm92ZSwgc2luY2UgaXQgZG9lcyBub3Qg cmVhbGx5IGdpdmUgYW55IGJldHRlciBpbmRpY2F0aW9uLiAgVGhpcyBQUiBkcmF3cyBhIGRpc3Rp bmN0aW9uIGJldHdlZW4gSUNNUCB3LyBhbmQgdy9vIG9uLXBhdGggcHJvb2YgYW5kIGluIHNvbWUg c3BlY2lmaWMgY2FzZXMsIGl0IHJlY29tbWVuZHMgYSBTSE9VTEQuDQoNCi0gSWdvcg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFZ2dlcnQsIExhcnMgW21haWx0bzpsYXJz QG5ldGFwcC5jb21dIA0KU2VudDogVGh1cnNkYXksIEp1bmUgMjgsIDIwMTggMzowMyBBTQ0KVG86 IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IE1hcnRpbiBEdWtlIDxt YXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBUcmVhdG1lbnQgb2YgSUNNUCBmb3IgUE1UVQ0KDQpIaSwNCg0KT24gMjAxOC02 LTI3LCBhdCAyMjozNiwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlPTQwYWthbWFpLmNvbUBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6DQo+IAnigKIgSXMgcHJvY2Vzc2luZyBJQ01QIHNpZ25hbHMgKGFu ZCwgZXNwZWNpYWxseSwgSUNNUCBQYWNrZXQgVG9vIEJpZyBzaWduYWwpIGEgTUFZIG9yIGEgU0hP VUxEPw0KPiANCj4gSW4gdGhlIFdHIGRyYWZ0LCBwcm9jZXNzaW5nIElDTVAgaXMgYSBNQVksIGJ1 dCBpbXBsZW1lbnRpbmcgUExQTVRVRCAoUkZDNDgyMSkgaXMgYSBTSE9VTEQuDQo+IEhvd2V2ZXIs IFBMUE1UVUQgY2xhaW1zIGl0c2VsZiB0byBiZSBhbiBleHRlbnNpb24gb2YgSUNNUC1iYXNlZCBQ TVRVRCBwcm9jZXNzLiBTbyBpdCBtYWtlcyBzZW5zZSB0byBtZSB0aGF0IGlmIFBMUE1UVUQgaXMg YSBTSE9VTEQsIHRoZW4gSUNNUCBpdHNlbGYgaXMgYSBTSE9VTEQuDQo+IFFVSUMgaW1wbGVtZW50 YXRpb25zIHcvbyBhY2Nlc3MgdG8gSUNNUCB3b3VsZCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQg dGhlIElDTVAgcGFydCwgYW5kIHRoaXMgaXMgb2sgYWxiZWl0IHVuZm9ydHVuYXRlOyBhbmQgdGhp cyBhbHNvIHBvaW50cyB0byBTSE9VTEQgKHNraXBwaW5nIG9uIE1BWSBpcyBub3QgInVuZm9ydHVu YXRlIikuDQoNCjQ4MjEgaXMgYW4gZXh0ZW5zaW9uIG9mIDExOTEvMTk4MSBpbiB0aGUgc2Vuc2Ug dGhhdCBpdCBwcm92aWRlcyBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkgaW4gYW4gSW50ZXJuZXQgd2hl cmUgSUNNUCBkZWxpdmVyeSBpcyB1bnJlbGlhYmxlIC0gaS5lLiwgdGhlIG9ubHkgSW50ZXJuZXQg d2UgaGF2ZS4gQmVjYXVzZSA0ODIxIHdvcmtzIHdpdGhvdXQgYW55IElDTVAgZGVsaXZlcnkgKGl0 cyBjb252ZXJnZW5jZSBpcyBpbXByb3ZlZCBieSBpdCwgYnV0IHRoYXQgaXMgYW4gb3B0aW1pemF0 aW9uKSwgdGhlIHR3byBuZWVkIG5vdCBiZSBhdCB0aGUgc2FtZSByZXF1aXJlbWVudHMgbGV2ZWwu DQoNCkFzIGFuIGluZGl2aWR1YWwsIEknZCBhcmd1ZSB0aGF0IDQ4MjEgbXVzdCBiZSBhIFNIT1VM RCAoYW5kIGFjdHVhbGx5IHNob3VsZCBiZSBhIE1VU1QsIGV4Y2VwdCB0aGF0IHdlIHByb2JhYmx5 IHdhbnQgdG8gYWxsb3cgZm9yIGluZWZmaWNpZW50IHN0YWNrcyB0aGF0IHNlbmQgZml4ZWQtc2l6 ZWQgc21hbGwgcGFja2V0cykuDQoNCkdpdmVuIHRoZSBjdXJyZW50IHN0YXRlIG9mIElDTVAgYmxv Y2thZ2UsIEkgZG9uJ3QgcmVhbGx5IGNhcmUgd2hhdCB3ZSBzYXkgYWJvdXQgMTE5MS8xOTgxLiBB IE1BWSBpcyBmaW5lOyBhIFNIT1VMRCBzZWVtcyBvdmVya2lsbCBnaXZlbiB0aGUgdW5yZWxpYWJp bGl0eSBvZiBJQ01QLCBidXQgSSBjb3VsZCBsaXZlIHdpdGggaXQuDQoNCj4gIAnigKIgV2hhdCB0 byBkbywgd2hlbiBhbiBJUHY0IElDTVAgKHcvbyBvbi1wYXRoIHByb29mKSByZXF1ZXN0IGEgUE1U VSByZWR1Y3Rpb24gKGFmdGVyIGhhbmRzaGFrZSk/DQoNCklzbid0IHRoaXMgc3VmZmljaWVudGx5 IGNvdmVyZWQgaW4gNDgyMT8NCg0KTGFycw0KDQpQUzogQ2hhaXIgaGF0IG9mZi4NCg== From nobody Fri Jun 29 17:01:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC96B130F30 for ; Fri, 29 Jun 2018 17:01:19 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 pUa5-XDP_j0f for ; Fri, 29 Jun 2018 17:01:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 EB93E130F28 for ; Fri, 29 Jun 2018 17:01:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5TNxrhq018428; Sat, 30 Jun 2018 01:01:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Ljw8hx7W5Zw1JDxSWmeq0hghY4dh9rQtNjd49mMyKcg=; b=Bzd3DPiP3qw/jbGsP9QjPKTVdIQWTYOzlN6bIxxhGs+mAajdDKDoPOaRUth+v7nvXTc4 hJgBqt3V8J10pMSPfyQIfib9zustmCKIPZTgniEX0IamqadpF5kS2U+mio5xUT8G5xxn /3h7IwMRkMyJ+/wsZw/aqfmXFE1Xr4NWSm86wBWdWbC0Kt1klA83hVldj4cBzZBlrf6H o+UIxXMAuZng9QvCVgUMg3AZ1FFAN+qq7ZyImDttMvSqr2Rud4yk2iLoDeLlqeOsS2Og 5P/nsXT8G0yqZzvqCPeQG9akr5jLwRi5+VVsQ4cBF0645vMEHhoDR8D1XNKKPpHivoKX Yw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2jwxxdr037-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 01:01:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5U01DDx008971; Fri, 29 Jun 2018 20:01:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ju9bupg5m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 29 Jun 2018 20:01:13 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 19:00:59 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Fri, 29 Jun 2018 19:00:58 -0500 From: "Lubashev, Igor" To: IETF QUIC WG , Kazuho Oku Subject: Using Long Header packets for PMTUD probes Thread-Topic: Using Long Header packets for PMTUD probes Thread-Index: AdQP6f+k+GmPnfLgQ7evczPwCZupaw== Date: Sat, 30 Jun 2018 00:00:58 +0000 Message-ID: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.116] Content-Type: multipart/alternative; boundary="_000_178f3f4cc96e4f1ab90595fd2530c4b3ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806290257 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806290256 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 00:01:21 -0000 --_000_178f3f4cc96e4f1ab90595fd2530c4b3ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We talked briefly in Kista about the possibility of using Long Header packe= ts for PMTUD probes. See Issue 1243 (https://github.com/quicwg/base-drafts= /issues/1243) for context. Briefly, load balancers that use server CID nee= d that server CID to route ICMPv6 packets back to the server doing PMTUD. @'Kazuho Oku' suggested using the new packet co= alescing functionality by sending an invalid long-header packet and coalesc= ing it with a valid short-header packet. This would have to work, if one f= ollows the current spec strictly. This is definitely a hack, however. I would like to come up with something that is not a hack, does not require= sending deliberately invalid packets, but also not to complicate the desig= n with the need to care about key phase and whatever else one wants to put = in the short-header in the future. What do people think about a new "0x7B - PMTU Probe" long header packet typ= e? A packet of that type would just be a bare minimum long header packet per I= nvariants (nothing after source CID), and its only purpose would be to be c= oalesced with other QUIC packets. - Igor --_000_178f3f4cc96e4f1ab90595fd2530c4b3ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We talked briefly in Kista about the possibility of = using Long Header packets for PMTUD probes.  See Issue 1243 (https://github.com/q= uicwg/base-drafts/issues/1243) for context.  Briefly, load balancers that use server CID need that server CID to route = ICMPv6 packets back to the server doing PMTUD.

 

@'Kazuho Oku' suggested usi= ng the new packet coalescing functionality by sending an invalid long-header packet and coalescing it with a valid short-header = packet.  This would have to work, if one follows the current spec stri= ctly.  This is definitely a hack, however.

 

I would like to come up with something that is not a= hack, does not require sending deliberately invalid packets, but also not = to complicate the design with the need to care about key phase and whatever= else one wants to put in the short-header in the future.

 

What do people think about a new “0x7B –= PMTU Probe” long header packet type?

A packet of that type would just be a bare minimum l= ong header packet per Invariants (nothing after source CID), and its only p= urpose would be to be coalesced with other QUIC packets.

 

- Igor

--_000_178f3f4cc96e4f1ab90595fd2530c4b3ustx2exdag1mb5msgcorpak_-- From nobody Fri Jun 29 17:19:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0C130F04 for ; Fri, 29 Jun 2018 17:19: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JDFqGcbP5FYz for ; Fri, 29 Jun 2018 17:19:01 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 EDAAE130E3A for ; Fri, 29 Jun 2018 17:19:00 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fZ3bL-000ArR-9d for quic@ietf.org; Sat, 30 Jun 2018 02:18:59 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fZ3bF-0004lR-P2 for quic@ietf.org; Fri, 29 Jun 2018 20:18:53 -0400 Received: (qmail 23241 invoked from network); 30 Jun 2018 00:18:47 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.20]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jun 2018 00:18:47 -0000 To: "Lubashev, Igor" , IETF QUIC WG , Kazuho Oku References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> Date: Fri, 29 Jun 2018 14:18:45 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------0AB04FC47D87BE25A31689B2" Content-Language: en-US Subject: Re: Using Long Header packets for PMTUD probes X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sbSG6xNtsS/Z1O+2a0pPVR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVizKimEX9oVMGHCqvZW4NrT87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB4lampmfDNuiABFovtjnMdR/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX6N+2DyDXes8vYD17nJ00FHeioMhHH1DLeXNjlAUNl8Tr2jT+b4hVq dU2fIu8T8BVz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqz6Jnv65JqzoprPQQCAlAFYE7tCqypI5WX0qWh4YQLBWJ0db6xdiV2rN 3bQCepzNbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLUKQCrMv/Srp/VLqDjjh0L1QKHY 6H+wSCoVvwvquzDDiPkKIKnisj+1ZHYjRAh7nr2Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 00:19:03 -0000 This is a multi-part message in MIME format. --------------0AB04FC47D87BE25A31689B2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes.=A0 See Issue 1243 > (https://github.com/quicwg/base-drafts/issues/1243) for context.=A0 > Briefly, load balancers that use server CID need that server CID to > route ICMPv6 packets back to the server doing PMTUD. > > =A0 > > @'Kazuho Oku' suggested using the new > packet coalescing functionality by sending an invalid long-header > packet and coalescing it with a valid short-header packet.=A0 This woul= d > have to work, if one follows the current spec strictly.=A0 This is > definitely a hack, however. > > =A0 > > I would like to come up with something that is not a hack, does not > require sending deliberately invalid packets, but also not to > complicate the design with the need to care about key phase and > whatever else one wants to put in the short-header in the future. > > =A0 > > What do people think about a new =930x7B =96 PMTU Probe=94 long header > packet type? > > A packet of that type would just be a bare minimum long header packet > per Invariants (nothing after source CID), and its only purpose would > be to be coalesced with other QUIC packets. > My personal inclination is to just ignore ICMP, and thus not have to deal with related attacks. My limited experience so far is that active PMTU discovery succeeds after just a couple of probes. In any case, I would rather not have a specific "PMTU Probe" long header -- I would rather not disclose to middleboxes that the node is engaged in PMTUD. But I could see the point of a generic "1-RTT" long header. It could help make stateless reset work. And it could be sent proactively, say every few RTT, as a form of greasing. -- Christian Huitema --------------0AB04FC47D87BE25A31689B2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 6/29/2018 2:00 PM, Lubashev, Igor wrote:

We talked briefly in Kista about the possibility of using Long Header packets for PMTUD probes.  See Issue 1243 (https://github.com/quicwg/base-drafts/issues/1243) for context.  Briefly, load balancers that use server CID need that server CID to route ICMPv6 packets back to the server doing PMTUD.

 

@'Kazuho Oku' suggested using the new packet coalescing functionality by sending an invalid long-header packet and coalescing it with a valid short-header packet.  This would have to work, if one follows the current spec strictly.  This is definitely a hack, however.

 

I would like to come up with something that is not a hack, does not require sending deliberately invalid packets, but also not to complicate the design with the need to care about key phase and whatever else one wants to put in the short-header in the future.

 

What do people think about a new “0x7B – PMTU Probe” long header packet type?

A packet of that type would just be a bare minimum long header packet per Invariants (nothing after source CID), and its only purpose would be to be coalesced with other QUIC packets.


My personal inclination is to just ignore ICMP, and thus not have to deal with related attacks. My limited experience so far is that active PMTU discovery succeeds after just a couple of probes.

In any case, I would rather not have a specific "PMTU Probe" long header -- I would rather not disclose to middleboxes that the node is engaged in PMTUD. But I could see the point of a generic "1-RTT" long header. It could help make stateless reset work. And it could be sent proactively, say every few RTT, as a form of greasing.

-- Christian Huitema



--------------0AB04FC47D87BE25A31689B2-- From nobody Fri Jun 29 17:32:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AF6130F66 for ; Fri, 29 Jun 2018 17:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 1yj2z3Nzzmpl for ; Fri, 29 Jun 2018 17:32:54 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 4DC30130F41 for ; Fri, 29 Jun 2018 17:32:54 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id w13-v6so4420052ywa.5 for ; Fri, 29 Jun 2018 17:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CSVskNbFgaiq1Wj+VXfL/cf0APb+2G8DbuSkz9awWpI=; b=Trd8IUrdBqx6FJUCTRYU/CHwk1BieYOpimo6ArPHr6p0QYAjU6XVICe3RyisLZ5yJx 42Racgr/TwsoH5iuT3XWp5FzFxSRMIgJqiyB9LyDNJtw1S29UaAemWTFW2qVgv0JWdNk cB2oZ8UhnmvlKEKAFzJiCuH7Uz1xfHzjS4Lw/UppM31yHWiMpGfQsCkgEim6ju1JpTKW bGDIOAAivjRt9KwGbElfvmTDEEgIZ6XsQt03Wuoxk5S3vpAvkzsErIirNdaroOS5exdF g3ZDt/hNq9GFqtNJYBXbLH/2XJRv4s/5T1du2H+Qh8S2hYlxYaxK46YCKLIKW5OlIGW6 27GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CSVskNbFgaiq1Wj+VXfL/cf0APb+2G8DbuSkz9awWpI=; b=aDkLDdAaL2umza39cMbCakC0TVXNJp64jFO2GBMACJobOeuzJhQ04cdYrv3z9wOtjj UvazUef+YgffoiWID3am3NQRKnQu9QDBMLAUAHBBIbfKkU6KSccgFHvIY7mROZUcaDL0 LPyOhbrwU31VHHod4BkksDWtQGDSQ+ZNoyLJ8PsMpx/bOW+Duxb0hsSJ/PqBlKP6OdIN z77h68lBUbj+pbnIC+VgVkOR2i7kb9sApKkOr8+U5E4qMNsNQ+Q6B49ES4MS3rt/AZSg HUQLCfg5dPsqLcz10GLniXrijSe8yjXx7b/I7QFPezTVXZDZJRrSRxi2llEUkdGHUakB YKIQ== X-Gm-Message-State: APt69E3ArIKLPt2fZ95oRVZW0ok/qoNZbnXBX7ItQV0e/3/hdb8NMfBw Ku4tlrDkZNhISEiMEiywtQ5Uwug+Z5SZ7HbflAEn8kY3 X-Google-Smtp-Source: ADUXVKI1SUmcUrF29V+FzVQYGqN20a4RKFSYNB+YvycNJXUIJNK6oSWhmc1KI8NaLlWQBDnDCxTBVx7gP3W/KXRSzNk= X-Received: by 2002:a5b:c09:: with SMTP id f9-v6mr8672712ybq.107.1530318773108; Fri, 29 Jun 2018 17:32:53 -0700 (PDT) MIME-Version: 1.0 References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> In-Reply-To: <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> From: Ian Swett Date: Fri, 29 Jun 2018 20:32:29 -0400 Message-ID: Subject: Re: Using Long Header packets for PMTUD probes To: Christian Huitema Cc: ilubashe=40akamai.com@dmarc.ietf.org, IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000de1670056fd11a20" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 00:32:58 -0000 --000000000000de1670056fd11a20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suggest using a RETRY packet with a 0 byte token length and DCIL. Which is basically an invariant header and nothing else. Technically it's also a hack, but at least you don't have to send anything extra, and it doesn't need to be encrypted. On Fri, Jun 29, 2018 at 8:19 PM Christian Huitema wrote: > On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes. See Issue 1243 ( > https://github.com/quicwg/base-drafts/issues/1243) for context. Briefly, > load balancers that use server CID need that server CID to route ICMPv6 > packets back to the server doing PMTUD. > > > > @'Kazuho Oku' suggested using the new packet > coalescing functionality by sending an invalid long-header packet and > coalescing it with a valid short-header packet. This would have to work, > if one follows the current spec strictly. This is definitely a hack, > however. > > > > I would like to come up with something that is not a hack, does not > require sending deliberately invalid packets, but also not to complicate > the design with the need to care about key phase and whatever else one > wants to put in the short-header in the future. > > > > What do people think about a new =E2=80=9C0x7B =E2=80=93 PMTU Probe=E2=80= =9D long header packet > type? > > A packet of that type would just be a bare minimum long header packet per > Invariants (nothing after source CID), and its only purpose would be to b= e > coalesced with other QUIC packets. > > > My personal inclination is to just ignore ICMP, and thus not have to deal > with related attacks. My limited experience so far is that active PMTU > discovery succeeds after just a couple of probes. > > In any case, I would rather not have a specific "PMTU Probe" long header > -- I would rather not disclose to middleboxes that the node is engaged in > PMTUD. But I could see the point of a generic "1-RTT" long header. It cou= ld > help make stateless reset work. And it could be sent proactively, say eve= ry > few RTT, as a form of greasing. > > -- Christian Huitema > > > > --000000000000de1670056fd11a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suggest using a RETRY packet with a 0 byte token length = and DCIL.=C2=A0 Which is basically an invariant header and nothing else.=C2= =A0 Technically it's also a hack, but at least you don't have to se= nd anything extra, and it doesn't need to be encrypted.

On Fri, Jun 29, 2018 at 8:19 PM C= hristian Huitema <huitema@huitema= .net> wrote:
=20 =20 =20

On 6/29/2018 2:00 PM, Lubashev, Igor wrote:

We talked briefly in Kista about the possibility of using Long Header packets for PMTUD probes.=C2=A0 Se= e Issue 1243 (https://github.com/quicwg/base-drafts/issues/1243<= /a>) for context.=C2=A0 Briefly, load balancers that use server CID need that server CID to route ICMPv6 packets back to the server doing PMTUD.

=C2=A0

@'Kazuho Oku' suggested using the new packet coalescing functionality by sending an invalid long-header packet and coalescing it with a valid short-header packet.=C2=A0 This would ha= ve to work, if one follows the current spec strictly.=C2=A0 This is definitely a hack, however.

=C2=A0

I would like to come up with something that is not a hack, does not require sending deliberately invalid packets, but also not to complicate the design with the need to care about key phase and whatever else one wants to put in the short-header in the future.

=C2=A0

What do people think about a new =E2=80=9C0x7B= =E2=80=93 PMTU Probe=E2=80=9D long header packet type?

A packet of that type would just be a bare minimum long header packet per Invariants (nothing after source CID), and its only purpose would be to be coalesced with other QUIC packets.


My personal inclination is to just ignore ICMP, and thus not have to deal with related attacks. My limited experience so far is that active PMTU discovery succeeds after just a couple of probes.

In any case, I would rather not have a specific "PMTU Probe" = long header -- I would rather not disclose to middleboxes that the node is engaged in PMTUD. But I could see the point of a generic "1-RTT= " long header. It could help make stateless reset work. And it could be sent proactively, say every few RTT, as a form of greasing.

-- Christian Huitema



--000000000000de1670056fd11a20-- From nobody Fri Jun 29 18:55:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A04130FD6 for ; Fri, 29 Jun 2018 18:55:34 -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 0-enRckKTVMF for ; Fri, 29 Jun 2018 18:55:31 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 72573130F7B for ; Fri, 29 Jun 2018 18:55:31 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id j3-v6so4959671pfh.11 for ; Fri, 29 Jun 2018 18:55:31 -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=Tm3wSl+X+x+rc/6O7XTIfwABbH5QkhuPEvEfQ7XMC1U=; b=i/rEXeHLoAj/MfO4G0uC050GATQ8JoHm4Y+hTXBsig0ECYtkxOsdA1lp03cnyA0ZW8 MU7UEdxkrcdoKpqq6V2EznyDXby6z0wjcShw1XShMnbb4bE8IQhnB3CgdVY0rDNEsazo bOE9xhRg+wjDIDsLhNoPlWyabSwPrqzecDggPT8pS/jmyo+U8X7le5Fz5J2sgq9ZJ6V+ UHtw2QAYp9oZmyBGrLioINOAc4fVrf5jhsViMUJmXvoFNl8x3MrCX8mhWp5zvM/bSHUg EmHh2aPMvJ8knd8yiN+qxAwOcCy5qkhK48HbOcNs9L0fTpYuXPd2YuwfiZr9VSTOFwpN iHqQ== 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=Tm3wSl+X+x+rc/6O7XTIfwABbH5QkhuPEvEfQ7XMC1U=; b=KSd7lWW3qzzRqfz0P/k3zw7WKTYJumskTWsUnAcEMn2L1bZrAprqYuM8NxYOjJOH1r 3C7DSoibeyeQCxwle+1kPUsoh/BOTvsk/3xV7vZaxFlrv9rKS/QYxDJefTU9xXtWspsN LuBNmGfNj1gzQ2TZhhNumWAl3RE0LkeGlqE6HDsACaK33Nm2uCGUOxMEm4WYaFQVW9vZ mHz8hWPId8XW43NXHfXNTnBSQGIAHf+OQPljlwUM028BTKQy11P3sIw9UQ+UmvHvuTvw 1uVF99HdYaAtofPo0suvt5I9zELctEmM1ydjrDDnQhlXKPBjvgn1tNznXM1uc6uJNVi1 JNHg== X-Gm-Message-State: APt69E2jULifQ/qwGYXGj+PZ0VQG44u2c7yLpnfloezg+yoZz0dH2G+g LUcVK5Ej/iHk2SwInMszbpxQ5AxQDYumfmffO3Q= X-Google-Smtp-Source: AAOMgpfaNfF7iYmduI/jWWbf3sRlDkInm1efLJbi52Orpz7UONNFlkOumLYaV0bi5G5UMl4Y1bf5Icc4R5o/vAiwTso= X-Received: by 2002:a65:5245:: with SMTP id q5-v6mr3704661pgp.67.1530323731022; Fri, 29 Jun 2018 18:55:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 29 Jun 2018 18:55:30 -0700 (PDT) In-Reply-To: <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> From: Kazuho Oku Date: Sat, 30 Jun 2018 10:55:30 +0900 Message-ID: Subject: Re: Using Long Header packets for PMTUD probes To: Christian Huitema Cc: "Lubashev, Igor" , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 01:55:35 -0000 2018-06-30 9:18 GMT+09:00 Christian Huitema : > On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes. See Issue 1243 > (https://github.com/quicwg/base-drafts/issues/1243) for context. Briefly= , > load balancers that use server CID need that server CID to route ICMPv6 > packets back to the server doing PMTUD. > > > > @'Kazuho Oku' suggested using the new packet coalescing functionality by > sending an invalid long-header packet and coalescing it with a valid > short-header packet. This would have to work, if one follows the current > spec strictly. This is definitely a hack, however. > > > > I would like to come up with something that is not a hack, does not requi= re > sending deliberately invalid packets, but also not to complicate the desi= gn > with the need to care about key phase and whatever else one wants to put = in > the short-header in the future. > > > > What do people think about a new =E2=80=9C0x7B =E2=80=93 PMTU Probe=E2=80= =9D long header packet > type? > > A packet of that type would just be a bare minimum long header packet per > Invariants (nothing after source CID), and its only purpose would be to b= e > coalesced with other QUIC packets. > > > My personal inclination is to just ignore ICMP, and thus not have to deal > with related attacks. My limited experience so far is that active PMTU > discovery succeeds after just a couple of probes. > > In any case, I would rather not have a specific "PMTU Probe" long header = -- > I would rather not disclose to middleboxes that the node is engaged in > PMTUD. But I could see the point of a generic "1-RTT" long header. It cou= ld > help make stateless reset work. And it could be sent proactively, say eve= ry > few RTT, as a form of greasing. +1 Use of an invalid long header packet is a form of greasing. There is no point in explicitly disclosing the fact that an endpoint is engaged in a PMTUD. Hence I continue to believe that using an invalid long header packet for the purpose would be fine. It *could* be a Retry packet as Ian suggests, but it can be anything else. And even if it is not a Retry packet, it does not need to be encrypted or carry the AEAD tag, because nobody is going to decrypt it (for example a Handshake packet with a zero-length payload is just an ordinary form of an invalid packet). > -- Christian Huitema > > > --=20 Kazuho Oku From nobody Fri Jun 29 20:14:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86370130E7F for ; Fri, 29 Jun 2018 20:14:04 -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 vRxDMUOq6cya for ; Fri, 29 Jun 2018 20:14:02 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::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 A0308127332 for ; Fri, 29 Jun 2018 20:14:02 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id s24-v6so5314127plq.6 for ; Fri, 29 Jun 2018 20:14:02 -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; bh=nwfQyyHTAtuT0Sre10q5YBgzJJ+78M98HG+7vHwFIEc=; b=FpH5OpkvRulgFCtOY35Hrev789K3Z19KXafOSmxinVnF057gf2H5lHMsT1Yymru2RG 0nQDQ1k1dhpmtJcARa3jQBwvmuYCJK5a4sXjR0vqrpme1JsmRSdUBIT5kMPKkcOAesZI ZrbQkLXU2ByCa66FYX//ILs3BuEzgkv5Tag6hVMS94lYNeQTKj3oVMRIZwZeQAhgaons gLtKBRPEX3XhMHmrNfKZ0NBKOlA5dDKIdv+xQEg+P6H4DqmdCJMHp1VnjgCkxB2Wo4l+ NFGw6K0h3lXZWjxlV580PmVaWaPH700BA6fQoVaajaiNXPWf1LbwOrjak24jquFQYyX7 sY1g== 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=nwfQyyHTAtuT0Sre10q5YBgzJJ+78M98HG+7vHwFIEc=; b=tsqAlZYQUtcKRYc0Fn9Z2dS5aFl1T4nViwNYDxd2X1cfNmR6X12N05VBGj/c/DQ5J5 9VHdRMdJrnsqBhLupA70o9UmQYIpn4bmh0WMRDI0/THvBjC/UgjnW2YAp28wYcZgvJbK XjgAq8VUeqh5ZiMJExDW7fCZgOb0lZ3IAGe1kqxvj8hR3JkCdwAexG3ozctIyjJLrFPS qrgaIFX5c9qgbvy5EcJvagmdHjxhqu0zutfPx7LedybYEnSpD8Xi/IW9tRLqh5hDlKkH RKSuq4TW9Ah65cVGwLX4SA2I3J55p7uzs1n+y2s/DlUuq05k3DRMBUuRWrrpl0sE9OfS ua3g== X-Gm-Message-State: APt69E3abylVydPtG0UkC7UPDI5jBlMC/Pe0x3zk4+IZAgREXQ9BrwVD G47KiW8zEexELOBa+Yjvr9N6XxklD7r32dHnVhA= X-Google-Smtp-Source: AAOMgpdjZvw9FbwUZYsOtzgD+hwG/pdmaUtngfQ8Z601Ue9pHV1MZ4m9yZEheyiI6z2x3Ww8t+zox0Cwecsv/THrHtM= X-Received: by 2002:a17:902:1e6:: with SMTP id b93-v6mr4935003plb.149.1530328442067; Fri, 29 Jun 2018 20:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 29 Jun 2018 20:14:01 -0700 (PDT) From: Kazuho Oku Date: Sat, 30 Jun 2018 12:14:01 +0900 Message-ID: Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions) To: Christian Huitema Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 03:14:05 -0000 I know that the recovery draft defines TLP, but it does not provide a way for a sender to request client to send an ACK immediately. I think that there should be a way to request that, because it would help the sender detect the loss at the earliest moment. One way is to specify a TLP frame, which is identical to a PING frame with only one difference: it suggests the peer to send ACK immediately. A sender sending a TLP will include the frame in the packet to evoke the peer to send ACK without waiting for the delay. Searching the mailing list archive told me that Christian raised the issue about a year ago (in the mail cited below), but it seems to me that the issue has not been resolved yet. 2017-08-25 14:52 GMT+09:00 Christian Huitema : > 3) Can the senders do something to speed up retransmission? > In the absence of continuous traffic flow, the previous decision tree > degenerates to timer based retransmission. To speed things up, > implementations can generate extra traffic. For example, if no > acknowledgement is received after a short timer, they can send a > gratuitous packet that may trigger a further acknowledgement. That's the > essence of the "tail loss probe" algorithm of TCP, but things are really > simpler with monotonously increasing packet sequence numbers. There are > various plausible ways to send a gratuitous packet -- a Ping, a Max Data > Update, or repeating the oldest packet will all work. > > Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start > being creative. For example, if packets are waiting and the > implementation is sending a naked ACK for whatever reason, it does not > cost much to add a Ping to that. > > This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is > very easy to implement. > > -- > Christian Huitema > > -- Kazuho Oku From nobody Fri Jun 29 20:43:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CC6130E40 for ; Fri, 29 Jun 2018 20:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 HAD5mbX_6Yqf for ; Fri, 29 Jun 2018 20:43:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9FC52130DF3 for ; Fri, 29 Jun 2018 20:43:17 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5U3gJDV014863; Sat, 30 Jun 2018 04:43:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=e33g+S/RSnTNVl/Og4kk3xxqvWTdiN1+HXj835A5qsc=; b=Nx+2w23mD9AuSUXRwnqAnStdsaBoTWoqEkPy1XFY3exmYi6gOzsHJpzHJl65tCI9Dmjc gMtofaTm0J9cTon1nxn6tbEeMi/ruBvA7t8MMGz1D6njXvweTtAPW7mqGzQOSskEVDm8 5Ok8mzIHLp27s/ZRYzcgZiZloyaD7mN+vrz2R9SGUTgkonTvBP9HTkpgrE+dkO+2+0I2 SCx/TbqLL6U9wwhkVCaRl0SOcaEUgqLUIDVmwmeHHujLQ8lnSrsckC3tccslhHWEJY78 fbBOrIKjSYceLAxbRtLWwFDm6YQUyhBeGJZt85uhI5to0mAcnOtH3jdIL9W+hqVRq9sC gg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2jx1cmr3rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 04:43:09 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5U3ewkW023607; Fri, 29 Jun 2018 23:43:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bw02ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 29 Jun 2018 23:43:08 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 22:43:07 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Fri, 29 Jun 2018 22:43:07 -0500 From: "Lubashev, Igor" To: "huitema@huitema.net" , "kazuhooku@gmail.com" CC: "quic@ietf.org" Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Index: AQHUECBvSG4+mMUizUuLpLeaaCeqgKR4KKij Date: Sat, 30 Jun 2018 03:43:06 +0000 Message-ID: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_037175748de14b49a815a91a883ee0e1ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=400 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=315 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300039 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 03:43:21 -0000 --_000_037175748de14b49a815a91a883ee0e1ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would make sense to define PING to require an ACK as soon as possible. T= he need for an immediate ACK is not just in tail loss probes. It is also PM= TU probes. Come to think of this, PATH_CHALLENGE should require an expedite= d ACK as well. - Igor -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Friday, 29 Jun 2018, 11:14PM To: Christian Huitema [huitema@huitema.net] CC: IETF QUIC WG [quic@ietf.org] Subject: Speeding up tail loss detection (Re: Congestion control algorithm = questions) I know that the recovery draft defines TLP, but it does not provide a way for a sender to request client to send an ACK immediately. I think that there should be a way to request that, because it would help the sender detect the loss at the earliest moment. One way is to specify a TLP frame, which is identical to a PING frame with only one difference: it suggests the peer to send ACK immediately. A sender sending a TLP will include the frame in the packet to evoke the peer to send ACK without waiting for the delay. Searching the mailing list archive told me that Christian raised the issue about a year ago (in the mail cited below), but it seems to me that the issue has not been resolved yet. 2017-08-25 14:52 GMT+09:00 Christian Huitema : > 3) Can the senders do something to speed up retransmission? > In the absence of continuous traffic flow, the previous decision tree > degenerates to timer based retransmission. To speed things up, > implementations can generate extra traffic. For example, if no > acknowledgement is received after a short timer, they can send a > gratuitous packet that may trigger a further acknowledgement. That's the > essence of the "tail loss probe" algorithm of TCP, but things are really > simpler with monotonously increasing packet sequence numbers. There are > various plausible ways to send a gratuitous packet -- a Ping, a Max Data > Update, or repeating the oldest packet will all work. > > Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start > being creative. For example, if packets are waiting and the > implementation is sending a naked ACK for whatever reason, it does not > cost much to add a Ping to that. > > This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is > very easy to implement. > > -- > Christian Huitema > > -- Kazuho Oku --_000_037175748de14b49a815a91a883ee0e1ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It would make sense to define PING to require an ACK as so= on as possible. The need for an immediate ACK is not just in tail loss prob= es. It is also PMTU probes. Come to think of this, PATH_CHALLENGE should require an expedited ACK as well.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Friday, 29 Jun 2018, 11:14PM
To: Christian Huitema [huitema@huitema.net]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Speeding up tail loss detection (Re: Congestion control alg= orithm questions)

I know that the recovery draft defines TLP, but it= does not provide a
way for a sender to request client to send an ACK immediately. I think
that there should be a way to request that, because it would help the
sender detect the loss at the earliest moment.

One way is to specify a TLP frame, which is identical to a PING frame
with only one difference: it suggests the peer to send ACK
immediately. A sender sending a TLP will include the frame in the
packet to evoke the peer to send ACK without waiting for the delay.

Searching the mailing list archive told me that Christian raised the
issue about a year ago (in the mail cited below), but it seems to me
that the issue has not been resolved yet.

2017-08-25 14:52 GMT+09:00 Christian Huitema <huitema@huitema.net>= ;:

> 3) Can the senders do something to speed up retransmission?
> In the absence of continuous traffic flow, the previous decision tree<= br> > degenerates to timer based retransmission. To speed things up,
> implementations can generate extra traffic. For example, if no
> acknowledgement is received after a short timer, they can send a
> gratuitous packet that may trigger a further acknowledgement. That's t= he
> essence of the "tail loss probe" algorithm of TCP, but thing= s are really
> simpler with monotonously increasing packet sequence numbers. There ar= e
> various plausible ways to send a gratuitous packet -- a Ping, a Max Da= ta
> Update, or repeating the oldest packet will all work.
>
> Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start=
> being creative. For example, if packets are waiting and the
> implementation is sending a naked ACK for whatever reason, it does not=
> cost much to add a Ping to that.
>
> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it i= s
> very easy to implement.
>
> --
> Christian Huitema
>
>



--
Kazuho Oku

 --_000_037175748de14b49a815a91a883ee0e1ustx2exdag1mb5msgcorpak_-- From nobody Fri Jun 29 21:22:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4872B130E54 for ; Fri, 29 Jun 2018 21:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 A00TJn30PT7b for ; Fri, 29 Jun 2018 21:22:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 805B3130E53 for ; Fri, 29 Jun 2018 21:22:15 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5U4LvPk031132; Sat, 30 Jun 2018 05:22:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=GaiRBEkoBfulYlY/sGzEGSH0aXoehQrWTH426ixr/po=; b=mQSbJFKkI6lDRB0HavFSkTI0ryHKhEMK0fTtFAAun0WkH0H1qSug+hVQlcZ8ucco2jdf j+s8PduMB5CKWp7YcN3KT5x9p3QWlrDdBf/RFLZoayLA+5lKD+e7ZP+lk9BLFoz4/tRr AW3MX0/57yWdjfLkMehbdGSnn2LRfIICNhFysWw1ZhZ6y70r3b5ztZjwLylWTvLDzOkd U7APsgkYpYsKj2XRVoLvELRoNzJWKcX0f5EwYxiU0B97Mx8v+T7ioj16xnczEVDrbUD6 F9SXSejtEF29ZH1cAx7K/3hL0Mce7ZUw99C4yoR+1C96uKhqZjPszjduMmyDePRiu1yh Sg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jx225033e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 05:22:06 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5U4LNZL016994; Sat, 30 Jun 2018 00:22:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bw05b7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 00:22:05 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 23:21:58 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Fri, 29 Jun 2018 23:21:58 -0500 From: "Lubashev, Igor" To: "huitema@huitema.net" , "kazuhooku@gmail.com" CC: "quic@ietf.org" Subject: RE: Using Long Header packets for PMTUD probes Thread-Topic: Using Long Header packets for PMTUD probes Thread-Index: AdQP6f+k+GmPnfLgQ7evczPwCZupawAR9GSAAANhAwD//9UbBw== Date: Sat, 30 Jun 2018 04:21:58 +0000 Message-ID: References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_a2ad6b9fde0d40f483532b4b32160015ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300047 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300047 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 04:22:19 -0000 --_000_a2ad6b9fde0d40f483532b4b32160015ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I like the idea of greasing. I also like the idea of using 1-rtt headers to= make stateless reset work. I would prefer not to use known packet types, especially "INITIAL" and "0-R= TT", because that will confuse stateless load balancers (these packet types= are expected to carry random destination CID). But RETRY and HANDSHAKE see= m fine. A special "Generic 0-rtt" type would work, too. - Igor -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Friday, 29 Jun 2018, 9:55PM To: Christian Huitema [huitema@huitema.net] CC: Lubashev, Igor [ilubashe@akamai.com]; IETF QUIC WG [quic@ietf.org] Subject: Re: Using Long Header packets for PMTUD probes 2018-06-30 9:18 GMT+09:00 Christian Huitema : > On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes. See Issue 1243 > (https://github.com/quicwg/base-drafts/issues/1243) for context. Briefly= , > load balancers that use server CID need that server CID to route ICMPv6 > packets back to the server doing PMTUD. > > > > @'Kazuho Oku' suggested using the new packet coalescing functionality by > sending an invalid long-header packet and coalescing it with a valid > short-header packet. This would have to work, if one follows the current > spec strictly. This is definitely a hack, however. > > > > I would like to come up with something that is not a hack, does not requi= re > sending deliberately invalid packets, but also not to complicate the desi= gn > with the need to care about key phase and whatever else one wants to put = in > the short-header in the future. > > > > What do people think about a new =930x7B =96 PMTU Probe=94 long header pa= cket > type? > > A packet of that type would just be a bare minimum long header packet per > Invariants (nothing after source CID), and its only purpose would be to b= e > coalesced with other QUIC packets. > > > My personal inclination is to just ignore ICMP, and thus not have to deal > with related attacks. My limited experience so far is that active PMTU > discovery succeeds after just a couple of probes. > > In any case, I would rather not have a specific "PMTU Probe" long header = -- > I would rather not disclose to middleboxes that the node is engaged in > PMTUD. But I could see the point of a generic "1-RTT" long header. It cou= ld > help make stateless reset work. And it could be sent proactively, say eve= ry > few RTT, as a form of greasing. +1 Use of an invalid long header packet is a form of greasing. There is no point in explicitly disclosing the fact that an endpoint is engaged in a PMTUD. Hence I continue to believe that using an invalid long header packet for the purpose would be fine. It *could* be a Retry packet as Ian suggests, but it can be anything else. And even if it is not a Retry packet, it does not need to be encrypted or carry the AEAD tag, because nobody is going to decrypt it (for example a Handshake packet with a zero-length payload is just an ordinary form of an invalid packet). > -- Christian Huitema > > > -- Kazuho Oku --_000_a2ad6b9fde0d40f483532b4b32160015ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I like the idea of greasing. I also like the idea of using= 1-rtt headers to make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL"= ; and "0-RTT", because that will confuse stateless load balancers= (these packet types are expected to carry random destination CID). But RET= RY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [huitema@huitema.net]
CC: Lubashev, Igor [ilubashe@akamai.com]; IETF QUIC WG [quic@ietf.or= g]
Subject: Re: Using Long Header packets for PMTUD probes

2018-06-30 9:18 GMT+09:00 Christian Huitema &l= t;huitema@huitema.net>:
> On 6/29/2018 2:00 PM, Lubashev, Igor wrote:
>
> We talked briefly in Kista about the possibility of using Long Header<= br> > packets for PMTUD probes.  See Issue 1243
> (https:/= /github.com/quicwg/base-drafts/issues/1243) for context.  Briefly,=
> load balancers that use server CID need that server CID to route ICMPv= 6
> packets back to the server doing PMTUD.
>
>
>
> @'Kazuho Oku' suggested using the new packet coalescing functionality = by
> sending an invalid long-header packet and coalescing it with a valid > short-header packet.  This would have to work, if one follows the= current
> spec strictly.  This is definitely a hack, however.
>
>
>
> I would like to come up with something that is not a hack, does not re= quire
> sending deliberately invalid packets, but also not to complicate the d= esign
> with the need to care about key phase and whatever else one wants to p= ut in
> the short-header in the future.
>
>
>
> What do people think about a new =930x7B =96 PMTU Probe=94 long header= packet
> type?
>
> A packet of that type would just be a bare minimum long header packet = per
> Invariants (nothing after source CID), and its only purpose would be t= o be
> coalesced with other QUIC packets.
>
>
> My personal inclination is to just ignore ICMP, and thus not have to d= eal
> with related attacks. My limited experience so far is that active PMTU=
> discovery succeeds after just a couple of probes.
>
> In any case, I would rather not have a specific "PMTU Probe"= long header --
> I would rather not disclose to middleboxes that the node is engaged in=
> PMTUD. But I could see the point of a generic "1-RTT" long h= eader. It could
> help make stateless reset work. And it could be sent proactively, say = every
> few RTT, as a form of greasing.

+1

Use of an invalid long header packet is a form of greasing. There is
no point in explicitly disclosing the fact that an endpoint is engaged
in a PMTUD.

Hence I continue to believe that using an invalid long header packet
for the purpose would be fine.

It *could* be a Retry packet as Ian suggests, but it can be anything
else. And even if it is not a Retry packet, it does not need to be
encrypted or carry the AEAD tag, because nobody is going to decrypt it
(for example a Handshake packet with a zero-length payload is just an
ordinary form of an invalid packet).

> -- Christian Huitema
>
>
>



--
Kazuho Oku
 --_000_a2ad6b9fde0d40f483532b4b32160015ustx2exdag1mb5msgcorpak_-- From nobody Fri Jun 29 23:09:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26AF130FE1 for ; Fri, 29 Jun 2018 23:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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 YYQd3LdroDsv for ; Fri, 29 Jun 2018 23:09:42 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 6983D130E55 for ; Fri, 29 Jun 2018 23:09:42 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id r24-v6so10323344ioh.9 for ; Fri, 29 Jun 2018 23:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=8gTY+mJJ21RLHnH0dNQetgaqI4OyvxMxyAOMs8V0b6E=; b=LF1OaAobQZSUc3JFruAbA81tLbfqpHNJIjaxatelp6+jhZrVy1hxd+8laUlvkFaj3B cKoeLTwor/ot03jQtzAqT5QEn2j5V+5MMAsz9Sq7xEdhfKNduzZu3iAPT8SaSq4cqDzp dtRufMOFlj0tuXQnevpFEIToSwDGiZ2YMRi3VPfRrf4gWgJirVwKhVjFwzACgp4z0RlD u13mticzLxwB1kNwecRzPCkjVwJDiVBf+5vEZgV0yCL32dnV8UzpPA/qgM4mtKxEgQrl wd6T41tclqCFl0CP4iJ+Oy7vtRZw03cke86Zfbyhp20pBppFHP7WP9RoW/oVKTSZ34ek H0BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=8gTY+mJJ21RLHnH0dNQetgaqI4OyvxMxyAOMs8V0b6E=; b=rUNXVACpJL1r4JOGr1DD6nAD6ukoxlXEDvDvglNy6SrD9mFiczb4napct0vVYyoxm3 dyE+7dV5RNKqF6PgdsFLOzSvaUQljXxhxzoWRJ4YQTghqFee1H+4AZDS9YqPHuYhb0Sy imYP69m+OWjEnYHmGEmWNFgSmqCBsTGYpKbwA4Gex7+xJstmJa9Gmqq7zywnNKejVP1A 06T4lvEC5aGrJlj5tlBvSlJzfJUx04QgY/HiDEQx/ENemj1Z+Uyh9scH6fEQdL0yMkLH dJHOIFdZpVJvfu3SchT3jj7uxv0LKhBqhQdkj4keDqXo8knswbFaqc3WFZbvv8XLoekK rR6g== X-Gm-Message-State: APt69E3ADxJ3mL8yHVJECRSLRuE6I8f5HNeREHCS4NwbzJoaEVmbRJyG YBt+xQZDS1daqEVOUjr7XvmnBdSn/xgH0Xg/KplyWQ== X-Google-Smtp-Source: AAOMgpeoW8+YOriOn9jWbgXBocnAIjcJgxL4V7z7I8wspk+LmICwzHB0aEFZK2ckMJYFVPVsV9WENSenD/jUvMXBeGw= X-Received: by 2002:a6b:1e91:: with SMTP id e139-v6mr15104291ioe.36.1530338981829; Fri, 29 Jun 2018 23:09:41 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 30 Jun 2018 02:09:40 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 30 Jun 2018 02:09:40 -0400 Message-ID: Subject: RE: Using Long Header packets for PMTUD probes To: "kazuhooku@gmail.com" , "Lubashev, Igor" , "huitema@huitema.net" Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000065e2d9056fd5cfa1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 06:09:48 -0000 --00000000000065e2d9056fd5cfa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sending explicit invalid headers would pollute logs and make it more difficult to track down problems. I=E2=80=99d assume probes are infrequent, but otherwise they might also tie= up resources and prevent (by the nature of greasing) dropping packets in DDoS scenario, or black listing addresses with bad content for a while. Mikkel On 30 June 2018 at 06.22.36, Lubashev, Igor ( ilubashe=3D40akamai.com@dmarc.ietf.org) wrote: I like the idea of greasing. I also like the idea of using 1-rtt headers to make stateless reset work. I would prefer not to use known packet types, especially "INITIAL" and "0-RTT", because that will confuse stateless load balancers (these packet types are expected to carry random destination CID). But RETRY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too. - Igor -----Original Message----- *From:* Kazuho Oku [kazuhooku@gmail.com] *Received:* Friday, 29 Jun 2018, 9:55PM *To:* Christian Huitema [huitema@huitema.net] *CC:* Lubashev, Igor [ilubashe@akamai.com]; IETF QUIC WG [quic@ietf.org] *Subject:* Re: Using Long Header packets for PMTUD probes 2018-06-30 9:18 GMT+09:00 Christian Huitema : > On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes. See Issue 1243 > (https://github.com/quicwg/base-drafts/issues/1243) for context. Briefly= , > load balancers that use server CID need that server CID to route ICMPv6 > packets back to the server doing PMTUD. > > > > @'Kazuho Oku' suggested using the new packet coalescing functionality by > sending an invalid long-header packet and coalescing it with a valid > short-header packet. This would have to work, if one follows the current > spec strictly. This is definitely a hack, however. > > > > I would like to come up with something that is not a hack, does not require > sending deliberately invalid packets, but also not to complicate the design > with the need to care about key phase and whatever else one wants to put in > the short-header in the future. > > > > What do people think about a new =E2=80=9C0x7B =E2=80=93 PMTU Probe=E2=80= =9D long header packet > type? > > A packet of that type would just be a bare minimum long header packet per > Invariants (nothing after source CID), and its only purpose would be to b= e > coalesced with other QUIC packets. > > > My personal inclination is to just ignore ICMP, and thus not have to deal > with related attacks. My limited experience so far is that active PMTU > discovery succeeds after just a couple of probes. > > In any case, I would rather not have a specific "PMTU Probe" long header -- > I would rather not disclose to middleboxes that the node is engaged in > PMTUD. But I could see the point of a generic "1-RTT" long header. It could > help make stateless reset work. And it could be sent proactively, say every > few RTT, as a form of greasing. +1 Use of an invalid long header packet is a form of greasing. There is no point in explicitly disclosing the fact that an endpoint is engaged in a PMTUD. Hence I continue to believe that using an invalid long header packet for the purpose would be fine. It *could* be a Retry packet as Ian suggests, but it can be anything else. And even if it is not a Retry packet, it does not need to be encrypted or carry the AEAD tag, because nobody is going to decrypt it (for example a Handshake packet with a zero-length payload is just an ordinary form of an invalid packet). > -- Christian Huitema > > > -- Kazuho Oku --00000000000065e2d9056fd5cfa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Sending explicit inv= alid headers would pollute logs and make it more difficult to track down pr= oblems.

<= /div>
I=E2=80=99d a= ssume probes are infrequent, but otherwise they might also tie up resources= and prevent (by the nature of greasing) dropping packets in DDoS scenario,= or black listing addresses with bad content for a while.

Mikkel

On 30 June 2018 at 06.22.36= , Lubashev, Igor (ilubashe=3D40akamai.com@dmarc.ietf.org) wrote:

I like the idea of greasing. I also like the idea of using 1-rtt headers to make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL"= ; and "0-RTT", because that will confuse stateless load balancers (these packet types are expected to carry random destination CID). But RETRY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@g= mail.com]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [huitem= a@huitema.net]
CC: Lubashev, Igor [ilubashe@= akamai.com]; IETF QUIC WG [quic@ietf.org]
Subject: Re: Using Long Header packets for PMTUD probes

20= 18-06-30 9:18 GMT+09:00 Christian Huitema <huitema@huitema.net>:
> On 6/29/2018 2:00 PM, Lubashev, Igor wrote:
>
> We talked briefly in Kista about the possibility of using Long Header
> packets for PMTUD probes.=C2=A0 See Issue 1243
> (https:/= /github.com/quicwg/base-drafts/issues/1243) for context.=C2=A0 Briefly,
> load balancers that use server CID need that server CID to route ICMPv6
> packets back to the server doing PMTUD.
>
>
>
> @'Kazuho Oku' suggested using the new packet coalescing functionality by
> sending an invalid long-header packet and coalescing it with a valid
> short-header packet.=C2=A0 This would have to work, if one follows the current
> spec strictly.=C2=A0 This is definitely a hack, however.
>
>
>
> I would like to come up with something that is not a hack, does not require
> sending deliberately invalid packets, but also not to complicate the design
> with the need to care about key phase and whatever else one wants to put in
> the short-header in the future.
>
>
>
> What do people think about a new =E2=80=9C0x7B =E2=80=93 PMTU Probe=E2= =80=9D long header packet
> type?
>
> A packet of that type would just be a bare minimum long header packet per
> Invariants (nothing after source CID), and its only purpose would be to be
> coalesced with other QUIC packets.
>
>
> My personal inclination is to just ignore ICMP, and thus not have to deal
> with related attacks. My limited experience so far is that active PMTU
> discovery succeeds after just a couple of probes.
>
> In any case, I would rather not have a specific "PMTU Probe" long header --
> I would rather not disclose to middleboxes that the node is engaged in
> PMTUD. But I could see the point of a generic "1-RTT" long header. It could
> help make stateless reset work. And it could be sent proactively, say every
> few RTT, as a form of greasing.

+1

Use of an invalid long header packet is a form of greasing. There is
no point in explicitly disclosing the fact that an endpoint is engaged
in a PMTUD.

Hence I continue to believe that using an invalid long header packet
for the purpose would be fine.

It *could* be a Retry packet as Ian suggests, but it can be anything
else. And even if it is not a Retry packet, it does not need to be
encrypted or carry the AEAD tag, because nobody is going to decrypt it
(for example a Handshake packet with a zero-length payload is just an
ordinary form of an invalid packet).

> -- Christian Huitema
>
>
>



--
Kazuho Oku
--00000000000065e2d9056fd5cfa1-- From nobody Fri Jun 29 23:26:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5736130FEB for ; Fri, 29 Jun 2018 23:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD1nl4ZCBNj1 for ; Fri, 29 Jun 2018 23:26:04 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680107.outbound.protection.outlook.com [40.107.68.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0FF130FE8 for ; Fri, 29 Jun 2018 23:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qr1rlLN19NjIbRGSJ/Xd3vP4k1i+ayQsWHjFI+WWNUc=; b=Q8XaLfvX2g9OGwyWFcKgXFb5oT0NYVDddnWKvl6YlRtlKAAFIhFCYkPFLSg1Ij+P+ESwna43Ld0aQkLmUaZVPoyMnLnltzm6je1n6PMTfmJdnneOT5AM5IdxMTxlgKKU71bDcjp3dPx7TACrRbPI2Twfz/1TvB7oWaTjES1eUWY= Received: from MW2PR2101MB1098.namprd21.prod.outlook.com (52.132.149.27) by MW2PR2101MB0891.namprd21.prod.outlook.com (52.132.152.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.5; Sat, 30 Jun 2018 06:26:01 +0000 Received: from MW2PR2101MB1098.namprd21.prod.outlook.com ([fe80::ca9:e464:9c1b:dd55]) by MW2PR2101MB1098.namprd21.prod.outlook.com ([fe80::ca9:e464:9c1b:dd55%5]) with mapi id 15.20.0930.016; Sat, 30 Jun 2018 06:26:01 +0000 From: Praveen Balasubramanian To: "Lubashev, Igor" , huitema , "kazuhooku@gmail.com" CC: "quic@ietf.org" Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Index: AQHUECByHqG/zftGOUq9fkJj1zXpE6R4KKgAgAAr8cA= Date: Sat, 30 Jun 2018 06:26:00 +0000 Message-ID: References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2:c07e:194e:8750:dc60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB0891; 7:qCbs4e+yRnENX5kU8d8FeG8dET7DAU9ONnRAQlw0Z1Q0P5nYIEfRoHit6/owNhiwMJo/7IIeU9siDnUdu8g1bGDogPTvy7wZMYLhlRNYdCN/tzQw61MG9jTA0GPS2WTSOJz2hzSqMcM45l4PTrUvufWpIKFhSBtkR1Zz8eK9Qo4ZHZa3L01YIXBKkF2vcFZ+QhmZbnpvqXVXx4KIE6wNRjKNdZpPh6yXD1Z3RcMXAHEXo5OzIS6+HFnuzSb5cNoF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 69041f04-e65a-4b1e-4ebd-08d5de525960 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR2101MB0891; x-ms-traffictypediagnostic: MW2PR2101MB0891: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231270)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MW2PR2101MB0891; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB0891; x-forefront-prvs: 0719EC6A9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(366004)(346002)(376002)(51444003)(13464003)(189003)(199004)(14444005)(4326008)(6436002)(6246003)(46003)(81156014)(81166006)(25786009)(110136005)(39060400002)(486006)(316002)(76176011)(53936002)(54896002)(6306002)(9686003)(11346002)(476003)(55016002)(236005)(256004)(99286004)(33656002)(68736007)(10090500001)(186003)(86612001)(8676002)(6116002)(790700001)(2906002)(14454004)(5660300001)(8936002)(10290500003)(86362001)(2900100001)(102836004)(2501003)(446003)(5250100002)(8990500004)(6346003)(229853002)(106356001)(97736004)(6506007)(105586002)(53546011)(22452003)(7736002)(74316002)(7696005)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0891; H:MW2PR2101MB1098.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: 1AZjo0nQzg1KlJ5s3nlXKxXpCGx3+l24aTCu93AlnOeJ27enKZAPjrm8rlbA4cgQ15l9McjvC2Sqk4TPOnvKmhWuhXEeOL0JJ1hFofoPy+UTFZgDNavp/lMLhCgYaOMcFeCqGpgcvLjQornW5PiDkVFDuZ8JXPLapzDzFczIRrXhrg2c7yJofiCmQCvW3NG5KiMeHnoiu+l+FOzSbucZYyHrGSP2l1XT2uSq6Orj+Ksf7Tzv0KMHeCXgjFPPiBUeu3jsxVlonqhGSfwiba3nqhUhbaSY0K1GTO4G09NJBIYiIq9riAD0gE/VB17LSm10pEmsctkRCclYkRC0GsmiGolahL56mpszcUN0V4uC6b0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB109824376095324090AA42A7B64D0MW2PR2101MB1098_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69041f04-e65a-4b1e-4ebd-08d5de525960 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2018 06:26:00.9230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0891 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 06:26:08 -0000 --_000_MW2PR2101MB109824376095324090AA42A7B64D0MW2PR2101MB1098_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All out of order packets elicit an immediate ACK, this applies to QUIC the = same way it applies to TCP. Section 3.4 of recovery spec: Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate loss recovery. The receiver SHOULD send an immediate ACK when it receives a new packet which is not one greater than the largest received packet number. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lubashev, Igor Sent: Friday, June 29, 2018 8:43 PM To: huitema ; kazuhooku@gmail.com Cc: quic@ietf.org Subject: RE: Speeding up tail loss detection (Re: Congestion control algori= thm questions) It would make sense to define PING to require an ACK as soon as possible. T= he need for an immediate ACK is not just in tail loss probes. It is also PM= TU probes. Come to think of this, PATH_CHALLENGE should require an expedite= d ACK as well. - Igor -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Friday, 29 Jun 2018, 11:14PM To: Christian Huitema [huitema@huitema.net] CC: IETF QUIC WG [quic@ietf.org] Subject: Speeding up tail loss detection (Re: Congestion control algorithm = questions) I know that the recovery draft defines TLP, but it does not provide a way for a sender to request client to send an ACK immediately. I think that there should be a way to request that, because it would help the sender detect the loss at the earliest moment. One way is to specify a TLP frame, which is identical to a PING frame with only one difference: it suggests the peer to send ACK immediately. A sender sending a TLP will include the frame in the packet to evoke the peer to send ACK without waiting for the delay. Searching the mailing list archive told me that Christian raised the issue about a year ago (in the mail cited below), but it seems to me that the issue has not been resolved yet. 2017-08-25 14:52 GMT+09:00 Christian Huitema >: > 3) Can the senders do something to speed up retransmission? > In the absence of continuous traffic flow, the previous decision tree > degenerates to timer based retransmission. To speed things up, > implementations can generate extra traffic. For example, if no > acknowledgement is received after a short timer, they can send a > gratuitous packet that may trigger a further acknowledgement. That's the > essence of the "tail loss probe" algorithm of TCP, but things are really > simpler with monotonously increasing packet sequence numbers. There are > various plausible ways to send a gratuitous packet -- a Ping, a Max Data > Update, or repeating the oldest packet will all work. > > Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start > being creative. For example, if packets are waiting and the > implementation is sending a naked ACK for whatever reason, it does not > cost much to add a Ping to that. > > This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is > very easy to implement. > > -- > Christian Huitema > > -- Kazuho Oku --_000_MW2PR2101MB109824376095324090AA42A7B64D0MW2PR2101MB1098_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All out of order packets elicit an immediate ACK, th= is applies to QUIC the same way it applies to TCP.

 

Section 3.4 of recovery spec:

 

&nb= sp;  Out-of-order packets SHOULD be acknowledged more quickly, in orde= r to

&nb= sp;  accelerate loss recovery.  The receiver SHOULD send an immed= iate ACK

&nb= sp;  when it receives a new packet which is not one greater than the

&nb= sp;  largest received packet number.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Lubashev, Igor
Sent: Friday, June 29, 2018 8:43 PM
To: huitema <huitema@huitema.net>; kazuhooku@gmail.com
Cc: quic@ietf.org
Subject: RE: Speeding up tail loss detection (Re: Congestion control= algorithm questions)

 

It would make sense to define PING to require an ACK as soon as poss= ible. The need for an immediate ACK is not just in tail loss probes. It is = also PMTU probes. Come to think of this, PATH_CHALLENGE should require an expedited ACK as well.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com]
Received: Friday, 29 Jun 2018, 11:14PM
To: Christian Huitema [huitema@huitema.net]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Speeding up tail loss detection (Re: Congestion control alg= orithm questions)

I know that the recovery draft defines TLP, but it does not pro= vide a
way for a sender to request client to send an ACK immediately. I think
that there should be a way to request that, because it would help the
sender detect the loss at the earliest moment.

One way is to specify a TLP frame, which is identical to a PING frame
with only one difference: it suggests the peer to send ACK
immediately. A sender sending a TLP will include the frame in the
packet to evoke the peer to send ACK without waiting for the delay.

Searching the mailing list archive told me that Christian raised the
issue about a year ago (in the mail cited below), but it seems to me
that the issue has not been resolved yet.

2017-08-25 14:52 GMT+09:00 Christian Huitema <huitema@huitema.net>:

> 3) Can the senders do something to speed up retransmission?
> In the absence of continuous traffic flow, the previous decision tree<= br> > degenerates to timer based retransmission. To speed things up,
> implementations can generate extra traffic. For example, if no
> acknowledgement is received after a short timer, they can send a
> gratuitous packet that may trigger a further acknowledgement. That's t= he
> essence of the "tail loss probe" algorithm of TCP, but thing= s are really
> simpler with monotonously increasing packet sequence numbers. There ar= e
> various plausible ways to send a gratuitous packet -- a Ping, a Max Da= ta
> Update, or repeating the oldest packet will all work.
>
> Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start=
> being creative. For example, if packets are waiting and the
> implementation is sending a naked ACK for whatever reason, it does not=
> cost much to add a Ping to that.
>
> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it i= s
> very easy to implement.
>
> --
> Christian Huitema
>
>



--
Kazuho Oku

--_000_MW2PR2101MB109824376095324090AA42A7B64D0MW2PR2101MB1098_-- From nobody Sat Jun 30 06:01:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED561310C6 for ; Sat, 30 Jun 2018 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 ednXlqVse8iz for ; Sat, 30 Jun 2018 06:01:54 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E448A130ECA for ; Sat, 30 Jun 2018 06:01:52 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5UCknp3017025; Sat, 30 Jun 2018 14:01:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=KeJbPkJbawRnzJ3WDqdbIx08xXKx245GvELrJHLB8+c=; b=Y+TXYt3yrq4qIRt+JEU+7mTYVfrpnhmdGZKnM4V7MU1LlLORKcflOikkVRU7IjStkleR LOdvx5T5hcqD9hhndb8ck+DDB1ASg3xB01eFlKwUXQzj6xskwsmyElizFWJx0KeY0rqv UrwAv+7ZT+3pQeykQmdTBt+75W9S7ws3A5085vSHJzvbw0xuk2wt8tMvZyc1G6wP8ryL 99N025meXSPXfBtbjE9sWXzZT+0rfU2MlSU35kcq9FHbwyiBCdwFi+7P9+CQ0vzxD+BI 2gbNDXAyhYVzAXYI6a/ZgJhQCu28FSTLfaVVjzJ+KxmfIiPPiKmI8juRqzxow9ZkwGXb nA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jx225101b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 14:01:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5UD12lU015264; Sat, 30 Jun 2018 09:01:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jx56vgm91-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 09:01:43 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 30 Jun 2018 08:01:42 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Sat, 30 Jun 2018 08:01:42 -0500 From: "Lubashev, Igor" To: "huitema@huitema.net" , "mikkelfj@gmail.com" , "kazuhooku@gmail.com" CC: "quic@ietf.org" Subject: RE: Using Long Header packets for PMTUD probes Thread-Topic: Using Long Header packets for PMTUD probes Thread-Index: AdQP6f+k+GmPnfLgQ7evczPwCZupawAR9GSAAANhAwD//9UbB4AAcegAgAAfTAM= Date: Sat, 30 Jun 2018 13:01:41 +0000 Message-ID: References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_df2ad840e4f34f00a3d8867c76ad287austx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300151 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 13:01:58 -0000 --_000_df2ad840e4f34f00a3d8867c76ad287austx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can see the log pollution argument. When a packet is dropped, people ofte= n want to be able to say why. At the minimum, it would pollute the meaning = of some counter -- it would increment for both intentionally invalid and un= intentionally invalid long header packets, making it impossible to tell the= two apart. Hence, a specific "Generic 1-rtt long header" type feels prefer= able. I would not worry about DDoS with such packets. They still require a valid = CID. It is simpler and more effective to DDoS with something that tries to = elicit a reply and not just a drop (and does not contain a valid CID). -----Original Message----- From: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com] Received: Saturday, 30 Jun 2018, 2:09AM To: kazuhooku@gmail.com [kazuhooku@gmail.com]; Lubashev, Igor [ilubashe@aka= mai.com]; huitema@huitema.net [huitema@huitema.net] CC: quic@ietf.org [quic@ietf.org] Subject: RE: Using Long Header packets for PMTUD probes Sending explicit invalid headers would pollute logs and make it more diffic= ult to track down problems. I'd assume probes are infrequent, but otherwise they might also tie up reso= urces and prevent (by the nature of greasing) dropping packets in DDoS scen= ario, or black listing addresses with bad content for a while. Mikkel On 30 June 2018 at 06.22.36, Lubashev, Igor (ilubashe=3D40akamai.com@dmarc.= ietf.org) wrote: I like the idea of greasing. I also like the idea of using 1-rtt headers to= make stateless reset work. I would prefer not to use known packet types, especially "INITIAL" and "0-R= TT", because that will confuse stateless load balancers (these packet types= are expected to carry random destination CID). But RETRY and HANDSHAKE see= m fine. A special "Generic 0-rtt" type would work, too. - Igor -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Friday, 29 Jun 2018, 9:55PM To: Christian Huitema [huitema@huitema.net] CC: Lubashev, Igor [ilubashe@akamai.com]; IETF = QUIC WG [quic@ietf.org] Subject: Re: Using Long Header packets for PMTUD probes 2018-06-30 9:18 GMT+09:00 Christian Huitema >: > On 6/29/2018 2:00 PM, Lubashev, Igor wrote: > > We talked briefly in Kista about the possibility of using Long Header > packets for PMTUD probes. See Issue 1243 > (https://github.com/quicwg/base-drafts/issues/1243) for context. Briefly, > load balancers that use server CID need that server CID to route ICMPv6 > packets back to the server doing PMTUD. > > > > @'Kazuho Oku' suggested using the new packet coalescing functionality by > sending an invalid long-header packet and coalescing it with a valid > short-header packet. This would have to work, if one follows the current > spec strictly. This is definitely a hack, however. > > > > I would like to come up with something that is not a hack, does not requi= re > sending deliberately invalid packets, but also not to complicate the desi= gn > with the need to care about key phase and whatever else one wants to put = in > the short-header in the future. > > > > What do people think about a new "0x7B - PMTU Probe" long header packet > type? > > A packet of that type would just be a bare minimum long header packet per > Invariants (nothing after source CID), and its only purpose would be to b= e > coalesced with other QUIC packets. > > > My personal inclination is to just ignore ICMP, and thus not have to deal > with related attacks. My limited experience so far is that active PMTU > discovery succeeds after just a couple of probes. > > In any case, I would rather not have a specific "PMTU Probe" long header = -- > I would rather not disclose to middleboxes that the node is engaged in > PMTUD. But I could see the point of a generic "1-RTT" long header. It cou= ld > help make stateless reset work. And it could be sent proactively, say eve= ry > few RTT, as a form of greasing. +1 Use of an invalid long header packet is a form of greasing. There is no point in explicitly disclosing the fact that an endpoint is engaged in a PMTUD. Hence I continue to believe that using an invalid long header packet for the purpose would be fine. It *could* be a Retry packet as Ian suggests, but it can be anything else. And even if it is not a Retry packet, it does not need to be encrypted or carry the AEAD tag, because nobody is going to decrypt it (for example a Handshake packet with a zero-length payload is just an ordinary form of an invalid packet). > -- Christian Huitema > > > -- Kazuho Oku --_000_df2ad840e4f34f00a3d8867c76ad287austx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can see the log pollution argument. When a packet is dro= pped, people often want to be able to say why. At the minimum, it would pol= lute the meaning of some counter -- it would increment for both intentionally invalid and unintentionally inva= lid long header packets, making it impossible to tell the two apart. Hence,= a specific "Generic 1-rtt long header" type feels preferable.
I would not worry about DDoS with such packets. They still require a valid = CID. It is simpler and more effective to DDoS with something that tries to = elicit a reply and not just a drop (and does not contain a valid CID).

-----Original Message-----
From: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]
Received: Saturday, 30 Jun 2018, 2:09AM
To: kazuhooku@gmail.com [kazuhooku@gmail.com]; Lubashev, Igor [iluba= she@akamai.com]; huitema@huitema.net [huitema@huitema.net]
CC: quic@ietf.org [quic@ietf.org]
Subject: RE: Using Long Header packets for PMTUD probes
Sending explicit invalid headers would pollute logs and make it more diffic= ult to track down problems.

I’d assume probes are infrequent, but otherwise they might also tie u= p resources and prevent (by the nature of greasing) dropping packets in DDo= S scenario, or black listing addresses with bad content for a while.

Mikkel

On 30 June 2018 at 06.22.36, Lubashev, Igor (ilubashe=3D40akamai.com= @dmarc.ietf.org) wrote:

I like the idea of greasing. I also like the idea of using= 1-rtt headers to make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL"= ; and "0-RTT", because that will confuse stateless load balancers= (these packet types are expected to carry random destination CID). But RET= RY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@g= mail.com]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [huitem= a@huitema.net]
CC: Lubashev, Igor [ilubashe@= akamai.com]; IETF QUIC WG [quic@ietf.o= rg]
Subject: Re: Using Long Header packets for PMTUD probes

20= 18-06-30 9:18 GMT+09:00 Christian Huitema <huitema@huitema.net>:
> On 6/29/2018 2:00 PM, Lubashev, Igor wrote:
>
> We talked briefly in Kista about the possibility of using Long Header<= br> > packets for PMTUD probes.  See Issue 1243
> (https://github.com/quicwg/base-drafts/issues/12= 43) for context.  Briefly,
> load balancers that use server CID need that server CID to route ICMPv= 6
> packets back to the server doing PMTUD.
>
>
>
> @'Kazuho Oku' suggested using the new packet coalescing functionality = by
> sending an invalid long-header packet and coalescing it with a valid > short-header packet.  This would have to work, if one follows the= current
> spec strictly.  This is definitely a hack, however.
>
>
>
> I would like to come up with something that is not a hack, does not re= quire
> sending deliberately invalid packets, but also not to complicate the d= esign
> with the need to care about key phase and whatever else one wants to p= ut in
> the short-header in the future.
>
>
>
> What do people think about a new “0x7B – PMTU Probe”= long header packet
> type?
>
> A packet of that type would just be a bare minimum long header packet = per
> Invariants (nothing after source CID), and its only purpose would be t= o be
> coalesced with other QUIC packets.
>
>
> My personal inclination is to just ignore ICMP, and thus not have to d= eal
> with related attacks. My limited experience so far is that active PMTU=
> discovery succeeds after just a couple of probes.
>
> In any case, I would rather not have a specific "PMTU Probe"= long header --
> I would rather not disclose to middleboxes that the node is engaged in=
> PMTUD. But I could see the point of a generic "1-RTT" long h= eader. It could
> help make stateless reset work. And it could be sent proactively, say = every
> few RTT, as a form of greasing.

+1

Use of an invalid long header packet is a form of greasing. There is
no point in explicitly disclosing the fact that an endpoint is engaged
in a PMTUD.

Hence I continue to believe that using an invalid long header packet
for the purpose would be fine.

It *could* be a Retry packet as Ian suggests, but it can be anything
else. And even if it is not a Retry packet, it does not need to be
encrypted or carry the AEAD tag, because nobody is going to decrypt it
(for example a Handshake packet with a zero-length payload is just an
ordinary form of an invalid packet).

> -- Christian Huitema
>
>
>



--
Kazuho Oku
--_000_df2ad840e4f34f00a3d8867c76ad287austx2exdag1mb5msgcorpak_-- From nobody Sat Jun 30 11:11:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484D3130DE2 for ; Sat, 30 Jun 2018 11:11:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 88TFlJSPedqX for ; Sat, 30 Jun 2018 11:11:20 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 222C8130DDB for ; Sat, 30 Jun 2018 11:11:19 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx64.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fZKL7-0001xO-Hn for quic@ietf.org; Sat, 30 Jun 2018 20:11:18 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fZKL4-0002yS-Q5 for quic@ietf.org; Sat, 30 Jun 2018 14:11:15 -0400 Received: (qmail 19951 invoked from network); 30 Jun 2018 18:11:11 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.74]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jun 2018 18:11:11 -0000 To: Praveen Balasubramanian , "Lubashev, Igor" , "kazuhooku@gmail.com" Cc: "quic@ietf.org" References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Sat, 30 Jun 2018 11:11:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------27E8BDA3D3BFD28B4B7C47D6" Content-Language: en-US Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions) X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rUD4Qp9YjVuqOEEgZNs8pV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViG63qURdim96QkovyzVpSTM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBmePYa3CQqb9L6x2mHOMrWx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXjCYqLkE/yXcDWRb/BCaEznnXm95a0vRtjH3/UwFOlrcpXK5uK/uyK 9WFAc2ArGWK3B+q+bUHXAsYFgsNREGhlzTFYPIyr5voE3ggyv83xvYRfyCMB4QZToA5YKb0SaS5E llm5CBzrwBATJ22MAarYF38+1Ld/o5jGCpWO7tD53U7k+vjbEFIODONvVl7uk83g5QZjLCEoUg1Y y5V2RcC564a1VhBkCngjhrK9f8csxNfH1yALUGC6BHMPRvkcc+0pHUcSPzy/ctQSmDKsmcj89R/2 gMGq0KWAzmMf+ibVDq3MNIorKOYgvz2LkLDi/veqWKEc9MBxZCWS72/wjopIVAY+3RHRetx4B6Z4 Ei5woFss+n2ffnQxt6aJ7klZab+5U3mWTJPTqb+xVIKqgeO7n3iwosDmKSszPVW9RecIRsxn9uie 2n4+ooHGqAOWILQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 18:11:23 -0000 This is a multi-part message in MIME format. --------------27E8BDA3D3BFD28B4B7C47D6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/29/2018 11:26 PM, Praveen Balasubramanian wrote: > > All out of order packets elicit an immediate ACK, this applies to QUIC > the same way it applies to TCP. > > =A0 > > Section 3.4 of recovery spec: > > =A0 > > =A0=A0 Out-of-order packets SHOULD be acknowledged more quickly, in ord= er to > > =A0=A0 accelerate loss recovery.=A0 The receiver SHOULD send an immedia= te ACK > > =A0=A0 when it receives a new packet which is not one greater than the > > =A0=A0 largest received packet number. > Yes, but I don't think this is what Ian is looking for. Ian is looking for something mechanical, "if you receive this signal please send an ACK right now." The paragraph that you quote does not achieve that. In it, "SHOULD" stands for something like "SHOULD unless you think you are smarter than that." For example, a receiver that experiences lots of out of order deliveries might replace the last sentence by "when it receives a new packet which is not X greater than the largest received packet number", where X is based on an estimate of current out of order deliveries. Besides, the sender might wish for an immediate ACK for other reasons than managing out of order deliveries. Precise time management or checking for connectivity come to mind. -- Christian Huitema --------------27E8BDA3D3BFD28B4B7C47D6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 6/29/2018 11:26 PM, Praveen Balasubramanian wrote:

All out of order packets elicit an immediate ACK, this applies to QUIC the same way it applies to TCP.

 

Section 3.4 of recovery spec:

 

   Out-of-order packets SHOULD be acknowledged more quickly, in order to

   accelerate loss recovery.  The receiver SHOULD send an immediate ACK

   when it receives a new packet which is not one greater than the

   largest received packet number.


Yes, but I don't think this is what Ian is looking for. Ian is looking for something mechanical, "if you receive this signal please send an ACK right now."

The paragraph that you quote does not achieve that. In it, "SHOULD" stands for something like "SHOULD unless you think you are smarter than that." For example, a receiver that experiences lots of out of order deliveries might replace the last sentence by "when it receives a new packet which is not X greater than the largest received packet number", where X is based on an estimate of current out of order deliveries.

Besides, the sender might wish for an immediate ACK for other reasons than managing out of order deliveries. Precise time management or checking for connectivity come to mind.

-- Christian Huitema
--------------27E8BDA3D3BFD28B4B7C47D6-- From nobody Sat Jun 30 11:12:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F267F130DDB for ; Sat, 30 Jun 2018 11:12:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4XSqaWJvEFw3 for ; Sat, 30 Jun 2018 11:12:29 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2F6DE130DC9 for ; Sat, 30 Jun 2018 11:12:29 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fZKMD-0002Wv-Nu for quic@ietf.org; Sat, 30 Jun 2018 20:12:26 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fZKMB-0003Kz-9j for quic@ietf.org; Sat, 30 Jun 2018 14:12:24 -0400 Received: (qmail 21998 invoked from network); 30 Jun 2018 18:12:21 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.74]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jun 2018 18:12:21 -0000 To: quic@ietf.org References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <317e7b72-6c84-635a-4de9-cc8079950d01@huitema.net> Date: Sat, 30 Jun 2018 11:12:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4535E089ADDA28D66394786A" Content-Language: en-US Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions) X-Originating-IP: 168.144.250.231 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5raiNMKHq6h4Kmbq4z7nzrx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViCaLoPIuLpOYClzWPo+6NQ87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYb2zh+9sZH+EhWDsCVUq+frMC4TvCXwec y35+2hkBCx9z1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqz6Jnv65JqzoprPQQCAlAFYE7tCqypI5WX0qWh4YQLC3TiQLgoE1Hbc4 jxRo9vGQbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLUKQCrMv/Srp/VLqDjjh0L1QKHY 6H+wSCoVvwvquzDDiPkKIKnisj+1ZHYjRAh7nr2Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 18:12:31 -0000 This is a multi-part message in MIME format. --------------4535E089ADDA28D66394786A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Oops. Attributed to Ian what was really Igor's idea. Sorry. On 6/30/2018 11:11 AM, Christian Huitema wrote: > > > > On 6/29/2018 11:26 PM, Praveen Balasubramanian wrote: >> >> All out of order packets elicit an immediate ACK, this applies to >> QUIC the same way it applies to TCP. >> >>   >> >> Section 3.4 of recovery spec: >> >>   >> >>    Out-of-order packets SHOULD be acknowledged more quickly, in order to >> >>    accelerate loss recovery.  The receiver SHOULD send an immediate ACK >> >>    when it receives a new packet which is not one greater than the >> >>    largest received packet number. >> > > Yes, but I don't think this is what Ian is looking for. Ian is looking > for something mechanical, "if you receive this signal please send an > ACK right now." > > The paragraph that you quote does not achieve that. In it, "SHOULD" > stands for something like "SHOULD unless you think you are smarter > than that." For example, a receiver that experiences lots of out of > order deliveries might replace the last sentence by "when it receives > a new packet which is not X greater than the largest received packet > number", where X is based on an estimate of current out of order > deliveries. > > Besides, the sender might wish for an immediate ACK for other reasons > than managing out of order deliveries. Precise time management or > checking for connectivity come to mind. > > -- Christian Huitema --------------4535E089ADDA28D66394786A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Oops. Attributed to Ian what was really Igor's idea. Sorry.


On 6/30/2018 11:11 AM, Christian Huitema wrote:



On 6/29/2018 11:26 PM, Praveen Balasubramanian wrote:

All out of order packets elicit an immediate ACK, this applies to QUIC the same way it applies to TCP.

 

Section 3.4 of recovery spec:

 

   Out-of-order packets SHOULD be acknowledged more quickly, in order to

   accelerate loss recovery.  The receiver SHOULD send an immediate ACK

   when it receives a new packet which is not one greater than the

   largest received packet number.


Yes, but I don't think this is what Ian is looking for. Ian is looking for something mechanical, "if you receive this signal please send an ACK right now."

The paragraph that you quote does not achieve that. In it, "SHOULD" stands for something like "SHOULD unless you think you are smarter than that." For example, a receiver that experiences lots of out of order deliveries might replace the last sentence by "when it receives a new packet which is not X greater than the largest received packet number", where X is based on an estimate of current out of order deliveries.

Besides, the sender might wish for an immediate ACK for other reasons than managing out of order deliveries. Precise time management or checking for connectivity come to mind.

-- Christian Huitema

--------------4535E089ADDA28D66394786A-- From nobody Sat Jun 30 17:45:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E57130EF9 for ; Sat, 30 Jun 2018 17:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ST3S5o07; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CKjhJuoI 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 Q6Ej15T3ng11 for ; Sat, 30 Jun 2018 17:45:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45987130EF8 for ; Sat, 30 Jun 2018 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7430221751 for ; Sat, 30 Jun 2018 20:45:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 30 Jun 2018 20:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pFuoDDVXZTCOq4dDV /UlvuqJtM92c0RAoUOuhSntQPc=; b=ST3S5o07CT95XbDudM11FIPYxmDCfJAL3 y8+Npv82dyb4PQdYmJT84O6MK4EDMyFOOh7PNyBcR+yuO/RPWkhYQ1gU8hIfsyuy yXKTMBAo7LyUHA0z1JTiAgn0zz1msSPSU+PatuDOE5etDg295P/e1EQoxrXKn+ME QDwG2BYEEjDDVCkucHyaGFKnUSBLewFDVISEYyy3H/9Wf35fhEv4Bk0iJYHhauVg 7LlRHaPVHx3dMuXkyX/NB7BF8XK5hQOJiAeppyr86GyDnFnmQOOk/3+yCg3rBtGY KWQ3g6+Daih0cgi2VvSo8S5Gr2OeoTxArzGeqOXtfSEtXVuPpPwqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=pFuoDDVXZTCOq4dDV/UlvuqJtM92c0RAoUOuhSntQPc=; b=CKjhJuoI e6B40Pqf9RW4Lvo/v4U2Ed7Y9rcozwgPiqgRK16+hL+rx26p7uieKapElhbXZIF5 5gMUVAXEGFsHs00rsJFG8Ow2f2bC3XqYvlzaJieyedVDNd+d/x8UruBhNYam9UBr +jZBgTdecTc5e9y3rpzE0I1/0WlaiK3FGy39Y+BporDRLEBJ+v1AluzyvnHJgpw3 iO1pe/yxRArzYpR6KKfLFZdNc2X/ZS1y1I68Iz3Pq0vit6eQVZjQrHNwWVtGlIGG XMpAxkzUUtRqhfcGRzW1FbpB1bhtPXaWBeJaF7fz+JQn8/NZihOEGAF9skUg1P+2 1MLm9bpxSUuo4g== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 695251025C for ; Sat, 30 Jun 2018 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id DF724C9EB4 for ; Sun, 1 Jul 2018 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0820399435580200625==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180701004517.DF724C9EB4@cloud.mnot.net> Date: Sun, 1 Jul 2018 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 00:45:26 -0000 --===============0820399435580200625== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+10/-7/=F0=9F=92=AC73) 10 issues created: - Frame type field in APPLICATION_CLOSE (by igorlord) https://github.com/quicwg/base-drafts/issues/1508 = - Can a client send 0-RTT data when receiving Retry? (by kazuho) https://github.com/quicwg/base-drafts/issues/1507 = - HTTP Security Considerations (by rpaulo) https://github.com/quicwg/base-drafts/issues/1506 = - Stateless Reset from clients, bis (by igorlord) https://github.com/quicwg/base-drafts/issues/1505 = - Make Packet Number a standard varint, with no inference (by martinduke) https://github.com/quicwg/base-drafts/issues/1502 = - Disagreement about Path Liveness (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1495 [-transport] [design] = - Packet Number Must Be Decrypted to Read Initial Token Field (by nibanks) https://github.com/quicwg/base-drafts/issues/1492 = - Greasing for Unidirectional Stream Types (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1490 [-http] [design] = - Guidance for flow control and ACK of extension frames (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1487 = - Client's initial destination CID is unauthenticated (by kazuho) https://github.com/quicwg/base-drafts/issues/1486 = 20 issues received 73 new comments: - #1490 Greasing for Unidirectional Stream Types (14 by kazuho, martintho= mson, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/1490 [-http] [design] = - #1479 Client's initial source CID is unauthenticated (7 by kazuho, chri= s-wood) https://github.com/quicwg/base-drafts/issues/1479 [-transport] [design] = - #1492 Packet Number Must Be Decrypted to Read Initial Token Field (7 by= martinthomson, nibanks, kazuho, ianswett) https://github.com/quicwg/base-drafts/issues/1492 [-transport] [design] = - #1495 Disagreement about CID Liveness (7 by kazuho, mikkelfj, ianswett,= MikeBishop) https://github.com/quicwg/base-drafts/issues/1495 [-transport] [design] = - #1484 Negative Connection ID Sequence Number (6 by martinthomson, mikke= lfj, kazuho, MikeBishop) https://github.com/quicwg/base-drafts/issues/1484 [-transport] [design] = - #1486 Client's initial destination CID is unauthenticated (5 by kazuho,= martinthomson) https://github.com/quicwg/base-drafts/issues/1486 [-transport] [design] = - #1243 ICMP and ICMPv6 PMTUD with asymmetric connection-ids (4 by igorlo= rd, gorryfair) https://github.com/quicwg/base-drafts/issues/1243 [-transport] [design]= [parked] = - #1505 Stateless Reset from clients, bis (4 by igorlord, hardie, MikeBis= hop) https://github.com/quicwg/base-drafts/issues/1505 = - #1481 Fragility in ECN counters with lost acks (3 by gloinul, martintho= mson, janaiyengar) https://github.com/quicwg/base-drafts/issues/1481 [-recovery] [-transpo= rt] [design] = - #1483 Connection ID Sequence Number and Server's Preferred Address (3 b= y martinthomson, janaiyengar, MikeBishop) https://github.com/quicwg/base-drafts/issues/1483 [-transport] [design] = - #1438 Resending ACKs increases max_ack_delay unnecessarily (2 by jongle= zb, ianswett) https://github.com/quicwg/base-drafts/issues/1438 [-recovery] [design] = - #1443 Stateless Reset Eternal Ping Pong (2 by martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/1443 [-transport] [design] = - #1507 Can a client send 0-RTT data when receiving Retry? (2 by ekr, nib= anks) https://github.com/quicwg/base-drafts/issues/1507 = - #804 ECN echo in ACK frame or as separate frame (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/804 [-transport] [design] = [parked] = - #805 ECN echo encoding, detailed packet level or ECN marked bytes (1 by= martinthomson) https://github.com/quicwg/base-drafts/issues/805 [-transport] [design] = [parked] = - #1448 What if the packet number of a retry packet is not zero? (1 by ma= rtinthomson) https://github.com/quicwg/base-drafts/issues/1448 [-transport] [design] = - #1474 Retry Token Makeup (1 by nibanks) https://github.com/quicwg/base-drafts/issues/1474 [-transport] [design] = - #1502 Make Packet Number a standard varint, with no inference (1 by ian= swett) https://github.com/quicwg/base-drafts/issues/1502 = - #1508 Frame type field in APPLICATION_CLOSE (1 by ianswett) https://github.com/quicwg/base-drafts/issues/1508 = - #1487 Guidance for flow control and ACK of extension frames (1 by marti= nthomson) https://github.com/quicwg/base-drafts/issues/1487 = 7 issues closed: - Retry Token Makeup https://github.com/quicwg/base-drafts/issues/1474 [-= transport] [design] = - Applications and Stream IDs https://github.com/quicwg/base-drafts/issue= s/910 [-http] [-transport] [design] [has-proposal] = - Client's initial source CID is unauthenticated https://github.com/quicw= g/base-drafts/issues/1479 [-transport] [design] = - ECN echo encoding, detailed packet level or ECN marked bytes https://gi= thub.com/quicwg/base-drafts/issues/805 [-transport] [design] [parked] = - ECN echo in ACK frame or as separate frame https://github.com/quicwg/ba= se-drafts/issues/804 [-transport] [design] [parked] = - Stream 0 DT proposal conflicts with PRIORITY https://github.com/quicwg/= base-drafts/issues/1421 [-http] [design] = - Priority grouping node ambiguity https://github.com/quicwg/base-drafts/= issues/441 [-http] [design] [needs-discussion] = Pull requests ------------- * quicwg/base-drafts (+9/-7/=F0=9F=92=AC22) 9 pull requests submitted: - Editorial: initial offsets -> initial limits (by igorlord) https://github.com/quicwg/base-drafts/pull/1504 = - Server push tidy up (by LPardue) https://github.com/quicwg/base-drafts/pull/1503 = - Rework Retry packet (by martinthomson) https://github.com/quicwg/base-drafts/pull/1498 = - CID Lifetime Management (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1496 [-transport] [design] = - qpack: section reference is broken (by reschke) https://github.com/quicwg/base-drafts/pull/1494 = - Add an appendix related to packet number decoding. (by rpaulo) https://github.com/quicwg/base-drafts/pull/1493 = - Don't Change Source CID After Retry (by nibanks) https://github.com/quicwg/base-drafts/pull/1491 = - Correct packet number example (by martinthomson) https://github.com/quicwg/base-drafts/pull/1489 = - Added change logs for -13 (by martinthomson) https://github.com/quicwg/base-drafts/pull/1488 = 10 pull requests received 22 new comments: - #1491 Don't Change Source CID After Retry (7 by martinthomson, MikeBish= op, nibanks, kazuho, mikkelfj) https://github.com/quicwg/base-drafts/pull/1491 = - #1493 Add an appendix related to packet number decoding. (4 by maskit, = martinthomson) https://github.com/quicwg/base-drafts/pull/1493 = - #1359 Unidirectional Stream Headers in HTTP (3 by LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/1359 [-http] [-qpack] [desig= n] = - #1498 Rework Retry packet (2 by martinthomson, kazuho) https://github.com/quicwg/base-drafts/pull/1498 [-transport] = - #1422 Placeholders for PRIORITY (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1422 [-http] [design] = - #1431 Move stream type into frame type (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1431 [-transport] [design] = - #418 Troubleshooting flags in public header (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/418 [-transport] [parked] = - #1072 Define a mechanism for negotiating extensions (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1072 = - #1478 tls: fix citation format (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1478 = - #1237 Clarify QPACK eviction races (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1237 [-qpack] = 7 pull requests merged: - Add an appendix related to packet number decoding. https://github.com/quicwg/base-drafts/pull/1493 = - qpack: section reference is broken https://github.com/quicwg/base-drafts/pull/1494 = - Don't Change Source CID After Retry https://github.com/quicwg/base-drafts/pull/1491 = - Added change logs for -13 https://github.com/quicwg/base-drafts/pull/1488 = - Unidirectional Stream Headers in HTTP https://github.com/quicwg/base-drafts/pull/1359 [-http] [-qpack] [desig= n] = - Correct packet number example https://github.com/quicwg/base-drafts/pull/1489 = - Placeholders for PRIORITY https://github.com/quicwg/base-drafts/pull/1422 [-http] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0820399435580200625== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday July 01, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+10/-7/=F0=9F=92=AC73)

10 issues created:

20 issues received 73 new comments:

7 issues closed:

Pull requests

quicwg/base-drafts (+9/-7/=F0=9F=92=AC22)

9 pull requests submitted:

10 pull requests received 22 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============0820399435580200625==--