From nobody Mon May 4 18:50:15 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ABB1B2D88 for ; Mon, 4 May 2015 18:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1llJlurJO6c for ; Mon, 4 May 2015 18:50:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4003F1B2D85 for ; Mon, 4 May 2015 18:50:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSD29564; Tue, 05 May 2015 01:50:07 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 May 2015 02:50:06 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 5 May 2015 09:50:03 +0800 From: "Weixinpeng (Jackie)" To: Jordan Melzer , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Collection of MPTCP proxy scenarios. Thread-Index: AdCAwvpNnNPeumeBQfS9+TLGmrSnh///e4sA//49DdD/+HUGkP/rkfCg Date: Tue, 5 May 2015 01:50:02 +0000 Message-ID: References: <553DF29E.7000502@tu-berlin.de> <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads> In-Reply-To: <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E337A2Fnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios. X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 01:50:13 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46E337A2Fnkgeml507mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGFuLA0KICAgICAgICAgU29ycnkgZm9yIGxhdGUgcmVwbHkuIChJIGhhdmUganVzdCBj b21lIGJhY2sgZnJvbSBhIHZhY2F0aW9uLi4pDQogICAgICAgICBJIHRoaW5rIHlvdSBoYXZlIHBy b3ZpZGVkIGEgdmVyeSBnb29kIHVzZSBjYXNlIHJlbGF0ZWQgd2l0aCB0aGUgaG9tZSBDUEUgZGV2 aWNlcyB0aGF0IGhhdmUgbW9yZSB0aGFuIG9uZSBpbnRlcmZhY2VzLg0KICAgICAgICAgQXMgbXkg dW5kZXJzdGFuZGluZywgdGhpcyB1c2UgY2FzZSBmb2N1c2VzIG9uIHByb3ZpZGluZyBtdWx0aXBh dGggc3VwcG9ydCBpbiB0aGUgbmV0d29yayBmb3IgVENQIGhvc3RzLiBNeSBmZWVsaW5nIGlzDQog ICAgICAgICB0aGF0IHRoaXMgdXNlIGNhc2UgaXMgYSBiaXQgb2Ygc2ltaWxhciB0byB3aGF0IEx1 a2FzeiBwcm92aWRlZCBiZWxvdy4gSSB0aGluayB0aGlzIGtpbmQgb2YgYmFjay10by1iYWNrIE1Q VENQIHByb3h5IHNldHVwIG1pZ2h0DQogICAgICAgICBiZSB1c2VmdWwgZm9yIHNwZWNpZmljIHNj ZW5hcmlvLg0KDQpSZWdhcmRzLA0KWGlucGVuZw0KDQpGcm9tOiBtdWx0aXBhdGh0Y3AgW21haWx0 bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvcmRhbiBNZWx6 ZXINClNlbnQ6IEZyaWRheSwgTWF5IDAxLCAyMDE1IDE6MTMgQU0NClRvOiBtdWx0aXBhdGh0Y3BA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXVsdGlwYXRodGNwXSBDb2xsZWN0aW9uIG9mIE1QVENQ IHByb3h5IHNjZW5hcmlvcy4NCg0KSGkgWGlucGVuZywNCg0KSSBoYXZlIHVzZWQgYSBiYWNrLXRv LWJhY2sgTVBUQ1AgcHJveHkgc2V0dXAgdG8gYWxsb3cgVENQIHRvIG11bHRpcGF0aCBvdmVyIGEg c2VnbWVudCBvZiBuZXR3b3JrLiAgTXkgdXNlIGNhc2UgaXMgYWxsb3dpbmcgYSBob21lIHJvdXRl ciB0byB1c2UgbW9yZSB0aGFuIG9uZSBJbnRlcm5ldCBjb25uZWN0aW9uLiAgVGhlIGhvbWUgcm91 dGVyIHdvdWxkIGhhdmUgb25lIE1QVENQIHByb3h5IGFuZCB0aGUgSVNQIHdvdWxkIGhhdmUgYW5v dGhlci4gIFRoZSBob21lIGRldmljZXMgd291bGQgbm90IG5lZWQgdG8gcnVuIE1QVENQLCBub3Ig d291bGQgYW55IEludGVybmV0IHNlcnZlcnMuICBUaGUgYWR2YW50YWdlIG9mIE1QVENQIHByb3hp ZXMgaGVyZSBpcyB0aGF0IHRoZSBkaWZmZXJlbnQgbmV0d29yayBjb25uZWN0aW9ucyBjb21pbmcg aW50byB0aGUgaG9tZSBuZWVkIG5vdCBoYXZlIGRldGVybWluaXN0aWMgY2FwYWNpdGllcywgYW5k IHRoZSBzeXN0ZW0gc3VwcG9ydHMgc21vb3RoIGZhaWxvdmVyIGFzIHdlbGwgYXMgYWdncmVnYXRp b24uICBEU0wsIExURSwgY2FibGUsIGFuZCBXaUZpIChlZywgZnJvbSBhIG5laWdoYm91cmluZyBo b21lKSBhcmUgYWxsIGNhbmRpZGF0ZSB0ZWNobm9sb2dpZXMgdG8gYmUgYWdncmVnYXRlZC4NCg0K VGhlIGNoYWxsZW5nZSBpbiB0aGlzIGNvbmZpZ3VyYXRpb24gaXMgZm9yIHRoZSBwcm94eSB0byBu b3QgcHJldmVudCBhIG5hdGl2ZSBNUFRDUCBkZXZpY2UgZnJvbSBydW5uaW5nIGFuIGVuZC10by1l bmQgTVBUQ1AgY29ubmVjdGlvbi4gIFRoZSBkZWZhdWx0IHByb3h5IG9uZSBnZXRzIGJ5IHJ1bm5p bmcgYSBUQ1AgcHJveHksIGVnIEhBUFJPWFksIG9uIGEgbWFjaGluZSBydW5uaW5nIGFuIE1QVENQ IGtlcm5lbCBkb2VzbuKAmXQgYXZvaWQgcHJveHlpbmcgTVBfSk9JTnMgZnJvbSBzZXNzaW9ucyBp dCBkb2VzbuKAmXQga25vdyBhYm91dCBhbmQgZG9lc27igJl0IGtlZXAgdGhlIGtleXMgdGhlIHNh bWUgb24gYm90aCBzaWRlcyBvZiB0aGUgY29ubmVjdGlvbiwgcHJldmVudGluZyBhbiBNUFRDUCBj YXBhYmxlIGhvbWUgY2xpZW50IGZyb20gc3VjY2Vzc2Z1bGx5IGRvaW5nIGFuIE1QX0pPSU4gdXNp bmcgYSBwYXRoIHRoYXQgZG9lc27igJl0IGdvIHRocm91Z2ggdGhlIGhvbWUgcHJveHkuDQoNCk9u ZSBjb3VsZCBwcm9iYWJseSBtb2RpZnkgSEFQUk9YWSB0byBkbyB0aGlzIGJlaGF2aW91ciBvciBt YWtlIG5mdGFibGVzIHJ1bGVzIHRoYXQgbWFrZSBNUFRDUCB0cmFmZmljIGJ5cGFzcyB0aGUgcHJv eGllcyBhbHRvZ2V0aGVyLg0KDQpJIGFtIG5vdCBlbnRpcmVseSBzYXRpc2ZpZWQgdGhhdCB0aGlz IGtpbmQgb2Ygc2V0dXAgaXMgYSBncmVhdCBpZGVhLCBidXQgdGhlIHVzZSBjYXNlIG9mIGJvbmRp bmcgZGlmZmVyZW50IGNvbm5lY3Rpb25zIHRvZ2V0aGVyIHdpdGhvdXQgY2hhbmdpbmcgYW55dGhp bmcgYXQgdGhlIGVuZHMgb2YgdGhlIG5ldHdvcmsgY291bGQgYmUgY29tcGVsbGluZy4NCg0KSm9y ZGFuDQoNCkZyb206IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgV2VpeGlucGVuZyAoSmFja2llKQ0KU2VudDogQXByaWwgMjgs IDIwMTUgMTE6MTQgUE0NClRvOiBsdWthc3ouYnVkemlzekB0dS1iZXJsaW4uZGU8bWFpbHRvOmx1 a2Fzei5idWR6aXN6QHR1LWJlcmxpbi5kZT47IG11bHRpcGF0aHRjcEBpZXRmLm9yZzxtYWlsdG86 bXVsdGlwYXRodGNwQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbGxl Y3Rpb24gb2YgTVBUQ1AgcHJveHkgc2NlbmFyaW9zLg0KDQpIaSBMdWthc3osDQogICAgICAgICBU aGFua3MgZm9yIHlvdXIgaW5mb3JtYXRpb24uDQogICAgICAgICBJIGhhdmUgcmVhZCB0aHJvdWdo IHRoZSBkb2N1bWVudCwgYW5kIGZpbmQgaXQgYW4gaW50ZXJlc3Rpbmcgc29sdXRpb24sIGJ1dCBJ IHRoaW5rIHRoZSBzb2x1dGlvbiBpbiB0aGUgZG9jdW1lbnQgaXMNCmFib3V0IGhvdyB0byB0cmFu c21pdCB0cmFkaXRpb25hbCBUQ1AgdHJhZmZpYyB0aHJvdWdoIG11bHRpcGF0aCwgYW5kIGl0IGlz IGEgYml0IG9mIGRpZmZlcmVudCBmcm9tIE1QVENQIHByb3RvY29sLg0KICAgICAgICAgVGhhbmtz Lg0KUmVnYXJkcywNClhpbnBlbmcNCg0KRnJvbTogTHVrYXN6IEJ1ZHppc3ogW21haWx0bzpsdWth c3ouYnVkemlzekB0dS1iZXJsaW4uZGVdDQpTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDE1IDQ6 MjYgUE0NClRvOiBXZWl4aW5wZW5nIChKYWNraWUpDQpTdWJqZWN0OiBSZTogW211bHRpcGF0aHRj cF0gQ29sbGVjdGlvbiBvZiBNUFRDUCBwcm94eSBzY2VuYXJpb3MuDQoNCkRlYXIgWGlucGVuZywN CnlvdSBtYXkgaGF2ZSBhIGxvb2sgYXQgdGhlIGRyYWZ0IHdlIHByZXNlbnRlZCBpbiB0aGUgSUVU RiBQYXJpcyBtZWV0aW5nOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF5YXIt dHJhbnNwYXJlbnQtc2NhLXByb3h5LTAwDQpCZXN0IHJlZ2FyZHMsDQpMdWthc3oNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsWBdWthc3ogQnVkemlzeiwg UGguRC4NCg0KUmVzZWFyY2ggRmVsbG93DQoNClRlY2huaXNjaGUgVW5pdmVyc2l0w6R0IEJlcmxp biAoVFUgQmVybGluKQ0KDQpUZWxlY29tbXVuaWNhdGlvbiBOZXR3b3JrcyBHcm91cA0KDQpUZWw6 ICs0OSAzMCAzMTQgMjM4MzYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpPbiAyNy8wNC8xNSAxMDoyMCwgV2VpeGlucGVuZyAoSmFja2llKSB3cm90ZToNCkhp IGFsbCwNCk1QVENQIHByb3h5IGFpbXMgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGRlcGxveW1lbnQg c3VwcG9ydCBmb3IgTVBUQ1AgcHJvdG9jb2wsIGFuZCB0aGUgZnVuY3Rpb25zIHByb3ZpZGVkDQpi eSBNUFRDUCBwcm94eSBjb3VsZCBpbnZvbHZlIHNldmVyYWwgZGlmZmVyZW50IGFzcGVjdHMgc3Vj aCBhcyBzdXBwb3J0aW5nIGVzdGFibGlzaG1lbnQgb2YgTVBUQ1AgY29ubmVjdGlvbiBiZXR3ZWVu DQpNUFRDUCBob3N0IGFuZCB0cmFkaXRpb25hbCBUQ1AgaG9zdCwgYWdncmVnYXRpbmcgb2Ygc3Vi Zmxvd3MgdG8gb25lIHBvaW50IGZvciBzZWN1cml0eSByZWFzb25zLOKApg0KDQpJIGFtIHRyeWlu ZyB0byBmaWd1cmUgb3V0IGFzIG1hbnkgTVBUQ1AgcHJveHkgZGVwbG95bWVudCBzY2VuYXJpb3Mg YXMgcG9zc2libGUgdG8gaGF2ZSBhIG1vcmUgZGVlcCB1bmRlcnN0YW5kaW5nDQpvZiBob3cgTVBU Q1AgcHJveHkgc2hvdWxkIHdvcmsuIEFzIGFuIGV4YW1wbGUsIGhlcmUgYXJlIHNvbWUgcG90ZW50 aWFsIHNjZW5hcmlvczoNCigxKSBNUFRDUCBwcm94eSBpbiBvcGVyYXRvcuKAmXMgbmV0d29yay4g VGhlIG9wZXJhdG9yIGNvdWxkIGRlcGxveSBNUFRDUCBwcm94eSB0byBhc3Npc3QgTVBUQ1AtY2Fw YWJsZSBVRSB0byBjb21tdW5pY2F0ZQ0Kd2l0aCBUQ1Agc2VydmVyIG9uIEludGVybmV0IHVzaW5n IE1QVENQLg0KKDIpIE1QVENQIHByb3h5IGluIGVudGVycHJpc2UgbmV0d29yay4gRW50ZXJwcmlz ZSBuZXR3b3JrIGNvdWxkIGFzayBhbGwgdGhlIHRyYWZmaWMgcGFzcyB0aHJvdWdoIHNlY3VyaXR5 IGNoZWNrIHBvaW50IGZvciBzZWN1cml0eSByZWFzb25zLA0KaW4gdGhpcyBjYXNlLCBhbGwgdGhl IHN1YmZsb3dzIGJlbG9uZyB0byBhIE1QVENQIGNvbm5lY3Rpb24gc2hvdWxkIGJlIGFnZ3JlZ2F0 ZWQgYXQgdGhlIHNhbWUgcG9pbnQuDQpCZXNpZGVzLCBzb21lIGV4aXN0aW5nIGRvY3VtZW50cyBz dWNoIGFzIGRyYWZ0LWRlbmctbXB0Y3AtcHJveHktMDEgYW5kIGRyYWZ0LWxvcGV6LW1wdGNwLW1p ZGRsZWJveC0wMCBhbHNvIHByb3ZpZGUgc29tZSByZWxhdGVkIGRpc2N1c3Npb24uDQoNClNvIGlm IHlvdSBrbm93IHNvbWUgYWRkaXRpb25hbCBNUFRDUCBwcm94eSBkZXBsb3ltZW50IHNjZW5hcmlv cyBlc3BlY2lhbGx5IHRoZSBvbmVzIHRoYXQgaGF2ZSBzb21lIHNwZWNpYWwgcmVxdWlyZW1lbnRz LCBJdCB3aWxsIGJlIGFwcHJlY2lhdGVkIGlmIHlvdSBjb3VsZA0Kc2hhcmUgaXQgaGVyZS4gT3Ig aWYgeW91IGhhdmUgYW55IG90aGVyIGNvbnNpZGVyYXRpb25zIG9uIHRoZSBNUFRDUCBwcm94eSB0 b3BpYywgd2UgY2FuIGFsc28gZGlzY3VzcyBpdCBoZXJlLg0KDQpUaGFua3MhDQoNClJlZ2FyZHMs DQotWGlucGVuZw0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KbXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdA0KDQptdWx0aXBhdGh0 Y3BAaWV0Zi5vcmc8bWFpbHRvOm11bHRpcGF0aHRjcEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3ANCg0K --_000_C5C3BB522B1DDF478AA09545169155B46E337A2Fnkgeml507mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1q dXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGg7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo 5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjpibGFjazt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQs IGRpdi5IVE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0 LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxv b25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBKb3JkYW4sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgU29ycnkgZm9yIGxhdGUgcmVwbHkuIChJIGhhdmUganVzdCBjb21lIGJhY2sgZnJvbSBh IHZhY2F0aW9uLi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB5b3UgaGF2ZSBwcm92aWRl ZCBhIHZlcnkgZ29vZCB1c2UgY2FzZSByZWxhdGVkIHdpdGggdGhlIGhvbWUgQ1BFIGRldmljZXMg dGhhdCBoYXZlIG1vcmUgdGhhbiBvbmUgaW50ZXJmYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB cyBteSB1bmRlcnN0YW5kaW5nLCB0aGlzIHVzZSBjYXNlIGZvY3VzZXMgb24gcHJvdmlkaW5nIG11 bHRpcGF0aCBzdXBwb3J0IGluIHRoZSBuZXR3b3JrIGZvciBUQ1AgaG9zdHMuIE15IGZlZWxpbmcg aXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgdGhpcyB1c2UgY2FzZSBpcyBhIGJpdCBvZiBz aW1pbGFyIHRvIHdoYXQgTHVrYXN6IHByb3ZpZGVkIGJlbG93LiBJIHRoaW5rIHRoaXMga2luZCBv ZiBiYWNrLXRvLWJhY2sgTVBUQ1AgcHJveHkgc2V0dXAgbWlnaHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBiZSB1c2VmdWwgZm9yIHNwZWNpZmljIHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlhpbnBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KIG11bHRpcGF0aHRjcCBb bWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9i PkpvcmRhbiBNZWx6ZXI8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMDEsIDIwMTUgMTox MyBBTTxicj4NCjxiPlRvOjwvYj4gbXVsdGlwYXRodGNwQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBDb2xsZWN0aW9uIG9mIE1QVENQIHByb3h5IHNjZW5h cmlvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+SGkgWGlucGVuZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkg aGF2ZSB1c2VkIGEgYmFjay10by1iYWNrIE1QVENQIHByb3h5IHNldHVwIHRvIGFsbG93IFRDUCB0 byBtdWx0aXBhdGggb3ZlciBhIHNlZ21lbnQgb2YgbmV0d29yay4mbmJzcDsgTXkgdXNlIGNhc2Ug aXMgYWxsb3dpbmcgYSBob21lIHJvdXRlciB0byB1c2UgbW9yZSB0aGFuIG9uZSBJbnRlcm5ldCBj b25uZWN0aW9uLiZuYnNwOw0KIFRoZSBob21lIHJvdXRlciB3b3VsZCBoYXZlIG9uZSBNUFRDUCBw cm94eSBhbmQgdGhlIElTUCB3b3VsZCBoYXZlIGFub3RoZXIuJm5ic3A7IFRoZSBob21lIGRldmlj ZXMgd291bGQgbm90IG5lZWQgdG8gcnVuIE1QVENQLCBub3Igd291bGQgYW55IEludGVybmV0IHNl cnZlcnMuJm5ic3A7IFRoZSBhZHZhbnRhZ2Ugb2YgTVBUQ1AgcHJveGllcyBoZXJlIGlzIHRoYXQg dGhlIGRpZmZlcmVudCBuZXR3b3JrIGNvbm5lY3Rpb25zIGNvbWluZyBpbnRvIHRoZSBob21lIG5l ZWQNCiBub3QgaGF2ZSBkZXRlcm1pbmlzdGljIGNhcGFjaXRpZXMsIGFuZCB0aGUgc3lzdGVtIHN1 cHBvcnRzIHNtb290aCBmYWlsb3ZlciBhcyB3ZWxsIGFzIGFnZ3JlZ2F0aW9uLiZuYnNwOyBEU0ws IExURSwgY2FibGUsIGFuZCBXaUZpIChlZywgZnJvbSBhIG5laWdoYm91cmluZyBob21lKSBhcmUg YWxsIGNhbmRpZGF0ZSB0ZWNobm9sb2dpZXMgdG8gYmUgYWdncmVnYXRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBjaGFsbGVuZ2UgaW4gdGhpcyBjb25maWd1 cmF0aW9uIGlzIGZvciB0aGUgcHJveHkgdG8gbm90IHByZXZlbnQgYSBuYXRpdmUgTVBUQ1AgZGV2 aWNlIGZyb20gcnVubmluZyBhbiBlbmQtdG8tZW5kIE1QVENQIGNvbm5lY3Rpb24uJm5ic3A7IFRo ZSBkZWZhdWx0IHByb3h5IG9uZSBnZXRzIGJ5IHJ1bm5pbmcgYSBUQ1ANCiBwcm94eSwgZWcgSEFQ Uk9YWSwgb24gYSBtYWNoaW5lIHJ1bm5pbmcgYW4gTVBUQ1Aga2VybmVsIGRvZXNu4oCZdCBhdm9p ZCBwcm94eWluZyBNUF9KT0lOcyBmcm9tIHNlc3Npb25zIGl0IGRvZXNu4oCZdCBrbm93IGFib3V0 IGFuZCBkb2VzbuKAmXQga2VlcCB0aGUga2V5cyB0aGUgc2FtZSBvbiBib3RoIHNpZGVzIG9mIHRo ZSBjb25uZWN0aW9uLCBwcmV2ZW50aW5nIGFuIE1QVENQIGNhcGFibGUgaG9tZSBjbGllbnQgZnJv bSBzdWNjZXNzZnVsbHkgZG9pbmcNCiBhbiBNUF9KT0lOIHVzaW5nIGEgcGF0aCB0aGF0IGRvZXNu 4oCZdCBnbyB0aHJvdWdoIHRoZSBob21lIHByb3h5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+T25lIGNvdWxkIHByb2JhYmx5IG1vZGlmeSBIQVBST1hZIHRvIGRvIHRo aXMgYmVoYXZpb3VyIG9yIG1ha2UgbmZ0YWJsZXMgcnVsZXMgdGhhdCBtYWtlIE1QVENQIHRyYWZm aWMgYnlwYXNzIHRoZSBwcm94aWVzIGFsdG9nZXRoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBlbnRpcmVseSBzYXRpc2ZpZWQgdGhhdCB0aGlzIGtp bmQgb2Ygc2V0dXAgaXMgYSBncmVhdCBpZGVhLCBidXQgdGhlIHVzZSBjYXNlIG9mIGJvbmRpbmcg ZGlmZmVyZW50IGNvbm5lY3Rpb25zIHRvZ2V0aGVyIHdpdGhvdXQgY2hhbmdpbmcgYW55dGhpbmcg YXQgdGhlIGVuZHMgb2YgdGhlIG5ldHdvcmsNCiBjb3VsZCBiZSBjb21wZWxsaW5nLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Sm9yZGFuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ DQogbXVsdGlwYXRodGNwIFs8YSBocmVmPSJtYWlsdG86bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPldlaXhpbnBlbmcgKEphY2tpZSk8YnI+DQo8Yj5TZW50OjwvYj4gQXByaWwg MjgsIDIwMTUgMTE6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpsdWthc3ou YnVkemlzekB0dS1iZXJsaW4uZGUiPmx1a2Fzei5idWR6aXN6QHR1LWJlcmxpbi5kZTwvYT47DQo8 YSBocmVmPSJtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnIj5tdWx0aXBhdGh0Y3BAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBDb2xsZWN0aW9u IG9mIE1QVENQIHByb3h5IHNjZW5hcmlvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs aWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkhpIEx1a2Fzeiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgZm9yIHlvdXIgaW5m b3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBoYXZlIHJlYWQgdGhyb3VnaCB0aGUgZG9j dW1lbnQsIGFuZCBmaW5kIGl0IGFuIGludGVyZXN0aW5nIHNvbHV0aW9uLCBidXQgSSB0aGluayB0 aGUgc29sdXRpb24gaW4gdGhlIGRvY3VtZW50IGlzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPmFib3V0IGhvdyB0byB0cmFuc21pdCB0cmFkaXRpb25hbCBUQ1AgdHJhZmZpYyB0aHJvdWdo IG11bHRpcGF0aCwgYW5kIGl0IGlzIGEgYml0IG9mIGRpZmZlcmVudCBmcm9tIE1QVENQIHByb3Rv Y29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5YaW5wZW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4NCiBMdWthc3ogQnVkemlzeiBbPGEgaHJlZj0ibWFpbHRvOmx1a2Fz ei5idWR6aXN6QHR1LWJlcmxpbi5kZSI+bWFpbHRvOmx1a2Fzei5idWR6aXN6QHR1LWJlcmxpbi5k ZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyNywgMjAxNSA0OjI2IFBN PGJyPg0KPGI+VG86PC9iPiBXZWl4aW5wZW5nIChKYWNraWUpPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbXVsdGlwYXRodGNwXSBDb2xsZWN0aW9uIG9mIE1QVENQIHByb3h5IHNjZW5hcmlvcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+RGVhciBYaW5wZW5nLDxicj4NCnlvdSBtYXkgaGF2ZSBhIGxvb2sgYXQg dGhlIGRyYWZ0IHdlIHByZXNlbnRlZCBpbiB0aGUgSUVURiBQYXJpcyBtZWV0aW5nOiA8YnI+DQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXlhci10cmFuc3BhcmVu dC1zY2EtcHJveHktMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1heWFyLXRy YW5zcGFyZW50LXNjYS1wcm94eS0wMDwvYT48YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KTHVrYXN6 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 OyI+xYE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+dWthc3ogQnVkemlzeiwgUGguRC48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+UmVzZWFyY2ggRmVsbG93PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTrlrovkvZMiPlRlY2huaXNjaGUgVW5pdmVyc2l0w6R0IEJlcmxpbiAoVFUgQmVybGluKTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5UZWxlY29tbXVuaWNhdGlvbiBOZXR3 b3JrcyBHcm91cDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5UZWw6ICYjNDM7 NDkgMzAgMzE0IDIzODM2PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g MjcvMDQvMTUgMTA6MjAsIFdlaXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk1QVENQIHByb3h5IGFpbXMgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGRl cGxveW1lbnQgc3VwcG9ydCBmb3IgTVBUQ1AgcHJvdG9jb2wsIGFuZCB0aGUgZnVuY3Rpb25zIHBy b3ZpZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPmJ5IE1QVENQIHByb3h5IGNvdWxkIGludm9sdmUgc2V2ZXJhbCBkaWZmZXJl bnQgYXNwZWN0cyBzdWNoIGFzIHN1cHBvcnRpbmcgZXN0YWJsaXNobWVudCBvZiBNUFRDUCBjb25u ZWN0aW9uIGJldHdlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+TVBUQ1AgaG9zdCBhbmQgdHJhZGl0aW9uYWwgVENQIGhvc3Qs IGFnZ3JlZ2F0aW5nIG9mIHN1YmZsb3dzIHRvIG9uZSBwb2ludCBmb3Igc2VjdXJpdHkgcmVhc29u cyzigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgYXMgbWFu eSBNUFRDUCBwcm94eSBkZXBsb3ltZW50IHNjZW5hcmlvcyBhcyBwb3NzaWJsZSB0byBoYXZlIGEg bW9yZSBkZWVwIHVuZGVyc3RhbmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+b2YgaG93IE1QVENQIHByb3h5IHNob3VsZCB3 b3JrLiBBcyBhbiBleGFtcGxlLCBoZXJlIGFyZSBzb21lIHBvdGVudGlhbCBzY2VuYXJpb3M6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPigxKSBNUFRDUCBwcm94eSBpbiBvcGVyYXRvcuKAmXMgbmV0d29yay4gVGhlIG9wZXJhdG9y IGNvdWxkIGRlcGxveSBNUFRDUCBwcm94eSB0byBhc3Npc3QgTVBUQ1AtY2FwYWJsZSBVRSB0byBj b21tdW5pY2F0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj53aXRoIFRDUCBzZXJ2ZXIgb24gSW50ZXJuZXQgdXNpbmcgTVBUQ1Au PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPigyKSBNUFRDUCBwcm94eSBpbiBlbnRlcnByaXNlIG5ldHdvcmsuIEVudGVycHJpc2Ug bmV0d29yayBjb3VsZCBhc2sgYWxsIHRoZSB0cmFmZmljIHBhc3MgdGhyb3VnaCBzZWN1cml0eSBj aGVjayBwb2ludCBmb3Igc2VjdXJpdHkgcmVhc29ucyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW4gdGhpcyBjYXNlLCBhbGwg dGhlIHN1YmZsb3dzIGJlbG9uZyB0byBhIE1QVENQIGNvbm5lY3Rpb24gc2hvdWxkIGJlIGFnZ3Jl Z2F0ZWQgYXQgdGhlIHNhbWUgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc2lkZXMsIHNvbWUgZXhpc3RpbmcgZG9j dW1lbnRzIHN1Y2ggYXMgZHJhZnQtZGVuZy1tcHRjcC1wcm94eS0wMSBhbmQgZHJhZnQtbG9wZXot bXB0Y3AtbWlkZGxlYm94LTAwIGFsc28gcHJvdmlkZSBzb21lIHJlbGF0ZWQgZGlzY3Vzc2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNvIGlmIHlvdSBrbm93IHNvbWUgYWRkaXRpb25hbCBNUFRDUCBw cm94eSBkZXBsb3ltZW50IHNjZW5hcmlvcyBlc3BlY2lhbGx5IHRoZSBvbmVzIHRoYXQgaGF2ZSBz b21lIHNwZWNpYWwgcmVxdWlyZW1lbnRzLCBJdCB3aWxsIGJlIGFwcHJlY2lhdGVkIGlmIHlvdSBj b3VsZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPnNoYXJlIGl0IGhlcmUuIE9yIGlmIHlvdSBoYXZlIGFueSBvdGhlciBjb25z aWRlcmF0aW9ucyBvbiB0aGUgTVBUQ1AgcHJveHkgdG9waWMsIHdlIGNhbiBhbHNvIGRpc2N1c3Mg aXQgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPi1YaW5wZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjps ZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk65a6L5L2TIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTrlrovkvZMiPm11bHRpcGF0aHRjcCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcEBp ZXRmLm9yZyI+bXVsdGlwYXRodGNwQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL211bHRpcGF0aHRjcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t dWx0aXBhdGh0Y3A8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C5C3BB522B1DDF478AA09545169155B46E337A2Fnkgeml507mbxchi_-- From nobody Tue May 5 00:59:23 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6781A1A3B for ; Tue, 5 May 2015 00:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEIP7Ph2HpIL for ; Tue, 5 May 2015 00:59:18 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id C7C091A0242 for ; Tue, 5 May 2015 00:59:18 -0700 (PDT) Received: from mbpobo.local (229.61-201-80.adsl-dyn.isp.belgacom.be [80.201.61.229]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id EA22011EF78; Tue, 5 May 2015 09:59:12 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be EA22011EF78 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1430812753; bh=suC4p7MkWoUPQh9CbcoeOoKCVTKntx2W6iiZkQ7hLNw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding:Date:From: MIME-Version:To:Subject:References:In-Reply-To:Content-Type:; b=RXNIE6QRUPmVp3sfips9OzNLy+l2ZB5C8oPGdN9HsOndsfF068/pznQ7d0EiIfzrv ATiH87L9rq8RSUuICZjNJyhSQmj5aDkQ4ehV/xf8QD38EhdkBBYbjhbLMXACayy3cb wREfjk8ai+HevViDJrmRE/ZhoRl+ZBF6Tw4u8heo= Message-ID: <5548784D.9000605@uclouvain.be> Date: Tue, 05 May 2015 09:59:09 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Weixinpeng (Jackie)" , Jordan Melzer , "multipathtcp@ietf.org" References: <553DF29E.7000502@tu-berlin.de> <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: EA22011EF78.A1D1C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios. X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 07:59:21 -0000 Hello, > > Sorry for late reply. (I have just come back from a vacation..) > > I think you have provided a very good use case related with > the home CPE devices that have more than one interfaces. > > As my understanding, this use case focuses on providing > multipath support in the network for TCP hosts. My feeling is > > that this use case is a bit of similar to what Lukasz provided > below. I think this kind of back-to-back MPTCP proxy setup might > > be useful for specific scenario. This is indeed an important use case which is actively considered by network operators and CPE vendors. There are ongoing discussions within the BBF on this topic for hybrid access networks. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue May 5 04:18:26 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447341A8903 for ; Tue, 5 May 2015 04:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur2ZXrrCEtEu for ; Tue, 5 May 2015 04:18:16 -0700 (PDT) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) (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 002BB1A88F6 for ; Tue, 5 May 2015 04:18:15 -0700 (PDT) X-tubIT-Incoming-IP: 91.65.35.1 Received: from ip5b412301.dynamic.kabel-deutschland.de ([91.65.35.1] helo=[192.168.1.128]) by mail.tu-berlin.de (exim-4.76/mailfrontend-6) with esmtpsa [UNKNOWN:AES128-SHA:128] for id 1Ypard-00084x-45; Tue, 05 May 2015 13:18:14 +0200 Message-ID: <5548A6F4.5080808@tu-berlin.de> Date: Tue, 05 May 2015 13:18:12 +0200 From: Lukasz Budzisz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <553DF29E.7000502@tu-berlin.de> <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050802000004070803030100" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.5.110017 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Archived-At: Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios. X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 11:18:21 -0000 This is a multi-part message in MIME format. --------------050802000004070803030100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Xingpeng, sorry for a delayed reply due the holidays. Our draft proposes a proxy architecture that is agnostic to the multipath solution, meaning it may be applied for multipath TCP (as a multipath-enabling solution) as well. More importantly however, the use case scenarios identified in that draft, apply for multipath TCP proxies, too. Best regards, Lukasz On 05/05/15 03:50, Weixinpeng (Jackie) wrote: > > Hi Jordan, > > Sorry for late reply. (I have just come back from a vacation..) > > I think you have provided a very good use case related with the home > CPE devices that have more than one interfaces. > > As my understanding, this use case focuses on providing multipath > support in the network for TCP hosts. My feeling is > > that this use case is a bit of similar to what Lukasz provided below. > I think this kind of back-to-back MPTCP proxy setup might > > be useful for specific scenario. > > Regards, > > Xinpeng > > *From:*multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf > Of *Jordan Melzer > *Sent:* Friday, May 01, 2015 1:13 AM > *To:* multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] Collection of MPTCP proxy scenarios. > > Hi Xinpeng, > > I have used a back-to-back MPTCP proxy setup to allow TCP to multipath > over a segment of network. My use case is allowing a home router to > use more than one Internet connection. The home router would have one > MPTCP proxy and the ISP would have another. The home devices would > not need to run MPTCP, nor would any Internet servers. The advantage > of MPTCP proxies here is that the different network connections coming > into the home need not have deterministic capacities, and the system > supports smooth failover as well as aggregation. DSL, LTE, cable, and > WiFi (eg, from a neighbouring home) are all candidate technologies to > be aggregated. > > The challenge in this configuration is for the proxy to not prevent a > native MPTCP device from running an end-to-end MPTCP connection. The > default proxy one gets by running a TCP proxy, eg HAPROXY, on a > machine running an MPTCP kernel doesn’t avoid proxying MP_JOINs from > sessions it doesn’t know about and doesn’t keep the keys the same on > both sides of the connection, preventing an MPTCP capable home client > from successfully doing an MP_JOIN using a path that doesn’t go > through the home proxy. > > One could probably modify HAPROXY to do this behaviour or make > nftables rules that make MPTCP traffic bypass the proxies altogether. > > I am not entirely satisfied that this kind of setup is a great idea, > but the use case of bonding different connections together without > changing anything at the ends of the network could be compelling. > > Jordan > > *From:*multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf > Of *Weixinpeng (Jackie) > *Sent:* April 28, 2015 11:14 PM > *To:* lukasz.budzisz@tu-berlin.de > ; multipathtcp@ietf.org > > *Subject:* Re: [multipathtcp] Collection of MPTCP proxy scenarios. > > Hi Lukasz, > > Thanks for your information. > > I have read through the document, and find it an interesting solution, > but I think the solution in the document is > > about how to transmit traditional TCP traffic through multipath, and > it is a bit of different from MPTCP protocol. > > Thanks. > > Regards, > > Xinpeng > > *From:*Lukasz Budzisz [mailto:lukasz.budzisz@tu-berlin.de] > *Sent:* Monday, April 27, 2015 4:26 PM > *To:* Weixinpeng (Jackie) > *Subject:* Re: [multipathtcp] Collection of MPTCP proxy scenarios. > > Dear Xinpeng, > you may have a look at the draft we presented in the IETF Paris meeting: > https://tools.ietf.org/html/draft-ayar-transparent-sca-proxy-00 > Best regards, > Lukasz > > ------------------------------------------ > Łukasz Budzisz, Ph.D. > Research Fellow > Technische Universität Berlin (TU Berlin) > Telecommunication Networks Group > Tel: +49 30 314 23836 > ------------------------------------------ > > On 27/04/15 10:20, Weixinpeng (Jackie) wrote: > > Hi all, > > MPTCP proxy aims to provide additional deployment support for > MPTCP protocol, and the functions provided > > by MPTCP proxy could involve several different aspects such as > supporting establishment of MPTCP connection between > > MPTCP host and traditional TCP host, aggregating of subflows to > one point for security reasons,… > > I am trying to figure out as many MPTCP proxy deployment scenarios > as possible to have a more deep understanding > > of how MPTCP proxy should work. As an example, here are some > potential scenarios: > > (1) MPTCP proxy in operator’s network. The operator could deploy > MPTCP proxy to assist MPTCP-capable UE to communicate > > with TCP server on Internet using MPTCP. > > (2) MPTCP proxy in enterprise network. Enterprise network could > ask all the traffic pass through security check point for security > reasons, > > in this case, all the subflows belong to a MPTCP connection should > be aggregated at the same point. > > Besides, some existing documents such as draft-deng-mptcp-proxy-01 > and draft-lopez-mptcp-middlebox-00 also provide some related > discussion. > > So if you know some additional MPTCP proxy deployment scenarios > especially the ones that have some special requirements, It will > be appreciated if you could > > share it here. Or if you have any other considerations on the > MPTCP proxy topic, we can also discuss it here. > > Thanks! > > Regards, > > -Xinpeng > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------050802000004070803030100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Xingpeng,

sorry for a delayed reply due the holidays.
Our draft proposes a proxy architecture that is agnostic to the multipath solution, meaning it may be applied for multipath TCP (as a multipath-enabling solution) as well.
More importantly however, the use case scenarios identified in that draft, apply for multipath TCP proxies, too.

Best regards,
Lukasz

On 05/05/15 03:50, Weixinpeng (Jackie) wrote:

Hi Jordan,

         Sorry for late reply. (I have just come back from a vacation..)

         I think you have provided a very good use case related with the home CPE devices that have more than one interfaces.

         As my understanding, this use case focuses on providing multipath support in the network for TCP hosts. My feeling is

         that this use case is a bit of similar to what Lukasz provided below. I think this kind of back-to-back MPTCP proxy setup might

         be useful for specific scenario.

        

Regards,

Xinpeng

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Jordan Melzer
Sent: Friday, May 01, 2015 1:13 AM
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

 

Hi Xinpeng,

 

I have used a back-to-back MPTCP proxy setup to allow TCP to multipath over a segment of network.  My use case is allowing a home router to use more than one Internet connection.  The home router would have one MPTCP proxy and the ISP would have another.  The home devices would not need to run MPTCP, nor would any Internet servers.  The advantage of MPTCP proxies here is that the different network connections coming into the home need not have deterministic capacities, and the system supports smooth failover as well as aggregation.  DSL, LTE, cable, and WiFi (eg, from a neighbouring home) are all candidate technologies to be aggregated.

 

The challenge in this configuration is for the proxy to not prevent a native MPTCP device from running an end-to-end MPTCP connection.  The default proxy one gets by running a TCP proxy, eg HAPROXY, on a machine running an MPTCP kernel doesn’t avoid proxying MP_JOINs from sessions it doesn’t know about and doesn’t keep the keys the same on both sides of the connection, preventing an MPTCP capable home client from successfully doing an MP_JOIN using a path that doesn’t go through the home proxy.

 

One could probably modify HAPROXY to do this behaviour or make nftables rules that make MPTCP traffic bypass the proxies altogether.

 

I am not entirely satisfied that this kind of setup is a great idea, but the use case of bonding different connections together without changing anything at the ends of the network could be compelling.

 

Jordan

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Weixinpeng (Jackie)
Sent: April 28, 2015 11:14 PM
To: lukasz.budzisz@tu-berlin.de; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

 

Hi Lukasz,

         Thanks for your information.

         I have read through the document, and find it an interesting solution, but I think the solution in the document is

about how to transmit traditional TCP traffic through multipath, and it is a bit of different from MPTCP protocol.

         Thanks.

Regards,

Xinpeng

 

From: Lukasz Budzisz [mailto:lukasz.budzisz@tu-berlin.de]
Sent: Monday, April 27, 2015 4:26 PM
To: Weixinpeng (Jackie)
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

 

Dear Xinpeng,
you may have a look at the draft we presented in the IETF Paris meeting:
https://tools.ietf.org/html/draft-ayar-transparent-sca-proxy-00
Best regards,
Lukasz 

------------------------------------------
Łukasz Budzisz, Ph.D.
Research Fellow
Technische Universität Berlin (TU Berlin)
Telecommunication Networks Group
Tel: +49 30 314 23836
------------------------------------------

On 27/04/15 10:20, Weixinpeng (Jackie) wrote:

Hi all,

MPTCP proxy aims to provide additional deployment support for MPTCP protocol, and the functions provided

by MPTCP proxy could involve several different aspects such as supporting establishment of MPTCP connection between

MPTCP host and traditional TCP host, aggregating of subflows to one point for security reasons,…

 

I am trying to figure out as many MPTCP proxy deployment scenarios as possible to have a more deep understanding

of how MPTCP proxy should work. As an example, here are some potential scenarios:

(1) MPTCP proxy in operator’s network. The operator could deploy MPTCP proxy to assist MPTCP-capable UE to communicate

with TCP server on Internet using MPTCP.

(2) MPTCP proxy in enterprise network. Enterprise network could ask all the traffic pass through security check point for security reasons,

in this case, all the subflows belong to a MPTCP connection should be aggregated at the same point.

Besides, some existing documents such as draft-deng-mptcp-proxy-01 and draft-lopez-mptcp-middlebox-00 also provide some related discussion.

 

So if you know some additional MPTCP proxy deployment scenarios especially the ones that have some special requirements, It will be appreciated if you could

share it here. Or if you have any other considerations on the MPTCP proxy topic, we can also discuss it here.

 

Thanks!

 

Regards,

-Xinpeng

 

 

 

 

 

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

 



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

--------------050802000004070803030100-- From nobody Mon May 11 09:26:09 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85DC1A87E9 for ; Mon, 11 May 2015 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdovnX83tgx1 for ; Mon, 11 May 2015 09:26:05 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1701A8A67 for ; Mon, 11 May 2015 09:26:04 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 17:25:55 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 11 May 2015 17:25:54 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 11 May 2015 17:25:54 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 11 May 2015 17:25:54 +0100 From: To: Thread-Topic: WG Last call for "Experience with Multipath TCP" Thread-Index: AQHQjAaqB7NxDkBWbEupZkh4hubTcA== Date: Mon, 11 May 2015 16:25:54 +0000 Message-ID: <1431361552419.40809@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.161.25] Content-Type: multipart/alternative; boundary="_000_143136155241940809btcom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] WG Last call for "Experience with Multipath TCP" X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:26:08 -0000 --_000_143136155241940809btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we'd like to start a 2-week WG last call for this document https://tools.ietf.org/html/draft-ietf-mptcp-experience-01? Please send your comments to the list. As well as suggested improvements, it's also useful to have comments such a= s "i've read the doc and think it's ready to progress" This is aimed at our Milestone Jan 2015 Use-cases and operational experiences (Informational) to IESG here's the relevant part of our Charter << The working group will also explore and document results with several of the proposed use cases for MPTCP in more detail, to ensure that MPTCP works well in practice and that operational experiences and issues are understood and captured. Likely use cases are to offload traffic from 3G to WiFi, and to manage traffic within a data centre. Another scenario is to enable, without changing the MPTCP protocol, operation of a single-homed, MPTCP end host on a campus network that has multiple providers. Prior to publishing a Standards Track specification, the working group will document experimental results and operational experiences to-date. This should consider not just experience with well-connected fat-pipe networks and long-lived flows, but also consider a broader links and types of applications; particularly looking for cases where MPTCP could be detrimental in some way. >> thanks, Phi & Yoshi --_000_143136155241940809btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

we'd like to start a 2-week WG last call for this document

https://tools.ietf.org/html/draft-iet= f-mptcp-experience-01​ 


Please send your comments to the list. 

As well as suggested improvements, it's also useful to have comments suc= h as "i've read the doc and think it's ready to progress"


This is aimed at our Milestone 

Jan 2015 Use-cases and operational experiences (Informational) to IESG


here's the relevant part of our Charter

<<

The working group will also explore and document results with several
of the proposed use cases for MPTCP in more detail, to ensure that
MPTCP works well in practice and that operational experiences and
issues are understood and captured. Likely use cases are to offload
traffic from 3G to WiFi, and to manage traffic within a data centre.
Another scenario is to enable, without changing the MPTCP protocol,
operation of a single-homed, MPTCP end host on a campus network that has multiple providers.

Prior to publishing a Standards Track specification, the working group
will document experimental results and operational experiences to-date.
This should consider not just experience with well-connected fat-pipe
networks and long-lived flows, but also consider a broader links and
types of applications; particularly looking for cases where MPTCP
could be detrimental in some way.

>>

thanks,

Phi & Yoshi

--_000_143136155241940809btcom_-- From nobody Mon May 11 09:44:06 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58A1A8794 for ; Mon, 11 May 2015 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRZIygdDBEVB for ; Mon, 11 May 2015 09:44:02 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1951A8774 for ; Mon, 11 May 2015 09:44:01 -0700 (PDT) Received: from EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 17:43:58 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 11 May 2015 17:43:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 11 May 2015 17:43:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 11 May 2015 17:43:59 +0100 From: To: Thread-Topic: Creating WG document for the Thread-Index: AQHQjAeyo3lsDXLQYES++WCAOBzcdw== Date: Mon, 11 May 2015 16:43:58 +0000 Message-ID: <1431362636609.44739@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.161.25] Content-Type: multipart/alternative; boundary="_000_143136263660944739btcom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Creating WG document for the X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:44:05 -0000 --_000_143136263660944739btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we have this milestone on our charter Apr 2015 Implementation advice (Informational) to IESG We have an existing, expired individual draft "Guidelines for implementers"= https://tools.ietf.org/html/draft-barre-mptcp-impl-00 ? We suggest that this is re-activated as a WG document and then updated with= recent information (Olivier B has kindly offered to do this). Doing this n= ow should let us discuss (finalise?) it during the Prague meeting. Also, this document concentrates on the Linux implementation - so it would = be very valuable if the freeBSD and Apple implementers are able to join the= draft. Please let us know if you can - and of course any other implementat= ions where you can contribute. Please let us know if there are any objections to creating this as a WG doc= ument, or other ideas how we can meet this milestone. thanks Phil & Yoshi ? Here's the additional charter text about this milestone <> --_000_143136263660944739btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi,
we have this milestone on our charter


Apr 2015	Implementation advice (Informational) to IESG





We have an exist=
ing, expired individual draft "Guidelines for implem=
enters" https://tools.ietf.org/html/draft-b=
arre-mptcp-impl-00 ​


We sugg=
est that this is re-activated as a WG document and then updated with recent=
 information (Olivier B has kindly offered to do this). Doing this now=
 should let us discuss (finalise?) it during the Prague meeting.


Also, t=
his document concentrates on the Linux implementation - so it would be very=
 valuable if the freeBSD and Apple implementers are able to join the draft.=
 Please let us know if you can - and of course any other implementations wh=
ere you can contribute. 





Please let us know if there are any objections=
 to creating this as a WG document, or other ideas how we can meet this mil=
estone. 





thanks


Phil & Yoshi


​




Here's the additi=
onal charter text about this milestone




<<The
 working group will document implementation advice. The current

documents
 have several points where an implementer may benefit from

guidance,
 for example about heuristics such as buffer sizing, or from<=
/span>

advice
 about alternative implementations such as bump-in-the-stack.=





>>






--_000_143136263660944739btcom_--


From nobody Sun May 17 03:13:15 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5AB1A902F for ; Sun, 17 May 2015 03:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.712
X-Spam-Level: 
X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyr_waBgFEOx for ; Sun, 17 May 2015 03:13:11 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1BD1A9027 for ; Sun, 17 May 2015 03:13:10 -0700 (PDT)
Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 17 May 2015 11:13:06 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 17 May 2015 11:13:08 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 17 May 2015 11:13:07 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Sun, 17 May 2015 11:13:07 +0100
From: 
To: 
Thread-Topic: IETF hackathon
Thread-Index: AQHQkIJMsXHC2XAENk2jbgpC2oAM3J1/8tSc
Date: Sun, 17 May 2015 10:13:06 +0000
Message-ID: <1431857585427.77044@bt.com>
References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net>
In-Reply-To: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.216.161.25]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [multipathtcp] FW: IETF hackathon
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 May 2015 10:13:13 -0000

Anyone want to join the IETF Prague hackathon with some MPTCP related work?=
=0A=
________________________________________=0A=
From: WGChairs  on behalf of Jari Arkko =0A=
Sent: 17 May 2015 10:17=0A=
To: IETF WG Chairs=0A=
Subject: IETF hackathon=0A=
=0A=
Chairs,=0A=
=0A=
I wanted to highlight that in Prague we will have a hackathon event:=0A=
=0A=
http://www.ietf.org/blog/2015/05/ietf-hackathon/=0A=
=0A=
Some of your working groups might have participants working actively on sof=
tware who might benefit from some time together. Or could implement a small=
 enhancement during the weekend. An opportunity for your consideration.=0A=
=0A=
Jari=0A=
=0A=


From nobody Mon May 18 02:04:21 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C927D1A8830 for ; Mon, 18 May 2015 02:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.114
X-Spam-Level: ****
X-Spam-Status: No, score=4.114 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 GK1fq0kvZ_oS for ; Mon, 18 May 2015 02:04:16 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3181A8836 for ; Mon, 18 May 2015 02:04:15 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B2DFE2781BB for ; Mon, 18 May 2015 18:04:13 +0900 (JST)
Received: by wicmx19 with SMTP id mx19so70236205wic.0 for ; Mon, 18 May 2015 02:04:10 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.121.163 with SMTP id ll3mr41675085wjb.142.1431939850936;  Mon, 18 May 2015 02:04:10 -0700 (PDT)
Received: by 10.194.27.193 with HTTP; Mon, 18 May 2015 02:04:10 -0700 (PDT)
In-Reply-To: <1431361552419.40809@bt.com>
References: <1431361552419.40809@bt.com>
Date: Mon, 18 May 2015 02:04:10 -0700
Message-ID: 
From: Yoshifumi Nishida 
To: multipathtcp 
Content-Type: multipart/alternative; boundary=089e0122911c27abe30516577afc
Archived-At: 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 May 2015 09:04:19 -0000

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

Hi,

I have reviewed this draft and I have the following comments. (sorry for
long lists)


* Title
   Experience with Multipath TCP
     --> Although the title seems to say it will describe experiences for
mptcp, I think it also contains some other stuff.
          For example, some use cases described here look like
possibilities, but haven't fully experienced yet.
          This may be fine as it's still useful info, but I think we had
better clarify what we should include in the doc.

* Section 1
   Section {{usecases}}. Seciton{{congestion}
     --> editorial miss?

* Section 2
   [HotMiddlebox13] documents a corner case with segment splitting that may
lead to desynchronisation between the two hosts.
      --> this sounds a bit problematic. Why you don't elaborate this?

* Section 2
   The results for [HotMiddlebox13] listed in the draft looks good.
However, it seems to me that it has some presumptions for the middleboxes.
   For example, I guess it might presume that middleboxes don't discard
options when it coalesces segments or don't drop options intermittently.
   If so, we might want to describe them.

* Section 3
   Description for backup mode doesn't look experiences to me.  Some
clarifications may be required.

* Section 3
   Description for single-path mode doesn't look experiences to me. Some
clarifications may be required.

* Section 3
   "From a protocol viewpoint, [Cellnet12] discusses the problem posed by
   the unreliability of the ADD_ADDR option and proposes a small
   protocol extension to allow hosts to reliably exchange this option.
   It would be useful to analyze packet traces to understand whether the
   unreliability of the REMOVE_ADDR option poses an operational problem
   in real deployments. "

     --> this seems to be useful info. I might want to see more detailed
info.

* Section 3
  "MPTCP provides a robust data transport and reduces variations in
download latencies".
      --> This looks good results, I might want to see more precise info.

* Section 3
    The use case of coupling mptcp and SDN doesn't look experiences to me.
Some clarifications may be required.
    I'm not very sure "Using an international network" is a part of SDN use
cases although this is described in the same paragraph.

* Section 4
    This seems to be very useful and important info and I personally would
like to see more detailed info.
    For example, which situation we can see performance benefits of OLIA?
How much benefit we can get.
    Is there any concern or risks to use OLIA or default CC? If OLIA is
better, shall we consider adopting it? Or, is it too early?
    It might be good if the authors can provide something on these points.

* Section 5.1
    "mptcp-dev mailing list"
      --> please provide the reference as readers might not know what it is=
.

* Section 5.1
   "The second subflow manager that is currently supported by the
   Multipath TCP implementation in the Linux kernel is the ndiffport
   subflow manager."
       --> we might need a reference for ndiffport?

* Section 5.1
  "This manager was initially created to exploit the
   path diversity that exists between single-homed hosts due to the
   utilization of flow-based load balancing techniques.  This subflow
   manager creates N subflows between the same pair of IP addresses.
   The N subflows are created by the client and differ only in the
   source port selected by the client."

          --> Does this mean the logic of the manager has been changed? If
so, what's the reason for this?
          --> How do we determine N? why it uses the same pair of IP
addresses?

* Section 5.2
   "However, from an implementation point-of-view supporting different
   destination ports for the same Multipath TCP connection introduces a
   new performance issue."

         --> It seems that the rest of the paragraph doesn't provide
specific explanation for performance issue.
              Is it coming from implementation proxy or other reasons?

* Section 5.2
   "This imposes an additional cost on servers, previously not existent on
legacy TCP implementations. "

     -->I understand there'll be additional cost. However, is it a very
complex mechanism to affect performance?
         I'm wondering some kinds of hash table might do some jobs.

* Section 5.3
     I think we should use "M_" state for the status of mptcp otherwise
it'll be confused with the status of TCP.

* Section 5.3
     "Figure 4 shows a very particular issue within Multipath TCP."
       --> I might miss something, but I'm not very sure the cases
described here.
            In my understanding, client should perform close() so that it
will go timewait and server can release the resource quickly.
            However, in this example, server perform close() and goes into
m_timewait. Please clarify this point.

* Section 6
     "SCTP implementations also include schedulers, but these are used to
schedule the different streams. "
        --> Does this mean all schedulers for SCTP are used to schedule the
different stream?

* Section 6
      "Unfortunately, none of the proposed techniques have been implemented
and used in real deployment."
         --> Is there any reason for this? If not, I think we had better
add "at this moment"

* Section 6
      "The simulation scenarios discussed in [PAMS2014] confirm the impact
of the packet scheduler on the performance of Multipath TCP."
         --> Can you elaborate this? Otherwise, it looks a bit ambiguous
info.

* Section 7
       "Taking the smallest MSS does not solve the issue as there might be
a case where the sublow with the smallest MSS will only participate
         marginally to the overall performance therefore reducing the
potential throughput of the other subflows."
        --> It seems to me that this approach might work in some
situations. If so, "does not solve the issue" sounds too much.

* Section 7
        Does the current linux approach perform better than others? No
drawback or potential risk in this approach?
        I would like to see more detailed analysis on this. If this is good
approach, we might want to document the detailed logic?


Thanks,
--
Yoshi



On Mon, May 11, 2015 at 9:25 AM,  wrote:

>  Hi,
>
> we'd like to start a 2-week WG last call for this document
>
> https://tools.ietf.org/html/draft-ietf-mptcp-experience-01=E2=80=8B
>
>
>  Please send your comments to the list.
>
> As well as suggested improvements, it's also useful to have comments such
> as "i've read the doc and think it's ready to progress"
>
>
>  This is aimed at our Milestone
>
> Jan 2015 Use-cases and operational experiences (Informational) to IESG
>
>
>  here's the relevant part of our Charter
>
> <<
>
> The working group will also explore and document results with several
> of the proposed use cases for MPTCP in more detail, to ensure that
> MPTCP works well in practice and that operational experiences and
> issues are understood and captured. Likely use cases are to offload
> traffic from 3G to WiFi, and to manage traffic within a data centre.
> Another scenario is to enable, without changing the MPTCP protocol,
> operation of a single-homed, MPTCP end host on a campus network that has
> multiple providers.
>
> Prior to publishing a Standards Track specification, the working group
> will document experimental results and operational experiences to-date.
> This should consider not just experience with well-connected fat-pipe
> networks and long-lived flows, but also consider a broader links and
> types of applications; particularly looking for cases where MPTCP
> could be detrimental in some way.
>
> >>
>
> thanks,
>
> Phi & Yoshi
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

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


Hi,

I have reviewed this draft and I ha=
ve the following comments. (sorry for long lists)

=

* Title
=C2=A0 =C2=A0Experience with Multipath TCP=

=C2=A0 =C2=A0 =C2=A0--> Although the title seems to say it wi=
ll describe experiences for mptcp, I think it also contains some other stuf=
f.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For example, some use cases=
 described here look like possibilities, but haven't fully experienced =
yet.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This may be fine as it=
9;s still useful info, but I think we had better clarify what we should inc=
lude in the doc.

* Section 1
=C2=A0 =C2=
=A0Section {{usecases}}. Seciton{{congestion}=C2=A0
=C2=A0 =C2=A0=
 =C2=A0--> editorial miss?

* Section 2
=C2=A0 =C2=A0[HotMiddlebox13] documents a corner case with segment splitt=
ing that may lead to desynchronisation between the two hosts.
=C2=
=A0 =C2=A0 =C2=A0 --> this sounds a bit problematic. Why you don't e=
laborate this?

* Section 2
=C2=A0 =C2=A0=
The results for [HotMiddlebox13] listed in the draft looks good. However, i=
t seems to me that it has some presumptions for the middleboxes.
=
=C2=A0 =C2=A0For example, I guess it might presume that middleboxes don'=
;t discard options when it coalesces segments or don't drop options int=
ermittently.=C2=A0
=C2=A0 =C2=A0If so, we might want to describe =
them.

* Section 3
=C2=A0 =C2=A0Descripti=
on for backup mode doesn't look experiences to me.=C2=A0 Some clarifica=
tions may be required.

* Section 3
=C2=
=A0 =C2=A0Description for single-path mode doesn't look experiences to =
me. Some clarifications may be required.

* Section=
 3
=C2=A0 =C2=A0"From a protocol viewpoint, [Cellnet12] disc=
usses the problem posed by
=C2=A0 =C2=A0the unreliability of the =
ADD_ADDR option and proposes a small
=C2=A0 =C2=A0protocol extens=
ion to allow hosts to reliably exchange this option.
=C2=A0 =C2=
=A0It would be useful to analyze packet traces to understand whether the
=C2=A0 =C2=A0unreliability of the REMOVE_ADDR option poses an opera=
tional problem
=C2=A0 =C2=A0in real deployments.=C2=A0"

=C2=A0 =C2=A0 =C2=A0--> this seems to be useful inf=
o. I might want to see more detailed info.

* Secti=
on 3
=C2=A0 "MPTCP provides a robust data transport and=
 reduces variations in download latencies".
=C2=A0 =C2=
=A0 =C2=A0 --> This looks good results, I might want to see more precise=
 info.

* Section 3
=C2=A0 =C2=A0 The use=
 case of coupling mptcp and SDN doesn't look experiences to me. Some cl=
arifications may be required.
=C2=A0 =C2=A0 I'm not very sure=
 "Using an international network" is a part of SDN use cases alth=
ough this is described in the same paragraph.

* Se=
ction 4
=C2=A0 =C2=A0 This seems to be very useful and important =
info and I personally would like to see more detailed info.
=C2=
=A0 =C2=A0 For example, which situation we can see performance benefits of =
OLIA? How much benefit we can get.
=C2=A0 =C2=A0 Is there any con=
cern or risks to use OLIA or default CC? If OLIA is better, shall we consid=
er adopting it? Or, is it too early?
=C2=A0 =C2=A0 It might be go=
od if the authors can provide something on these points.

* Section 5.1
=C2=A0 =C2=A0 "mptcp-dev mailing list&q=
uot;
=C2=A0 =C2=A0 =C2=A0 --> please provide the reference as =
readers might not know what it is.

* Section 5.1
=C2=A0 =C2=A0"The second subflow manager that is current=
ly supported by the
=C2=A0 =C2=A0Multipath TCP implementation in =
the Linux kernel is the ndiffport
=C2=A0 =C2=A0subflow manager.&q=
uot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> we might need a refe=
rence for ndiffport?

* Section 5.1
=C2=
=A0 "This manager was initially created to exploit the
=C2=
=A0 =C2=A0path diversity that exists between single-homed hosts due to the<=
/div>
=C2=A0 =C2=A0utilization of flow-based load balancing techniques.=
=C2=A0 This subflow
=C2=A0 =C2=A0manager creates N subflows betwe=
en the same pair of IP addresses.
=C2=A0 =C2=A0The N subflows are=
 created by the client and differ only in the
=C2=A0 =C2=A0source=
 port selected by the client."
=C2=A0=C2=A0
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Does this mean the logic of the manager=
 has been changed? If so, what's the reason for this?
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> How do we determine N? why it uses the s=
ame pair of IP addresses?

* Section 5.2
=
=C2=A0 =C2=A0"However, from an implementation point-of-view supporting=
 different
=C2=A0 =C2=A0destination ports for the same Multipath =
TCP connection introduces a
=C2=A0 =C2=A0new performance issue.&q=
uot;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> It s=
eems that the rest of the paragraph doesn't provide specific explanatio=
n for performance issue.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Is it coming from implementation proxy or other reasons?

* Section 5.2
=C2=A0 =C2=A0"This imposes a=
n additional cost on servers, previously not existent on legacy TCP impleme=
ntations.=C2=A0"
=C2=A0=C2=A0 =C2=A0 =C2=A0
=C2=A0=
 =C2=A0 =C2=A0-->I understand there'll be additional cost. However, =
is it a very complex mechanism to affect performance?
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0I'm wondering some kinds of hash table might do=
 some jobs.

* Section 5.3
=C2=A0 =C2=A0 =
=C2=A0I think we should use "M_" state for the status of mptcp ot=
herwise it'll be confused with the status of TCP.
=C2=A0 =C2=
=A0 =C2=A0
* Section 5.3
=C2=A0 =C2=A0 =C2=A0"Figure 4 shows a very particular=
 issue within Multipath TCP."
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> I might miss some=
thing, but I'm not very sure the cases described here.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 In my understanding, client should perform close() so =
that it will go timewait and server can release the resource quickly.
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, in this example, server perform close(=
) and goes into m_timewait. Please clarify this point.

* Section 6
=C2=A0 =C2=A0 =C2=A0"SCTP implementations also=C2=A0include schedulers, but these are used to schedul=
e the different=C2=A0streams. "=
;
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 --> Does this mean all schedulers for SCTP are used to schedule t=
he different stream?

* Section 6
=
=C2=A0 =C2=A0 =C2=A0 "Unfortunately, none of the proposed techniques h=
ave been implemented and used in real deployment."
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> Is there any reason for this? If not, I t=
hink we had better add "at this moment"

=
* Section 6
=C2=A0 =C2=A0 =C2=A0 "The simulation scenarios d=
iscussed in [PAMS2014] confirm the impact of the packet scheduler on the pe=
rformance of Multipath TCP."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0--> Can you elaborate this? Otherwise, it looks a bit ambiguous info.=


* Section 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
"Taking the smallest MSS does not solve the issue as there might be a =
case where the sublow with the smallest MSS will only participate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0marginally to the overall performance th=
erefore reducing the potential throughput of the other subflows."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> It seems to me that this approach =
might work in some situations. If so, "does not solve the issue" =
sounds too much.

* Section 7
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Does the current linux approach perform better than other=
s? No drawback or potential risk in this approach?
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 I would like to see more detailed analysis on this. If this i=
s good approach, we might want to document the detailed logic?

Thanks,
--
Yoshi
=



On Mon, May 11, 2015 at 9:25 AM,  <philip.eardley@bt.com<=
/a>> wrote:








Hi,




we'd like to start a 2-week=C2=A0WG last call for this document




https://tools.ietf.org/=
html/draft-ietf-mptcp-experience-01=E2=80=8B=C2=A0









Please send your comments to the list.=C2=A0




As well as suggested improvements, it's also useful to have comments=
 such as "i've read the doc and think it's ready to progress&q=
uot;









This is aimed at our Milestone=C2=A0




Jan 2015 Use-cases and opera=
tional experiences (Informational) to IESG









here's the relevant part of our Charter




<<



The working group will also explore and document results with several

of the proposed use cases for MPTCP in more detail, to ensure that

MPTCP works well in practice and that operational experiences and

issues are understood and captured. Likely use cases are to offload

traffic from 3G to WiFi, and to manage traffic within a data centre.

Another scenario is to enable, without changing the MPTCP protocol,

operation of a single-homed, MPTCP end host on a campus network that has
multiple providers.



Prior to publishing a Standards Track specification, the working group

will document experimental results and operational experiences to-date.

This should consider not just experience with well-connected fat-pipe

networks and long-lived flows, but also consider a broader links and

types of applications; particularly looking for cases where MPTCP

could be detrimental in some way.





>>




thanks,




Phi & Yoshi







_______________________________________________

multipathtcp mailing list

multipathtcp@iet=
f.org

https://www.ietf.org/mailman/listinfo/multipathtcp





--089e0122911c27abe30516577afc--


From nobody Mon May 18 11:29:43 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590821A1B5E for ; Mon, 18 May 2015 11:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBiqmeo14vaX for ; Mon, 18 May 2015 11:29:38 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id BC7331B2A2D for ; Mon, 18 May 2015 11:28:27 -0700 (PDT)
Received: from mbpobo.lan (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9509E11EF57; Mon, 18 May 2015 20:28:16 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 9509E11EF57
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1431973696; bh=Xv0KwbXCdLRwTKoF6JdOiJyc1iBNeEm0YZ5araxEcek=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding:Date:From: MIME-Version:To:Subject:References:In-Reply-To:Content-Type:; b=X5e6Ixu/gMrLHMrZ+4sIE8/2r5dD+gkzmY1fsOzaANRKl6HNL/oI1E+dMQarjQDvp dcr/zzvGaOY7JKNSmzf8eBr+l4scLqD0Cc1RzH0hYmSld/5/b4kzqzWftQJOWTDE5O ran/5t/36WBhiEJNzI3mScMMbCfxcuym4bci/4rA=
Message-ID: <555A2F3F.1020606@uclouvain.be>
Date: Mon, 18 May 2015 20:28:15 +0200
From: Olivier Bonaventure 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Yoshifumi Nishida ,  multipathtcp 
References: <1431361552419.40809@bt.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: 9509E11EF57.A628E
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 May 2015 18:29:42 -0000

Yoshifumi,
>
> I have reviewed this draft and I have the following comments. (sorry for
> long lists)
>

Thanks for the detailed comments. I'll try to answer them below

> * Title
>     Experience with Multipath TCP
>       --> Although the title seems to say it will describe experiences
> for mptcp, I think it also contains some other stuff.
>            For example, some use cases described here look like
> possibilities, but haven't fully experienced yet.
>            This may be fine as it's still useful info, but I think we
> had better clarify what we should include in the doc.

We could remove the discussion of the use cases from this document.

> * Section 1
>     Section {{usecases}}. Seciton{{congestion}
>       --> editorial miss?

Wrong conversion from markdown to text :-(

> * Section 2
>     [HotMiddlebox13] documents a corner case with segment splitting that
> may lead to desynchronisation between the two hosts.
>        --> this sounds a bit problematic. Why you don't elaborate this?

I can expand it based on the text in [HotMiddlebox13]

> * Section 2
>     The results for [HotMiddlebox13] listed in the draft looks good.
> However, it seems to me that it has some presumptions for the middleboxes.
>     For example, I guess it might presume that middleboxes don't discard
> options when it coalesces segments or don't drop options intermittently.
>     If so, we might want to describe them.

I can add other scenarios, but this will make the text more difficult to 
read. Some of the scenarios explored in [HotMiddlebox13] are corner 
cases that are unlikely to happen in practice.

We recently analysed all the MPTCP connections received on 
multipath-tcp.org and observed the following :

Among the 184 thousands Multipath TCP connections in the trace, we 
observed only 125 of them falling back to regular TCP, which happened 
with 28 distinctive client IP addresses. These include 91 HTTP 
connections and 34 FTP connections. The FTP interference is expected and 
due to Application Level Gateways running on NAT boxes. The HTTP 
interference appeared only on the direction from server to client and 
could have been caused by transparent proxies deployed in cellular and 
enterprise networks.

Note that we do not observe interference where a middlebox removes the 
MP_CAPABLE option from the SYN in this dataset.


>
> * Section 3
>     Description for backup mode doesn't look experiences to me.  Some
> clarifications may be required.

There are two issues with the backup mode that could be discussed for 
smartphones. Let us assume for simplicity that the WiFi is used as a 
primary interface and cellular as a backup interface.

The first is that by starting the backup flow (i.e. with a three-way 
handshake) over the cellular interface, the smartphone consummes energy 
and radio channel capacity (typically for a few seconds). If the backup 
subflow is not started immediately, but only when the primary fails, 
then energy and radio channel consumption are reduced.

The second issue that we observe on smartphones is that the status of a 
subflow cannot be described as a binary value (active/inactive). There 
are many situations where a subflow is considered active while it cannot 
efficiently transmit data. A typical example is a smartphone that is far 
away from a WiFi access point, but close enough to perform the 
three-way-handshake. If this subflow is a primary subflow and the 
cellular a backup subflow, then MPTCP will try to retransmit data 
several times over the WiFi interface before stopping the WiFi subflow 
and starting to use the cellular one. This can cause delays of tens of 
seconds before switching to the cellular interface.

>
> * Section 3
>     Description for single-path mode doesn't look experiences to me.
> Some clarifications may be required.
>
> * Section 3
>     "From a protocol viewpoint, [Cellnet12] discusses the problem posed by
>     the unreliability of the ADD_ADDR option and proposes a small
>     protocol extension to allow hosts to reliably exchange this option.
>     It would be useful to analyze packet traces to understand whether the
>     unreliability of the REMOVE_ADDR option poses an operational problem
>     in real deployments. "
>
>       --> this seems to be useful info. I might want to see more
> detailed info.

This should be compared with the decision of Apple to not implement 
ADD_ADDR. We can add some text.
>
> * Section 3
>    "MPTCP provides a robust data transport and reduces variations in
> download latencies".
>        --> This looks good results, I might want to see more precise info.

This sentence comes from the conclusion of the paper IMC13b. What kind 
of more precise information do you expect ?

> * Section 3
>      The use case of coupling mptcp and SDN doesn't look experiences to
> me. Some clarifications may be required.
>      I'm not very sure "Using an international network" is a part of SDN
> use cases although this is described in the same paragraph.

This part could be removed and we could point to the MPTCP bibliography 
for other use cases https://github.com/obonaventure/mptcp-bib

I think that the use case described in a recent NSDI paper
https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/croitoru
should be added to this section because it is important for mobile devices

> * Section 4
>      This seems to be very useful and important info and I personally
> would like to see more detailed info.
>      For example, which situation we can see performance benefits of
> OLIA? How much benefit we can get.
>      Is there any concern or risks to use OLIA or default CC? If OLIA is
> better, shall we consider adopting it? Or, is it too early?
>      It might be good if the authors can provide something on these points.

It is possible to find simulation scenarios/topologies where one 
congestion control algorithm works better than others. However, we 
should not decide on the basis of a small number of examples.

The best approach to compare different congestion control schemes is to 
explore a wide range of network conditions. Christoph Paasch has used an 
experimental design approach to perform this analysis for a bonding 
scenario (two links without congestion). The results are described in
http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp
and have been updated in
http://inl.info.ucl.ac.be/publications/improving-multipath-tcp

Based on these results, there does not seem to be a strong benefit with 
OLIA over LIA. If the WG wants to reconsider the selection of the 
default congestion control scheme, it should use a similar experimental 
approach and use different network topologies.

> * Section 5.1
>      "mptcp-dev mailing list"
>        --> please provide the reference as readers might not know what
> it is.

Will add.

> * Section 5.1
>     "The second subflow manager that is currently supported by the
>     Multipath TCP implementation in the Linux kernel is the ndiffport
>     subflow manager."
>         --> we might need a reference for ndiffport?

There is no explicit document on this path manager afaik.

> * Section 5.1
>    "This manager was initially created to exploit the
>     path diversity that exists between single-homed hosts due to the
>     utilization of flow-based load balancing techniques.  This subflow
>     manager creates N subflows between the same pair of IP addresses.
>     The N subflows are created by the client and differ only in the
>     source port selected by the client."
>            --> Does this mean the logic of the manager has been changed?
> If so, what's the reason for this?
>            --> How do we determine N?

N is a static configuration. Some experiments have been reported in the 
SIGCOMM'11 paper

> why it uses the same pair of IP
> addresses?

Because it is used on single-homed hosts

>
> * Section 5.2
>     "However, from an implementation point-of-view supporting different
>     destination ports for the same Multipath TCP connection introduces a
>     new performance issue."
>
>           --> It seems that the rest of the paragraph doesn't provide
> specific explanation for performance issue.
>                Is it coming from implementation proxy or other reasons?

This comes from an implementation issue because the stack needs to 
listen to more ports.

> * Section 5.2
>     "This imposes an additional cost on servers, previously not existent
> on legacy TCP implementations. "
>       -->I understand there'll be additional cost. However, is it a very
> complex mechanism to affect performance?
>           I'm wondering some kinds of hash table might do some jobs.

I don't think that such a solution has been explored

> * Section 5.3
>       I think we should use "M_" state for the status of mptcp otherwise
> it'll be confused with the status of TCP.

Will add

> * Section 5.3
>       "Figure 4 shows a very particular issue within Multipath TCP."
>         --> I might miss something, but I'm not very sure the cases
> described here.
>              In my understanding, client should perform close() so that
> it will go timewait and server can release the resource quickly.
>              However, in this example, server perform close() and goes
> into m_timewait. Please clarify this point.
>
> * Section 6
>       "SCTP implementations also include schedulers, but these are used
> to schedule the different streams. "
>          --> Does this mean all schedulers for SCTP are used to schedule
> the different stream?

That was our understanding, but maybe there are schedulers on CMT-SCTP 
implementations.

> * Section 6
>        "Unfortunately, none of the proposed techniques have been
> implemented and used in real deployment."
>           --> Is there any reason for this? If not, I think we had
> better add "at this moment"

Exact, everything in the document is to be considered "as of this writing".

> * Section 6
>        "The simulation scenarios discussed in [PAMS2014] confirm the
> impact of the packet scheduler on the performance of Multipath TCP."
>           --> Can you elaborate this? Otherwise, it looks a bit
> ambiguous info.

Will expand.

> * Section 7
>         "Taking the smallest MSS does not solve the issue as there might
> be a case where the sublow with the smallest MSS will only participate
>           marginally to the overall performance therefore reducing the
> potential throughput of the other subflows."
>          --> It seems to me that this approach might work in some
> situations. If so, "does not solve the issue" sounds too much.
>
> * Section 7
>          Does the current linux approach perform better than others? No
> drawback or potential risk in this approach?
>          I would like to see more detailed analysis on this. If this is
> good approach, we might want to document the detailed logic?

It would be interesting to see if other implementors have faced the 
issue and found other solutions to cope with it.


Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


From nobody Mon May 18 20:56:33 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB21A000A for ; Mon, 18 May 2015 20:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unmbv-kEiUhE for ; Mon, 18 May 2015 20:56:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAC81A0006 for ; Mon, 18 May 2015 20:56:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSR86782; Tue, 19 May 2015 03:56:28 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 May 2015 04:56:25 +0100
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.90]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 19 May 2015 11:56:21 +0800
From: "Weixinpeng (Jackie)" 
To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" 
Thread-Topic: WG Last call for "Experience with Multipath TCP"
Thread-Index: AQHQjAaqB7NxDkBWbEupZkh4hubTcJ2CshdQ
Date: Tue, 19 May 2015 03:56:21 +0000
Message-ID: 
References: <1431361552419.40809@bt.com>
In-Reply-To: <1431361552419.40809@bt.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.76.176]
Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46EDCD21Cnkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 03:56:33 -0000

--_000_C5C3BB522B1DDF478AA09545169155B46EDCD21Cnkgeml507mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHJlYWxseSBjb21wcmVoZW5zaXZlIHN1cnZleSAgYWJv
dXQgdGhlIE1QVENQIGV4cGVyaWVuY2VzLCBhbmQgdGhhdCB3b3VsZA0KYmUgdmFsdWFibGUgZm9y
IHRoZSBpbXByb3ZlbWVudCBvZiBNUFRDUC4gU28gSSBzdXBwb3J0IHRoZSBwcm9ncmVzcyBvZiB0
aGlzIGRvY3VtZW50Lg0KDQoNClhpbnBlbmcNCg0KRnJvbTogbXVsdGlwYXRodGNwIFttYWlsdG86
bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwaGlsaXAuZWFyZGxl
eUBidC5jb20NClNlbnQ6IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAxMjoyNiBBTQ0KVG86IG11bHRp
cGF0aHRjcEBpZXRmLm9yZw0KU3ViamVjdDogW211bHRpcGF0aHRjcF0gV0cgTGFzdCBjYWxsIGZv
ciAiRXhwZXJpZW5jZSB3aXRoIE11bHRpcGF0aCBUQ1AiDQoNCg0KSGksDQoNCndlJ2QgbGlrZSB0
byBzdGFydCBhIDItd2VlayBXRyBsYXN0IGNhbGwgZm9yIHRoaXMgZG9jdW1lbnQNCg0KaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXB0Y3AtZXhwZXJpZW5jZS0wMeKAiw0K
DQoNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4NCg0KQXMgd2VsbCBh
cyBzdWdnZXN0ZWQgaW1wcm92ZW1lbnRzLCBpdCdzIGFsc28gdXNlZnVsIHRvIGhhdmUgY29tbWVu
dHMgc3VjaCBhcyAiaSd2ZSByZWFkIHRoZSBkb2MgYW5kIHRoaW5rIGl0J3MgcmVhZHkgdG8gcHJv
Z3Jlc3MiDQoNCg0KDQpUaGlzIGlzIGFpbWVkIGF0IG91ciBNaWxlc3RvbmUNCg0KSmFuIDIwMTUg
VXNlLWNhc2VzIGFuZCBvcGVyYXRpb25hbCBleHBlcmllbmNlcyAoSW5mb3JtYXRpb25hbCkgdG8g
SUVTRw0KDQoNCg0KaGVyZSdzIHRoZSByZWxldmFudCBwYXJ0IG9mIG91ciBDaGFydGVyDQoNCjw8
DQoNClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBleHBsb3JlIGFuZCBkb2N1bWVudCByZXN1
bHRzIHdpdGggc2V2ZXJhbA0Kb2YgdGhlIHByb3Bvc2VkIHVzZSBjYXNlcyBmb3IgTVBUQ1AgaW4g
bW9yZSBkZXRhaWwsIHRvIGVuc3VyZSB0aGF0DQpNUFRDUCB3b3JrcyB3ZWxsIGluIHByYWN0aWNl
IGFuZCB0aGF0IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2VzIGFuZA0KaXNzdWVzIGFyZSB1bmRlcnN0
b29kIGFuZCBjYXB0dXJlZC4gTGlrZWx5IHVzZSBjYXNlcyBhcmUgdG8gb2ZmbG9hZA0KdHJhZmZp
YyBmcm9tIDNHIHRvIFdpRmksIGFuZCB0byBtYW5hZ2UgdHJhZmZpYyB3aXRoaW4gYSBkYXRhIGNl
bnRyZS4NCkFub3RoZXIgc2NlbmFyaW8gaXMgdG8gZW5hYmxlLCB3aXRob3V0IGNoYW5naW5nIHRo
ZSBNUFRDUCBwcm90b2NvbCwNCm9wZXJhdGlvbiBvZiBhIHNpbmdsZS1ob21lZCwgTVBUQ1AgZW5k
IGhvc3Qgb24gYSBjYW1wdXMgbmV0d29yayB0aGF0IGhhcw0KbXVsdGlwbGUgcHJvdmlkZXJzLg0K
DQpQcmlvciB0byBwdWJsaXNoaW5nIGEgU3RhbmRhcmRzIFRyYWNrIHNwZWNpZmljYXRpb24sIHRo
ZSB3b3JraW5nIGdyb3VwDQp3aWxsIGRvY3VtZW50IGV4cGVyaW1lbnRhbCByZXN1bHRzIGFuZCBv
cGVyYXRpb25hbCBleHBlcmllbmNlcyB0by1kYXRlLg0KVGhpcyBzaG91bGQgY29uc2lkZXIgbm90
IGp1c3QgZXhwZXJpZW5jZSB3aXRoIHdlbGwtY29ubmVjdGVkIGZhdC1waXBlDQpuZXR3b3JrcyBh
bmQgbG9uZy1saXZlZCBmbG93cywgYnV0IGFsc28gY29uc2lkZXIgYSBicm9hZGVyIGxpbmtzIGFu
ZA0KdHlwZXMgb2YgYXBwbGljYXRpb25zOyBwYXJ0aWN1bGFybHkgbG9va2luZyBmb3IgY2FzZXMg
d2hlcmUgTVBUQ1ANCmNvdWxkIGJlIGRldHJpbWVudGFsIGluIHNvbWUgd2F5Lg0KDQo+Pg0KDQp0
aGFua3MsDQoNClBoaSAmIFlvc2hpDQo=

--_000_C5C3BB522B1DDF478AA09545169155B46EDCD21Cnkgeml507mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz
cGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNw
YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpI
LUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSByZWFsbHkg
Y29tcHJlaGVuc2l2ZSBzdXJ2ZXkgJm5ic3A7YWJvdXQgdGhlIE1QVENQIGV4cGVyaWVuY2VzLCBh
bmQgdGhhdCB3b3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
YmUgdmFsdWFibGUgZm9yIHRoZSBpbXByb3ZlbWVudCBvZiBNUFRDUC4gU28gSSBzdXBwb3J0IHRo
ZSBwcm9ncmVzcyBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlhpbnBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbXVsdGlwYXRodGNwIFttYWlsdG86
bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnBoaWxp
cC5lYXJkbGV5QGJ0LmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTIsIDIwMTUg
MTI6MjYgQU08YnI+DQo8Yj5Ubzo8L2I+IG11bHRpcGF0aHRjcEBpZXRmLm9yZzxicj4NCjxiPlN1
YmplY3Q6PC9iPiBbbXVsdGlwYXRodGNwXSBXRyBMYXN0IGNhbGwgZm9yICZxdW90O0V4cGVyaWVu
Y2Ugd2l0aCBNdWx0aXBhdGggVENQJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6YmxhY2siPndlJ2QgbGlrZSB0byBzdGFydCBhIDItd2VlayZuYnNwO1dHIGxhc3Qg
Y2FsbCBmb3IgdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1tcHRjcC1leHBlcmllbmNlLTAxIiB0aXRsZT0iaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXB0Y3AtZXhwZXJpZW5jZS0wMQpDdHJsJiM0
MztjbGljayBvciB0YXAgdG8gZm9sbG93IGxpbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLW1wdGNwLWV4cGVyaWVuY2UtMDE8L2E+4oCLJm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr
Ij5BcyB3ZWxsIGFzIHN1Z2dlc3RlZCBpbXByb3ZlbWVudHMsIGl0J3MgYWxzbyB1c2VmdWwgdG8g
aGF2ZSBjb21tZW50cyBzdWNoIGFzICZxdW90O2kndmUgcmVhZCB0aGUgZG9jIGFuZCB0aGluayBp
dCdzIHJlYWR5IHRvIHByb2dyZXNzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIGlzIGFp
bWVkIGF0IG91ciBNaWxlc3RvbmUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmFuIDIwMTU8c3BhbiBjbGFzcz0iYXBw
bGUtdGFiLXNwYW4iPg0KPC9zcGFuPlVzZS1jYXNlcyBhbmQgb3BlcmF0aW9uYWwgZXhwZXJpZW5j
ZXMgKEluZm9ybWF0aW9uYWwpIHRvIElFU0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmhlcmUncyB0aGUg
cmVsZXZhbnQgcGFydCBvZiBvdXIgQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7Jmx0OzxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2xpbmUtaGVpZ2h0
OjE2LjA1cHQ7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+VGhl
IHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIGV4cGxvcmUgYW5kIGRvY3VtZW50IHJlc3VsdHMgd2l0
aCBzZXZlcmFsPGJyPg0Kb2YgdGhlIHByb3Bvc2VkIHVzZSBjYXNlcyBmb3IgTVBUQ1AgaW4gbW9y
ZSBkZXRhaWwsIHRvIGVuc3VyZSB0aGF0PGJyPg0KTVBUQ1Agd29ya3Mgd2VsbCBpbiBwcmFjdGlj
ZSBhbmQgdGhhdCBvcGVyYXRpb25hbCBleHBlcmllbmNlcyBhbmQ8YnI+DQppc3N1ZXMgYXJlIHVu
ZGVyc3Rvb2QgYW5kIGNhcHR1cmVkLiBMaWtlbHkgdXNlIGNhc2VzIGFyZSB0byBvZmZsb2FkPGJy
Pg0KdHJhZmZpYyBmcm9tIDNHIHRvIFdpRmksIGFuZCB0byBtYW5hZ2UgdHJhZmZpYyB3aXRoaW4g
YSBkYXRhIGNlbnRyZS48YnI+DQpBbm90aGVyIHNjZW5hcmlvIGlzIHRvIGVuYWJsZSwgd2l0aG91
dCBjaGFuZ2luZyB0aGUgTVBUQ1AgcHJvdG9jb2wsPGJyPg0Kb3BlcmF0aW9uIG9mIGEgc2luZ2xl
LWhvbWVkLCBNUFRDUCBlbmQgaG9zdCBvbiBhIGNhbXB1cyBuZXR3b3JrIHRoYXQgaGFzPGJyPg0K
bXVsdGlwbGUgcHJvdmlkZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjcuOXB0O2xpbmUtaGVpZ2h0OjE2LjA1cHQ7YmFja2dyb3VuZDp3aGl0ZTtib3gt
c2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy
aWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+UHJpb3IgdG8gcHVibGlzaGluZyBhIFN0YW5kYXJkcyBU
cmFjayBzcGVjaWZpY2F0aW9uLCB0aGUgd29ya2luZyBncm91cDxicj4NCndpbGwgZG9jdW1lbnQg
ZXhwZXJpbWVudGFsIHJlc3VsdHMgYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2VzIHRvLWRhdGUu
PGJyPg0KVGhpcyBzaG91bGQgY29uc2lkZXIgbm90IGp1c3QgZXhwZXJpZW5jZSB3aXRoIHdlbGwt
Y29ubmVjdGVkIGZhdC1waXBlPGJyPg0KbmV0d29ya3MgYW5kIGxvbmctbGl2ZWQgZmxvd3MsIGJ1
dCBhbHNvIGNvbnNpZGVyIGEgYnJvYWRlciBsaW5rcyBhbmQ8YnI+DQp0eXBlcyBvZiBhcHBsaWNh
dGlvbnM7IHBhcnRpY3VsYXJseSBsb29raW5nIGZvciBjYXNlcyB3aGVyZSBNUFRDUDxicj4NCmNv
dWxkIGJlIGRldHJpbWVudGFsIGluIHNvbWUgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2xpbmUtaGVpZ2h0OjE2LjA1cHQ7YmFja2dyb3Vu
ZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jmd0OyZndDs8bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+
dGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOmJsYWNrIj5QaGkgJmFtcDsgWW9zaGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C5C3BB522B1DDF478AA09545169155B46EDCD21Cnkgeml507mbxchi_--


From nobody Tue May 19 00:56:47 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7D1ACE4C for ; Tue, 19 May 2015 00:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PB-K0EaoN2H for ; Tue, 19 May 2015 00:56:43 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1E22D1A8A50 for ; Tue, 19 May 2015 00:56:43 -0700 (PDT)
Received: from wifi-secure1-100.sri.ucl.ac.be (wifi-secure1-100.sri.ucl.ac.be [130.104.92.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0EC4511FD38; Tue, 19 May 2015 09:56:29 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 0EC4511FD38
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1432022189; bh=v7TTFMD7MAgt3rCTYMOPFYQszl+2vydM0h/bDjCcQ2A=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding:Date:From: MIME-Version:To:Subject:References:In-Reply-To:Content-Type:; b=DyO3ZGWZ5SPtIkqznRH9dN42AQwMNcCqvCqj//6IE+0JNPz7ZRGZKZdqmk8AvxlVc KLktx3Si+Q3eBCDnVviod5N5aZBnSGciPyW+47CureR9kOqZ/Vw1EOayjoldUQ6M0G y9XIiM9LfDjqJLHJHS3gSveHDkjo/PHJCes2njzU=
Message-ID: <555AECAD.8050907@uclouvain.be>
Date: Tue, 19 May 2015 09:56:29 +0200
From: Olivier Bonaventure 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: philip.eardley@bt.com, multipathtcp@ietf.org
References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> <1431857585427.77044@bt.com>
In-Reply-To: <1431857585427.77044@bt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: 0EC4511FD38.A509E
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: 
Subject: Re: [multipathtcp] FW: IETF hackathon
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 07:56:45 -0000

Phil,

> Anyone want to join the IETF Prague hackathon with some MPTCP related work?


If there are some members of the list who would be interested in working 
with us on the Multipath TCP implementation in the Linux kernel or 
related tools like mptcptrace or tracebox, we could organise something 
in Prague.

We are ready to come to Prague if we are not the only ones working on 
Multipath TCP related stuff there.


Olivier


> I wanted to highlight that in Prague we will have a hackathon event:
>
> http://www.ietf.org/blog/2015/05/ietf-hackathon/
>
> Some of your working groups might have participants working actively on software who might benefit from some time together. Or could implement a small enhancement during the weekend. An opportunity for your consideration.
>
> Jari
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> .
>


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


From nobody Tue May 19 02:50:20 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6E1A6FF2 for ; Tue, 19 May 2015 02:50:19 -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=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAWXXZH4yE7d for ; Tue, 19 May 2015 02:50:17 -0700 (PDT)
Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9ABE1A6EE4 for ; Tue, 19 May 2015 02:50:16 -0700 (PDT)
Received: from [141.85.37.157] (helo=[10.10.1.102]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1Yue9u-000DHZ-TB; Tue, 19 May 2015 10:49:58 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Costin Raiciu 
In-Reply-To: <555AECAD.8050907@uclouvain.be>
Date: Tue, 19 May 2015 12:49:58 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <859B80D6-3BF5-4A9D-9458-20A6BB2453F2@cs.ucl.ac.uk>
References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> <1431857585427.77044@bt.com> <555AECAD.8050907@uclouvain.be>
To: Olivier Bonaventure , Dragos Niculescu 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] IETF hackathon
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 09:50:19 -0000

We could organize a hackathon to kickstart a larger scale =
(crowd-sourced) mobility experiment at the IETF.=20

The basis for this would be our MultiWifi work published in this =
year=E2=80=99s NSDI paper =
(https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/=
croitoru)=20
that proposes that all mobile clients should connect to all Access =
Points they see and spread traffic over them with Multipath TCP.=20

In this way, mobility is seamless, and no fast handover is needed when =
switching APs.

At the hackathon we will:
- make  our current implementation available to participants, e.g. via =
bootable usb sticks.
- write scripts to enable multiwifi to work in the IETF network =
seamlessly
- write monitoring software to test the performance of multiwifi as it =
is used around the IETF venue, in particular the number of connections, =
their performance, instantaneous throughput, etc.
- improve different parts of the code to cope with channel switching, =
etc.

The plan is then to assemble the data we have and show some of it during =
the MPTCP slot, together with a presentation of the design of multiwif.

Would people find this useful?
Costin


> On 19 May 2015, at 10:56, Olivier Bonaventure =
 wrote:
>=20
> Phil,
>=20
>> Anyone want to join the IETF Prague hackathon with some MPTCP related =
work?
>=20
>=20
> If there are some members of the list who would be interested in =
working with us on the Multipath TCP implementation in the Linux kernel =
or related tools like mptcptrace or tracebox, we could organise =
something in Prague.
>=20
> We are ready to come to Prague if we are not the only ones working on =
Multipath TCP related stuff there.
>=20
>=20
> Olivier
>=20
>=20
>> I wanted to highlight that in Prague we will have a hackathon event:
>>=20
>> http://www.ietf.org/blog/2015/05/ietf-hackathon/
>>=20
>> Some of your working groups might have participants working actively =
on software who might benefit from some time together. Or could =
implement a small enhancement during the weekend. An opportunity for =
your consideration.
>>=20
>> Jari
>>=20
>>=20
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> .
>>=20
>=20
>=20
> --=20
> INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
>=20
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp


From nobody Tue May 19 06:40:00 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50A1B2F44 for ; Tue, 19 May 2015 06:39:59 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbZoWUOHpH3X for ; Tue, 19 May 2015 06:39:54 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::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 ADAAF1B2F43 for ; Tue, 19 May 2015 06:37:40 -0700 (PDT)
Received: by labbd9 with SMTP id bd9so24621676lab.2 for ; Tue, 19 May 2015 06:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H7EhdwO7kfJEMyFgJhQpdagcIhyWKm1HPddPVv9iT3E=; b=S2hxCTShilcqvNt2SowmxDX/P9TbTChy/YmGCgYJMNjdlxnwxUv6G1QvAu0AgE9w7O CXfKDzP1gVSr3FSDVhcsceYPB3ha7e15xroTaIZL9vTGRp94Ky3XM3p3QdDRRCCJJBKK xjVn+TekT/k8xedd+oWwKn7cnd+F12d03CQ7vHeUPC6QyqbdSqz1+JKbGZwfR6PpkHvP VhOQ2t9s7IiF58huwTlpqlVxA9L9f4QcK2bZr2TOMB8lmrvO7HMTXQrJ7zuh18fBX7SJ gcjapWbdEpUnMhda3oE3Wm/N58sn7cUeN5CL7eMg04GSeZ1yh52bgY9OBhslGGatm+VH HHZQ==
MIME-Version: 1.0
X-Received: by 10.112.190.10 with SMTP id gm10mr20938363lbc.2.1432042658951; Tue, 19 May 2015 06:37:38 -0700 (PDT)
Received: by 10.114.229.135 with HTTP; Tue, 19 May 2015 06:37:38 -0700 (PDT)
In-Reply-To: <555A2F3F.1020606@uclouvain.be>
References: <1431361552419.40809@bt.com>  <555A2F3F.1020606@uclouvain.be>
Date: Tue, 19 May 2015 22:37:38 +0900
Message-ID: 
From: Jaehyun Hwang 
To: Olivier Bonaventure 
Content-Type: multipart/alternative; boundary=001a11c37bccfd779405166f69c0
Archived-At: 
Cc: multipathtcp , "Walid, Anwar I \(Anwar\)" 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 13:39:59 -0000

--001a11c37bccfd779405166f69c0
Content-Type: text/plain; charset=UTF-8

Olivier,

Regarding the congestion control, can you also include the Balia congestion
control scheme in Section 4?

We basically agree we have to explore a wide range of network conditions to
compare the algorithms, but Balia has shown it balances the tradeoff
between friendliness and responsiveness well, and we found out some
scenarios where Balia works better than LIA and OLIA. In addition, it has
been included in the MPTCP kernel v0.9 (and also in the NorNet Core
testbed). So we believe it would be worth mentioning.

Below links are the paper and the I-D.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7000573

http://tools.ietf.org/html/draft-walid-mptcp-congestion-control-02

Thanks,
Jaehyun




On Tue, May 19, 2015 at 3:28 AM, Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> Yoshifumi,
>
>>
>> I have reviewed this draft and I have the following comments. (sorry for
>> long lists)
>>
>>
> Thanks for the detailed comments. I'll try to answer them below
>
>  * Title
>>     Experience with Multipath TCP
>>       --> Although the title seems to say it will describe experiences
>> for mptcp, I think it also contains some other stuff.
>>            For example, some use cases described here look like
>> possibilities, but haven't fully experienced yet.
>>            This may be fine as it's still useful info, but I think we
>> had better clarify what we should include in the doc.
>>
>
> We could remove the discussion of the use cases from this document.
>
>  * Section 1
>>     Section {{usecases}}. Seciton{{congestion}
>>       --> editorial miss?
>>
>
> Wrong conversion from markdown to text :-(
>
>  * Section 2
>>     [HotMiddlebox13] documents a corner case with segment splitting that
>> may lead to desynchronisation between the two hosts.
>>        --> this sounds a bit problematic. Why you don't elaborate this?
>>
>
> I can expand it based on the text in [HotMiddlebox13]
>
>  * Section 2
>>     The results for [HotMiddlebox13] listed in the draft looks good.
>> However, it seems to me that it has some presumptions for the middleboxes.
>>     For example, I guess it might presume that middleboxes don't discard
>> options when it coalesces segments or don't drop options intermittently.
>>     If so, we might want to describe them.
>>
>
> I can add other scenarios, but this will make the text more difficult to
> read. Some of the scenarios explored in [HotMiddlebox13] are corner cases
> that are unlikely to happen in practice.
>
> We recently analysed all the MPTCP connections received on
> multipath-tcp.org and observed the following :
>
> Among the 184 thousands Multipath TCP connections in the trace, we
> observed only 125 of them falling back to regular TCP, which happened with
> 28 distinctive client IP addresses. These include 91 HTTP connections and
> 34 FTP connections. The FTP interference is expected and due to Application
> Level Gateways running on NAT boxes. The HTTP interference appeared only on
> the direction from server to client and could have been caused by
> transparent proxies deployed in cellular and enterprise networks.
>
> Note that we do not observe interference where a middlebox removes the
> MP_CAPABLE option from the SYN in this dataset.
>
>
>
>> * Section 3
>>     Description for backup mode doesn't look experiences to me.  Some
>> clarifications may be required.
>>
>
> There are two issues with the backup mode that could be discussed for
> smartphones. Let us assume for simplicity that the WiFi is used as a
> primary interface and cellular as a backup interface.
>
> The first is that by starting the backup flow (i.e. with a three-way
> handshake) over the cellular interface, the smartphone consummes energy and
> radio channel capacity (typically for a few seconds). If the backup subflow
> is not started immediately, but only when the primary fails, then energy
> and radio channel consumption are reduced.
>
> The second issue that we observe on smartphones is that the status of a
> subflow cannot be described as a binary value (active/inactive). There are
> many situations where a subflow is considered active while it cannot
> efficiently transmit data. A typical example is a smartphone that is far
> away from a WiFi access point, but close enough to perform the
> three-way-handshake. If this subflow is a primary subflow and the cellular
> a backup subflow, then MPTCP will try to retransmit data several times over
> the WiFi interface before stopping the WiFi subflow and starting to use the
> cellular one. This can cause delays of tens of seconds before switching to
> the cellular interface.
>
>
>> * Section 3
>>     Description for single-path mode doesn't look experiences to me.
>> Some clarifications may be required.
>>
>> * Section 3
>>     "From a protocol viewpoint, [Cellnet12] discusses the problem posed by
>>     the unreliability of the ADD_ADDR option and proposes a small
>>     protocol extension to allow hosts to reliably exchange this option.
>>     It would be useful to analyze packet traces to understand whether the
>>     unreliability of the REMOVE_ADDR option poses an operational problem
>>     in real deployments. "
>>
>>       --> this seems to be useful info. I might want to see more
>> detailed info.
>>
>
> This should be compared with the decision of Apple to not implement
> ADD_ADDR. We can add some text.
>
>>
>> * Section 3
>>    "MPTCP provides a robust data transport and reduces variations in
>> download latencies".
>>        --> This looks good results, I might want to see more precise info.
>>
>
> This sentence comes from the conclusion of the paper IMC13b. What kind of
> more precise information do you expect ?
>
>  * Section 3
>>      The use case of coupling mptcp and SDN doesn't look experiences to
>> me. Some clarifications may be required.
>>      I'm not very sure "Using an international network" is a part of SDN
>> use cases although this is described in the same paragraph.
>>
>
> This part could be removed and we could point to the MPTCP bibliography
> for other use cases https://github.com/obonaventure/mptcp-bib
>
> I think that the use case described in a recent NSDI paper
>
> https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/croitoru
> should be added to this section because it is important for mobile devices
>
>  * Section 4
>>      This seems to be very useful and important info and I personally
>> would like to see more detailed info.
>>      For example, which situation we can see performance benefits of
>> OLIA? How much benefit we can get.
>>      Is there any concern or risks to use OLIA or default CC? If OLIA is
>> better, shall we consider adopting it? Or, is it too early?
>>      It might be good if the authors can provide something on these
>> points.
>>
>
> It is possible to find simulation scenarios/topologies where one
> congestion control algorithm works better than others. However, we should
> not decide on the basis of a small number of examples.
>
> The best approach to compare different congestion control schemes is to
> explore a wide range of network conditions. Christoph Paasch has used an
> experimental design approach to perform this analysis for a bonding
> scenario (two links without congestion). The results are described in
>
> http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp
> and have been updated in
> http://inl.info.ucl.ac.be/publications/improving-multipath-tcp
>
> Based on these results, there does not seem to be a strong benefit with
> OLIA over LIA. If the WG wants to reconsider the selection of the default
> congestion control scheme, it should use a similar experimental approach
> and use different network topologies.
>
>  * Section 5.1
>>      "mptcp-dev mailing list"
>>        --> please provide the reference as readers might not know what
>> it is.
>>
>
> Will add.
>
>  * Section 5.1
>>     "The second subflow manager that is currently supported by the
>>     Multipath TCP implementation in the Linux kernel is the ndiffport
>>     subflow manager."
>>         --> we might need a reference for ndiffport?
>>
>
> There is no explicit document on this path manager afaik.
>
>  * Section 5.1
>>    "This manager was initially created to exploit the
>>     path diversity that exists between single-homed hosts due to the
>>     utilization of flow-based load balancing techniques.  This subflow
>>     manager creates N subflows between the same pair of IP addresses.
>>     The N subflows are created by the client and differ only in the
>>     source port selected by the client."
>>            --> Does this mean the logic of the manager has been changed?
>> If so, what's the reason for this?
>>            --> How do we determine N?
>>
>
> N is a static configuration. Some experiments have been reported in the
> SIGCOMM'11 paper
>
>  why it uses the same pair of IP
>> addresses?
>>
>
> Because it is used on single-homed hosts
>
>
>> * Section 5.2
>>     "However, from an implementation point-of-view supporting different
>>     destination ports for the same Multipath TCP connection introduces a
>>     new performance issue."
>>
>>           --> It seems that the rest of the paragraph doesn't provide
>> specific explanation for performance issue.
>>                Is it coming from implementation proxy or other reasons?
>>
>
> This comes from an implementation issue because the stack needs to listen
> to more ports.
>
>  * Section 5.2
>>     "This imposes an additional cost on servers, previously not existent
>> on legacy TCP implementations. "
>>       -->I understand there'll be additional cost. However, is it a very
>> complex mechanism to affect performance?
>>           I'm wondering some kinds of hash table might do some jobs.
>>
>
> I don't think that such a solution has been explored
>
>  * Section 5.3
>>       I think we should use "M_" state for the status of mptcp otherwise
>> it'll be confused with the status of TCP.
>>
>
> Will add
>
>  * Section 5.3
>>       "Figure 4 shows a very particular issue within Multipath TCP."
>>         --> I might miss something, but I'm not very sure the cases
>> described here.
>>              In my understanding, client should perform close() so that
>> it will go timewait and server can release the resource quickly.
>>              However, in this example, server perform close() and goes
>> into m_timewait. Please clarify this point.
>>
>> * Section 6
>>       "SCTP implementations also include schedulers, but these are used
>> to schedule the different streams. "
>>          --> Does this mean all schedulers for SCTP are used to schedule
>> the different stream?
>>
>
> That was our understanding, but maybe there are schedulers on CMT-SCTP
> implementations.
>
>  * Section 6
>>        "Unfortunately, none of the proposed techniques have been
>> implemented and used in real deployment."
>>           --> Is there any reason for this? If not, I think we had
>> better add "at this moment"
>>
>
> Exact, everything in the document is to be considered "as of this writing".
>
>  * Section 6
>>        "The simulation scenarios discussed in [PAMS2014] confirm the
>> impact of the packet scheduler on the performance of Multipath TCP."
>>           --> Can you elaborate this? Otherwise, it looks a bit
>> ambiguous info.
>>
>
> Will expand.
>
>  * Section 7
>>         "Taking the smallest MSS does not solve the issue as there might
>> be a case where the sublow with the smallest MSS will only participate
>>           marginally to the overall performance therefore reducing the
>> potential throughput of the other subflows."
>>          --> It seems to me that this approach might work in some
>> situations. If so, "does not solve the issue" sounds too much.
>>
>> * Section 7
>>          Does the current linux approach perform better than others? No
>> drawback or potential risk in this approach?
>>          I would like to see more detailed analysis on this. If this is
>> good approach, we might want to document the detailed logic?
>>
>
> It would be interesting to see if other implementors have faced the issue
> and found other solutions to cope with it.
>
>
> Olivier
>
>
> --
> INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

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


Olivier,

Regarding the congestion contr=
ol, can you also include the Balia congestion control scheme in Section 4?<=
/div>

We basically agree we have to explore a wide range=
 of network conditions to compare the algorithms, but Balia has shown it ba=
lances the tradeoff between friendliness and responsiveness well, and we fo=
und out some scenarios where Balia works better than LIA and OLIA. In addit=
ion, it has been included in the MPTCP kernel v0.9 (and also in the NorNet =
Core testbed). So we believe it would be worth mentioning.

Below links are the paper and the I-D.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7000573


Thanks,
Jaehyun




On Tue, May 19, 2015 at 3:28 AM, Oliv=
ier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
Yoshifumi,





I have reviewed this draft and I have the following comments. (sorry for
long lists)







Thanks for the detailed comments. I'll try to answer them below





* Title

=C2=A0 =C2=A0 Experience with Multipath TCP

=C2=A0 =C2=A0 =C2=A0 --> Although the title seems to say it will describ=
e experiences

for mptcp, I think it also contains some other stuff.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, some use cases descri=
bed here look like

possibilities, but haven't fully experienced yet.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This may be fine as it's still=
 useful info, but I think we

had better clarify what we should include in the doc.





We could remove the discussion of the use cases from this document.





* Section 1

=C2=A0 =C2=A0 Section {{usecases}}. Seciton{{congestion}

=C2=A0 =C2=A0 =C2=A0 --> editorial miss?





Wrong conversion from markdown to text :-(





* Section 2

=C2=A0 =C2=A0 [HotMiddlebox13] documents a corner case with segment splitti=
ng that

may lead to desynchronisation between the two hosts.

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> this sounds a bit problematic. Why you do=
n't elaborate this?





I can expand it based on the text in [HotMiddlebox13]





* Section 2

=C2=A0 =C2=A0 The results for [HotMiddlebox13] listed in the draft looks go=
od.

However, it seems to me that it has some presumptions for the middleboxes.<=
br>
=C2=A0 =C2=A0 For example, I guess it might presume that middleboxes don=
9;t discard

options when it coalesces segments or don't drop options intermittently=
.

=C2=A0 =C2=A0 If so, we might want to describe them.





I can add other scenarios, but this will make the text more difficult to re=
ad. Some of the scenarios explored in [HotMiddlebox13] are corner cases tha=
t are unlikely to happen in practice.



We recently analysed all the MPTCP connections received on multipath-tcp.org and observed t=
he following :



Among the 184 thousands Multipath TCP connections in the trace, we observed=
 only 125 of them falling back to regular TCP, which happened with 28 disti=
nctive client IP addresses. These include 91 HTTP connections and 34 FTP co=
nnections. The FTP interference is expected and due to Application Level Ga=
teways running on NAT boxes. The HTTP interference appeared only on the dir=
ection from server to client and could have been caused by transparent prox=
ies deployed in cellular and enterprise networks.



Note that we do not observe interference where a middlebox removes the MP_C=
APABLE option from the SYN in this dataset.









* Section 3

=C2=A0 =C2=A0 Description for backup mode doesn't look experiences to m=
e.=C2=A0 Some

clarifications may be required.





There are two issues with the backup mode that could be discussed for smart=
phones. Let us assume for simplicity that the WiFi is used as a primary int=
erface and cellular as a backup interface.



The first is that by starting the backup flow (i.e. with a three-way handsh=
ake) over the cellular interface, the smartphone consummes energy and radio=
 channel capacity (typically for a few seconds). If the backup subflow is n=
ot started immediately, but only when the primary fails, then energy and ra=
dio channel consumption are reduced.



The second issue that we observe on smartphones is that the status of a sub=
flow cannot be described as a binary value (active/inactive). There are man=
y situations where a subflow is considered active while it cannot efficient=
ly transmit data. A typical example is a smartphone that is far away from a=
 WiFi access point, but close enough to perform the three-way-handshake. If=
 this subflow is a primary subflow and the cellular a backup subflow, then =
MPTCP will try to retransmit data several times over the WiFi interface bef=
ore stopping the WiFi subflow and starting to use the cellular one. This ca=
n cause delays of tens of seconds before switching to the cellular interfac=
e.







* Section 3

=C2=A0 =C2=A0 Description for single-path mode doesn't look experiences=
 to me.

Some clarifications may be required.



* Section 3

=C2=A0 =C2=A0 "From a protocol viewpoint, [Cellnet12] discusses the pr=
oblem posed by

=C2=A0 =C2=A0 the unreliability of the ADD_ADDR option and proposes a small=


=C2=A0 =C2=A0 protocol extension to allow hosts to reliably exchange this o=
ption.

=C2=A0 =C2=A0 It would be useful to analyze packet traces to understand whe=
ther the

=C2=A0 =C2=A0 unreliability of the REMOVE_ADDR option poses an operational =
problem

=C2=A0 =C2=A0 in real deployments. "



=C2=A0 =C2=A0 =C2=A0 --> this seems to be useful info. I might want to s=
ee more

detailed info.





This should be compared with the decision of Apple to not implement ADD_ADD=
R. We can add some text.





* Section 3

=C2=A0 =C2=A0"MPTCP provides a robust data transport and reduces varia=
tions in

download latencies".

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> This looks good results, I might want to =
see more precise info.





This sentence comes from the conclusion of the paper IMC13b. What kind of m=
ore precise information do you expect ?





* Section 3

=C2=A0 =C2=A0 =C2=A0The use case of coupling mptcp and SDN doesn't look=
 experiences to

me. Some clarifications may be required.

=C2=A0 =C2=A0 =C2=A0I'm not very sure "Using an international netw=
ork" is a part of SDN

use cases although this is described in the same paragraph.





This part could be removed and we could point to the MPTCP bibliography for=
 other use cases https://github.com/obonaventure/mptcp-bib



I think that the use case described in a recent NSDI paper

https://www.usenix.org/conference/nsdi=
15/technical-sessions/presentation/croitoru

should be added to this section because it is important for mobile devices<=
span class=3D"">





* Section 4

=C2=A0 =C2=A0 =C2=A0This seems to be very useful and important info and I p=
ersonally

would like to see more detailed info.

=C2=A0 =C2=A0 =C2=A0For example, which situation we can see performance ben=
efits of

OLIA? How much benefit we can get.

=C2=A0 =C2=A0 =C2=A0Is there any concern or risks to use OLIA or default CC=
? If OLIA is

better, shall we consider adopting it? Or, is it too early?

=C2=A0 =C2=A0 =C2=A0It might be good if the authors can provide something o=
n these points.





It is possible to find simulation scenarios/topologies where one congestion=
 control algorithm works better than others. However, we should not decide =
on the basis of a small number of examples.



The best approach to compare different congestion control schemes is to exp=
lore a wide range of network conditions. Christoph Paasch has used an exper=
imental design approach to perform this analysis for a bonding scenario (tw=
o links without congestion). The results are described in

http://inl.info.ucl.a=
c.be/publications/benefits-applying-experimental-design-improve-multipath-t=
cp

and have been updated in

http://inl.info.ucl.ac.be/publications/improving-multipat=
h-tcp



Based on these results, there does not seem to be a strong benefit with OLI=
A over LIA. If the WG wants to reconsider the selection of the default cong=
estion control scheme, it should use a similar experimental approach and us=
e different network topologies.





* Section 5.1

=C2=A0 =C2=A0 =C2=A0"mptcp-dev mailing list"

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> please provide the reference as readers m=
ight not know what

it is.





Will add.





* Section 5.1

=C2=A0 =C2=A0 "The second subflow manager that is currently supported =
by the

=C2=A0 =C2=A0 Multipath TCP implementation in the Linux kernel is the ndiff=
port

=C2=A0 =C2=A0 subflow manager."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> we might need a reference for ndiffport?=






There is no explicit document on this path manager afaik.<=
br>




* Section 5.1

=C2=A0 =C2=A0"This manager was initially created to exploit the

=C2=A0 =C2=A0 path diversity that exists between single-homed hosts due to =
the

=C2=A0 =C2=A0 utilization of flow-based load balancing techniques.=C2=A0 Th=
is subflow

=C2=A0 =C2=A0 manager creates N subflows between the same pair of IP addres=
ses.

=C2=A0 =C2=A0 The N subflows are created by the client and differ only in t=
he

=C2=A0 =C2=A0 source port selected by the client."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean the logic of=
 the manager has been changed?

If so, what's the reason for this?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> How do we determine N?





N is a static configuration. Some experiments have been reported in the SIG=
COMM'11 paper





why it uses the same pair of IP

addresses?





Because it is used on single-homed hosts







* Section 5.2

=C2=A0 =C2=A0 "However, from an implementation point-of-view supportin=
g different

=C2=A0 =C2=A0 destination ports for the same Multipath TCP connection intro=
duces a

=C2=A0 =C2=A0 new performance issue."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> It seems that the rest of the par=
agraph doesn't provide

specific explanation for performance issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is it coming from im=
plementation proxy or other reasons?





This comes from an implementation issue because the stack needs to listen t=
o more ports.





* Section 5.2

=C2=A0 =C2=A0 "This imposes an additional cost on servers, previously =
not existent

on legacy TCP implementations. "

=C2=A0 =C2=A0 =C2=A0 -->I understand there'll be additional cost. Ho=
wever, is it a very

complex mechanism to affect performance?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm wondering some kinds of hash tab=
le might do some jobs.





I don't think that such a solution has been explored




* Section 5.3

=C2=A0 =C2=A0 =C2=A0 I think we should use "M_" state for the sta=
tus of mptcp otherwise

it'll be confused with the status of TCP.





Will add





* Section 5.3

=C2=A0 =C2=A0 =C2=A0 "Figure 4 shows a very particular issue within Mu=
ltipath TCP."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> I might miss something, but I'm not =
very sure the cases

described here.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my understanding, client=
 should perform close() so that

it will go timewait and server can release the resource quickly.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However, in this example, s=
erver perform close() and goes

into m_timewait. Please clarify this point.



* Section 6

=C2=A0 =C2=A0 =C2=A0 "SCTP implementations also include schedulers, bu=
t these are used

to schedule the different streams. "

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean all schedulers for =
SCTP are used to schedule

the different stream?





That was our understanding, but maybe there are schedulers on CMT-SCTP impl=
ementations.





* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Unfortunately, none of the proposed techni=
ques have been

implemented and used in real deployment."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Is there any reason for this? If =
not, I think we had

better add "at this moment"





Exact, everything in the document is to be considered "as of this writ=
ing".





* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"The simulation scenarios discussed in [PAM=
S2014] confirm the

impact of the packet scheduler on the performance of Multipath TCP."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Can you elaborate this? Otherwise=
, it looks a bit

ambiguous info.





Will expand.





* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Taking the smallest MSS does not solve th=
e issue as there might

be a case where the sublow with the smallest MSS will only participate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 marginally to the overall performance th=
erefore reducing the

potential throughput of the other subflows."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> It seems to me that this approach =
might work in some

situations. If so, "does not solve the issue" sounds too much.


* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does the current linux approach perform b=
etter than others? No

drawback or potential risk in this approach?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I would like to see more detailed analysi=
s on this. If this is

good approach, we might want to document the detailed logic?





It would be interesting to see if other implementors have faced the issue a=
nd found other solutions to cope with it.





Olivier





-- 

INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be




_______________________________________________

multipathtcp mailing list

multipathtcp@iet=
f.org

https://www.ietf.org/mailman/listinfo/multipathtcp





--001a11c37bccfd779405166f69c0--


From nobody Tue May 19 07:28:39 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756981B3091 for ; Tue, 19 May 2015 07:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.701
X-Spam-Level: 
X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMa0CORMD4Xm for ; Tue, 19 May 2015 07:28:35 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E41B2FC7 for ; Tue, 19 May 2015 07:24:29 -0700 (PDT)
Received: from mbpobo.local (unknown [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CA3BA183442; Tue, 19 May 2015 16:24:23 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be CA3BA183442
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1432045463; bh=uVqLwI4FLcMRgXgsYo28cBrjTv7xs0pNwukb9gYs4i4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eXB68FL6AK12PnCUMLNjst41XUFDxjWSDBpYt/iW6EMSxSU8IHU4QLTryeCGDrzK0 RDlXAmioohbLM4VtzgkWIKy94fREbTMrXcW62pZH3D1v45jzbYzeEeLPVdhZ1RyFjp kxLMbA2cIG8a1VEeAcVrMO09fIBQyFfXjvP1szmU=
Message-ID: <555B4798.1050708@uclouvain.be>
Date: Tue, 19 May 2015 16:24:24 +0200
From: Olivier Bonaventure 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Jaehyun Hwang 
References: <1431361552419.40809@bt.com>		<555A2F3F.1020606@uclouvain.be> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: CA3BA183442.A0B7F
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: 
Cc: multipathtcp , "Walid, Anwar I \(Anwar\)" 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 14:28:37 -0000

Hello,
>
> Regarding the congestion control, can you also include the Balia
> congestion control scheme in Section 4?
>
> We basically agree we have to explore a wide range of network conditions
> to compare the algorithms, but Balia has shown it balances the tradeoff
> between friendliness and responsiveness well, and we found out some
> scenarios where Balia works better than LIA and OLIA. In addition, it
> has been included in the MPTCP kernel v0.9 (and also in the NorNet Core
> testbed). So we believe it would be worth mentioning.
>

I can add links to BALIA in addition to the other congestion control 
algorithms that have been proposed for Multipath TCP. Given that the 
litterature is quickly growing in this field, I would propose to only 
list the congestion control algorithms that have been implemented in one 
Multipath TCP implementation.

Yesterday, I read again the implementation report coordinated by Phil 
and was worried by the following answer about the implemented congestion 
control schemes :

| Question 8 asks about congestion control and related issues: how     |
| traffic is shared across multiple subflows; support for 'handover';  |
| and support of RFC6356 (or other) coupled congestion control.        |
|            | UCLouvain | Swinburne |   Anon    |  Citrix   |         |
|sharing     |shared, RTT|shared     |active/back|active/back|         |
|handover    |Yes        |           |Yes        |Yes        |         |
|coupled cc  |Yes        |No         |No         |No         |         |
|other ccc   |Yes, OLIA  |No         |No         |No         |         |
|MP-PRIO & B |Yes        |No         |Yes        |Yes        |         |


I was wondering whether the other implementations had any plan to 
support one of the coupled congestion control schemes ?


Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


From nobody Tue May 19 16:02:11 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635C61B34EF for ; Tue, 19 May 2015 16:02:09 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYkv6kROFihS for ; Tue, 19 May 2015 16:02:07 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE571B34D3 for ; Tue, 19 May 2015 16:01:47 -0700 (PDT)
Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 20 May 2015 00:01:40 +0100
Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 20 May 2015 00:01:44 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 20 May 2015 00:01:42 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 20 May 2015 00:01:42 +0100
From: 
To: , , 
Thread-Topic: [multipathtcp] WG Last call for "Experience with Multipath TCP"
Thread-Index: AQHQjAaqB7NxDkBWbEupZkh4hubTcJ2BamMAgACdmoCAAe6L/w==
Date: Tue, 19 May 2015 23:01:41 +0000
Message-ID: <1432076500253.90041@bt.com>
References: <1431361552419.40809@bt.com> , <555A2F3F.1020606@uclouvain.be>
In-Reply-To: <555A2F3F.1020606@uclouvain.be>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.216.161.24]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 May 2015 23:02:09 -0000

=0A=
________________________________________=0A=
From: multipathtcp  on behalf of Olivier Bon=
aventure =0A=
Sent: 18 May 2015 19:28=0A=
=0A=
> * Title=0A=
>     Experience with Multipath TCP=0A=
>       --> Although the title seems to say it will describe experiences=0A=
> for mptcp, I think it also contains some other stuff.=0A=
>            For example, some use cases described here look like=0A=
> possibilities, but haven't fully experienced yet.=0A=
>            This may be fine as it's still useful info, but I think we=0A=
> had better clarify what we should include in the doc.=0A=
=0A=
We could remove the discussion of the use cases from this document.=0A=
----=0A=
=0A=
[phil]=0A=
i'd prefer to keep the use cases. perhaps you could say which have practica=
l experience and which are proposed.=0A=
=0A=
according to the charter, the doc covers "Use-cases and operational experie=
nces"=0A=
and the relevant paragraphs say:-=0A=
=0A=
<>=


From nobody Thu May 21 08:19:09 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A701A87D9 for ; Thu, 21 May 2015 08:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.915
X-Spam-Level: ****
X-Spam-Status: No, score=4.915 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XsiN7mJFdpXz for ; Thu, 21 May 2015 08:19:03 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0EF1A87D2 for ; Thu, 21 May 2015 08:17:37 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E03832780C6 for ; Fri, 22 May 2015 00:17:35 +0900 (JST)
Received: by wgjc11 with SMTP id c11so89132738wgj.0 for ; Thu, 21 May 2015 08:17:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.209.168 with SMTP id mn8mr5892639wjc.49.1432221452936; Thu, 21 May 2015 08:17:32 -0700 (PDT)
Received: by 10.194.27.193 with HTTP; Thu, 21 May 2015 08:17:32 -0700 (PDT)
In-Reply-To: <555A2F3F.1020606@uclouvain.be>
References: <1431361552419.40809@bt.com>  <555A2F3F.1020606@uclouvain.be>
Date: Thu, 21 May 2015 08:17:32 -0700
Message-ID: 
From: Yoshifumi Nishida 
To: Olivier Bonaventure 
Content-Type: multipart/alternative; boundary=047d7b3a8980f12dbd0516990afc
Archived-At: 
Cc: multipathtcp 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 May 2015 15:19:08 -0000

--047d7b3a8980f12dbd0516990afc
Content-Type: text/plain; charset=UTF-8

Hi Olivier,

Thanks for the response.

On Mon, May 18, 2015 at 11:28 AM, Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> Yoshifumi,
>
>>
>> I have reviewed this draft and I have the following comments. (sorry for
>> long lists)
>>
>>
> Thanks for the detailed comments. I'll try to answer them below
>
>  * Title
>>     Experience with Multipath TCP
>>       --> Although the title seems to say it will describe experiences
>> for mptcp, I think it also contains some other stuff.
>>            For example, some use cases described here look like
>> possibilities, but haven't fully experienced yet.
>>            This may be fine as it's still useful info, but I think we
>> had better clarify what we should include in the doc.
>>
>
> We could remove the discussion of the use cases from this document.


I am personally fine with it. I think the draft can describe the current
experience and provide some guidelines for future experiences and use cases.
But, I think you should articulate what's in the doc in abstract and
introduction section.


>
>  * Section 1
>>     Section {{usecases}}. Seciton{{congestion}
>>       --> editorial miss?
>>
>
> Wrong conversion from markdown to text :-(
>
>  * Section 2
>>     [HotMiddlebox13] documents a corner case with segment splitting that
>> may lead to desynchronisation between the two hosts.
>>        --> this sounds a bit problematic. Why you don't elaborate this?
>>
>
> I can expand it based on the text in [HotMiddlebox13]
>
>  * Section 2
>>     The results for [HotMiddlebox13] listed in the draft looks good.
>> However, it seems to me that it has some presumptions for the middleboxes.
>>     For example, I guess it might presume that middleboxes don't discard
>> options when it coalesces segments or don't drop options intermittently.
>>     If so, we might want to describe them.
>>
>
> I can add other scenarios, but this will make the text more difficult to
> read. Some of the scenarios explored in [HotMiddlebox13] are corner cases
> that are unlikely to happen in practice.
>

I don't think you have to describe minor corner cases. But, I might want to
see some texts that navigate users to the doc if they're interested.

>
> We recently analysed all the MPTCP connections received on
> multipath-tcp.org and observed the following :
>
> Among the 184 thousands Multipath TCP connections in the trace, we
> observed only 125 of them falling back to regular TCP, which happened with
> 28 distinctive client IP addresses. These include 91 HTTP connections and
> 34 FTP connections. The FTP interference is expected and due to Application
> Level Gateways running on NAT boxes. The HTTP interference appeared only on
> the direction from server to client and could have been caused by
> transparent proxies deployed in cellular and enterprise networks.
>
> Note that we do not observe interference where a middlebox removes the
> MP_CAPABLE option from the SYN in this dataset.


this looks very useful experiences to me. it may be good to put this in the
doc.

>
>
>> * Section 3
>>     Description for backup mode doesn't look experiences to me.  Some
>> clarifications may be required.
>>
>
> There are two issues with the backup mode that could be discussed for
> smartphones. Let us assume for simplicity that the WiFi is used as a
> primary interface and cellular as a backup interface.
>
> The first is that by starting the backup flow (i.e. with a three-way
> handshake) over the cellular interface, the smartphone consummes energy and
> radio channel capacity (typically for a few seconds). If the backup subflow
> is not started immediately, but only when the primary fails, then energy
> and radio channel consumption are reduced.
>
> The second issue that we observe on smartphones is that the status of a
> subflow cannot be described as a binary value (active/inactive). There are
> many situations where a subflow is considered active while it cannot
> efficiently transmit data. A typical example is a smartphone that is far
> away from a WiFi access point, but close enough to perform the
> three-way-handshake. If this subflow is a primary subflow and the cellular
> a backup subflow, then MPTCP will try to retransmit data several times over
> the WiFi interface before stopping the WiFi subflow and starting to use the
> cellular one. This can cause delays of tens of seconds before switching to
> the cellular interface.


If we'll put some future/potential use cases in the doc, I think this will
be useful guideline.

>
>
>> * Section 3
>>     Description for single-path mode doesn't look experiences to me.
>> Some clarifications may be required.
>>
>> * Section 3
>>     "From a protocol viewpoint, [Cellnet12] discusses the problem posed by
>>     the unreliability of the ADD_ADDR option and proposes a small
>>     protocol extension to allow hosts to reliably exchange this option.
>>     It would be useful to analyze packet traces to understand whether the
>>     unreliability of the REMOVE_ADDR option poses an operational problem
>>     in real deployments. "
>>
>>       --> this seems to be useful info. I might want to see more
>> detailed info.
>>
>
> This should be compared with the decision of Apple to not implement
> ADD_ADDR. We can add some text.
>
>>
>> * Section 3
>>    "MPTCP provides a robust data transport and reduces variations in
>> download latencies".
>>        --> This looks good results, I might want to see more precise info.
>>
>
> This sentence comes from the conclusion of the paper IMC13b. What kind of
> more precise information do you expect ?


 Well, I am wondering if you can show some small dataset here as I feel
this sentence doesn't have much info.

>
>
>  * Section 3
>>      The use case of coupling mptcp and SDN doesn't look experiences to
>> me. Some clarifications may be required.
>>      I'm not very sure "Using an international network" is a part of SDN
>> use cases although this is described in the same paragraph.
>>
>
> This part could be removed and we could point to the MPTCP bibliography
> for other use cases https://github.com/obonaventure/mptcp-bib
>
> I think that the use case described in a recent NSDI paper
>
> https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/croitoru
> should be added to this section because it is important for mobile devices
>
> The SDN part looks a bit thin to me. It might be good to be replaced If
you have other good use cases.


>  * Section 4
>>      This seems to be very useful and important info and I personally
>> would like to see more detailed info.
>>      For example, which situation we can see performance benefits of
>> OLIA? How much benefit we can get.
>>      Is there any concern or risks to use OLIA or default CC? If OLIA is
>> better, shall we consider adopting it? Or, is it too early?
>>      It might be good if the authors can provide something on these
>> points.
>>
>
> It is possible to find simulation scenarios/topologies where one
> congestion control algorithm works better than others. However, we should
> not decide on the basis of a small number of examples.
>

> The best approach to compare different congestion control schemes is to
> explore a wide range of network conditions. Christoph Paasch has used an
> experimental design approach to perform this analysis for a bonding
> scenario (two links without congestion). The results are described in
>
> http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp
> and have been updated in
> http://inl.info.ucl.ac.be/publications/improving-multipath-tcp
>
> Based on these results, there does not seem to be a strong benefit with
> OLIA over LIA. If the WG wants to reconsider the selection of the default
> congestion control scheme, it should use a similar experimental approach
> and use different network topologies.


I believe this is a very nice explanation for the current status of CC
studies. I think this type of views will be useful as a guidance for future
experiences.


>  * Section 5.1
>>      "mptcp-dev mailing list"
>>        --> please provide the reference as readers might not know what
>> it is.
>>
>
> Will add.
>
>  * Section 5.1
>>     "The second subflow manager that is currently supported by the
>>     Multipath TCP implementation in the Linux kernel is the ndiffport
>>     subflow manager."
>>         --> we might need a reference for ndiffport?
>>
>
> There is no explicit document on this path manager afaik.


OK. then, I might prefer something like "TCP implementation in the Linux
kernel is named ndiffport subflow manager"

>
>
>  * Section 5.1
>>    "This manager was initially created to exploit the
>>     path diversity that exists between single-homed hosts due to the
>>     utilization of flow-based load balancing techniques.  This subflow
>>     manager creates N subflows between the same pair of IP addresses.
>>     The N subflows are created by the client and differ only in the
>>     source port selected by the client."
>>            --> Does this mean the logic of the manager has been changed?
>> If so, what's the reason for this?
>>            --> How do we determine N?
>>
>
> N is a static configuration. Some experiments have been reported in the
> SIGCOMM'11 paper
>
>  why it uses the same pair of IP
>> addresses?
>>
>
> Because it is used on single-homed hosts


OK. But, what if the node is multi-homed?

>
>
>> * Section 5.2
>>     "However, from an implementation point-of-view supporting different
>>     destination ports for the same Multipath TCP connection introduces a
>>     new performance issue."
>>
>>           --> It seems that the rest of the paragraph doesn't provide
>> specific explanation for performance issue.
>>                Is it coming from implementation proxy or other reasons?
>>
>
> This comes from an implementation issue because the stack needs to listen
> to more ports.
>
>  * Section 5.2
>>     "This imposes an additional cost on servers, previously not existent
>> on legacy TCP implementations. "
>>       -->I understand there'll be additional cost. However, is it a very
>> complex mechanism to affect performance?
>>           I'm wondering some kinds of hash table might do some jobs.
>>
>
> I don't think that such a solution has been explored


OK,  Then, It seems to me that "introduces a new performance issue." might
be too much..

>
>
>  * Section 5.3
>>       I think we should use "M_" state for the status of mptcp otherwise
>> it'll be confused with the status of TCP.
>>
>
> Will add
>
>  * Section 5.3
>>       "Figure 4 shows a very particular issue within Multipath TCP."
>>         --> I might miss something, but I'm not very sure the cases
>> described here.
>>              In my understanding, client should perform close() so that
>> it will go timewait and server can release the resource quickly.
>>              However, in this example, server perform close() and goes
>> into m_timewait. Please clarify this point.
>>
>> * Section 6
>>       "SCTP implementations also include schedulers, but these are used
>> to schedule the different streams. "
>>          --> Does this mean all schedulers for SCTP are used to schedule
>> the different stream?
>>
>
> That was our understanding, but maybe there are schedulers on CMT-SCTP
> implementations.


Hmm. when we say SCTP implementations, I tend to think about both SCTP
(rfc4960) and CMT-SCTP implementations.
So, I am personally a bit skeptical about this sentence.

>
>
>  * Section 6
>>        "Unfortunately, none of the proposed techniques have been
>> implemented and used in real deployment."
>>           --> Is there any reason for this? If not, I think we had
>> better add "at this moment"
>>
>
> Exact, everything in the document is to be considered "as of this writing".
>
>  * Section 6
>>        "The simulation scenarios discussed in [PAMS2014] confirm the
>> impact of the packet scheduler on the performance of Multipath TCP."
>>           --> Can you elaborate this? Otherwise, it looks a bit
>> ambiguous info.
>>
>
> Will expand.
>
>  * Section 7
>>         "Taking the smallest MSS does not solve the issue as there might
>> be a case where the sublow with the smallest MSS will only participate
>>           marginally to the overall performance therefore reducing the
>> potential throughput of the other subflows."
>>          --> It seems to me that this approach might work in some
>> situations. If so, "does not solve the issue" sounds too much.
>>
>> * Section 7
>>          Does the current linux approach perform better than others? No
>> drawback or potential risk in this approach?
>>          I would like to see more detailed analysis on this. If this is
>> good approach, we might want to document the detailed logic?
>>
>
> It would be interesting to see if other implementors have faced the issue
> and found other solutions to cope with it.


I am hoping some implementors will speak up on this...


--
Yoshi

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


Hi Olivier,

Thanks for the response.=C2=
=A0

On Mon, Ma=
y 18, 2015 at 11:28 AM, Olivier Bonaventure <Olivier.Bona=
venture@uclouvain.be> wrote:
Yoshifumi,





I have reviewed this draft and I have the following comments. (sorry for
long lists)







Thanks for the detailed comments. I'll try to answer them below





* Title

=C2=A0 =C2=A0 Experience with Multipath TCP

=C2=A0 =C2=A0 =C2=A0 --> Although the title seems to say it will describ=
e experiences

for mptcp, I think it also contains some other stuff.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, some use cases descri=
bed here look like

possibilities, but haven't fully experienced yet.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This may be fine as it's still=
 useful info, but I think we

had better clarify what we should include in the doc.





We could remove the discussion of the use cases from this document.

I am personally fine with it. I think the draft ca=
n describe the current experience and provide some guidelines for future ex=
periences and use cases.
But, I think you should articulate what&=
#39;s in the doc in abstract and introduction section.
=C2=A0





* Section 1

=C2=A0 =C2=A0 Section {{usecases}}. Seciton{{congestion}

=C2=A0 =C2=A0 =C2=A0 --> editorial miss?





Wrong conversion from markdown to text :-(





* Section 2

=C2=A0 =C2=A0 [HotMiddlebox13] documents a corner case with segment splitti=
ng that

may lead to desynchronisation between the two hosts.

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> this sounds a bit problematic. Why you do=
n't elaborate this?





I can expand it based on the text in [HotMiddlebox13]





* Section 2

=C2=A0 =C2=A0 The results for [HotMiddlebox13] listed in the draft looks go=
od.

However, it seems to me that it has some presumptions for the middleboxes.<=
br>
=C2=A0 =C2=A0 For example, I guess it might presume that middleboxes don=
9;t discard

options when it coalesces segments or don't drop options intermittently=
.

=C2=A0 =C2=A0 If so, we might want to describe them.





I can add other scenarios, but this will make the text more difficult to re=
ad. Some of the scenarios explored in [HotMiddlebox13] are corner cases tha=
t are unlikely to happen in practice.

I=
 don't think you have to describe minor corner cases. But, I might want=
 to see some texts that navigate users to the doc if they're interested=
. =C2=A0



We recently analysed all the MPTCP connections received on multipath-tcp.org and observed t=
he following :



Among the 184 thousands Multipath TCP connections in the trace, we observed=
 only 125 of them falling back to regular TCP, which happened with 28 disti=
nctive client IP addresses. These include 91 HTTP connections and 34 FTP co=
nnections. The FTP interference is expected and due to Application Level Ga=
teways running on NAT boxes. The HTTP interference appeared only on the dir=
ection from server to client and could have been caused by transparent prox=
ies deployed in cellular and enterprise networks.



Note that we do not observe interference where a middlebox removes the MP_C=
APABLE option from the SYN in this dataset.

this looks very useful experiences to me. it may be good to put this in th=
e doc.







* Section 3

=C2=A0 =C2=A0 Description for backup mode doesn't look experiences to m=
e.=C2=A0 Some

clarifications may be required.





There are two issues with the backup mode that could be discussed for smart=
phones. Let us assume for simplicity that the WiFi is used as a primary int=
erface and cellular as a backup interface.



The first is that by starting the backup flow (i.e. with a three-way handsh=
ake) over the cellular interface, the smartphone consummes energy and radio=
 channel capacity (typically for a few seconds). If the backup subflow is n=
ot started immediately, but only when the primary fails, then energy and ra=
dio channel consumption are reduced.



The second issue that we observe on smartphones is that the status of a sub=
flow cannot be described as a binary value (active/inactive). There are man=
y situations where a subflow is considered active while it cannot efficient=
ly transmit data. A typical example is a smartphone that is far away from a=
 WiFi access point, but close enough to perform the three-way-handshake. If=
 this subflow is a primary subflow and the cellular a backup subflow, then =
MPTCP will try to retransmit data several times over the WiFi interface bef=
ore stopping the WiFi subflow and starting to use the cellular one. This ca=
n cause delays of tens of seconds before switching to the cellular interfac=
e.

If we'll put some future/potential u=
se cases in the doc, I think this will be useful guideline.







* Section 3

=C2=A0 =C2=A0 Description for single-path mode doesn't look experiences=
 to me.

Some clarifications may be required.



* Section 3

=C2=A0 =C2=A0 "From a protocol viewpoint, [Cellnet12] discusses the pr=
oblem posed by

=C2=A0 =C2=A0 the unreliability of the ADD_ADDR option and proposes a small=


=C2=A0 =C2=A0 protocol extension to allow hosts to reliably exchange this o=
ption.

=C2=A0 =C2=A0 It would be useful to analyze packet traces to understand whe=
ther the

=C2=A0 =C2=A0 unreliability of the REMOVE_ADDR option poses an operational =
problem

=C2=A0 =C2=A0 in real deployments. "



=C2=A0 =C2=A0 =C2=A0 --> this seems to be useful info. I might want to s=
ee more

detailed info.





This should be compared with the decision of Apple to not implement ADD_ADD=
R. We can add some text.





* Section 3

=C2=A0 =C2=A0"MPTCP provides a robust data transport and reduces varia=
tions in

download latencies".

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> This looks good results, I might want to =
see more precise info.





This sentence comes from the conclusion of the paper IMC13b. What kind of m=
ore precise information do you expect ?

=C2=
=A0Well, I am wondering if you can show some small dataset here as I feel t=
his sentence doesn't have much info.






* Section 3

=C2=A0 =C2=A0 =C2=A0The use case of coupling mptcp and SDN doesn't look=
 experiences to

me. Some clarifications may be required.

=C2=A0 =C2=A0 =C2=A0I'm not very sure "Using an international netw=
ork" is a part of SDN

use cases although this is described in the same paragraph.





This part could be removed and we could point to the MPTCP bibliography for=
 other use cases https://github.com/obonaventure/mptcp-bib



I think that the use case described in a recent NSDI paper

https://www.usenix.org/conference/nsdi=
15/technical-sessions/presentation/croitoru

should be added to this section because it is important for mobile devices<=
span class=3D"">


The SDN part looks a bit thin to me. It might =
be good to be replaced If you have other good use cases.
=C2=A0



* Section 4

=C2=A0 =C2=A0 =C2=A0This seems to be very useful and important info and I p=
ersonally

would like to see more detailed info.

=C2=A0 =C2=A0 =C2=A0For example, which situation we can see performance ben=
efits of

OLIA? How much benefit we can get.

=C2=A0 =C2=A0 =C2=A0Is there any concern or risks to use OLIA or default CC=
? If OLIA is

better, shall we consider adopting it? Or, is it too early?

=C2=A0 =C2=A0 =C2=A0It might be good if the authors can provide something o=
n these points.





It is possible to find simulation scenarios/topologies where one congestion=
 control algorithm works better than others. However, we should not decide =
on the basis of a small number of examples.


The best approach to compare different congestion control schemes is to exp=
lore a wide range of network conditions. Christoph Paasch has used an exper=
imental design approach to perform this analysis for a bonding scenario (tw=
o links without congestion). The results are described in

http://inl.info.ucl.a=
c.be/publications/benefits-applying-experimental-design-improve-multipath-t=
cp

and have been updated in

http://inl.info.ucl.ac.be/publications/improving-multipat=
h-tcp



Based on these results, there does not seem to be a strong benefit with OLI=
A over LIA. If the WG wants to reconsider the selection of the default cong=
estion control scheme, it should use a similar experimental approach and us=
e different network topologies.

I believe t=
his is a very nice explanation for the current status of CC studies. I thin=
k this type of views will be useful as a guidance for future experiences.
=C2=A0



* Section 5.1

=C2=A0 =C2=A0 =C2=A0"mptcp-dev mailing list"

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> please provide the reference as readers m=
ight not know what

it is.





Will add.





* Section 5.1

=C2=A0 =C2=A0 "The second subflow manager that is currently supported =
by the

=C2=A0 =C2=A0 Multipath TCP implementation in the Linux kernel is the ndiff=
port

=C2=A0 =C2=A0 subflow manager."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> we might need a reference for ndiffport?=






There is no explicit document on this path manager afaik.
=

OK. then, I might prefer something like "TCP implementa=
tion in the Linux kernel is named ndiffport subflow manager"






* Section 5.1

=C2=A0 =C2=A0"This manager was initially created to exploit the

=C2=A0 =C2=A0 path diversity that exists between single-homed hosts due to =
the

=C2=A0 =C2=A0 utilization of flow-based load balancing techniques.=C2=A0 Th=
is subflow

=C2=A0 =C2=A0 manager creates N subflows between the same pair of IP addres=
ses.

=C2=A0 =C2=A0 The N subflows are created by the client and differ only in t=
he

=C2=A0 =C2=A0 source port selected by the client."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean the logic of=
 the manager has been changed?

If so, what's the reason for this?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> How do we determine N?





N is a static configuration. Some experiments have been reported in the SIG=
COMM'11 paper





why it uses the same pair of IP

addresses?





Because it is used on single-homed hosts

OK=
. But, what if the node is multi-homed?=C2=A0






* Section 5.2

=C2=A0 =C2=A0 "However, from an implementation point-of-view supportin=
g different

=C2=A0 =C2=A0 destination ports for the same Multipath TCP connection intro=
duces a

=C2=A0 =C2=A0 new performance issue."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> It seems that the rest of the par=
agraph doesn't provide

specific explanation for performance issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is it coming from im=
plementation proxy or other reasons?





This comes from an implementation issue because the stack needs to listen t=
o more ports.





* Section 5.2

=C2=A0 =C2=A0 "This imposes an additional cost on servers, previously =
not existent

on legacy TCP implementations. "

=C2=A0 =C2=A0 =C2=A0 -->I understand there'll be additional cost. Ho=
wever, is it a very

complex mechanism to affect performance?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm wondering some kinds of hash tab=
le might do some jobs.





I don't think that such a solution has been explored
<=
br>
OK, =C2=A0Then, It seems to me that "introduces a new pe=
rformance issue." might be too much..






* Section 5.3

=C2=A0 =C2=A0 =C2=A0 I think we should use "M_" state for the sta=
tus of mptcp otherwise

it'll be confused with the status of TCP.





Will add





* Section 5.3

=C2=A0 =C2=A0 =C2=A0 "Figure 4 shows a very particular issue within Mu=
ltipath TCP."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> I might miss something, but I'm not =
very sure the cases

described here.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my understanding, client=
 should perform close() so that

it will go timewait and server can release the resource quickly.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However, in this example, s=
erver perform close() and goes

into m_timewait. Please clarify this point.



* Section 6

=C2=A0 =C2=A0 =C2=A0 "SCTP implementations also include schedulers, bu=
t these are used

to schedule the different streams. "

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean all schedulers for =
SCTP are used to schedule

the different stream?





That was our understanding, but maybe there are schedulers on CMT-SCTP impl=
ementations.

Hmm. when we say SCTP implemen=
tations, I tend to think about both SCTP (rfc4960) and CMT-SCTP implementat=
ions.
So, I am personally a bit skeptical about this sentence.=C2=
=A0






* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Unfortunately, none of the proposed techni=
ques have been

implemented and used in real deployment."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Is there any reason for this? If =
not, I think we had

better add "at this moment"





Exact, everything in the document is to be considered "as of this writ=
ing".





* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"The simulation scenarios discussed in [PAM=
S2014] confirm the

impact of the packet scheduler on the performance of Multipath TCP."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Can you elaborate this? Otherwise=
, it looks a bit

ambiguous info.





Will expand.





* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Taking the smallest MSS does not solve th=
e issue as there might

be a case where the sublow with the smallest MSS will only participate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 marginally to the overall performance th=
erefore reducing the

potential throughput of the other subflows."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> It seems to me that this approach =
might work in some

situations. If so, "does not solve the issue" sounds too much.


* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does the current linux approach perform b=
etter than others? No

drawback or potential risk in this approach?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I would like to see more detailed analysi=
s on this. If this is

good approach, we might want to document the detailed logic?





It would be interesting to see if other implementors have faced the issue a=
nd found other solutions to cope with it.

I=
 am hoping some implementors will speak up on this...
=C2=A0

--
Yoshi=C2=A0


--047d7b3a8980f12dbd0516990afc--


From nobody Thu May 21 16:20:04 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F571A8888 for ; Thu, 21 May 2015 09:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.323
X-Spam-Level: *
X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 WxYiIm7u7X-5 for ; Thu, 21 May 2015 09:10:00 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c: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 C81161A8871 for ; Thu, 21 May 2015 09:09:55 -0700 (PDT)
Received: by wicmc15 with SMTP id mc15so17719602wic.1 for ; Thu, 21 May 2015 09:09:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bristol.ac.uk; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YDOK5ahL37/LfOA+LuWOqVNZWfI+BkN0eRHBaWezOPo=; b=KvWcd4Yy2G8jT2mBmKayOw1NuS2eKsaM0fS+IyYOF8BZfIZ4S0Q8wv0Pu9c1vxDEkT Mw1mzrhHGAAmznccLfl47Lq0Ze31iYEng4BRg0csOGNqvnR7yhkb1wsE/6R4t23jrGGl 0Iy5emypuGfrmaHXM/eZqNK0KR6dH5N64eF6c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YDOK5ahL37/LfOA+LuWOqVNZWfI+BkN0eRHBaWezOPo=; b=kqFckljoWHW35tF2UVAew2lHkOkf6SdhWrJK48W3dbL7V1A66bkk150CsN0GlDLEKl E6jhtLNvsNYQG+A9IBmOoa1MsSIP2CraITCQDv7Fm3vqGt9oO2QgtVHqUK97skHFoHR3 pcAoVwChAdxUH0pNrHxioPBPkDUW04cWixo00pUj2bIMNzvt9QqgpGYBZ4TbuVXjNOyl Hnwo50PS+hovzWvA24H74foa5JFLIz1862pLwZ/Qo81ZHNIw2o/BIoch0zdr9zNdFuZ6 bWjrZ7hX4fmAgtm2GbZ1+6lRgJpeWbOEHHLH84ajP4LV7w1LqRYCSVBzsSBtTbUW4RIE sYYA==
X-Gm-Message-State: ALoCoQnIaqzgNGRC1DiA9o6c+XAqLMTSIOLyHgPVjussHSOEvEl1jEEYTQkFr5RF/IplOpQmU0K6
MIME-Version: 1.0
X-Received: by 10.180.20.200 with SMTP id p8mr52259951wie.78.1432224594391; Thu, 21 May 2015 09:09:54 -0700 (PDT)
Received: by 10.28.72.193 with HTTP; Thu, 21 May 2015 09:09:54 -0700 (PDT)
In-Reply-To: 
References: <1431361552419.40809@bt.com>  <555A2F3F.1020606@uclouvain.be> 
Date: Thu, 21 May 2015 17:09:54 +0100
Message-ID: 
From: Amani Alheid 
To: Yoshifumi Nishida 
Content-Type: multipart/alternative; boundary=bcaec53f35ef30047c051699c6c6
Archived-At: 
X-Mailman-Approved-At: Thu, 21 May 2015 16:20:03 -0700
Cc: multipathtcp 
Subject: Re: [multipathtcp] WG Last call for "Experience with Multipath TCP"
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 May 2015 16:10:06 -0000

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

Hi Multipath group members
I am wondering if your document is related to MPTCP using Linux
implementation only or not. I have published papers on the behaviour of
MPTCP using three different congestion control algorithms used in
conjunction with four TCP packet reordering solutions using NS-3. The
papers are published in AINA2014 and SIMS2014.
"An Analysis of the Impact of Out-Of-Order Recovery Algorithms on MPTCP
Throughput" .
and "Performance Evaluation of MPTCP in Indoor Heterogeneous Networks."
which can be found in the following links
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D6838660&tag=3D1
http://ijssst.info/Vol-15/No-5/data/5198a173.pdf
The study investigates how sensitive the performance is against the delay
difference between the paths used. I am thinking weather this study can add
things to your experiences or not. T
if any one is interesting I am glad to answer any question.
Best regards,
=E2=80=8B=E2=80=8B
*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*
*=E2=80=8BMrs. =E2=80=8BAmani Alheid*



*=E2=80=8BPhD student.=E2=80=8BCommunication Systems & Networks GroupUniver=
sity of
BristolUnited Kingdom=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*

On 21 May 2015 at 16:17, Yoshifumi Nishida  wrote:

> Hi Olivier,
>
> Thanks for the response.
>
> On Mon, May 18, 2015 at 11:28 AM, Olivier Bonaventure <
> Olivier.Bonaventure@uclouvain.be> wrote:
>
>> Yoshifumi,
>>
>>>
>>> I have reviewed this draft and I have the following comments. (sorry fo=
r
>>> long lists)
>>>
>>>
>> Thanks for the detailed comments. I'll try to answer them below
>>
>>  * Title
>>>     Experience with Multipath TCP
>>>       --> Although the title seems to say it will describe experiences
>>> for mptcp, I think it also contains some other stuff.
>>>            For example, some use cases described here look like
>>> possibilities, but haven't fully experienced yet.
>>>            This may be fine as it's still useful info, but I think we
>>> had better clarify what we should include in the doc.
>>>
>>
>> We could remove the discussion of the use cases from this document.
>
>
> I am personally fine with it. I think the draft can describe the current
> experience and provide some guidelines for future experiences and use cas=
es.
> But, I think you should articulate what's in the doc in abstract and
> introduction section.
>
>
>>
>>  * Section 1
>>>     Section {{usecases}}. Seciton{{congestion}
>>>       --> editorial miss?
>>>
>>
>> Wrong conversion from markdown to text :-(
>>
>>  * Section 2
>>>     [HotMiddlebox13] documents a corner case with segment splitting tha=
t
>>> may lead to desynchronisation between the two hosts.
>>>        --> this sounds a bit problematic. Why you don't elaborate this?
>>>
>>
>> I can expand it based on the text in [HotMiddlebox13]
>>
>>  * Section 2
>>>     The results for [HotMiddlebox13] listed in the draft looks good.
>>> However, it seems to me that it has some presumptions for the
>>> middleboxes.
>>>     For example, I guess it might presume that middleboxes don't discar=
d
>>> options when it coalesces segments or don't drop options intermittently=
.
>>>     If so, we might want to describe them.
>>>
>>
>> I can add other scenarios, but this will make the text more difficult to
>> read. Some of the scenarios explored in [HotMiddlebox13] are corner case=
s
>> that are unlikely to happen in practice.
>>
>
> I don't think you have to describe minor corner cases. But, I might want
> to see some texts that navigate users to the doc if they're interested.
>
>>
>> We recently analysed all the MPTCP connections received on
>> multipath-tcp.org and observed the following :
>>
>> Among the 184 thousands Multipath TCP connections in the trace, we
>> observed only 125 of them falling back to regular TCP, which happened wi=
th
>> 28 distinctive client IP addresses. These include 91 HTTP connections an=
d
>> 34 FTP connections. The FTP interference is expected and due to Applicat=
ion
>> Level Gateways running on NAT boxes. The HTTP interference appeared only=
 on
>> the direction from server to client and could have been caused by
>> transparent proxies deployed in cellular and enterprise networks.
>>
>> Note that we do not observe interference where a middlebox removes the
>> MP_CAPABLE option from the SYN in this dataset.
>
>
> this looks very useful experiences to me. it may be good to put this in
> the doc.
>
>>
>>
>>> * Section 3
>>>     Description for backup mode doesn't look experiences to me.  Some
>>> clarifications may be required.
>>>
>>
>> There are two issues with the backup mode that could be discussed for
>> smartphones. Let us assume for simplicity that the WiFi is used as a
>> primary interface and cellular as a backup interface.
>>
>> The first is that by starting the backup flow (i.e. with a three-way
>> handshake) over the cellular interface, the smartphone consummes energy =
and
>> radio channel capacity (typically for a few seconds). If the backup subf=
low
>> is not started immediately, but only when the primary fails, then energy
>> and radio channel consumption are reduced.
>>
>> The second issue that we observe on smartphones is that the status of a
>> subflow cannot be described as a binary value (active/inactive). There a=
re
>> many situations where a subflow is considered active while it cannot
>> efficiently transmit data. A typical example is a smartphone that is far
>> away from a WiFi access point, but close enough to perform the
>> three-way-handshake. If this subflow is a primary subflow and the cellul=
ar
>> a backup subflow, then MPTCP will try to retransmit data several times o=
ver
>> the WiFi interface before stopping the WiFi subflow and starting to use =
the
>> cellular one. This can cause delays of tens of seconds before switching =
to
>> the cellular interface.
>
>
> If we'll put some future/potential use cases in the doc, I think this wil=
l
> be useful guideline.
>
>>
>>
>>> * Section 3
>>>     Description for single-path mode doesn't look experiences to me.
>>> Some clarifications may be required.
>>>
>>> * Section 3
>>>     "From a protocol viewpoint, [Cellnet12] discusses the problem posed
>>> by
>>>     the unreliability of the ADD_ADDR option and proposes a small
>>>     protocol extension to allow hosts to reliably exchange this option.
>>>     It would be useful to analyze packet traces to understand whether t=
he
>>>     unreliability of the REMOVE_ADDR option poses an operational proble=
m
>>>     in real deployments. "
>>>
>>>       --> this seems to be useful info. I might want to see more
>>> detailed info.
>>>
>>
>> This should be compared with the decision of Apple to not implement
>> ADD_ADDR. We can add some text.
>>
>>>
>>> * Section 3
>>>    "MPTCP provides a robust data transport and reduces variations in
>>> download latencies".
>>>        --> This looks good results, I might want to see more precise
>>> info.
>>>
>>
>> This sentence comes from the conclusion of the paper IMC13b. What kind o=
f
>> more precise information do you expect ?
>
>
>  Well, I am wondering if you can show some small dataset here as I feel
> this sentence doesn't have much info.
>
>>
>>
>>  * Section 3
>>>      The use case of coupling mptcp and SDN doesn't look experiences to
>>> me. Some clarifications may be required.
>>>      I'm not very sure "Using an international network" is a part of SD=
N
>>> use cases although this is described in the same paragraph.
>>>
>>
>> This part could be removed and we could point to the MPTCP bibliography
>> for other use cases https://github.com/obonaventure/mptcp-bib
>>
>> I think that the use case described in a recent NSDI paper
>>
>> https://www.usenix.org/conference/nsdi15/technical-sessions/presentation=
/croitoru
>> should be added to this section because it is important for mobile devic=
es
>>
>> The SDN part looks a bit thin to me. It might be good to be replaced If
> you have other good use cases.
>
>
>>  * Section 4
>>>      This seems to be very useful and important info and I personally
>>> would like to see more detailed info.
>>>      For example, which situation we can see performance benefits of
>>> OLIA? How much benefit we can get.
>>>      Is there any concern or risks to use OLIA or default CC? If OLIA i=
s
>>> better, shall we consider adopting it? Or, is it too early?
>>>      It might be good if the authors can provide something on these
>>> points.
>>>
>>
>> It is possible to find simulation scenarios/topologies where one
>> congestion control algorithm works better than others. However, we shoul=
d
>> not decide on the basis of a small number of examples.
>>
>
>> The best approach to compare different congestion control schemes is to
>> explore a wide range of network conditions. Christoph Paasch has used an
>> experimental design approach to perform this analysis for a bonding
>> scenario (two links without congestion). The results are described in
>>
>> http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-de=
sign-improve-multipath-tcp
>> and have been updated in
>> http://inl.info.ucl.ac.be/publications/improving-multipath-tcp
>>
>> Based on these results, there does not seem to be a strong benefit with
>> OLIA over LIA. If the WG wants to reconsider the selection of the defaul=
t
>> congestion control scheme, it should use a similar experimental approach
>> and use different network topologies.
>
>
> I believe this is a very nice explanation for the current status of CC
> studies. I think this type of views will be useful as a guidance for futu=
re
> experiences.
>
>
>>  * Section 5.1
>>>      "mptcp-dev mailing list"
>>>        --> please provide the reference as readers might not know what
>>> it is.
>>>
>>
>> Will add.
>>
>>  * Section 5.1
>>>     "The second subflow manager that is currently supported by the
>>>     Multipath TCP implementation in the Linux kernel is the ndiffport
>>>     subflow manager."
>>>         --> we might need a reference for ndiffport?
>>>
>>
>> There is no explicit document on this path manager afaik.
>
>
> OK. then, I might prefer something like "TCP implementation in the Linux
> kernel is named ndiffport subflow manager"
>
>>
>>
>>  * Section 5.1
>>>    "This manager was initially created to exploit the
>>>     path diversity that exists between single-homed hosts due to the
>>>     utilization of flow-based load balancing techniques.  This subflow
>>>     manager creates N subflows between the same pair of IP addresses.
>>>     The N subflows are created by the client and differ only in the
>>>     source port selected by the client."
>>>            --> Does this mean the logic of the manager has been changed=
?
>>> If so, what's the reason for this?
>>>            --> How do we determine N?
>>>
>>
>> N is a static configuration. Some experiments have been reported in the
>> SIGCOMM'11 paper
>>
>>  why it uses the same pair of IP
>>> addresses?
>>>
>>
>> Because it is used on single-homed hosts
>
>
> OK. But, what if the node is multi-homed?
>
>>
>>
>>> * Section 5.2
>>>     "However, from an implementation point-of-view supporting different
>>>     destination ports for the same Multipath TCP connection introduces =
a
>>>     new performance issue."
>>>
>>>           --> It seems that the rest of the paragraph doesn't provide
>>> specific explanation for performance issue.
>>>                Is it coming from implementation proxy or other reasons?
>>>
>>
>> This comes from an implementation issue because the stack needs to liste=
n
>> to more ports.
>>
>>  * Section 5.2
>>>     "This imposes an additional cost on servers, previously not existen=
t
>>> on legacy TCP implementations. "
>>>       -->I understand there'll be additional cost. However, is it a ver=
y
>>> complex mechanism to affect performance?
>>>           I'm wondering some kinds of hash table might do some jobs.
>>>
>>
>> I don't think that such a solution has been explored
>
>
> OK,  Then, It seems to me that "introduces a new performance issue." migh=
t
> be too much..
>
>>
>>
>>  * Section 5.3
>>>       I think we should use "M_" state for the status of mptcp otherwis=
e
>>> it'll be confused with the status of TCP.
>>>
>>
>> Will add
>>
>>  * Section 5.3
>>>       "Figure 4 shows a very particular issue within Multipath TCP."
>>>         --> I might miss something, but I'm not very sure the cases
>>> described here.
>>>              In my understanding, client should perform close() so that
>>> it will go timewait and server can release the resource quickly.
>>>              However, in this example, server perform close() and goes
>>> into m_timewait. Please clarify this point.
>>>
>>> * Section 6
>>>       "SCTP implementations also include schedulers, but these are used
>>> to schedule the different streams. "
>>>          --> Does this mean all schedulers for SCTP are used to schedul=
e
>>> the different stream?
>>>
>>
>> That was our understanding, but maybe there are schedulers on CMT-SCTP
>> implementations.
>
>
> Hmm. when we say SCTP implementations, I tend to think about both SCTP
> (rfc4960) and CMT-SCTP implementations.
> So, I am personally a bit skeptical about this sentence.
>
>>
>>
>>  * Section 6
>>>        "Unfortunately, none of the proposed techniques have been
>>> implemented and used in real deployment."
>>>           --> Is there any reason for this? If not, I think we had
>>> better add "at this moment"
>>>
>>
>> Exact, everything in the document is to be considered "as of this
>> writing".
>>
>>  * Section 6
>>>        "The simulation scenarios discussed in [PAMS2014] confirm the
>>> impact of the packet scheduler on the performance of Multipath TCP."
>>>           --> Can you elaborate this? Otherwise, it looks a bit
>>> ambiguous info.
>>>
>>
>> Will expand.
>>
>>  * Section 7
>>>         "Taking the smallest MSS does not solve the issue as there migh=
t
>>> be a case where the sublow with the smallest MSS will only participate
>>>           marginally to the overall performance therefore reducing the
>>> potential throughput of the other subflows."
>>>          --> It seems to me that this approach might work in some
>>> situations. If so, "does not solve the issue" sounds too much.
>>>
>>> * Section 7
>>>          Does the current linux approach perform better than others? No
>>> drawback or potential risk in this approach?
>>>          I would like to see more detailed analysis on this. If this is
>>> good approach, we might want to document the detailed logic?
>>>
>>
>> It would be interesting to see if other implementors have faced the issu=
e
>> and found other solutions to cope with it.
>
>
> I am hoping some implementors will speak up on this...
>
>
> --
> Yoshi
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

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


Hi Multipath group members
I am wondering if your document is related to MPTCP usi=
ng Linux implementation only or not. I have published papers on the behavio=
ur of MPTCP=C2=A0using three
different congestion control algorithms used in conjunction with four TCP p=
acket reordering solutions=C2=A0using NS-3. The papers are published in AINA2014 and SIMS2014.
"An Analysis of the Im=
pact of Out-Of-Order Recovery Algorithms on MPTCP Throughput" .=C2=A0<=
/div>
and "Performance Eva=
luation of MPTCP in Indoor Heterogeneous Networks."=C2=A0
=

which can be found in the following links=C2=
=A0
http://ieeexplore.ieee.or=
g/xpls/abs_all.jsp?arnumber=3D6838660&tag=3D1
h=
ttp://ijssst.info/Vol-15/No-5/data/5198a173.pdf
The study investigates how sensitive the performance is against the =
delay difference between the paths used.=C2=A0I am thinking=C2=A0weather=C2=
=A0this study can add things to your experiences or not.=C2=A0T
=
if any one is=C2=A0interesting I am glad to answer =
any question.
Best regards,
=E2=80=8B=E2=80=8B<=
/div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=E2=80=8BMrs. =E2=80=8B
Amani Alheid
=
=E2=80=8BPhD student.=E2=80=8B

Communication Systems & Networks Group
<=
span style=3D"line-height:20px;font-family:Arial,Helvetica,Verdana,sans-ser=
if">University of Bristol
United Kingdom
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On 21 May 2015 at 16:17, Yoshifumi Nishida <=
span dir=3D"ltr"><nishida@sfc.wide.ad.jp> wrote:
Hi Olivier,

Thanks for the response.=C2=A0<=
br>

On Mon, May 18, 2015 at 11:28 AM, Olivier Bonaventure =
<O=
livier.Bonaventure@uclouvain.be> wrote:
=
Yoshifumi,





I have reviewed this draft and I have the following comments. (sorry for
long lists)







Thanks for the detailed comments. I'll try to answer them below




* Title

=C2=A0 =C2=A0 Experience with Multipath TCP

=C2=A0 =C2=A0 =C2=A0 --> Although the title seems to say it will describ=
e experiences

for mptcp, I think it also contains some other stuff.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, some use cases descri=
bed here look like

possibilities, but haven't fully experienced yet.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This may be fine as it's still=
 useful info, but I think we

had better clarify what we should include in the doc.





We could remove the discussion of the use cases from this document.

I am personally fine with it. I think the d=
raft can describe the current experience and provide some guidelines for fu=
ture experiences and use cases.
But, I think you should articulat=
e what's in the doc in abstract and introduction section.
=C2=A0





* Section 1

=C2=A0 =C2=A0 Section {{usecases}}. Seciton{{congestion}

=C2=A0 =C2=A0 =C2=A0 --> editorial miss?





Wrong conversion from markdown to text :-(





* Section 2

=C2=A0 =C2=A0 [HotMiddlebox13] documents a corner case with segment splitti=
ng that

may lead to desynchronisation between the two hosts.

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> this sounds a bit problematic. Why you do=
n't elaborate this?





I can expand it based on the text in [HotMiddlebox13]





* Section 2

=C2=A0 =C2=A0 The results for [HotMiddlebox13] listed in the draft looks go=
od.

However, it seems to me that it has some presumptions for the middleboxes.<=
br>
=C2=A0 =C2=A0 For example, I guess it might presume that middleboxes don=
9;t discard

options when it coalesces segments or don't drop options intermittently=
.

=C2=A0 =C2=A0 If so, we might want to describe them.





I can add other scenarios, but this will make the text more difficult to re=
ad. Some of the scenarios explored in [HotMiddlebox13] are corner cases tha=
t are unlikely to happen in practice.

I don't think you have to describe minor corner cases. But, I mig=
ht want to see some texts that navigate users to the doc if they're int=
erested. =C2=A0



We recently analysed all the MPTCP connections received on multipath-tcp.org and observed t=
he following :



Among the 184 thousands Multipath TCP connections in the trace, we observed=
 only 125 of them falling back to regular TCP, which happened with 28 disti=
nctive client IP addresses. These include 91 HTTP connections and 34 FTP co=
nnections. The FTP interference is expected and due to Application Level Ga=
teways running on NAT boxes. The HTTP interference appeared only on the dir=
ection from server to client and could have been caused by transparent prox=
ies deployed in cellular and enterprise networks.



Note that we do not observe interference where a middlebox removes the MP_C=
APABLE option from the SYN in this dataset.

this looks very useful experiences to me. it may be good to put thi=
s in the doc.







* Section 3

=C2=A0 =C2=A0 Description for backup mode doesn't look experiences to m=
e.=C2=A0 Some

clarifications may be required.





There are two issues with the backup mode that could be discussed for smart=
phones. Let us assume for simplicity that the WiFi is used as a primary int=
erface and cellular as a backup interface.



The first is that by starting the backup flow (i.e. with a three-way handsh=
ake) over the cellular interface, the smartphone consummes energy and radio=
 channel capacity (typically for a few seconds). If the backup subflow is n=
ot started immediately, but only when the primary fails, then energy and ra=
dio channel consumption are reduced.



The second issue that we observe on smartphones is that the status of a sub=
flow cannot be described as a binary value (active/inactive). There are man=
y situations where a subflow is considered active while it cannot efficient=
ly transmit data. A typical example is a smartphone that is far away from a=
 WiFi access point, but close enough to perform the three-way-handshake. If=
 this subflow is a primary subflow and the cellular a backup subflow, then =
MPTCP will try to retransmit data several times over the WiFi interface bef=
ore stopping the WiFi subflow and starting to use the cellular one. This ca=
n cause delays of tens of seconds before switching to the cellular interfac=
e.

If we'll put some future/pote=
ntial use cases in the doc, I think this will be useful guideline.







* Section 3

=C2=A0 =C2=A0 Description for single-path mode doesn't look experiences=
 to me.

Some clarifications may be required.



* Section 3

=C2=A0 =C2=A0 "From a protocol viewpoint, [Cellnet12] discusses the pr=
oblem posed by

=C2=A0 =C2=A0 the unreliability of the ADD_ADDR option and proposes a small=


=C2=A0 =C2=A0 protocol extension to allow hosts to reliably exchange this o=
ption.

=C2=A0 =C2=A0 It would be useful to analyze packet traces to understand whe=
ther the

=C2=A0 =C2=A0 unreliability of the REMOVE_ADDR option poses an operational =
problem

=C2=A0 =C2=A0 in real deployments. "



=C2=A0 =C2=A0 =C2=A0 --> this seems to be useful info. I might want to s=
ee more

detailed info.





This should be compared with the decision of Apple to not implement ADD_ADD=
R. We can add some text.





* Section 3

=C2=A0 =C2=A0"MPTCP provides a robust data transport and reduces varia=
tions in

download latencies".

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> This looks good results, I might want to =
see more precise info.





This sentence comes from the conclusion of the paper IMC13b. What kind of m=
ore precise information do you expect ?

<=
div>=C2=A0Well, I am wondering if you can show some small dataset here as I=
 feel this sentence doesn't have much info.






* Section 3

=C2=A0 =C2=A0 =C2=A0The use case of coupling mptcp and SDN doesn't look=
 experiences to

me. Some clarifications may be required.

=C2=A0 =C2=A0 =C2=A0I'm not very sure "Using an international netw=
ork" is a part of SDN

use cases although this is described in the same paragraph.





This part could be removed and we could point to the MPTCP bibliography for=
 other use cases https://github.com/obonaventure/mptcp-bib



I think that the use case described in a recent NSDI paper

https://www.usenix.org/conference/nsdi=
15/technical-sessions/presentation/croitoru

should be added to this section because it is important for mobile devices<=
span>


The SDN part looks a bit thin to me. It=
 might be good to be replaced If you have other good use cases.
=C2=A0



* Section 4

=C2=A0 =C2=A0 =C2=A0This seems to be very useful and important info and I p=
ersonally

would like to see more detailed info.

=C2=A0 =C2=A0 =C2=A0For example, which situation we can see performance ben=
efits of

OLIA? How much benefit we can get.

=C2=A0 =C2=A0 =C2=A0Is there any concern or risks to use OLIA or default CC=
? If OLIA is

better, shall we consider adopting it? Or, is it too early?

=C2=A0 =C2=A0 =C2=A0It might be good if the authors can provide something o=
n these points.





It is possible to find simulation scenarios/topologies where one congestion=
 control algorithm works better than others. However, we should not decide =
on the basis of a small number of examples.


The best approach to compare different congestion control schemes is to exp=
lore a wide range of network conditions. Christoph Paasch has used an exper=
imental design approach to perform this analysis for a bonding scenario (tw=
o links without congestion). The results are described in

http://inl.info.ucl.a=
c.be/publications/benefits-applying-experimental-design-improve-multipath-t=
cp

and have been updated in

http://inl.info.ucl.ac.be/publications/improving-multipat=
h-tcp



Based on these results, there does not seem to be a strong benefit with OLI=
A over LIA. If the WG wants to reconsider the selection of the default cong=
estion control scheme, it should use a similar experimental approach and us=
e different network topologies.

I be=
lieve this is a very nice explanation for the current status of CC studies.=
 I think this type of views will be useful as a guidance for future experie=
nces.
=C2=A0



* Section 5.1

=C2=A0 =C2=A0 =C2=A0"mptcp-dev mailing list"

=C2=A0 =C2=A0 =C2=A0 =C2=A0--> please provide the reference as readers m=
ight not know what

it is.





Will add.





* Section 5.1

=C2=A0 =C2=A0 "The second subflow manager that is currently supported =
by the

=C2=A0 =C2=A0 Multipath TCP implementation in the Linux kernel is the ndiff=
port

=C2=A0 =C2=A0 subflow manager."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> we might need a reference for ndiffport?=






There is no explicit document on this path manager afaik.
=

OK. then, I might prefer something like "TCP imp=
lementation in the Linux kernel is named ndiffport subflow manager"






* Section 5.1

=C2=A0 =C2=A0"This manager was initially created to exploit the

=C2=A0 =C2=A0 path diversity that exists between single-homed hosts due to =
the

=C2=A0 =C2=A0 utilization of flow-based load balancing techniques.=C2=A0 Th=
is subflow

=C2=A0 =C2=A0 manager creates N subflows between the same pair of IP addres=
ses.

=C2=A0 =C2=A0 The N subflows are created by the client and differ only in t=
he

=C2=A0 =C2=A0 source port selected by the client."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean the logic of=
 the manager has been changed?

If so, what's the reason for this?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> How do we determine N?





N is a static configuration. Some experiments have been reported in the SIG=
COMM'11 paper





why it uses the same pair of IP

addresses?





Because it is used on single-homed hosts

=

OK. But, what if the node is multi-homed?=C2=A0
=







* Section 5.2

=C2=A0 =C2=A0 "However, from an implementation point-of-view supportin=
g different

=C2=A0 =C2=A0 destination ports for the same Multipath TCP connection intro=
duces a

=C2=A0 =C2=A0 new performance issue."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> It seems that the rest of the par=
agraph doesn't provide

specific explanation for performance issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is it coming from im=
plementation proxy or other reasons?





This comes from an implementation issue because the stack needs to listen t=
o more ports.





* Section 5.2

=C2=A0 =C2=A0 "This imposes an additional cost on servers, previously =
not existent

on legacy TCP implementations. "

=C2=A0 =C2=A0 =C2=A0 -->I understand there'll be additional cost. Ho=
wever, is it a very

complex mechanism to affect performance?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm wondering some kinds of hash tab=
le might do some jobs.





I don't think that such a solution has been explored
<=
br>
OK, =C2=A0Then, It seems to me that "introduces a=
 new performance issue." might be too much..






* Section 5.3

=C2=A0 =C2=A0 =C2=A0 I think we should use "M_" state for the sta=
tus of mptcp otherwise

it'll be confused with the status of TCP.





Will add





* Section 5.3

=C2=A0 =C2=A0 =C2=A0 "Figure 4 shows a very particular issue within Mu=
ltipath TCP."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> I might miss something, but I'm not =
very sure the cases

described here.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my understanding, client=
 should perform close() so that

it will go timewait and server can release the resource quickly.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However, in this example, s=
erver perform close() and goes

into m_timewait. Please clarify this point.



* Section 6

=C2=A0 =C2=A0 =C2=A0 "SCTP implementations also include schedulers, bu=
t these are used

to schedule the different streams. "

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> Does this mean all schedulers for =
SCTP are used to schedule

the different stream?





That was our understanding, but maybe there are schedulers on CMT-SCTP impl=
ementations.

Hmm. when we say SCTP i=
mplementations, I tend to think about both SCTP (rfc4960) and CMT-SCTP impl=
ementations.
So, I am personally a bit skeptical about this sente=
nce.=C2=A0






* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Unfortunately, none of the proposed techni=
ques have been

implemented and used in real deployment."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Is there any reason for this? If =
not, I think we had

better add "at this moment"





Exact, everything in the document is to be considered "as of this writ=
ing".





* Section 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0"The simulation scenarios discussed in [PAM=
S2014] confirm the

impact of the packet scheduler on the performance of Multipath TCP."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> Can you elaborate this? Otherwise=
, it looks a bit

ambiguous info.





Will expand.





* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Taking the smallest MSS does not solve th=
e issue as there might

be a case where the sublow with the smallest MSS will only participate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 marginally to the overall performance th=
erefore reducing the

potential throughput of the other subflows."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--> It seems to me that this approach =
might work in some

situations. If so, "does not solve the issue" sounds too much.


* Section 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does the current linux approach perform b=
etter than others? No

drawback or potential risk in this approach?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I would like to see more detailed analysi=
s on this. If this is

good approach, we might want to document the detailed logic?





It would be interesting to see if other implementors have faced the issue a=
nd found other solutions to cope with it.

=

I am hoping some implementors will speak up on this...
=C2=A0

--
Yoshi=C2=A0


_______________________________________________

multipathtcp mailing list

multipathtcp@ietf.org

https://www.ietf.org/mailman/listinfo/multipathtcp





--bcaec53f35ef30047c051699c6c6--


From nobody Sun May 24 08:15:43 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1CA1A9244 for ; Sun, 24 May 2015 08:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.806
X-Spam-Level: 
X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEAU9zNyfEEP for ; Sun, 24 May 2015 08:15:38 -0700 (PDT)
Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FD51A923B for ; Sun, 24 May 2015 08:15:36 -0700 (PDT)
Received: from [136.186.242.238] (vpn242-238.cc.swin.edu.au [136.186.242.238]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t4OFFQVq024968;  Mon, 25 May 2015 01:15:27 +1000
Message-ID: <5561EB0E.1010400@swin.edu.au>
Date: Mon, 25 May 2015 01:15:26 +1000
From: Nigel Williams 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: philip.eardley@bt.com, multipathtcp@ietf.org
References: <1431362636609.44739@bt.com>
In-Reply-To: <1431362636609.44739@bt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [multipathtcp] Creating WG document for the
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 May 2015 15:15:42 -0000

Hi Philip,

I should be able to provide some feedback in relation to the FreeBSD 
implementation I've been working on. (Incidentally I should also be 
attending the Prague meeting).

cheers,
nigel

On 12/05/15 02:43, philip.eardley@bt.com wrote:
> Hi,
>
> we have this milestone on our charter
>
> Apr 2015	Implementation advice (Informational) to IESG
>
>
> We have an existing, expired individual draft "Guidelines for implementers"https://tools.ietf.org/html/draft-barre-mptcp-impl-00  ​
>
> We suggest that this is re-activated as a WG document and then updated with recent information (Olivier B has kindly offered to do this). Doing this now should let us discuss (finalise?) it during the Prague meeting.
>
> Also, this document concentrates on the Linux implementation - so it would be very valuable if the freeBSD and Apple implementers are able to join the draft. Please let us know if you can - and of course any other implementations where you can contribute.
>
>
> Please let us know if there are any objections to creating this as a WG document, or other ideas how we can meet this milestone.
>
>
> thanks
>
> Phil & Yoshi
>
> ​
>
> Here's the additional charter text about this milestone
>
> < documents have several points where an implementer may benefit from
> guidance, for example about heuristics such as buffer sizing, or from
> advice about alternative implementations such as bump-in-the-stack.
>
>>>
>
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>


From nobody Mon May 25 04:28:23 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964291B2B55 for ; Mon, 25 May 2015 02:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk24HrD1qJ8y for ; Mon, 25 May 2015 02:56:01 -0700 (PDT)
Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDB11B2B54 for ; Mon, 25 May 2015 02:55:59 -0700 (PDT)
From: "Appanasamy, Palanivelan" 
X-IronPort-AV: E=Sophos; i="5.13,491,1427731200"; d="scan'208,217"; a="49338850"
Received: from sc-hkg-simr01.ap.verizon.com ([166.45.72.242]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2015 17:55:57 +0800
Received: from sc-hkg-simr01.ap.verizon.com ([166.45.72.242]:48021) by sc-hkg-simr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Ywp6z-00054l-4B for multipathtcp@ietf.org; Mon, 25 May 2015 09:55:57 +0000
Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-hkg-simr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Ywp6y-00054i-4q for multipathtcp@ietf.org; Mon, 25 May 2015 09:55:57 +0000
Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Mon, 25 May 2015 15:25:55 +0530
To: "multipathtcp@ietf.org" 
Importance: high
X-Priority: 1
Date: Mon, 25 May 2015 15:25:54 +0530
Thread-Topic: What are the existing challenges to MultipathTCP Implementation
Thread-Index: AdCW0CawwKunYlLaQxO1OOWAmDZEsw==
Message-ID: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_70AEAEC90FCAE0408586E94F491A07EC047B4E21D7MSBANE7MB01in_"
MIME-Version: 1.0
X-VZ-EMEA-INT-SIG: e4f64b7f8116da17dd2519c65b8bba35
X-APAC-E2-SIG: e4f64b7f8116da17dd2519c65b8bba35
Archived-At: 
X-Mailman-Approved-At: Mon, 25 May 2015 04:28:22 -0700
Subject: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2015 09:56:05 -0000

--_000_70AEAEC90FCAE0408586E94F491A07EC047B4E21D7MSBANE7MB01in_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWxsLA0KDQpJIGFwcHJlY2lhdGUgdGhlIGlkZWEgb2YgTXVsdGlwYXRoVENQLCB0aGUgcG9wdWxh
cml0eSBpdCBnb3QgYW5kICB0aGUgaXNzdWVzIGl0IHRyaWVzIHNvbHZpbmcuDQpCdXQsIHdoYXQg
YXJlIHRoZSBjaGFsbGVuZ2VzIHRoYXQgIG1ha2UgaW1wbGVtZW50ZXJzIGhlc2l0YW50IHRvIGFk
b3B0IHRoaXM/IEkgYmVsaWV2ZSB0aGUgcGFjZSBoYXMgc2xvd2VkIGRvd24gaW1tZW5zZWx5Lg0K
DQpQZXJoYXBzLCB3ZSBzaG91bGQgZ2V0IG1vcmUgZGF0YSBhbmQgc2VlIHdoZXJlIHdlIGNhbiBp
bXByb3ZlLiBBbnkgdGhvdWdodHMgb3IgcG9pbnRlcnM/DQpSZWFsbHkgYXBwcmVjaWF0ZSBzb21l
IGlucHV0cy9yZXNwb25zZS4gVGhhbmtzLg0KDQpSZWdhcmRzLA0KQS5QYWxhbml2ZWxhbg0KRE1U
Uy1FbmdnLCBWZXJpem9uIExhYnMNCg0K

--_000_70AEAEC90FCAE0408586E94F491A07EC047B4E21D7MSBANE7MB01in_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt
LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s
ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K
PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIy
Ij4NCjxkaXY+QWxsLDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSBhcHByZWNpYXRl
IHRoZSBpZGVhIG9mIE11bHRpcGF0aFRDUCwgdGhlIHBvcHVsYXJpdHkgaXQgZ290IGFuZCZuYnNw
OyB0aGUgaXNzdWVzIGl0IHRyaWVzIHNvbHZpbmcuIDwvZGl2Pg0KPGRpdj5CdXQsIHdoYXQgYXJl
IHRoZSBjaGFsbGVuZ2VzIHRoYXQmbmJzcDsgbWFrZSBpbXBsZW1lbnRlcnMgaGVzaXRhbnQgdG8g
YWRvcHQgdGhpcz8gSSBiZWxpZXZlIHRoZSBwYWNlIGhhcyBzbG93ZWQgZG93biBpbW1lbnNlbHku
PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5QZXJoYXBzLCB3ZSBzaG91bGQgZ2V0IG1v
cmUgZGF0YSBhbmQgc2VlIHdoZXJlIHdlIGNhbiBpbXByb3ZlLiBBbnkgdGhvdWdodHMgb3IgcG9p
bnRlcnM/IDwvZGl2Pg0KPGRpdj5SZWFsbHkgYXBwcmVjaWF0ZSBzb21lIGlucHV0cy9yZXNwb25z
ZS4gVGhhbmtzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4N
CjxkaXY+QS5QYWxhbml2ZWxhbjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iI0MwMDAwMCI+PGk+
RE1UUy1FbmdnLCBWZXJpem9uIExhYnM8L2k+PC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp
dj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_70AEAEC90FCAE0408586E94F491A07EC047B4E21D7MSBANE7MB01in_--


From nobody Mon May 25 06:11:01 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5941A8A07 for ; Mon, 25 May 2015 06:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.221
X-Spam-Level: *
X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Tv8Nu7vYVA9j for ; Mon, 25 May 2015 06:10:58 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACEF1A8A05 for ; Mon, 25 May 2015 06:10:57 -0700 (PDT)
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1770C278025 for ; Mon, 25 May 2015 22:10:55 +0900 (JST)
Received: by wgez8 with SMTP id z8so72822656wge.0 for ; Mon, 25 May 2015 06:10:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.172.72 with SMTP id ba8mr16398596wjc.136.1432559452655;  Mon, 25 May 2015 06:10:52 -0700 (PDT)
Received: by 10.194.27.193 with HTTP; Mon, 25 May 2015 06:10:52 -0700 (PDT)
In-Reply-To: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com>
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com>
Date: Mon, 25 May 2015 06:10:52 -0700
Message-ID: 
From: Yoshifumi Nishida 
To: "Appanasamy, Palanivelan" 
Content-Type: multipart/alternative; boundary=089e013c6b344b95640516e7bd2f
Archived-At: 
Cc: "multipathtcp@ietf.org" 
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2015 13:11:00 -0000

--089e013c6b344b95640516e7bd2f
Content-Type: text/plain; charset=UTF-8

Hi Palanivelan,

There're already several mptcp implementations.
I think you might want to take a look at the following draft to get some
rough ideas about implementation status.

https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02

Thanks,
--
Yoshi


On Mon, May 25, 2015 at 2:55 AM, Appanasamy, Palanivelan <
palanivelan.appanasamy@in.verizon.com> wrote:

>  All,
>
> I appreciate the idea of MultipathTCP, the popularity it got and  the
> issues it tries solving.
> But, what are the challenges that  make implementers hesitant to adopt
> this? I believe the pace has slowed down immensely.
>
> Perhaps, we should get more data and see where we can improve. Any
> thoughts or pointers?
> Really appreciate some inputs/response. Thanks.
>
> Regards,
> A.Palanivelan
> *DMTS-Engg, Verizon Labs*
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

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


Hi Palanivelan,

There're already several mptcp implementations.
I think you might want to take a look at the following=
 draft to get some rough ideas about implementation status.

https:=
//tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02
=


Thank=
s,
--
Y=
oshi

<=
br>
On Mon, May 25, 2015 at 2:55 AM, Appanasamy, =
Palanivelan <palanivelan.appanasamy@in.verizon.com=
> wrote:











All,


=C2=A0


I appreciate the idea of MultipathTCP, the popularity it got and=C2=A0=
 the issues it tries solving. 


But, what are the challenges that=C2=A0 make implementers hesitant to =
adopt this? I believe the pace has slowed down immensely.


=C2=A0


Perhaps, we should get more data and see where we can improve. Any tho=
ughts or pointers? 


Really appreciate some inputs/response. Thanks.


=C2=A0


Regards,


A.Palanivelan


DMTS-Engg, Verizon Labs


=C2=A0






_______________________________________________

multipathtcp mailing list

multipathtcp@ietf.org

https://www.ietf.org/mailman/listinfo/multipathtcp





--089e013c6b344b95640516e7bd2f--


From nobody Mon May 25 12:24:17 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE88C1ACDA3 for ; Mon, 25 May 2015 12:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Hr0g9zjZH2 for ; Mon, 25 May 2015 12:24:13 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 429F21A1EF4 for ; Mon, 25 May 2015 12:24:13 -0700 (PDT)
Received: from mbpobo.lan (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 386EC183493; Mon, 25 May 2015 21:24:06 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 386EC183493
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1432581846; bh=7nHf7/BNi8wdnsoJ80Fm0dvgQfaNOwXaDIE9Y/CUghs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sXXDwqdS6IA8KEOsCKdaV9LDsrhleg+KvJgSwdpZmxxwyn/vxBt/4s9rTPAhhbGzk dkQocP8SIGko5qSH0rg1T/WMnL6bKofH/8evJ9nY6ZnM1lGKzhdpDNZHJzhFhhKAkF 73+MLfFoiJgMhluD1rhABmTpQcFPWWbMES0f4/Bc=
Message-ID: <556376D5.9050409@uclouvain.be>
Date: Mon, 25 May 2015 21:24:05 +0200
From: Olivier Bonaventure 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Appanasamy, Palanivelan" ,  "multipathtcp@ietf.org" 
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com>
In-Reply-To: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated, 
X-SGSI-MailScanner-ID: 386EC183493.A1880
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: 
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2015 19:24:16 -0000

Hello,

> I appreciate the idea of MultipathTCP, the popularity it got and  the
> issues it tries solving.
> But, what are the challenges that  make implementers hesitant to adopt
> this? I believe the pace has slowed down immensely.
> Perhaps, we should get more data and see where we can improve. Any
> thoughts or pointers?

We see different types of deployments of Multipath TCP.

The first type of deployment is the end-to-end deployment with Apple as 
the example. Apple has implemented Multipath TCP in iOS and uses it for 
the SIRI application. This end-to-end scenario is possible because Apple 
controls the client and the server.

We've seen similar deployments in private networks. For example, a user 
of the Multipath TCP implementation in the Linux kernel has reported 
that he uses Multipath TCP for support the CEPH storage service. 
Apparently, he does this by assigning a loopback address to each storage 
server and one IP address per interface. The loopback addresses are 
advertised by the routing protocol and Multipath TCP does the load 
balancing between the different IP addresses of the physical interfaces. 
An advantage of this setup is that a link failure does not necessarily 
result in a reorganisation of the storage blocks.

On smartphones, we've performed lots of successful test with Android 
smartphones using the Multipath TCP implementation in the Linux kernel. 
This requires the utilisation of a proxy to reach servers running 
Multipath TCP, but this setup works with all the Android applications 
that we have tested. It enables Android smartphones to get higher 
capacity by bundling cellular and WiFi and more importantly allows to 
seamlessly switch form cellular to WiFi. This is important in areas 
where the network operators have deployed large WiFi networks, e.g. by 
providing a community WiFi service on their DSL routers.

Another growing use case is the utilisation of Multipath TCP in 
middleboxes to bond different access links (ADSL+cable, ADSL+cellular).
In this case, a proxy in the CPE converts TCP into Multipath TCP to 
enable the efficient utilisation of the bonded links and another proxy 
inside the network converts Multipath TCP back to regular TCP to reach 
the normal server. There is a growing interest for this solution to 
support the hybrid access network scenario withint the Broadband Forum. 
Several implementations for this solution are being developed, but they 
are not all public

Several companies are also working on bonding with solutions like 
OpenVPN on top of Multipath TCP.

Feel free to contact me offline if you'd like additional details

Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


From nobody Tue May 26 05:42:19 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A31D1B2B2B for ; Tue, 26 May 2015 05:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skHtTzSdqTQO for ; Tue, 26 May 2015 05:42:15 -0700 (PDT)
Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58BC1B2B19 for ; Tue, 26 May 2015 05:42:13 -0700 (PDT)
Received: from nordmarka.simula.nornet ([77.88.71.157]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id t4QCg0bp028423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 May 2015 14:42:01 +0200
From: Thomas Dreibholz 
To: multipathtcp@ietf.org, Olivier.Bonaventure@uclouvain.be
Date: Tue, 26 May 2015 14:42 +0200
Message-ID: <3139857.6Qu1WdSWEE@nordmarka.simula.nornet>
User-Agent: KMail/4.13.3 (Linux/3.13.0-39-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <555AECAD.8050907@uclouvain.be>
References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> <1431857585427.77044@bt.com> <555AECAD.8050907@uclouvain.be>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2325623.1iM2uOeMUd"; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19
Archived-At: 
Subject: Re: [multipathtcp] IETF hackathon
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 12:42:17 -0000

--nextPart2325623.1iM2uOeMUd
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Hi,

Tirsdag 19. mai 2015 09.56.29 skrev Olivier Bonaventure:
> If there are some members of the list who would be interested in work=
ing=20
> with us on the Multipath TCP implementation in the Linux kernel or=20=

> related tools like mptcptrace or tracebox, we could organise somethin=
g=20
> in Prague.

This is a great idea!

I will be in Prague as well and can provide interested people access to=
 the NorNet Core infrastructure. I have ~100 nodes with a pre-installed=
 Linux MPTCP kernel, and I could further instantiate some full VMs with=
 Linux and FreeBSD 10.1 for running modified MPTCP kernel versions. The=
 NorNet Core systems are distributed at ca. 20 sites, most of them with=
 IPv4/IPv6 multi-homing and many of the sites also have multiple indepe=
ndent ISPs. A list of the sites is provided at https://www.nntb.no/pub/=
nornet-configuration/NorNetCore-Sites.html . I think this is can be an =
interesting and challenging setup for some real-world MPTCP tests.

More details on NorNet Core are provided on the project website at http=
s://www.nntb.no/ .

=2D-=20
Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Thomas Dreibholz

 Simula Research Laboratory
 Simula Innovation AS, Network Systems Group
 Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
 Mailing address:  P.O.Box 134, 1325 Lysaker, Norway
=2D----------------------------------------------------------------------=

 E-Mail:     dreibh@simula.no
 Homepage:   http://simula.no/people/dreibh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--nextPart2325623.1iM2uOeMUd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlVkahgACgkQ32BbsHYPLWXENQCfTxuL3qeFv191C+tpf71+HX7t
i0oAnjavhu0OQDULlA+vHQs7q5c6wl4C
=EAAE
-----END PGP SIGNATURE-----

--nextPart2325623.1iM2uOeMUd--


From nobody Tue May 26 08:03:33 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8D1A8938 for ; Tue, 26 May 2015 08:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 bH5RUL3TMqDB for ; Tue, 26 May 2015 08:03:29 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 0EACA1A00DB for ; Tue, 26 May 2015 08:03:29 -0700 (PDT)
Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 758602D80DB; Tue, 26 May 2015 10:00:29 -0500 (CDT)
Received: from NDJSCHT114.ndc.nasa.gov (ndjscht114-pub.ndc.nasa.gov [198.117.1.214]) by ndjsppt104.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id t4QF3Rxj025865;  Tue, 26 May 2015 10:03:27 -0500
Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.61]) by NDJSCHT114.ndc.nasa.gov ([198.117.1.214]) with mapi id 14.03.0224.002; Tue, 26 May 2015 10:03:27 -0500
From: "Ivancic, William D. (GRC-LCA0)" 
To: "Olivier.Bonaventure@uclouvain.be" , "Appanasamy, Palanivelan" , "multipathtcp@ietf.org" 
Thread-Topic: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
Thread-Index: AQHQlyBnNJDQUosVZ0qhXgCbpw23qp2ObMgA
Date: Tue, 26 May 2015 15:03:26 +0000
Message-ID: 
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com> <556376D5.9050409@uclouvain.be>
In-Reply-To: <556376D5.9050409@uclouvain.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [139.88.111.195]
Content-Type: multipart/mixed; boundary="_004_D18A00472E32Dwilliamdivancicnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-05-26_02:, , signatures=0
Archived-At: 
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 15:03:31 -0000

--_004_D18A00472E32Dwilliamdivancicnasagov_
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8C18B061E4181047A833831290AF5B7C@mail.nasa.gov>
Content-Transfer-Encoding: quoted-printable

I have recently been funded to look at some NASA specific problems with
channel bonding Iridium phones - work should begin in July.  I will not
make the Prague IETF, but hope to attend a few others.  Here is how we are
trying to use MPTCP.  If MPTCP works well we "may" consider looking at
developing some type of MPUDP, but that is To Be Determined.  There may be
better / simpler solutions.

 - Will Ivancic


The fundamental problem of
multipath aggregation is the difficulty of fulfilling a range of
conflicting
criteria. For example, it is difficult to schedule IP packets over
heterogeneous paths without causing reordering and performance penalties
at the
transport layer. It is also hard to implement a generic multipath solution
without modifying standardized protocols or changing third-party network
equipment.
=20

A robust multipath aggregation
solution should be able to cope with any kind of path heterogeneity,
throughput
fluctuations, or jitter. Solutions should also be able to deal with
persistent
reordering of data packets. Finally, a complete multipath aggregation
solution
should support and be compatible with all existing transport protocols and
applications.
=20

The current solution (use on NASA's Atmospherice Reseach aircraft) to the
channel multiplexing problem (bonding 4 Iridium modes to increase
bandwidht)  is to use the PPP
Multilink Protocol (PPP-MP). This has been serviceable, but has numerous
flaws that result in less-than optimal operations, costing precious time =
=AD
particularly considering the limited time of an aeronautical science
research
flight and the associated costs.  Thus, a
robust, reliable solution is highly desirable.
=20

In order to baseline current
system operations and obtain data necessary to model the existing
implementation (and our proposed solutions), we propose to measure the
current
operations of the iridium channels and modems and model this behavior.
The models will be needed to ensure that we
have a full understanding of the current failure mechanisms and validate
our
hypothesis the PPP-MP is susceptible to high loss and unreliable links.
=20

Next, we propose to study the
use of TCP Extensions for Multipath Operation with Multiple Addresses =AD
also
know as multipath-TCP (MPTCP) =AD to perform the channel bonding.  Multipat=
h
TCP (MPTCP) is a set of extensions
to regular TCP to provide a Multipath TCP service, which enables a
transport
connection to operate across multiple paths simultaneously.


Unlike PPP-MP, MPTCP does not
fragment packets across flows and treats each subflow independently. Also,
the
data sequence mapping specifies a mapping from subflow sequence space to
data
sequence space. A mapping is fixed, in that the subflow sequence number is
bound to the data sequence number after the mapping has been processed.
MPTCP
allows the same data sequence number to mapped to by different subflows for
retransmission purposes.  Thus, if one
channel (modem) fails, the failed subflow can be retransmitted over another
path (channel). We believe such operation will result in a robust
communication
system as when on modem looses lock or rests, it should not affect the
other
subflows and MPTCP should automatically adapt.
=20

This protocol specification does
not mandate any mechanisms for handling retransmissions. Rather, this will
be
dependent upon local policy. Aggressive connection-level retransmissions
policies could be implemented where every packet lost at subflow level is
retransmitted on a different subflow (hence, wasting bandwidth but
possibly reducing
application-to-application delays), or conservative retransmission policies
where connection-level retransmits are only used after a few subflow-level
retransmission timeouts occur. This is an area that we will experiment
with.  Having good channel characteristics is also critical for
understanding the trade space(hence the need to first characterize the
Iridium modem performance). Also, Multiple retransmissions are triggers
that  can be used to indicate that a subflow is performing badly and could
lead to a host resetting the subflow. Additional research is
required to understand the heuristics of how and when to reset
underperforming
subflows. For example, a highly asymmetric path may be misdiagnosed as
underperforming, unnecessarily triggering a subflow reset.
=20
Once we fully understand MPTCP
applicability to channel bonding, we will utilize that knowledge to
address UPD
communications.=20

Aircraft systems utilizing satellite links often utilize UDP packets to
avoid TCP=B9s issues with
latency.  Since UPD does not contain
state or explicit feedback, developing a multipath UDP implementation has
some
unique challenges relative to MPTCP.  UDP
is a single packet protocol with no state. There's no relationship between
two
UDP packets - regardless of same/different port or addresses. However, at
the
application level, two UDP packets that take different paths could produce
injury to the application. Thus, reordering and losses will need to be
studied
and addressed. We will also consider the use of the multipath Real-Time
Protocol (MPRTP) as RTP has state and can adopt many of the concepts of
MPTCP.   Lessons learned from our study of MPTCP and
MPRTP will be applied to a new multipath UPD protocol (whereby the subflows
would maintain some minimal state and receive some minimal feedback in
relation
to each subflow path). Finally, an alternative to Multipath UDP (MPUDP)
may be capable
of applying channel coding prior to splitting a UDP flow over multiple
paths =AD
analogous to a UDP performance enhancing proxy.
It will also be evaluated as well.
=20

Since UDP was originally
designed to be an unreliable transport and we are basically attempting to
make it
reliable (at least at least over the channel-bonded link), we will need to
evaluate our final results to ensure that we have not created something
unwieldy.  Understanding whether we need
to develop a MPUDP implementation or perform a modification and update of
PPP-MP will all be part of the research effort.


>


--_004_D18A00472E32Dwilliamdivancicnasagov_
Content-Type: application/xml; name="default.xml"
Content-Description: default.xml
Content-Disposition: attachment; filename="default.xml"; size=3222;
	creation-date="Tue, 26 May 2015 15:03:26 GMT";
	modification-date="Tue, 26 May 2015 15:03:26 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF
94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr
vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d
CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL
LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr
/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz
hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn
IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ
ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j
U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv
dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b
1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt
td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE
IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY
DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH
1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO
FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb
wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs
bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR
Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc
vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC
QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f
//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+
/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u
RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv
Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+
AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E
pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9
DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV
Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX
hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe
jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC
s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb
GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT
S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ
kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE
9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz
VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6
Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA
sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3
6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr
HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb
dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT
B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1
LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl
6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA
GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC
dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs
jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9
oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D
AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U
eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y
ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo
ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA
AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf
tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu
eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA

--_004_D18A00472E32Dwilliamdivancicnasagov_
Content-Type: image/png; name="default.png"
Content-Description: default.png
Content-Disposition: attachment; filename="default.png"; size=57522;
	creation-date="Tue, 26 May 2015 15:03:26 GMT";
	modification-date="Tue, 26 May 2015 15:03:26 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAREAAACeCAYAAAAVBT43AAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF
Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8
AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa
GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP
wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY
Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0
HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj
ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo
Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY
BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE
hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB
DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS
Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c
AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n
fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e
k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW
ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O
okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/
wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83
Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAAQABJREFUeAHsveezJkl23pfXm762vZvpnh7XPXZnd9Zi
gbVY7pKQQJAMQRRDFBFBfpD0P+ij/gAyQgxKDJGARAgASSxA2A1gsX5nZnfH9Zg2M9Pe3e6+3ns9
v5P51Jv3nduzgPQVJ+J9qyp9VeV58pyTJ7NS+lv62yfwt0/gb5/A/48n0EHe/+Pf/tb2jjK21lLq
7N0RtLaxHte93T2pq7srba4tRxrOezq208r6Vurv6YwjCR3uQta3OyJdZ1dP6lW61KXyN1WPaE15
oaWV1TTY3xfxhHEdZa6u5PbQropWS76+vv4IXVW6OFc64jh3GMeOrq7U27kdcS6GsO3NTV+mPrWN
vJsbua6Njc3UrXv0sUlYnRAHbW5sxHFtM99PXJS/pfWONNiznXwkmPNl3ePm+mY6uHcgDfTtfOak
cd2cmwiDXC/nDnP4SH83py3q6Ut9uve+/sEIW11ZysetjgjnYlXn8dz0DPq6e9NqeQaRkP5Qnn+/
nuv2+nKkj36icNLX1ORt60fuI33qAh1d+itE/yEMcvh2eY5c02/cHzjf2sz9kfS+5titMjqV3v2H
eIh646j+RRx90Mf2vkjZlNXb359WFucjX11HnXdLbaQ+H0lMuRBtgTZKd6jzOc2DeMFt8DGXlP9d
juMedCS1eYo0/bp3E+1dW8/3SRzEPUJ+zk7fPCfFzcwvp3/xz/9p4EYk1l++TTpH6SA+GjR4+MHY
Ag8ABNqEaUrn4JwOQL44RoqSRueAB9TX3Z1fDC/TAMKxUNyk4nhxphpAODdoRLzqh+ENGoRx7fb3
pfUMIOQDhAq5jEirsBpASLK03EoLk/b1D0TO3Zg5Iqq/Lt2jAQSAqAkAgXys49rPDUaE7wYUhDmc
dtUAMtjd0boWcNQESKxttsYLrqEAj3LOc4swA8j6alz7ueaLnf8ACIxu5jeABLAAMIWZ6mNX7862
xftVnZRBP+K3WmGx+wc1u9NzDtDU1zAsnR4Gpt9SJ0cIJoEJINI439rKSrnO+cxMhHNuZoqM+oMB
g/kdUI6E519+hrQFgIFcF/lIs4PKYFqncxuibr3juj7yZ7DM/EhaX5PO15z73il7RQNWvu8MfL09
OT9H3yPt9HsircnnvKd22hliIFEqAwYv0w9gfWsr8duVCqi0V4KU4gcS+QwgLkTXvnEHBcjoIgCI
cgEopIz6BmhrqdOjoQEAoFja0Khb0nPkt7GaOxD1GEw4R+qw5NFVjagGENJAZlanWdVLgZkdnlOl
kCgAi90kC6cxyCCFbCxPOziOgNFuZOAwyFCvw0hPu1ZTTwJIdhBgIjBAEkGCaAiAMEg4sA14Urmu
nxfvInWKQXlWeg8wPsxsycFFpa0CQCUAcCEN4MBoZ7Bwvrp9dGT3JeJ39CGVRxv4URZxjt9ck2Sn
H++GI2Dl/kszaqaCeWowgektNcCUNeOSlzoII01XX2ZAwg0KAAZxZk7qpXz37wwwShB51qNdhMHc
OSzfJ88mX5f8ZfCu76MGJ8K5dntzvS1JjbL8fDinjdTJ0Wlph/OTBvI1R34Gkhzb+g8QQTwNRoQp
y8+SCEl52XSW7a3N+DmuGeFhaP148XVjOQfhohGSMGopo2mQUJgbWpUqEHl1zQjAzYXEQ9m7EJ2a
+psfbRS5sw8OtCSaSKt4mKwGDM4BF8JhRgMJR65XVyqGq9rgdAS1MzJhy6trASA+7gYmlki6eiRJ
DIyTLcgA4ev6aLAyyNDGVliW6mgbABoEQBhApCpZ8kAa8XmTroBMU18buBiQiW9XXQIYVG+QgMPx
HT0Dib4VkoneI+eWVugvOX0+Ugbp+dGPnI6jz3OG0h/dVx1YjqQFOAAXfvQjk899hIlM9FHCAY88
qmeJgXP3VdJAHDc3BNQaAGHe+PW2+psZmv5MnzeDEm6qR3/CqMNMDXi6jVFnJamQlnJID0hCwZ9x
lsGBUwNZCQ7QbudN4gjjR92U6TQGWOf3M/B1fYy7qhvhSGwHQX7ZemlIJ/4BJNgT6AxrFovVkbh5
HgKIzwtoCHBQHouOEc7D0Yug/gAMBbqxvplG2iBO9RgQom6F1QxtCYGyA0zECAYVwiCncT6kF84t
dXBOGpjTDFrn8zlp+oqYTBhUpwdAII4+j4DyhyTSubEU9hCHkw51qC7HcbTPUofb1p7O90SeHUCi
69XSniQppbdLdhAwRwDTKaHHPwMLEsFu1Eh6NWCUtJFHABJAoE5elxGDlApEcgipgz4FCLTRysJs
pAEISMePfsDRTEUW+hc/i931yG2x3GmQZimDPuZ+TnnOkwFD8WX0d5Ng/P7eVgeGYemb7p+k6025
/9KHa3KadgCgTOwQBq9esU8AkNpHWrfFZZkHyAdxzXPgmrSAJWHwmuts5ZVaqHui3dyrnxXxfpaE
84t2OqOOlEsbqSO3uSWltIMT2eIp8cAbqkCjDq/PSQvIGGhC9SkjAy/KNx9lVg94S50o8qq+puEC
EoywUb6O3CBxHCOstMdABaOYWdqPlG2dPo5iEl9HxcTX96prwICfy+Ic4mim5dpSicNIz7mvSQPt
JnXkmNa/VZlWSD4jb52/lkqoz+DRno/r+r7a1ZkAlKKWJEkpNqp2bhexuUMiv36mAJOS3lIFcTuk
O7WHdAFOqC1Sb/iZ+eNaeRrmrUFD57xb9ynbUAA16gs1hfL1W1qaD0nE5fpIe+jsLof+QhzMxLn7
YLekZ65hNA9slmwI9+hPeeTJxsaslqysZekAZnIe0rUDDmHiVtXTEm3q84jXn8GDa+qhfDM/6S3B
AIQGQ4eTh/bCxJTjsgjjB1EW8c5LGO3mGfGsTH42PA/i3AZLNqSDBy05cf8m1+trjlV0CeZlw7j6
0QHciYziTeYCGh5R/DJpmG8qKkQCUTkQjQ/wELA4jHDsJlCvjn4ApG3qVF0GLZibzoxBlKM7tkEA
mwDAwTGkFh0hx3s0jcDyZ0Dg0mBhpq3jAAwYuQ5rlwbqch90jgRSk20itcRCuagtlpDq9Ludt0tc
fi4wZjuokB/BZCtPJkVxASioMG1qTG3XQLrgZ8kirhFpBB4NkxU7CKpEvD8PSjq6LzEqwvBQhOn9
kp9zHznn57oIp0yO/Ewuh/4Co7jvEU9YnZY4MwH9lHin4+i8mRkzkOT4bKzknP7bv2eYU8khRQIp
fdxlE9cp9cZ9nHCfeySnbsJhUH5O43SAR83IhGeQzIBBXI5vgUbdftJTh3+Oo22c19eEQTwrgIQ4
8udffmacP4hab6MthTslL25XKkBDXP1CaAAN5waDBBjNuRhDbzpQ23EcG7DgXOJVkNICTEGlIyKN
oMZYKnEbSVNLE1wDBp76dTxHmIu0/Lr78swL4QaDdpBoj+MaIh0/gAWJgV+7VJJTtv6RQPhtdedp
1lZMPrMUYoMtoQBWO7keHx3PPe0IQ5oAFCxV6NHb7hB5FA6QWCJxmMvj+CAVJzN/Gd0EHGGwrdQZ
8lqE5j1GegJF7UBgUEHyQAox4/uYc2U1hr4FM3E0I3Bej6KkJ46fQcb9Eoat+xvifJ3OeWEal/kh
BhJoQF3du6t9Eak07vcc+VF3SBtlBpJ6AY96xHeeGlTcFp4HIEQawtwujpTNAEw+yuUa4pyfn5fP
HecjEh/Ppf2Z8/zI42eR4OE2iqr8UFErGoNXlK6HtZrnyd0hfBwcHI5Rgms3lHJoLNSAgSURwAQr
c7mOh6XzSOfRSvl4EGvSY5FKTCFRqGxLIw5HhDegwGwGEqSQAIXSdqcnjSWRkCbKbE3NeD43QDjv
bkenRWLgF3UqYW81Utb5bEz1sY6rz204JYw62gHK9biN3DfPgp/jAjzapAqkD+wh/EzYQ3r0bvg9
kKpyUF8AjOhsReoAmGrCttH0I0kZjXqynPsSHZMf/QXg4Fd33vBBURhkECAtPzpzbYsiH/3PR0uy
bk9dLulQI0xcMwBSh9PVfRjJxnaDpo97kFMhYVxVH4bM/JzTRjN4DJoKQ7KAwaGttZVIb6nEaWvg
cH2kBxBoC7zlNMRDPnLucpyOMM65J5+7TsL9rDgPqU/9x2kNQq7XzzepP7ZTay4xGFmdATVF580o
HhY4RiRlVbjMMFEGDxey+kJDurZb8jHXEDcWyKkZFyhmaNbzvDzhnbLYt+zakST+yOcbIiB0/tI2
p6olEcIMJKTN7Wx1GOfxEcaDyGNm5NpMSPzqynwwcM3UpGkn8iA9/HWoBpDFDVD9wy+Fctwmji4f
MKnByukCHMujB3SWUh4tdqgxRSJZ3RAAdPSHWoKRFdtgMLyebV+86zJzUwEH9VgiQaqJviCJwQOK
GZ10ca40ljyyNIn6KcCgnAIOEV8NHvGuy/uNGRqlh6hL8lKc+68GAsoFVMygZiSYJds3cj90XpjO
Ax9hZsJoH3WVEdzpaT9x7ov0dwa+/j3qPx4glbgGkYE9LVBlIiH6f3Hson1mUN8HvEI7OBLXHr6m
LuL6RwZb90obydPULfcLl02cnwn34PvcKOo98R7oiQMsgvTe4UkPkDkw1+Pz9mOACBLI5gbGRbVW
L5bRPSzPvFQR06jBmHoAfaord4xWwQaM9sK5DtDQw84PMneG5qYVb2OrUdFl+KZ97aOBI0BFgb7m
pm0/ICwYKzKthQqDBEIaGNJg46PtIGbczKyZuQ0gxEGUQTzETIqlDqdzeCT4iD/sInv09OcqnMMm
YpWm/SUGo/B+2qgGr3qEJn8DJsG+yggw6J2ubBUAKFPBq2pDX08eUTXONzUAKoAHto9g5jj6WkbV
EofdJAysAg/6Rt+WpEiF4R3b2aP6xHSMZJrsb0b8YH6AWqBiu0euOAMO6UljgGsapZMI15E0/GA6
wjg3mRGRCgiv+6gZpu5jpAGsiIMRYUDH81w7VAfARHhdlvuywYv6Oa/7PWFm9kYiEcM7LPIU5ka1
6dzKwEf9rTTZr8b35TZkdSzfX7S3M+fFJtMtiae9vQYZAwz3FH0od++Gt2mTedbPwXUSV1OAiF3Y
6wgbTHmJlgIMIH6Y8bA7S+3u4IXZLPaET0lpsR84Ih4IbaIDxINXB6yJDrmyjqiuDq7OD5hhE0Gt
MXiQHqmhq8hUBgbCzYhOCxCQljQGDoZig4JH+poZHUZZMDmgYcCQBSLOnYY6IdIYYOzBmmM09WpP
1mIX6eqR08/u7ihNu5yXo8HMYW5rbUfJUlYGBaerjxkUskrTFwOFnkcBs76+rEbuJlc1oKHCKKMm
SzF1GP4oMRiVQDN52E+KMTYAR/EGBpL2ae6TvByTAYnZHxFlOC1qWe2Ba+kjEpY/AwiMQD6eF4wY
fViMS7jbRRauGflrhuHZAqLu6sGIRQoxozkvxxgQi5qTw5VZVEshLaDKcWZuG1QNSoT73FJ/FFb+
6jDa3ICD6t9Qg1cFonb4bNWZwYkiuLcaVCkDU8JWVS/pkIT6izcz1zVl1isSR0RwvqUeZVEzrtUh
dc2I4Ya6QXrquTwxaB8AUsAE57FofFVbAEXIz61AGocIGchdgpF/ggUoS6MnktG2VCADCMkC2BSH
/QMCFGqQIAzJhHS2gxAGgBhcuI6HWDxEawaFETfE3QECeiHt06/khWoAyiEf/l9ZXg5jaq3KkCrP
0hQQ1rWlEOLagcn1ENdOcZ+VTmgg5biDUEVWCzzo/OfROoygqV8ff1564gMgdEQKWRU3rmkCEOat
GZU4mN9piYdJGTTiXPkivQw2qDbt+YkDBOrpJYNDexvJKz/rpgzeN/lhNo+wpIn8hUk8SDZAoldk
U3gDMpIWOF9RF3V61201wdI10kW3WhFSRJEUzOwcbbSkDTayUnZTvwvWsQ4jDXWsdevli1cMaA0v
aaBmuQlEWqsylBGgRVsy++S2KR3hjbQUOfMfPEo+ymknRYkMGOU8/D8AjwpcDCAkyY1tmyaC4cuN
EO+1Mu3WXICEHw/ODap1SMqHrOYgfXh9C0dLFTlV6x9Gsg0gj8QZMEhfgwY5AAv/eHGmOl3NgDVz
k9ZTsUgkljQ4t4TiMB/7B9S2snamfXoXt3cT5X4UWLh8pydt/rWBhRLU7Xf65ojNopIkshTRxDYn
9h2x0dUSDKDS2EhKaq7rMGwvqDQARQ0gZqzIhjRSjLJ0Uuv9xMHYMB1HE+dOQxxA5GsApTYYOw99
i87PaAuz05aaEckPgMHMdV3BZKUQ+il9GiKv8/ucvMRzXd+fJQiYEqJ+2k159Y820r64p8IflEUa
wiDXWbfLYeY714etBqJNbjd1m6KtUndot8snjvsnzET9EPVYWmnqdCLiOQ/GNJAU8LDdg2Ots8aN
FS/AusBoLJJIIa6jEYBLFU404by46ACqN4AF9abcPEeMO6TDwGsjL1JFSCAq40FgAvPwMyBwbgmF
uh3OiMS5r83ADiO+JjMsYagrBiEApp25iedngpGQRvhBAEk7mBBOHpflI+FQfW2gIYyf74F0nLvt
BtN271WmdEO6IIOo8WYNSWUnQHj616DjI+GARgMokgodFyuF7Xqfq2j+t9ZLBw+v2VZ/gbnd5zg3
8PicDh72E/WBAJMYXPLK8bgHpB5AReGQAQEGjn5IYHGMgRH50X9RBwCw6JNl9siMRR8209JHuY5+
rqIcHsUGs+d6DBiU7TQZHJAscp8AaGqwqSUX56Fc+IMfdg8GXX4wuc9JI+6Og8ugfeYnjg6PRPrj
PgmHx6iLdho4MtDmNjq9j3W7HOZjkyOmSlFZ1AhLJhZhqIgfFMdK4vBDZVoWRIwGunQd/QJRbyAe
SIBHXOlPoOWX45ujLCQRp0MagQAO/7g2c6DKABZWbYiDySEzGPFmKsLbmbJm4Aw63THKGwyc3gzs
srkGgAxChEOWQgCQ1dakVY78a/77HtqTuy2EO41BkfY4nns2+VlxXFiRzlu1yZJIgECRUgjj2lII
5QAYBh+kFCZziHc+SxX2iHXdHM3ctmFw5GeVhjT5WbXaHGECAQOCB44AHA0uBhrSQaTzgOc4AwLx
rpubh3Hom55lJL5/aFR9Mfd18sGAzt8wn9LRX814ue9mwIA3SM+R9AYNykZKMoByDdjUkhPlEOZ2
kQZeZDaGIwxuaaA+r22LdRtzHboHAEPk++AcQIDXXBf5TDX/mueJ415Qk2hnO4XChK2hA6tRZ5kn
FmNHAWWgIGNduAsxcPjaEsdasbkhTQAs/Jj5WeK8opj1UZq6bM6bmxKoueOQzUDAEaexJTEC55np
s8EUoHA68tQGV6clvCaYjjIMOD6aGZ3W1zAqTGugMNCQjjQACkS4rCmy+kukr3wpLJGQhgV4c3dn
JKWMp96hPQSp/RWHR8jOv2YWqiwQNJCQyvfCOeqdwYPr1WV5yqodVvtCmpDAFYBRZmJiBodz3YPB
hbymABWmhkPS0LGcAyQ1IDg9x2AW+kIhMzPhq5stdZJogwDnBg8AgfMRvXPIzIfNBSLeoGGVISKq
vzySZmMyi4W2ipqAJMLIDlGHYLLKlU8JD5uN4taKMZYYpAn6qxkLO7Ad+3K6zMC1KqHFUlEoTB3h
zXVOG5Hlj3rxAjAzt/NhY/sQuFPfRxFl8AxWceVXmRlIWjNO5M3A9+FyCMf2g4+cJa26roAVAKS/
VyjKxkNFrSEjjW5vuDMH47eBggGDNOFYpiNIbynEeX1sVJM2puGG48EJzOq1L7UkAbhw7R8AYarT
EV7H1eK+0+92NCNbwqilDRiVHyBhAHGY8zmcsmsA4bqvzCRxjk1kcHiM0waU4kJ/lOXyCDNY7HZP
xDu91RnCatosQAaw7AAX7BkAH1PAqDS6xgnNVEsgEWZVRceCl04aBtXhXgyVg/EjogYNrmuphBkY
AwBxEMxTk69JF8Aj8OhamUuDW4t1sjhnxHT6OrIeicN+UiQO+qfr99FM6/yEIxFAwVDqe66D6wiX
mgaD8atVCNrDj/rdBjNijO5qh1WbDHQt0EDioHyHO5+vo2L9eRBuQKVEIIVYRSSoVX8LKGtpxPft
MPJQP/cK4Ll+wmuKrsIS/80NPaiB/KConAIDZRFhhFzzCwvNVFFdQICM1I8B7aRV7ecTU7iAR6z2
1Zw4IOWVutkvRdCG/UWg1defmShASIXzkOaWik2iT+sUijpDvTBQO0jgvq6J34hrB4y6rWZCGB6G
4wg5vE7rOMI4ZzrX5wBKSBmls3NeM3sk1J8llVqlAUCs3tjZbGl+Ju3dK0mkKoe8BiK3FQCkrZaU
qAfAwDhMmO+L8ABLdeyNjrwi2WH1vbarNI1hFDBROwEPJA9+PqecmkKVKQGedVndxGlRyw66JfXo
uS1hXBWAGUxIzjOpw+iozh/x5dmasQEPgANBYXRqIb3++k+j1j0nDqTHj59Jc0NSb+REh8rgPJGg
qgtkhJEsrdDHaybjGqmE2RyTpQgzYOSp4knXMJceKH4xRNOHAQnHuU6Xy9Fgg18IzNopAE9lvx6D
E/VRDrM7Zm7PskRZekem9l3YMEe0E8+GMk2uh2uf5zqtkiltSEN5VbDz1cfgIqQGGLuzyP6N56nC
AAHiPVVEZoCjJuI3YSxJi6HiVJHMqER8JbXEgjuVHf4pSov9g4b7JoqUmksBZEp9lj6q4uPUszeA
C6rZyuJCMFvNMAYepm0J5+cRG1Bon4FxHTVjO4yjAcLnZniufc5xdWUxmAWVBgqpZBfHEGZwAAHa
ArmMuNCfQcqA4nDy1ODCtQnJo3UlCWhbUpnUqw9RTJVntSbAAmOHnvs6aimSqcA+1BhnbNQZB+Tj
DlsIwoQqXyotAAQMIgE8mpmJ0RzX+eIDsoh6Kgcpe7u6dPIu3v4gLZ67FkEnDh1KR595KE3MrKRr
V6/G74kzp9ORo4+mza4RPbtWXWSwJGggICzAARSt0tKvVzZ39u06DxIDoACzAwAAViust7F5GHjC
BlKAizotcUT9Uj9ctvs9ZcIHIWlo+pV4zhuwUZzLMDhhWN2SZ3UG4dbaGdqwupkHYsqnXIQD1DfK
pGzCIICzBhekM9JBTrul9lAmQNZOTR9rQELMlbPrQQscQsVRLkSlOBcY1HpgFIhOpgbuRjB1I3ns
lkBh7PngOp2Em4iXuqIXiySC1JKygbWWRgwO5ANsVqUe2GZgqSSP0lmKcfmEQTCdpYyaQX1upvQ1
RzM4QOIRlbIsPRhg6jh35NoeQh4T4S7XYRxdP+duA+dQfe37yTE7/20DWSoAUttKUGu4Rn1BpQk1
xgBCMfHcdVRYeLYCMFZnHgAmrt2gwTVSBPDVpT067m/lxZU8n2xTyZ29W11opFOMLT+lbinhHUvL
6frGTLr/1ntpXL35keOPRtEXtmfS9kp/Gh8fSwePn0wbV95Pt995N229dyOdfPYTaX3vkPrrSANa
7aAShezyB2PCKGbu9iRm8i0kNZG9cc3Y3G+/+BLJIUgMHlQEm2D8Iq2Qpr+rgJLODRQBKAVAcuad
/+a9YObiUh9gIGnBkgrXnFsiA2CQrix1MXgSZ/CqayDMAEK4nwXtdRvr9Jw3IGK0CuCoUnEN2QqM
ihKAowfksCr5ztMO3ZnIaowNqYQhjWQ2zvG10dU3WwOTZ2jIC9VAkkM06kmfMqgYQIhD6qivzXBm
UI611AJz1kRcqDCVhyrxMD2G02CGrj27gkBdzoPObRNxmRzdNgOFj8T5vL3dvi/a63PSGygaMCnA
QZwBZTC17CBIIAzSNqyGkVXdIHYERDKBABeDSQ4pgKDMgEuhRkUCnQhX50YSgbG71jfSWJd6gbrJ
4u0iqU3PpKsTE8KRBTHpUEonx9KJRx5P2+N96cLkRAwofUNjad/xU2nvgNRSGQq7Xvh4On74SLry
9vn0l9/5T+njL3w1DT71lJsQRwMJx7i5QEuAv8wCKBUMA4jUQMK5CeYLx7WiiiFpRHlK4HMDxQ6j
kgvgoZa0xFsVrZnTdVtKMBMT3i4FICVANgwDDDEbI5ADCCiDNLFEq6Sj/dhakDbgM9IQFvYTHbm2
JFLXCS+G5Bg17vxrQKRpNMZVjdJh66hc08kG0PQJVNoNOMSFpAIyIrG05WNf1h7N/FgtiRstYnKI
y+6YKifPxrAor5qekqEPiaZWWwwKlGmP1Mw42UcERhscyvs+2MW9BgraDLUzHGEwJ/khHzkPSaPY
RnzNMev2H5bELH2QxmSjKnaRPd2bzdqZOfHQiHgGoh7xR5DBxEffg4GEe26/hxpAcik7/8f34Lkq
MEAHp8Np1sP+IKQMGwjzFJW+3Ughpag6znmwSWyjtgEuBUgam4muB9W3xvo20+Jd2UOmr0RJ99Zn
0tRmftYAwZ0hSZsDY+oHoxE/PQ1oraXxLoX39KeDR06mgT1j8czn+eIArk7qH4P7DqWTz+jy+xPp
tWvn03PHjsaUbe7XuXwKBDRgfEbWYn7YARqRRmDSMEzBEJg53PApQwOHwcPSR4AGUkYpN456jxCS
Skgx2EtEVkWyCiFjsVQbSwcGinYpgfKwi0AeXF0H5Rh8AAbaDrB4Spg8lOdrg455nvgGUJTOg7jz
caT8bt1HY6sksFB01Vp8iSX4aohq1INSKlSV4gNCpe32EMqJsNLhagDpA/UHyrSlUDtGrwIYgAVr
YsKlXXaTrIoURow0AhK1A1WnV9ekt/RhAMngkHX8LIHY6JpHS6czk9UMV4dxD8SZMbk21YBCmFWV
3VQP59ntGNKKIgCW3VSaPZv3U+eagFM6vakGsDqMNrldHHcDDfLyw+hqCcRlNNIBYrmAJDN6Np7G
YJkFyMagyqDdGFcRMiSFhJ+IJIqYyZHjGeR7BEAwqqLC2CYy3LmZOiVJ3H37vXRRYLJvYCR1jnal
JVBV98AU4uLCvJgpq6xLGj737R1NJ08qndYZ7R+WUbRzSJ1YwKH6YRSe5VCHbE5axbj0ykvp7Plz
aevU4TQ8JhCavRUgEswIaMDAshFY9QhG5sbENHOqFzsMz8ojP4xpIDGDU0ZjB1F/7tR99hewDIaG
zennojgWaYdrQIc6SccP8kI76jQQGEQiQfmDgaH2uKY8GWYdB4+GtFQAzPdTigpw8RIDng3p41mq
Tb4mLTydyy/SjFiT+N2MtQEidWbAoyajXhNWqTEWicJ3v0mgE4nTnmkBSFaF/gAV6QGD8EuRZKFu
F4vp8E8JgJHNAzDhhcbDUKNtfDUgUI3BACAwsBD+IKITwPzD1RLt3dLCkFDNvPV5O3D4GuMpZMkD
ZqrPI3KXP6SPmrbWlsRI2otDtD22P459/XtCorI0RSBtMpDwDCADiWeO7M5vAMFHpG+grAApOn1k
1HmGgKy+4AkRUgqRKtrggeQBwJCWhZgAjwHEaTgGSRLp2igAIiYbWVhJg2LwcxOTafCZU2n/pvxX
pHrOSHVJqDSybQzsyW07fPhUGldPxXYCARzQPN/JERDlLQQkPUki7F7aTNO3bqf+tZkAps7HHksP
feyxNL7vobSExEzfw0qPsV19gGsfKZM4mBffFOJg7l5JNXUcN20JBGAISUbPKKiDOjB8MkDySZQ8
+BIX9eRbyGn5V1larB9Hq1EYLN3XAYJgXoXVRLilEMJJA19SH0fzr6URyuPdEQ5xjfRhVYYnbWmE
MJ6B2+CyKBdVKAQECpHYRvlWjQgyBdeE1Tb3RUoPKYSNUyCrLlwH2hWJg8owmAIEzK4EwnNzSA6y
d6wpblUye0gjUVL+Cxd2qy/o1UXKoGNCoc6o8aW7B7i020PMOLZ/5JyZkZh9aScYDvWgljbMdHVa
AwbpOTezRhrd90dJIYCGwcMAUttMCAsJpGof0sdi1/402rsZo25/l6znONExV74xm6YX1Ak0+22Q
oh2ACuS2+Z4Ii/uU4ZM4wv2cwidE9dfEIBlSRxXYgIekk3b1hmSrHWKwCoAswRDXk3mP0yCYeF2L
/fbJO3b5yrn0xs176YUXPpkuzN8J8Nh76Gg68fjhNACwqR+Eq7xywlxL27r/IpR2bMuJTdfx/NSx
PRLeuXsjG1zn7qW5vYfSMYFH3/ixNDAyrsFqKaZ7aQgAYIYNABBYmBwHgECWIpA4JJMEMOSIljrE
dX+/7IHCJtKv6BWFhFJG/kivPxjOEgdhTkPYssQuQJ7BDaaEl0LqMQ+6kOpIPgy6LUlKFaOOFqIM
z2paivBUMHGQQYZzSyOWQggLHFC7arK0U4NJHc95gIgDDRhcsx+BCRWFQkDdkEwEEIBsXZ1VHpfR
K6br7dcL1IsXfunFll7hQjkWMAlbSexChi+JXp5GBm68sZ0oKb4gtU2E7JZOzDAwTTs41EzGiyMN
Lw+GqwnGAyQsXTjOzMoUsEd5x/loxkZXhlyGQcegUvuIkA4AqamvKxv5Bkfkfi2/m/GhhaS+Iz8L
LRXQ1COSChNVSzP302CRVAY61UF6i5+NCqO9Ju59VR19VXm5X/YXsWQSaQpYNKpJmV7OUgZOZ3oV
lcTRB9ID/IViOtjSh8KRTJi8scG1R+k7ZqfT/SmByZmH08u3r0fOU2c+HtIGF6g7PB/UlJHBbGtY
FfB42pcRlWb1aerGADJ760Ka0GzMgQUNGAKQ4eeeSt3jR6Kc5QIgBgYDiK9h5kZ6UP0hgaCmVCDQ
kjhaz5K2GoSQPHxOeRo9YiQP/hC4BAmhV2ShHpH9CYLB2T2eIyM/xNEM7nN7ntpoSjrOaR8gAFnN
4EgcZRJntQspyBTAofiQptSmKIOjpDPuoZZC2m0hBiVmkaC6XJfPseEkVI5UfELqBEgmAIjBIxAJ
cUkjDc4t4dquDO2zOlEGHUxL+AMMFNBM9RYJxPVk+4gaKsCxdIF4NagOtBXz9vq+jKZu20HD4OFy
2o+Oh7Es3pOmBpCa6cz8pNkNUAg3UQZ5na4++txp62MNJCPCnFqlWZWYbyAhT1dnfxoe6kkjPQck
xfCBqwxSMz0YjLVSSAbG9XUknJm0XDayIR9kYNvU6uaujpZUkmNTrJ8Z7FYZwfXbYUStVPiQOPL3
mTQqC0hisTEGU4Bf768GEKs1fXrfg3omS2Gx7EvYQdL2Yppcnktd830Cxf6YVQFcao9ZJDgAAhvK
pqZmA0DKpkb4nvR1y64j71SMshdeeytN3tGzkMSx+sSZNC71p5t7wO+EKWMRxl0MwQZvwmCYkGh0
3KqkEeJ2EOIZD6KM3jvAovhdkD7Ap9hDuLZUwnlIKjKX9nbmgdPMyJF0BgMfbbewSkEZzkOYASWk
EQEH6Ql3PpdDHyfNDmbnfqK8PED5vmg/+SgDIEPCAZRcZmTSnyUfX+92DBAJhzLFrm5r5OrYyLYD
xPdQTRShzhEoi9FLgGKVhxux7WNNo17YQpQv7CplhDLSUrmneqM+FQPZYOptF7GXYD8hH+XjIxIq
Tk4e/5Y4LK77WCUJBofRARKolj5gfgOJj6SpwwEUxxkscjnZ/gGTAhbRcTW9C3H9IHIHb48HSKam
utK1N95IEzdvS8WQ/UBM9sgjJ9OJJ58KENnWDEafOuyqmJjj2PCeOD722KnUIaabm51M0ytdaV0S
yqQc7ebn5tLWwq202j0qY+1M6pcRkzFM/UUjfwYiJBJ4xWBguwbtI6wBlCIthrpSAAS39nl1BROq
D/HYKaBB2biWpINv6tjZsSd8PDonV9OeM4fSw4PbaabsgITKEwQ4CQQ2e1Ft6JL0paJ2FEe0Hnmp
vvPWq+n9+5fTw8+/mMYeeko2njz7xpYD8SPPlgCFa1E8c4UxawT5GBfVH4wNIVUgPfhzMyG1SK0J
ILEdhPYVxhRK5VJ0xIzhcgIAinRi4IgyUHGoA/sM55L2271Mc4Gt/7BlqC+ayV23+coAQg4AJAb7
VvY4sxRmQCSQc1iwBSTZI5ZrzBYuPwrQn4FpN1AJELEviGQbPXm9QABEUkGQpmy9q3WWQvSSCu2Y
zpWa0JRDfAEhp/UI5usaGCx9EEcZ+KJscicY/dyOkpG0SCS7AYcBw3EGBYMB4U7jdtRH0jlPSBPV
dC7p6JSMbhxtp6hHO9IAPsRZtWnCsloa+fFetev75sL9dPHVH6fb96f05nJn3tYszeXbE+nxiam0
/LGn0uH9o2lgcCgtLy2kvpHhABDKhfo7ltO2RIaDYz1pefRgembgWLo7syQvxsU0rRWKd6fn0vri
TJpfli4uaWWgU67joq0RZoG0vgU+KOBA+A6SPwGqSbiuS7rAf6SwjXpslkZGdb/disDAefvORMy4
PNS/P/WoPdDSvXvpgHSSCzfOh0QycOxA2tMzltYePb6jKi7o2IyUWdzPjI8EAoBcKQBy8JkX05Fj
x2QMFVDVJQAgAUZVYAmLaWcF+11FPSXZDgYrQOHRGFAw43EMUNII7jCKIE2AjVhHMgadJH5baksD
LACP7otyUQ3MuHASA2XwFWUVg6rrJ13jdVqAjjp3kCUnBVq9oWLKID+gU98veX0NUAByWVMo6aOc
3Fn9bAyOlGcwoRxTgAiSQaziLQ2dX5aruRgqSGCgGdiQLkIy0XVIGj66JB0px5IJDwYDKwNWnplp
JQywkYjs6V1ikEBMIbGoY7cDCPEAiIHEgPAgcAAUDCikdfpcTksaATgg0htIatUmIn/OH+ktidBZ
nd9hllxcDGoNto2zb7yabt+9E0wZ9gbdd4fWGbHa8r0P3tPm16vpi7/0Oak2uY3kt0TisjguL+cX
z3EYZOgbS6NytTh5JNtd5jX6I61sLU01wKJvvKfVYk/p6dEeJ2XLxkYKgSlF2C3W5TLv2Zf5ldwW
AGRq4v20fn8hbc1upv17pXYcOJAuy+lr+spWSCBnDu1L6dBYmrxwId1Pt9Jdyeb31i6nE2NisrFj
TZk2cgajRq26T63wHfvgRuqXJHZP9rWHXvx8OnzitHaJy6uT19fnpY4J6DoLgJBPUkjYZtS/Gr+V
Up4HAS5hEJjJgOBr4pzOzIZ0FF7NXXlHNtJYVANAAmwAkDYK5lNegwLRIYWgSugHGUA4tyri0R5Q
CFsGkSLqCpAC0BQH2Eb7JVJY1SFdU18FIL4/36/vjbp6e7Ia0+RTGaSP+kq9eOIaTKijpkAKDJbZ
aKmOqAVvwcRiKKZkFVBEm+zXvyL00usNW4gfW/ZiFQiIUa2GIMkgqXRqxgGyimL7SA0QAQzlJawG
YkWWBlhsUM2hH/4HHGqwaE9BvCUM4kLK0AsweNTpnW43I2oDDkV9cVkGCpdjAPE1R8CJjmgJxgBy
RWs/gippAACRvJW2NUzcvnNXsxnTcvHeqzVtQPKwnPlk45Gt5K9DQ7IjLKx2SVIZTAcjw5F0Jh0J
aYXLyalZCY1boQbhW4EBl1ki7C1b6h0hqUjqCAChjSLUlflLN0LywN7x8MefSZuHV9KN6dm0LZ+L
gcePp0FJJ2uyh71XRK4nf+nTad+EwGDqVhp96lS6fH0iPTJ0TA9GBUplwR6y3TLRhTqzefFCWrhx
JV3fP5QOP3IyHXj4qYbpV7Wxk0GNNplC2mCaPGw9CrWEotP2xYCoyvXWAzAONhhLLAYTl23G4xqG
C7d1DbyerQkGVxxSiHfV95IKSx/kDeCpVF/AwiBgAIl06qMM2MRbjSEcytJaPg/mz2NIAy4hhRAt
fjWAcMl5fYwLgY3D63t0uyLNR/wVcQOoyF+N01NMo0ODGUDUaZbUbzGIWjIJOwgFijExrkJhtOS6
JuWpCcTF8oyxdEYrgmuyZGG1xo5njXrEDEGl1gA6lioMHuQl37Q6ssGBdmELgWBiiDgzOWHkdxri
AmAqNcb5wg4UJez8c0dzmXWsgYMwyjaAcL0yP52eePRU+sLnP5OuX76SXnrtTU39ARL0f7RVOTtJ
relYWdCs0LIA5L46iFSXdd0fu+i2FAuyPJAAEAgJZWCgBTyACuQj57UatCg7y6IYdW5We50UYBnU
bA6G3p7p1TR3/QN5iJ5OewQoiwKSZYHG6BF5k2rKdlgzS5ZWOldn06g0k3PfPyup5UbaHB9Jo139
6ejRsZihCZVE0kPYR0Id0TvT+x2Yv5tmpR7J1Jo6x4fT6P6jqW9mWnVNpe3RfRrGipNckZaQPiCU
oJCkBB68m4aKzWUQ460YCWbBYAzZXwRGAkBgZCQGzvPUa5a8PPqTrh6lwwaiclY0ncVszJymtge0
FQJgApmhfYxA/QEcQWJie8+GTQY1REQ8tkim6NY2sxTiMiOB/mgrA7ZtGIBL3Wan89Eg4XtAuvC9
kGZbXsDerpRn4JkZ4iJdZVwmDGpAZL1Hxjp1CHwyLC2EeK1ESCZbUk0aABHjmcEDHMJ0H+Xt+Av1
poRYMiEs7B5tEgdL+U0ARn1jNYA4DcwPkNRSiN3fYV6Y1kDTAIEzlyNp+EGWTgwGHMnneriuJQ4A
ARWFjuY8lFPPAhmcMG5C4xIbzYgHnv5iOvbwSRkHNTUq9fEfXruSvvWjN9NffOtPGzBBreGxjPeL
IQQg0PrirMTKjjR1bybd0BfYjhzcn3o1Jb5ZpCOAwqpNZGj769LnIjY16wPV51xnQBlMh7mQtAIB
LDbaorrc+els2D26Zae5trqQbsktHc/Sww/JU1TggVTDD2llViPoqdGedOfslfTqvetpanElHRwS
86uPPT5yRABRuh/SgghfERg6hAhh/z6BwLTqOd5/KE0K1K5rFe/Ftek0Kl+aJz75OfVeAY6Eo/A2
xQ2ulIOEEuHiUYzAeLR2LOkdaKYoSBrWkIB6nn4sQFitxj+urffDjKFOgEpidN4toz6MyMwL50gz
IyyvULyJMnYwO3EqowENJfS5VR7yU24AABiia4DFfihRdjHgsoN+tEH1QJo+KNacAlhdeUsCJImQ
hFQ34xJ1ElbfA/l9v7QbEDKwAFAhBZHoIyjeIgxLRsZsnMHqhXLOC7CwRQCAgmqCYAsYhJ0EKaO4
xvMQ8IIrGBsICfiEEYeBVi+unVBXLH04zu2pwQRpA89NGJtzO5ZxbunEgFEfDRQOcx310SDhLQEM
MM4LgDCyYTD1CGcgqcsxcJHP4LFXCiV+H8ysIEk89tgn09DoWAAIeQGSR04/m3790MP6vsli+sM/
/VZT5PHh0TQyxjqSPKp1dA2kYT1CQOXW7Rtp7v51vXgt+ZcD1IGxfWlThpAaVJqCdAK4iIc/BB51
mvZzgOVI75403TGVbn7vZnrulz+R9uwZSVfvTqXzF99PR8fHVf9WmptbUvmahC5esUzAjMmIu35W
TmHyExlVuqn522lWc9p6FGlDNg6v3+nTTI4aHSoNLKEnEirbgGwpe3U1P7CeXv/xT9Lla7fTpz/1
sXRXEsrEe6+lvY99XHK9bsjEyC8GBNj79L4AgJ+8+kq6fvHd9Mm9+0MSmpKkmh47IWl7NB166Ejq
3/dISETLXVITAQdARMBQqzkwXTC3pCKrEQECukfSEU++yIv3aiHKg0ICKaDgMMLhi24xeJQvh7q+
3uHGkGqejPQa/V2GbTHUFe0t8EGfBISjXWVmNEBDz9PgQZ3UBbk86tnN3tEOHi6jXZqirAARTiiM
RXIQQBISQxH3IlB6cdhKdOFVfjGtq2s/tpjPLrsx2SU+pBrNsgA8DyIAgK0OIQDBFIvutGESAIMR
tndT071taUgbNpXI11JzXAbHdrXGwACo+LxO/1HnIXVo1K8BpC6HPTuSJA8kjt4xdWYBRz/fbFXY
8npn+vPv/jS9/MbF9N/96tc1gg2I6bRobfhw6pABlanaT3/x6+nNd84nbCUDsik9/tzHNMLzQadK
NFcDAQ7N10RTiVtfFKhISkk3c9ywvow1MrIn7dGIb1DBPgKh4mj7kkYiicAH/K1syxHs7r30yss/
SV/4+19KR47sTVdu3E4zc/Ppsx9/Ie07fCRhtMW2EiqQ3Ot7JBJ3S+W5I2bfkLG1/8mDafr7V5oa
sMvi99I3cEBhMFpv+JSs4SMimwQzMlc0BA9oYd5e7XEzvNyTLt2cStOzs+muJLAnBg6ni2+/lQYO
nRbAtvpL+KuszGZjq75Xs7rWFwBy7uKlNP6iFu89/WQaFg/1TupznvIGvv/Dl9OTh26n3uMn09hT
uo/tHqlhuMHnaXAa3DC9VK4sdWbm9ehNGhi6HuwYAMnnkbxm3NBUkUxEa2V2JAOCpMMSbimkqZvE
xBXA4ZI8zFBZ4gkAKcKAgYZ0UGgB4iEIEAig0Xm44HMU4Lr9SFhNvMIhX/sYgdVfgIjFF4CDWRrA
xOpKPf1n9YQ4A4kNqZTJrGw2xgqhS6PHhrWjlaQYKFSfDM5igrwqF4BgdSaqSA0gSBzeF8TiJhsx
d4shDRpWNbJakxnKoGCpgzSQr31eL+0njHwAhPMTVpPBw2GoMoMagZdkL9he0uI5RYTEoWmXvj1D
DXCE+7ZwZQ8ewFo68I1f/mqantK07oXz6d73Xk9nzjyVTn3tmTS871TMqkwq7slHDgWIPP/MU2l0
n2Y21LH3yWnMBEBkKn4S5Wo5HPP0HjQazonJ59nl5/ZsSCkD8hUZGx3S5kuash/c9yEbictuP+5R
R/2t3/89tfdq+urX/m668MHt9MHl8+nJpz6RDh8GBKQaSKoakZ2iv+NIXG+8dzV959yb6eEnj8f1
+zffl11nKW3rGQx3COja9eqihpA43N9lt8A7t6bVNTGmulHH+nSawNYxhgPenECk5a2bbalFxdEL
AYwWpB51qI/xnk48/9lYScy6nI3FqbTxwYF099y76bzW9ew7q8V+v/SFWA1suPbMCMwMgEBmbEsC
bqNBhXBotxE7JJZi73A5zu/yqNNxDiMNTA6zR/kCkwCVNv+UkB4K0FC/67OzWpRTVBqfc4yyJL3Y
/rIp/u5iplVpbe+JZAVUIk/1F72xnl61NGLbBXYRn4f6QuEijK0ACKtsN2WAsaThI2lChVF8zN6g
AgEgUodizQ2AheutOgbldsmt2eBAXgMI5ybirS6wCZvPW/EZ4W2XcDzHJVnsmShgahVidsSL3Oyz
4bic4sP/dX5ikYqgAXVY1r/0itF7tzXLoEckzUHMrEViUjNg6nk5gUE4m37yU59L517/UVzz92f/
4Q/Sw099VrMcz0bnvnB5In36Y0+mkyceijT2YqWsAQEXYHFX6sTczL2I78FJq9B6Yb6FLXmqrmmd
yuJ6ekYu5wEsRfUBhAC1hdH9ASpIKgODsqsUW4nL4ri5tpjWZbNZkrHwnfMXwkj62U99RptKj2ni
YE/Ek27vmNRg+aJ0zk+la5KkPv33PplGDh1JZ1/7sUbMPtUzKCFjOS3PyadkYSmNTU+ljvnFkNjW
e8WgsYZGbv24zosR5u7cSXuG8uK7s7fPp6VFgZCkgYkrE2nvqaeljvSk4fB1UeUK98phGLCvF725
I00vyoFqaS7sAQD+wPK91DMvN3st/Ht/405aOHsh7RWz7Ts4mn5060qa/E+zad/pJ9K+Tz2Xtkce
DmaGaYNxVSJl+1yXcW6GxxuWlcsmGNhGSSQGu+NborDnaKSvJAznr4/UaemG8wAHwpAgxOgug3PA
zNIGWww09SkRINGAApKN1Z4iwaxsdodrPgCCaz+zTl2antsszoHU09QXlea/wlISKqU2WPrAJhIM
rsKwV9QgE9OtYnpmayx1kL4GjyhaIFNuL9Lm2RzdBZJBMWa6bEs45LMqRVwNKrm5yl4kC64tiTjO
0gaggURhMLl/44P0gx/8MJL1F1ge1Z6mKxK9V5e1LiVWFuZSHO8yfXQax9fX/VrzsrVhSHGO3Y8s
eR+QnYM8wx1z6fU3v5du3NWo+8Z7qf+/aPGYmHVFszTjgyfT6sxMOvjQqDxU1RlEAAgEgHz/T/4i
TZUZiQjc5W+v1NG5jYk01v2J9KnPfFYpWpLLoqSi5Tu3mjJRfQYkofTL3oGR1qqPjAbqbH1pdnYp
XXjzp+nME4+kgScfw6c0AAQggaa0VeGBvpX0s1evpEefPq0tQfam1956J+JWdE/Q4QP70tULt9Mx
nT/71JnUKWnurlzYUW3WpMqxRoh1QKtS/bqlbuwd7U6T/evple+8Efn71R/nBQ5dh4fTkZOqQ9PQ
UMzMoFNrNglJRuaZmHk5+9JfpSmpQB0yJs/fv5LWfzya3p64ml6V6jc2Ni6QPpG6BVS9h/elr3d+
Kc2ffTdNnr+YptUfTn1FUlZISDslkBpIDCC0AZ8UqwQhMajzw/jQ8oLUW0n3XRpo1qSE1hQqj9Jh
07C0Q3wNVq7HYdhnNKcS4GgJKEBJAxdpYPSQSlROSDC0owBG1C0AcVtD+lAgBtwAHKmWSCLSoANw
5FIY7zoAiDqzYB/F+C9ApGZmvn6XbRBqkApjGhcmtzTijEgXJkAGQBHgCnAydMS/GD6kFxKKsQ0k
MLdBqEsouLSQvSgH1YFRg7r0WUCmO5mxMYDRRqs7gIulEtQSG0PbQQUwQdXAoWu5fF4BUbVPq1FX
NG0KuYNvF2/BFW3N5/MOPidaEeEWdR3HmGcKfVcXSFeQy+GcKXSHzzFvLnJ6veoch9Gv0KWrV9Kt
iTvp5OShdObk4XTs8CF2MUpD3evpxJ776StfPO6kHzp2DxyNsIMYAExz76ehvSfUpmExlWwCoqEy
hCxs9Ej9WYwf4UgpM/IXGpaRdknAxbR5//ZSunrjbjr+8BGSNISkAu2TkeWCNk8euDuZxmXXuXj+
fFbpNMUweeOdNDOjLR6k0kD75freJVVjQO/0+ScEUv1PpEVNj2ITwrYyc35GHTn3o+WlxTSj58U+
I8tamIeJWeJdNuDC5HJzlwKTGV5dEj+PgdV72mdkJF2+fIXUUqW20111sXMnltJDX/h0OtE7Kklj
X155LBseq43Htcx75AsH0sDpY+nW29fD6NvfM9r4e1COjZecQ9nYqjoFfoCXQQObBIvt1OQwFs/e
uaxp6r16rpqaVvvwizGfUA4gQX6O/AwWDXigAtleovRWsxj7bOS3vSbWGlGopZvSBTCeWgqJcm2s
Nb8WaYQ0ARzwvjSNFXVa7sXkMnzNMboRjBrMLrAIkgqjJxKn7EpWU2spf0t0i89uyqeEVZ+xdkEH
/EFig6Mqc7jJlzoAoSi7oLWTYbHuUeM3MeqqswBeAAgEcECAg8EDALF0QjhEHHuHCIrSS9p38849
uZQXCuYXKsc+mdoJ3c9nTffbq3BqII3PnY+jgWO3OOINEpy3E/YcfS8uyt0RhyFWRJnthN/B+YtX
05VrE7Ge5h//yqfSkX2zsp/0p4f34ba+GwFQ96uIPJ17bbJl2AZIatqjqg0sEa77X9DimG2trH75
zbfEjOfTdv9Q+uDa1fSpF59OS/Ma3bXT2LY64nrxhdjQDMxb37+YvvjffiXdvn07isEGszGdVS4k
LNPy7P30+k9+KBf+/WE0fujkyXT45NNpz8ED6akTR9OPNZW7T/upXpYEObs2F0DPwl47Ii4vTsum
Iw9bdVF/gByXd6Zzb1x5L3VOzyfguOumnoPWGa3oPjo1HTx85FTqP3BKD1tMLMkBZoXpmBJekAF5
W0bFgeMvpFPHzlSqyYAmULWbh/okkknD2MoLBRjIyF3TKiqUOJw3uogBWVLn4vSNWLaw1T8eEtR2
Yas8nLRy06YAEgEHfRM3gfpbOAaYkDAYuAU+kCWOkGYEIDXoEG/JZEe4gCn8TxSPRINUZKpVGIc9
6BggwiwAMy8heRSvxAAG5WIZ/6rEpwAPl8JMDVvT6Yh9Y3kFP4Y8i+IkWdVRozAQFGJLgcYQq3U6
PVrlSf5OjSaoUzUNDg6HdEOb6DwGEKex9OFrjkPda2lWRsgwgur6ypXr6a3XXm6Y35LBmlz241x7
VXCHBgfCIafjHOZejXQtcOE6dyFSPJgCjNQRdoALoCHwgqiPjkJ8b2cJr+IjkdKi3vA7/+7b6clf
fCiC9drL8ecdSJeBhJRdmlrdRKeqiDBZKiPEcQAL4TjJMpKvdmzJHqIZjoN7JUXck21DqsXCZrov
ewlqVt9lSSRTE2ny1vW0qPpGpIbMaN3M4Lze3bKmEbu0+5iARLeb7UMTt9OAZOiV2b40NbeQZnf2
Sr8AAEAASURBVAQKH3v6E+mt118J8GC9DS7z+/eNpz/92Zt6KfmJHz52KI1rgOhcmQ6A8W1g1Nba
Xtk4FtMTn30sXfzgUrqhD4Np6W4kwajbGQv88rNnBA9Vn/4uUIkVvnKCgwCYkBh0DpPih8Gu8L3R
RxfT/Jr6mJ4HA+GQ1HpoU1td2GA7vGev+AOXgJkAj+6VyUiTdNxaRRrR9L6mlmF4Bk0mHKyW2PEN
uweE492IbEZslRDTyZJUIIY7AwrXloIIC3VGrUaqD3BARZBSwkwOYINUYqptLS6jVn0oy9JHO9C4
jHgCMXXLw0QCCSkkn8Pgmxt4gupa8dxETNmWtKHilJKy2pFvkKBQgaTXAgLYS3jgbM7MQ8MuojWb
EkJVdkF0NmohD7zBzYe6pHrsaGYpg7IxutpfpA4HQFCVCAPBL144lwZUlnKE5NEaCzMgUNZuFKBS
JIMAlqLq1OCyW772MAOEwy31yC2wARYDTD5mUCEeGpTxEtvNxO1bkgpm03XZD25PHpA00gKFXHZ9
/fPBJYOGytfb99R6LicDB+EmzUBn4l1sSJbSNPLEO0vpytyEk8hOoRnTc3dT5/7ehK3lyPHj6dLV
S2n+jqapx46l2e28/aEzDGv26qtf+2o69ehTaeLedKS9+t6ltPDW9ZgtmYKBDh1PR547maYvav2Q
7FbbfKFRtLbakY7u7U0j2tH9xZNPxvTy2vT9dO/NcxF/+LlTqVe2kp49UllkcJW5LgYhbFC480N2
RIuL6O+ozZplYzOkQoAHQILHbtfSZBrQ5tFdWji4rV3Yjh7JksfG5rzsWloQ2SdA6WCBo2bCBgV2
23KIk/p3X1K2AaR/GI8XSJsucdDzZHylRcb0kEIEs7V9xP4qHCO+gAhFtEtFtnPsMLhSVZEWHW/A
wgCL8ZQdG5ow8SNGVaelnp9H0V0CsdazVGFfEG4SAAnHMzEifhprepkhGWjKtkMjSyzaUw0hwehI
WlDAdgxXbgMs499YP0wt3c9AUmwrLoM8BioDCGEQ4IFEUm8VmGPyvw2pqDc3zv0s3b5+Mw1q273R
od40PTOnhwXItUS2Ou9u5yN6cZBfltMMhBzSKgfVKD485ATV0TxYBcUp4bbH1HGAicEGAHny1MNp
+u5tdfxsgwJAekJYd65cw62b1yLg6LGHKdmROj6oBRlAasCoMuVTLTirZ3629d4nJyfTyL6NdHLk
uPT8zNhb05vp7XQ3PXXmybQk28vtGyn98Ec/S3cuXk5Lg3uzBCLVFDsUrZldk69C37hUDEk2p7SS
58iR9J/+1X9I52TU/PQvnEk/efdq+tbFt+MHgy0KQLTsUoPDihb73U5Xbw7Lm1WdXaD2sacfTXJJ
EcDNpD+/8L78ZK5G26fnJL1pOk2smu9FBmDc93u0opmFhh5QYkd7gU2oF7JVeN+SyzcvpaW3L0Ve
Fv+luel0oFcqpO4tvZXC5X/86H5JanPpzkyuYqtvNAyoXM1KMunUkgXAAwlydi2rddudqB/XNeX8
tvx4RtPpZ5/TBlNHwr7SyeyeWoxDY030P+wvuDqEPaSoK5ZE3D8tYYQkIgCrgaA5F3LVagv1hLFU
g68lkSZt3Yhy3qhFVVyACExrqcKgAQOzQBLi3MBgG4n9SYiPvBhiRDQA1YR4jiFdKDzUHTGlHV9i
C0WFA1oxsyOxEFUnAISCRLWvCNdWaQwm2dCaR23iIcKWtAjsrbfPBYDQcdmj40FkdPcLIR0vpb72
uV9We1k1gNSAEnYXJSbe4RGGOiNpw5KKQaMGEOq4fe1y/Dhf2c4My/lO4t4eBBQ53PaQzsGxkD52
5t/9ClVFikcwKswYVObAMdAOjWT1h/C56cmQQgCVoXQiLSj53NTdmD1akocq6t9Aj6Z31Y+WNBDd
nNT+qlJfoHWtYP7Rn303vX/+nfSYXPgvSaoYeuZESj+a0fS0DKqyCwEgfVKlpETLZ2Y5DYlbhno0
VSyfmhtX1G+kQr3/3q00ocWKU7fuhU9Ik08PF5v6hAy+r2vPltPPfVK1KkDErnDsteK9Zw8KYKY0
I7Z2/UpizumE1KnuJ/fJKXY47EOobhMzG7Eg8vU3NJPz1mZ66JGT6fHHn5BNRUsglGdTozv7hHQM
HUi9C9o46d7ZdPHiVLq+aNhSIhE2Muiupps/+9lfCp8X2sIHx9jrpU9rcFCr7FDGbEzMygAo8vBF
cnK/5Oi+aSkEPrR0wTkAwcbSWaVRxYhB3g9FlwYHJBOoXRohnnpqI2sk1F+ACBcw+boYnwrZUs+E
LQRgART4FCbEZjM1kRe7BWkNMgAI4VCUQRqVY8BB+kG1AUC8peKKfBq4BkzmlvUghcy7kcHEcZ61
8fW777wdox7XMG1MXzmy7ei4zmJAxikJn4KQM6u0hH8UARTxUoteHWl3O1cY9g0TIrc2XohLg4nj
2o/D3XRtEwDRKufAsWeLhNIKc8rdjgvrg2LEzMiOR7XZ2h5Mb539afrht3+aQUD3HWt4qE1GhB/9
4J30yCMnd0xUbt7fTKfG85YDgMu2AGhkr7xUr1wR+OWZlRXdHAsKocuX9dW6Ny6nR7b2pMlvv5TO
XTifxk6PyRy8kb545tk0NXokTfzRS6lzUQv71O9w7IPoY7cmF9O9mfX0rNSWBe19c/uObCsvvxPx
/G31SMpYwgWfWSNt0Bwrn5O8Z+/IT2Uu/aNf/ZXYHmFWasrsB9fTDTnC3ZSauLG1kJaQNETPPH0w
dR59KIBjfqozTcinpEOG2S1Nd/fvG0wnHj6d0tPb6eHp2+naa2+nN9+/no59/guxuzwzJuwQyGdl
VaQcYzvSgsB7bX6iGTSiktKdzkt6unr1ZgTxZxeCT372c+nM889pejjP3OS+1drSsMnACZIJA7BU
eNJ5LiTyKDqARXydk+Z3kFUc8bkN+sz+UI6pOvf0LuXOtYEhyZtcMDoMDlgYuczwjuN7vYCEHdJc
X4BEqDICozA+OaYASIlzuUwbI3HwbRmAJD4zIRUkpBB8BUQbkiAABySgWtUBQAwa8bHvRmnPEhOd
5f13ZYgTWRLgHF8BaLtyqCLM1zVINEASOST2w0hKO6AX4TiO/RodTZ3rYkg6UEWkMQUw6aIOI65D
IvRHEXUwS9OlLRChoQE5zcVAuhMsdqo4LpE0/dLL30u31p+iB2hbQXnayvFrKAQbidabBUikurz5
6k/Ta2++G34rtyZzuAEkb0+Q0nv3Z9K//+YP02eeeySdfvRYOry3BrZcLzM9OIX1YdBT2/lM2YpG
cahDnXZM08Hnf/jjtHHxYnpYg8mJX35ctpSsdnQf25d+5zf/KCQPegLDSMzMFOClPbOaHYKWBQTv
vno+HZI/CU+6474c2iS9qGItI1BABdZIMtB//t3/mH71V76SeudW06I+X/G41uc8ro2Slg88lVYH
VkLtfV+q49xb5yWFqf69R+XUpmUJA5pViaUVKkTveVXqfp/2df3YL+xNd2cvp+6b8rk5JaDUhky9
sr+MbkymDS0zuK0NCLDHoAquhX2OPpgH42iQ/nA/wA5HOK+Wc/ya2Ef3iUcfjWSWNJBGkEJYLYzB
M1QQAYABo+ExgYCd0lBvTPSl3q5q+wJF2HAqMUVXGWwscRDneMr+kLexcgSIGCxqZl1XBhoI+pM5
pApNu/bLUryiEQUgCdVH4GMyCJEv3Nml80KADAQARUN0Tl5m/YgLdaZMzyZNxyHqARRRBvYTDK6F
2A29ZfzVgiWVE0CjtgEwb7/8nbjR/q1lGbBaD8/5DSa+NnP7miOjWQIUChlAlpHQBEIAAWHuo+1l
RDrlzfMJuZClonKQj9kOvr1rQgLJhlWHqBqrQLRju/0+MoD06VlkQNFzLMX52iURfm1uLN24f0uL
3valu7IZHDx2ItbVNPYQAUiH9PkFiWXvXb6fVjp0XaROymE07w+w1jsXc56/dC2kiV944nj6p7/x
jzTNOxNqyNOducMzhbzNptIygkKUNdqhL74xw4IhU+rca5r6RX3plQ9M/7AkAHm6ntL07q03tQXA
vTtKK3BFny5Tw6gyfPoBevf8lfTQsTfCd+ZQvzZDOvBY2tqn6dlbN+UFq/6gNJ1i2D5tmbC9lvOQ
DybF/+YH3/2L8Ag+/PS+dEdiPXaeO1enBRKd6bBsSo8cPZp6JVnhs3JTDibsDLfClpNyhMOhcYQV
hCJAbm5wRMsdHov9VdiBbUXrf6SopntJ3wSWetLfdystz8/pVlrvMA+TGSzaAYVyCZuVFPbyd78l
t/5/nA5rhgqQAEhiSpl6JREYOEKCCABQ3xXIoJKgjkS8wAR+JK9tIebBkDAKEBHm67CR0JA2inBp
Cu0UTwPwyDMxKlEEswfC6dxSSNhECoICIDA2cZZMnC7AhULoLKIyGMU5fyGpKD8AEYZTIXrxvWrS
ZGc3zeHzXV2li+lm5alJX2tN22oDwMEnIKnn8nuvp7u3r0eyZZVLZ0J6MFM7P2EfRSFVKEGdz+c1
CBlcKMvxDyq3zuc0zUesBCi7qTIACV6cq/KG5e7HNPvRohaAtIyqBwUmhO+UUshzUAY97AhX70qv
n3svnTh2OB3Zf0D7g2Qm65G+jBEVfxDNXgqIWzX1FeZthYgB9F7uimnuMI0rj88kW0b2NWnZSpy+
T2LBmFbxYkhlG0hsJOMyeA89fzBtDS9rb5WNABBUoa19dyKbR2YuRmWM36vZmktXb0Tcslzgr9+8
nY53SgW6vZj2nt5KR49p7VH3a3rfAi+NOX16+cvqgwNaIT2+T8Zd5aFebCUzs6sBHNP9+pavpqxf
ePRMOnD0pCR7fQpVrgVrS/OpXz4jj+i+njmd+90C6o9+16ZW0l05AZr6BwTyWr+z0L+aFs5fSA9p
x/o5bUjdpbKTGHeFqaCKGCzwF2oHj/brXkno17SA8Sff/1b68te+noaKdy5FMauSv0SX7SL4pYSz
mcKRJhjcAAXbOZzHPB2gIkD3lC/xESbwqwHEEojDfE36mjKkKqSZldE5BQIKJksoAE39DV1LMAYS
VKFa2iC/3lkQEgM3FhINoCWJhr1GY4tE7YAVUgfAIyMWhJU6Ft4RJkAIQ28Bnj4Z/CwQHuydTwcO
HEz37t1NZ19/I/IGw0okXcYYqRGR44B2PI9rpVguoxuJCf955Pykq8/jusyaOI5jTXW9dTjns0ta
Ij/YQnZLH3U6wqTbpQ0ZBo9ns0MTbemjNSPTemdNorYTwOPWvTmtK+G+70mNGJYn5abUG0mYmu3g
2W1rps5kO0ZskFRJJ6hhGDlZ6De0tz8dn90QY+jdSarBINshQOrrEwCqA5AWO9CgmAsCIGSuSG9p
NuZZrVV57lmpWhXhrj8t8R9TEarMtvYY2JaNZWx8X4zQSErbl+6lu7IXQCPad3ZhXtcCNRYqTvOV
vJgV4FMb+jaMxLPx/ePhdIhEcOP+bPqvHv2V9KVfkJEVI3evtls0r2s1NVsz5JKjCVFH38BBrVg+
mI6xjmj7E5Jw5tPMxLV0f2ZNu8LNhM3kvhYEDmmv2TWpSEPdw9ozVcXLloKjm+4kyvFfDZIOaz8C
JNhMevb8LH3lK1LBBBK4LrDvKjZFUziYcVGkEU5tH7GdI6sn8hGJON0sRlUBJQCBXdAG1Zw3PwxL
LAYP0uIS304NiNQRnokhzMCBvQIAMdXAgi8O4IGUAZC020zIY6nF+QO0AiAk0fiBCCwsweTZoTam
0KjM6/AX0vYL/TdWuuUP8m56+dU3Yp0ENoR+jJfikQGpAr2a7x/QfD8qir7a+JGUX7baOiC/Fs0i
mA7r+ufRHo3ki2U+vk7LwrPl4iiV5CK+os9CTMjngBGJEb7TSKBMtQ3HszhY56dlL4Ctj8qjMwvR
tLFVSz7PzyqrM9FVQioh1dacvhAnCeTxA5NhFEV8hwCSBX04e3xM6pnWkyzLKoiNKIz2FbaijhhM
IqP+0PFB8vMf3ElPnPxYWpJasnFBLu9f05L6WTxH1DnF/AAIUgvv5bBWJE8vyC4jEEElnFrSu5Ef
CTNBlogiY9tfqEES55muR8zXl8Bl7FxIe/W93l/68sfFJ+vppbeuhAoFePXLr2lVHKy9nBrW7dcC
v4EeqSV6rWxQdP7cO+nZZ59Og6N6twaQtnp3uwRgwhanBYvj48+mUwIdiI2lfvPyFa336dE+stoZ
UF65kDfKigv9YUi3HSzAtES0SyJOzxGHySP7hsPQ2qG+nf1Z2nijymD7CUct/wxVhg6HbQQgaABD
17i1AzQABXEGDNJwjkDh9HHN3i9t9CEQCftEAU0DCCt1oTCGFoa3FGIJJtQYVdiuGrk+209oAqrH
hgxsm0oP6KwVY6yBiTwhCck+wvdJuuRdODKSt90j7uaNa+kD6eUdWn8xq/nE82+/Fp2f5zE7NZPG
teYjM6SWgGNokzLQqdEtHoLKgzGheMjqnM15WaIOo3tBHSL4ysLOXoahjDQ1rQhoOvSA8Yw0kY6l
6A11aG8NPsVXqP/nLBumne4QgycPOVsDDk1AdWJwAUxQa1Bvbq2NSRXSTEGZitq3Twvhbt7R6tUj
oeLgQHZPZdSzRi6yto1479eIEzMBBBg5B7SidvDjH0tvf/sv0/jMyYjGJgIBIAAO+8SyiC9IYbyr
Kdkv8FZldXLP6FGNklLbJgUu8klirQ4MPyA9b3W7P7ZGiLwMPHqkU8q/dUi+Incm08z2iIys99PN
ebb203uRdLgtnYy69UI0w7Gcrl65HCoEb03jeHrj3UvpF+/c085r47lN/x/+2QPGdEDP4IgW87ES
+wVJLNNLsmvcu5LOat9a+hLbXIo5pCYhCWM+Va8sLws7Ux/SmehBYIKhtWtof+x0PxL2qUie88gO
wkpm/Euwg2D78PSuU4UHLFUorgaL8Ckhvwgpg3Uz2HQMIEgjdReOhG1/0aMBCxOeojVAwAKITj28
kIrM8OQ1kDja11ZzCAcUKGdN3w1ExenCTa7Qh6QXgQe0pVWZx+Td2KWpt3FZAeenJ9Jf/OVfplff
uphW1NHonHQU2ZDkjMUKTnVD9U42r/kwFWRUJ5zN71AV7AQH56EM9jnlCGHUg5nMRB6ZHRZ7oha1
y2VYomqudWLDlsS2ELMPyZkM2o15Q42JWHUsGbKPHdAOY+Gp2uq4JXrXA+Cxg/r2h38F6sfx44dD
CsGbEv0ZhyivECZPSBk7MrcufO+oGXSubunqK1v700OH5VZ95kktdvyZpJ0n02Gt9r3xzrUAi/Ac
1UDUp44etJ6lk5WF6bR9/Wraf+KwFsAtpOnloVi126qtdeaPpBHC1zyXpQJfePtGOvjcYHpaDmeT
2nZgbemcfnkx5/aA6lI9gFB9PzApEgAbYP/gldeaLSpbNbXOOqSCD4RaJIkiLGytuPazVUldG1KT
TOOD6+noE0+k6Xevh1Ts8Pq4JTABSLDfBJCAcIVqKYWglSXt7vZDGVq//g9kP4tliFrfI3eMwkaN
SlNNzbqsDCwytqo/B7gISGJqV6oekgZAEcAiYxLmL84hwKSd6pkexzXDohmfCAyZMHxMuerax1oP
cwGxgbMs1rGKt8y08DU9pIx2tcblAFIDBbicBuFgdXk+gMOb/Y7L2xFixeeMHJp+9w/+Kt25cSV9
4tknwrqOazM7hX3vpTcjnd55Jhj6I6hB6geksznIRxfl68jfmRmiDhNUxktqwMIZyxEXfByuIIyN
jMyA4G5G1ZKlOQzu1/J8Te+2E4Pay+e04/rITHrksYfbo+N6QPuGQCx4W5lHlRHT7tGUurA6plY1
MwKxujYbgD/8/ACPWqlDVQCCUVMOHchgePKTv5g6Lr2VtiflQPXQmZhFwfz0yCMn0mdefCHq6Jfh
8fbd6fTd734vrrfua8r+e++niWf2pw6pOx2LHQmbyJRUl+UF2TS0OxkzLVs8N6u7emDMcE3pi1kX
786krT/4QXp/q0g5Uar6rBzkBvVlsBjZ1fBtNaSjRwZNylF5jA9vvP56+sIXflFbAhwruXYetvVy
d5a6M76+unrlSlyyQZNpSRIRzmu85zZIdxIJEDuBhCdvADlx9GDsw0JiVGKWP7z5k++mL37567qH
/DZYWwOhwkP4qWg+Js75AyAACmZrLNWGw2e8vRxv0KglFPKGf4lUHvYUYY+RkE6K1EK8qQERSxT5
KNQqnZ2ELUkl20QMJnUaFwiYoBKtypjJVDA+/wBKkDpBMIyZl05R/EIGhSLDw9oKr0P7hWoUBThi
sxllnJldKAByKf2dr31Jo7I2Bh4fiiIXLl/Sjl3aPU2qAh2NJeN/HaoZnW3qMGJxjM6qAup4i4Z1
WH1e11eHD8jI5y0IOGeOPYBEjIWeHyOzRkv0uyL0fAhQ7Br/0OFx9Rt9/8Xeo6VSJOLPnMFJKjtK
1W3hHJDZ16Mv461LEtHszKQ2BWLZPzMz35E79gGN4CYmdRqbiNQAS2ofMqoWAysrVaHxYyf1vLKR
5qS2c7z13htp+4OJtCWg2N7SOhIx82/8k19HpEr9mhK9PTUfW0BO35tIrJOZWpgQEmqzoaFDWvV7
O4yymu9RuJ6XOgyjdABJxu0ABplapE6J4eT30ikP1omzV2iKZle603Gpa29pBS/bSVggO3xwXKpd
ZjzsVGyzgDTyyg9/oM2u/4HiWsA50CfvU21CbYrFpuViQcsnoNGDh1RZFh02tcnSzEtnY//Z8VGp
eaW775Gj3f31O6GahUHexn7lZz0Q7vyAcz+8JomHFtAHkUzgk1+TY9ynn38sTWt9UY8GgL/89l+l
b/7xt9JBrd956lNfiOlewMNbEtCucNQs052x1k382EwFk0BEGj6UZanC6gpgEepMkW4cH7ucKR8g
43U+UVD5CxBpDKaVWuNEAIa+BhD7fxCGuoPUYmABNAwqVl8IY58QVuk2AEJmwCNUFX1isXQIjKR8
Y7WvL+uEfUK+1U3Wgcq+oBmDKzdvpD/+0x+kSzcm0q9940vpxWdPxz4XFPdbv/076f05iWPipF7E
1A6NNNylwMmqCCrOtnZmhzqK56NBIQLL30oBM4c5DZ23IYbVIt42YdUJHQACkKAtiUbsXcLUIue4
HUNhJ9DWZ/2abWCB324Agk0HEwYjFcTMTDuARIT+imrtyw8dMawOyTEKwi5ya3Ihffz0gQCQPYUR
sJGYGL0HetfFhA558PHCxSvpO9/9trZxPBmJ+HDWpKYmX3/nXJPp2geX062bV2L3tKXrl7Wt4sPp
iy+eTr/zB7djg6DTzz2fAI0kz1HI9pRYeKebA9h5D6g0AVx6D9t6D2zfwPqcR4+eDOBhVgh6QpIq
M0d4t66SR7aLX/2v/0764pe+Ii6QJCZ/mVdeeSX963/9v6W33ngjvfD0mfSkVDFoWmtzXn/zUpzz
N6ApbGjx/fPpWjWwspXiM9oWYWhsJL39F3+S7uubOl84fboBkMhEvhvzUrH0oTQZOJcFYtxTTQC0
dsgNpzr6BQAC0Se++Yd/nE4//M9iNmbx9qX0pc8+n65dvaq2v6r72p+efOLRnFj/4/K1QSoBOFBz
YkGhpAbWkwEG9GevGLaE4SUoLoTl/57Nb9/RzEBjYHEejgEisbJWF2xzaAIQcHPv1D6EhPPJiNVN
WellBAUgDA4GEI5dkj6sFhHvOCQWDKv4dLDHx97eDX3ceVgSh9YJ6Nu/WMqs22Hy7xPiLciZ5oc/
ezl973s/DgPeN778mQCQ4ydPxDZ+//v/+e/Tz6RzHz18uNkNrAwALQABzgUoBo9GLPZN6shIBzHa
tZPBgOnIn0chaRSmyyuHlaN8TT3GaFCzXLNvBetBZsWlrp9m0HFKc5rqQmLRiCnWaML+JifreRsf
TePm3skU7+QkMwePxEwNNhLP1rCVIsTsw2yR6NpnZSKBBgNsIrT96q276aVXzur7vz9Nt6bmNGWu
b+3q+zAHNc2JdyQzEUgUr7x5Pr348U+oD2wrHQvTsgp0W6L+X167nr6iqf0BSSTX3r0coNt/CElz
PtQPq04hJeo2qLtTgA2gfCC38n4BsQmGxdjLVO97q5OyA2nhnfrU977/k/SLv/CZdE8ezSN7ZtOL
LzyTTj/zcak0b6c//Jf/Jo2eekg70U+GZPOopo4772VAOn50NG3enk+3tUKPnnJEq3Wh9d//03RD
trlVSYjntE/rc7/+d9PmgHZlK565pIGbJmeuchpkAEECaSemoge013BNPNvf/sM/T//9P/4n+nJA
Vjn/4T/8tXT9/v+dzr7yvdiSk8918HnUda2q7hiMkSarOmIr3CfCOU2vFR5kjx/AhKliiH2fABSM
rrUETVgvPlilMQYQLolrp0adQXqwJMERAhCW9DMY9GlqjfU17DFiQyuNa1QhgQuAENfabyQwqYzw
I2r3sLb5G5dODGXwyKMs+5WgsuCnMDN3J9ZSvHH2Ylj0cVL68qeeT59/8fkEgIyPH07f/NM/Ty//
5KwclE6mL3/xl9KffOvPtQO5NspRh4U5TS1pJIdYVXE8x+UiBuyQOEoCSxZO34CKA6qj1RaCbPfQ
5qRVCp2Wa3TebXWalUV1/i3t0iVpiWZggOzsG0mHjhxNLL4jDG/RwYP7dkzv7iz0wVeoP8LsmJ05
oGniZU3p4ly1IKljSbuMsYPZnBj1+eefTnMr8kn4z38Sjm1aBdYUirgNtbxWm6hobx9+EGLkJY2o
w/uPp6MjnWl8UtPEslEwu7QiXxjey7/5zd9L/+7/+r1WZp2tqRczK3H50qV0Ye9Y+vLBhxX6gdzJ
FS6RvVdT0cvxTNRnCsgHgGjAMqBQIJ+j+EC7r8GczHjhTDYwkkET9RZp9N3z59LPBBhf/+LnG7Xq
G1/7RtSN9+yxiwvpkGZVRrQ7vj4rkO7dFRBp79UbtzRzJQA5UMADMDGQnL14Md27oJck+qvv/1iD
3ptxzp6yEKroOS0IhHYDDsLxCA9a1lHg7EElB6b0/ZfPpjNPnk5f/OzHBKirAsX+9Btf/UL6V7/9
W7GT/Tf+x38eSfk20KwWPc7JM5nVyhAL+qZWNVAXnW6rhEek/gwevQIbE4CBtGHgqO0hTtN+DBBB
R2qnXm06S6cGQCyptKcDQOggGXOK6qKRn4HBX4rHzsHMCjSoj0/7A8XsJJ2pRy99Ml25PRWg8Z0f
vCJvvJV06NCh9PRpbfEvb8AjPdpYWFsnAiCIxX/+F9+Vo9ZKuDDf+t07kZ52tFP+kpxC1abdZkva
0+8GMjW4ACq7AYnBpo5DMtk/Ppqu326pCdSHlBLgqvMNob1edYy2iLIQHQ8DGgCCKkOafYfXm5kZ
tJufp75EQdVfbBKtRWsD/ffS3pGhmNqdmF4WCJ9K+7TQ7OGTB9L81r70zT/7drzPWsd2MdntvVzx
PEXb0nMHtZfGrDbBviO9/bmPnUyffOHp9NOXv6cFb8uxG9tMyQJYA6k8TyQIAITnhcHzBalX++Wf
wnc+Tx7Yn75/44o2JNKzknF1Zr59Ybyei/odBKD0SVW5JDUILbaeMt/qGk17+uRMt8pHxgRq6h//
/j/8fnrt9Z+lkWXt3dqlAVLAh7S0qqnN4cefFQhK+tErWTus7+zc1yZHd++nx04/re4zl3545Wqo
Wb/YE4pXSCZP/YPPJRYfQpirL6/IxV3S6Np0lj7Y8qAm2tesiK4i8BcCTAC8Afm5tNP/8x//Szr9
yOF0SO7v19T/z7z4aPq1O7+cfvuP/jB98w/+JP2zf/E/a8tM+fpsH5YkdDrhXctnPK7cmdfAoe8t
ayV1EJthi7a1G+DAsEC6uDdEYPmzcdVHG1Sd5oHqDJ0mbBwSgXwEQFBb6OZmzxCJpGMBJpxDpAsq
07JSieNLaONyxjEBHiZsHVBHd56mWpaaA4DwGcY3LlxL87fupOc//7nY6Tw23FLa8Zv6Zss3v5cu
/VpKv/Mn34q1G5QBo60JTFABmBK1EZI4qJFE2nWEHL3jPzrmLmBDeK0GsVVdDRYPAhZsIPezir+j
HqQUcD8DyI6o6OiEtN/HSLc4qpABxEbWkDZKHDaT3cLZWQza7NyTbt6bTSceOhAAMqrRflqevm9L
LbwzeS7S8KhioVjmjQir//rl34PoDcGYK50DaWqtI43t3RvOUPu0WdDAnnHtmXw1HTp2TGaO2UiL
/AmQ8Oya7f4EIND7shnt0QiPgZVRH1rVEnnc27dZmCcQeBDRhlnNgIypvwFYMOl91QmAm8ImNrAn
TYi5vvXdOzEzRhx5AW+OM/IlGdWms4PhuSvp5vhjaXZsNq1pQeDopr4OKbeBqfn+9ANtUHSoOxv1
f/jNb0cVp+Vrwq7xq1ILDn1KGy1dRV3E1N0fatWtzmyTQ/VmZiqvMJZ0oj7SLQADQABpVMcZ7TI9
Jp8oE/YpBtV/9zt/mP6n/+HXwx64uDWYPvd3v5ZeuqgNyH/8Ujp24mT6b/7+1yJLOMPJu3avJhoU
HMQeud6/ls+b8tGw1VVtIqWxna0hmR5mL5KYxRHD27mMa6Z5ARR7qu62bWKICF3aHg53WqQOjKgm
dh1jupYf5zxsVL7tou7ECC8RC+BgdgUDabZzABrAz+6EwXRb9pFOGYCuTuhbs6VSRuDho4e1QOyk
Rg9ZrTWFx2cG7klFmtTX1i7+2w/Sq9ezt2VdMmCipxJBqAmsFK0JMOnrzR2fcAx0Hs0sadC5ixmg
zhrnTusIA4clEIfXR4yp0gHqoA+d92gWAGJExUJvaYQwmHm2OPkhZtfTuwYOH0kPtV9HWL2BkWwy
rEw9cviopkg1ZIpRJ+5cC0Pr3ftzYvxs1KHuB7U82lgAhvNZ9Zuz756Lr/L9nnaPf/zMU/IiXgrX
8kE5kyFN0W9M6OTYODBQY8yO5681UtNt/WURJz+5t4vVQlILBV5XkVdHnhnEsYN3Xw1ad4TeAyzq
KwSTylQTNg3efd0zaRnTvvS9saFHU/9+JZT9qm+gQ5/8PJQlHM2AbKnP3rpzJUp8WwxYEzNBe+ww
een99IlP6HtBMkxDoVbdzIDBzvNnnjgVM0N35Oi2R22hbZZIwwdHosyyduhDxQ3fEVRfAcnZ81fT
//K//ssoE8/qbb1LvsUD/cHv/76+CnAifeNzH9d7zYAVEfrDIW5cgMrPoDKjT2ngtt8CFm2OXSaj
2MekcfNVfgAE/5KwQQEmLrg6NupMBhB9Q6bMvHjGxgZU+bq0FtNpxNYtJD7WvEcfLarVlQd3PyGN
Xh8AAgEgl29NpltaE8Lel1MTt8LwePTQXm3KQlOl5sgD8crV62nipt6Csu9lmz059ejRUER0UHv9
ce0PYnNeU9gfClcAMOq+aoCARvex5XUiekABijp8lATj9M1sjspYkaH0b0KehqZdq2tqjwbaGkAo
C2C0UZOFd5Yw/ib1kJYNieY3FlOP9F6gNabcJZFsL+nD2EUqnNTOadrVMBjl55W/2zPmi3frmnVY
0T4s78nIiIcmixhXqpXQlGsA4BwAtmrDtSaww4C5qAV60KDa178tV3ydh+TDlDPn4nHK4WcgoU23
pD6F4VJ2EaSRetlCMGl51x40ojD9IR1RFl6tM9rk6JBUmuUtOanhB+QpRIHIk0+cEIMuhRQM49c0
NjSSPv+FX0j3bt9Ozz/7ZPrqV76cfvLSt9P1d+QG/9AT6TPDh9IbMizPzGi9zeh0OnrocPiO3J+Z
DEmEsrzvCW2NsUf9k7YCJL0CSWaj7gqURwDLaJeesYAW+wuS6+/+5r9LJ9X2M3JwM5DYo5bj/8ve
e0fXkd13nhcgER5ARAYAJEgAzKkZutmBnVutVrKSZVsj+1haz3jGmrD2yJ6xvbZnd8c+M+MZr7XH
Hp/R2MrSWLacZLklS2qFTlLnQLLZzBFMIEGCAAgiEeHt9/Or+j1cFB9AdpC0f/CHg1dVt27dV6/q
3u/95ZsXZ+KEI1xePlYOLDGodPUp17ISoZBH1jiWEa1OqATYVybn6X1q2Jje01tKtomyIi1zAOHQ
FKauzdILgEZ1s9PFFYXxm6gSY7vqSTxipbXJ1BHGLo4+ABBmwrPnp7iKM5c0apgBJAcjw0IXey+F
zhNnxOL1ywS3LpzqPJYMNljclFxSYdCB3vwzs3gHoxoKTF4OrCOUgEQy6+psUqaOGHMxPsDt5LQP
v06DXCBAu85RxNf7JfwWBw3/XWPRbOF6G2ZsLDEAB50UOTknFhyWNxt4523PtC3GkbAAFYaanOJM
8PydpxeJchUiU1hZriYsVKqh/ceOW1n8wT25gnVauZ5zuZTtK2rLw9rGJlv46VxddRg48qo4nEFz
Q58zrIWpmd0iMiBIfUwovjBXPhOAxyIpRVI6di6xjkghZ8+kRK7xTg4kfgx3odyddghHgBKTWT8m
40aTbmUilZk8NUgh9DPQuZ7+sFh5RuZKjh6RYri6VLEnYoZGJiotCvmOrevCXFl+WrvnmgjGfeOT
cufqm7QYem3olh5ig8zFrNnD0qclCg6tFhfWsnqtIn/F9SkZE0QfhyN5eZdM0HrX9Mu4f1LH9COk
pBAxwXiPf+CB+8LPvO/t8qNKFmbfd7QrfOp//InFY/3Z574Ufv1jv2Lg4ABiDdCGgCSm+Lie9yNQ
WaJMbm3yZeEcbvuTl04Xlkgl1+xMVAARlKd6XQXTLbPyBGHMYjlxP1/UUBsW1Et5qllsXhmZo8UX
T2MMp74CX4+rASQBGgBmQqbgQ8e0OhuxDrWNduHAhVPTdAFdXd3hhZ17wpA6/Pq16/QmNci0al1J
+TzJtMmAgwtpEavfr9iWkfNdNghpjE7P4IP8BbHPiyLrlINJVuzJHgMKxcjaiU7EoED7TvPEpa2V
LX/XK3v0GLWSXAQe3IOH2NNhXM/AtYX2lZ2rUUCaBN5Nn/38O4ptXTdS7FyvZO42nZgr3dZYGihX
qrD1OoFIb5r4KHtdMQAp1JElhziWA5q5V0kBmSsTiKQnF4xXBGUxsSMHdWZXG7IpiBggFBq79g7X
I156e1zB8ahm2nxp8l2UMevHHAPPHhA3nUxqSOC6mDNhRj+jTGk4x0Fj6l9lApMGiQ5qLjRJyX/3
hu3hQt3+sLk3AeD5C+pswavD+5P3fl7PoELcNGsGB0X41tWKQ6vqD1vWrw2PnRNHLRqVrgeqr68R
cCWD0/uk91cG5uTolFgzKTEQy80TMjy88+7NYcXKReGC0kxuW7889P70B8Onv/DFcGDfvvDXf/Xl
8C8/+gs0PyspDrrgyg9owKngYQuxXy9Ju6qhw47hbDBd+9pAVhh9GIhUViuHgjoyoovFzWjhbGiB
LCvK1yZxpTEFDl4/OUvt9LQPuIsscBQrg0M5Jvv3WcUZACBk4C6YpMSakbwWACHlP+nsoEVNtWH/
noNJKD/mCRFu48zepNorRrwMV1b5YI3roSlHVo8HLyIO2n6LGpVSLFYiwuFAsM6Vc2rtuizXA1vM
rAF3BGcEmawtRVk+jXdwl2baMRYW014RAkj4b1Dg3apWcWh1N0lJsk9bAeo1yOf9ihrNZOcRdg+a
yZXLRodl6lXIelNjrfp48p5xgW9q7ZDXb5fJ336Ps36NnlXMESD7a4WYkJejGeITQXTDmqmlmSuQ
iSAauGxjwpsT5aqW9ku20UkGGoQ1jveT1U9FVc0fqOBYKNM0iZBGtHg5YGLArImxRNG9Fqui9wTZ
vr6aLaINCb3xaG2cR0Y2AYkGT6/+KqsaQr9E3iqFgl/sAjD0v6DKLDiNKHHFkUEnxAHN1cQLzZM3
bb/y4NSdu2jA0rFmo5maWX0PbgQXhZHhffIiThQScLRMXA4kLtYAHqk0Hi5qsvzEF/4q/NbHPiqO
WxyDnOMeemC7fH3OmTfrI48/HRZLr/ie977P7iHmOKwg/cjGAjmQeJ0qBQs6qChjlTgy/iV2Rgpr
r2sg0nfxvPQdUp7qIUs/GmpkkiXMvkKOZkPSQ+CCjqNdhTlLJQ/LG/BtFkAo9zLAxAkx5tiZCwWR
BQAhg9TE2Ljku2QGyIl1ReMOodEek/YfZVKzckJAHrJvBzN8EGVLFO3rpTgatyQdbLSVL2+yJq+r
bSW5ceL3zZGpGmL5zuPyPIypwH2o0GclA5GmJWG8/i5l3no15GtuDivnL1LGLLWj5QpmomOdesYn
5KU6t1f/Sa0ky7jeiVzfoZIJ75bJebKW90rRel0AwiWIuBrUgCbu5xeGZLWbw+AZVYg/MJbMtlQ1
C546onMPADeTgCtcbauBXr2gMVSM9wp5uSoh8pEUsoLxnU76btdheVG8NbFQQBJzIybGZvRX/hRs
q/b7lDq+QaKJZDwDXp4bQFJZORz6NfMHxfewmLjQOfk6AclFAQrLYjjV1wtUROPkGREnw1RYKyDZ
vL4tXLxw1hSr6EUAEuKK+jVBZsn7wAipD2Tncf1IhcbIrr0HZa35avjA2+9XKgeJXoNHzev28ad3
hHMXusNXvvIPYUnrsnDzzVunNRvrRTiRBZj4GNd9P85eN61RHdgvR0laI+TBLJs4gQEUILUSJ8uV
3H06Erft2TmOGDAcRNh6+c79JxJ5T1wInnYV44nsygAbutwXGmvKw4GDnULcxEzWcfNmu+dpMq7C
vN2FnJNxHg6rrA8z+WrrtnAL6RfnAlCR/Z3jLHmIP1sHDgcT33IN50bkqHUVkAg0AAuneRooBE55
WQwkXse3Pvv4sYMKWvjHnzuutXefCWs2ngy/8q8eCuUS6WakOTXhvLKf/69PfzUs7qgP71NHm0Yy
yUKkQ2Qg4LE6ogA8EgrvTJM6cd45L/aZoeMBy7liHr7Uhar1fBMeR1gnV2/EzgZxmUZMRKnCksxa
zjUpB6FZaDCfHksFInPQkkiHLp2ERIu0lOjYDHo2sohhrejtkbuAJWkGrJO78GeJSNOsSako2T3h
Yj9q6Qz7FKJQT66RlAakK6mTGbZXS0csa20KJ9LF1DkdA8hcjSGCEueVDoe2VWssYRJ1nnvyVf3u
kXDb8vXh4eefMqACRCASU5GgaiaK9SNmsREH/e3Hnw+PywvXU3OSLwefFwi/nU9/7ovhN+XNOlNw
oQME9QGJ+Jiy+Nj3ZwITA5FlykyV6Dkcl2nmanJQ8DNZccWBws/71suxxpBXokKLMgEgTiXqQP0X
xTLq4SNL4l2ITmNpa6tVmavEQlhleNDoLcrVyXBlh3XFQ9V1Fy62UEadZJuE8ft3Bb1cn0WtLJ1R
40GCGAMlFpN+U9Qm+1acfkxX3Fm0qIaBeaPKJOfb+ArfJ55mNvJOT52z3Selb7xXANIablu/UNnB
ZgaQocvKzaGMcUs7Voe7H7zV3NpLqxJuqL566nnDsqMYYRFvQCRZWGmKa0PjzwDHLd8ofUbGVksM
g7OoUEeOgQSfkMW1CnsgB+9IUxhIZ1ciceuV9rBVykdojmJXqsQh4OgV09mzF8K5ga64aPq+gveg
MnG1BSBJgaOiPHlfgHrBb2n61VNHAgsmEluL2Tjr9FQKbvRBHNfIdQJNpk6R5RXDSh8p4EX6rJUt
qWVJuHAmYZkw/zbUVsrPpE59G4uJJqiJnKVcaFm8PJw6esjauiR9VG1rY+g43xbOHlfgaOMCE52w
JvHOnZdxMRwuiv5O/0Y/Ygpkayn5ANuvSDyD8spwTx91kCHx1ec/+6nwFsULtSmEoE7voFzjjhSQ
cbAh184EEl5OHSh7nJSmnAgWlqv1HIqbERonqeVljktFEgcSP2brZd4oW3J2BokgvlarOZUpRyYA
kqVz3edlgVFItziFI4cO6AWPS4k7XyzaWqt6SdYZ9BSu+AQcmCMAEkQwKW6s3uWBhMWfV4McLd1E
qmBFZeyWESpu2brVZqn9ctYxy4PEJ1aIJ/vV8UNHrC0+Hnr7u8IJuZ+jsGI2ZhC1Lllq5/FEdaBY
2pLMbpT5spuIBvXzYXuRt5MgvGblD2G2JN8nZB0ntRhZQZGPycOnQlNDLvzEr/9k4eyjO7QkU9WR
sF33YqAi7mOovys8/PU9Ftr//v/tl8PP/tLtiqZ9KZzQ2rRZGiOaNFU8Z88xCCe1aFmSECntoDKD
I4I4poyYdUzcHINFxMB7h+TyNR1L7LhT5npEgGMnuhTXIh8EvdtwcLedm+mjPJ8MWjKTLZZJEcsH
CnjMtnAkDBh/v3CSHtZOewYImYZjMYZTzumhPDWHP/lfIHpliXMF8clOJvflEcCIKmfkU7NYCZ0Q
s+dP4BsgcGyuMfDIE/+iXCf443zn68+FqoU7C8+NemPDF6VkXR6+deaEuS4Y+LYuDcc6j3Pa9Hi3
b1ljJuFRyYnNSrPg+XFMbyMQJ3es6ZeE+/TJgjWShyQaTfU9iD3VAszy7Ru1pOkpOxeUbBrLHIu1
42xIMKKDykwgkVw486eDX6FGcVCQuUczE+KNg0fhAu0UK4vPs79f1hh7wOkJFg6CUDBixkUZeVoK
JmJlqpQzE3rqmWdNZkTRZSx0mi3LTuoDNg9wuCy3eZRSgAegANHhcOZJAEUFApuWRQrW0wBmnQ+P
dbntLe8KB3c8ZzPcCKn7RO2rVthiRyzDaRySwtc3KnaHepB3ZgClW4pERDH0HDi84e1ZodkD3wEI
U+KwOCbY8TLN8O4gxDmXe9mPuQ+OnUZlfaoePqDDbV4UOhrpLB36T0WnVD9CbpD+iZrQKCsCz+vK
wmYDEV+vRoHDuhex/EoHMDnaa+0tFhd6RsmHoZqSS8q8pdlc+yRK4p3IHKYRQoF2086po4Q7Sxkq
6u4/eFhlCXfWefK86QI8Oxz1ZyM4iGr1r0USZRrVuffxnjMqH7uXtBFEUcHaNCDhlImumnFHpdys
SBgX40a9k/vzjvU+hXb5nXA7KAUjQozF58QYIbmPl9jaP/2hUdbKZUruNDKU/Ga4D3KlkFOVKWL4
sh6Y9Cfez0pqUExWa1HvQVNQrlFIB74jiKv00SbVxVJjSa0FVFgkX961WwApq4zeJeMEYh9isioB
2AEOm0it2D7MiVxAQ+Dh0zt2mfh1y+olaQVxkppAuk6dl/csE/rhAqjMqZovtwJlqXuN2d78+U7d
QbpXoTxueLEmlLDC1wMWcUNwIeV6uAeOnVZuTTnHoN5NaTIFBJYfiGcSXHzPp+HXS5oWGsuHxeb4
ma6CiIJvBQDiBIBYmR7omB4QDDwAgmmyUtm7iVfplTl5RGZFPElzYmmbFzZa4l5v45CsPC1S7OFJ
WT9PiXNOYq0at7Vw5bBibDhh+yePd1r2cGJjqhWHUipF1r5XXjHgA9DIAwpQMXPnxGqaCCDRje+F
U+FeYn2Of7/PlH7sW8S6oyPLwjoVIK5AFQ2LbHu8E3Z6QFyUEtb0KL5IkbpkbRsWWtDZJhWPQpAd
1hLj/7SMRv/Fc2H8tNq5dZW1wap4tTqPWFOgVHSgf7LQeDrBWUdG1INbQRnKDGgstJzLCjNp2qMI
gnMqDFQVIHqU6PnH6SXZN6FLSkrEBZbeDAOn7XJ0KtUaxChYq1JJLsmBq0lU3xX3HS5oml+npTwV
L6J37xOKiwScR+x0cdI47dSSkqBEYlXz+7V7xKKQEse4x9M/enu6Qkf7cn2/rHVFRhFgTYqS2gb9
lojIY3tFQLJuRXs4e/pc6NISHiwf0rCwySxQ+rlGa1Y0WzT0boHzkuYlBjzo+eo0Qbi+bmRCz0u/
lcTaMcBHX6fJYjKcFDc9BSLJWfqFzQz6dFABUJxTwQXARaBrgUqRn59wFgDAtUAjVpjGN26ijAoA
kG5lFscaE5MDCEDQd/GizSD9lyfDiralcleuMytBpQLubtmyOcxbuERpAwQGYssQY66iCIUBkrz8
Fsx9OOVImHUMC1WvV1GOWBRy8otAdBkZ6Qq7n3nCrAYNNTkDDFjvnXsP2dfAYSCfdqps5CiOVfIi
lOKMmWNIHMi504kM734UgEy/1ikBuKwDp7MG3wm52AP3wozjMBhzIcXAJDd4UFcnwEE7z39/l6U3
vJQq95p2y6uwucPWlQmXL1nny8lngtR+yTIOXJXQoCJ4qxXfMiHBv0wZzzTPSo+hleWUsJmgtebF
taGQdFryMxwWlrJK+U5MLUc6NRnQqkR9hdGn+jR5d0JE1iZ6BXEMAqOGFDwU+6X7arB7HNIsm1Vw
l8xfHDrmdCqvrb5DYIz5d0jP0dMrAEIL5QVau6gjnNj1mCnjLZWkZvRSOY0x0BlQFQI4AxKXweyu
BGISLRHVsMDwO8n8DidlWe4FugYgcCUzkHGcAhGIcA04EJSt6EQsfEOijClC9UxZx8YIl4n0uVDW
OyLvYf32LbdsCk98+9HQp4nzinQYEEmhcHIDaG6/ZZ3F2pDVD2pcmMQJsY9kQH8zUUbbaf7oqbhD
Pah0TAvBXzhviah8MffkzNRntXpCQgmn0qfs+S4CATj0FdwzTASausz2poEIoAEAuB4jU7dw6HWy
9b3cK168PBb2HTseSvRgXZRxAIErAXRhZfulIGtqrAr/+T/9rvQcteF//5WPGWhYeLmUrtLN26Lc
tOscB9tixKCHfGDDBhoLqAfrjkqWMVx4ApeA0o+1UOBU+keOqZNJnFnWauLM8ROnBGBai0TgsWZ5
a0DsgssgsI5Z7KaN68ILL2mtE3VyU6yqY2ARqBMAlkgk4zqUk3SqBs0gp06fTIAILkllkn+m6UUA
kxhQ7Ifoo3tgSilKGQmEJsoaNTtrxZ38UNglzm2pst7XpqZFnIJ6+xQaL0cDW8YhbYjBYgl/Lghs
cXJK0yZyGj3JgsVN4baV8DwKq5FOB8JrGGppUfJhvU8nlOFOB8RNjvYTRKn3mc6knjuFOjyHQMSo
uIwP/dR7wsqVq8Nnv/AXofvQ/nA+tZQRK4PpdFwTRpDvbPlFWWX0rCEA1yk/eim8+97bwvt+/ufD
//qTEB7/3iPhjNzNJdhblWESRysEfmgsuX+/Lt7ikn/HtvvC+z/wAYs7ObHrRQvZx1QNNUhXgIMs
YoxxIypDDDUFrn4H7vFyEgkNsiYifrPYNxyJDWT9Hk/EXDlXXK+S46TLDtO0noOSdVcqolkcyWKB
+YqVK8Krh46Le0qc41pknUyU03Jx1ySQeLbuNlM1fdR1IDRlJvNoEvXJys4BLOrzvI7JMt1jhlgu
tbQkeb6cyoJLrfSNTDROY0qEjV9R1ykvmdoaiAAGrhy9FoD4pc5t+LFvvbxED+uUvpEAOgDERRm2
DiRcg4YaRec6OeKQn5IwZvcX4WURWZlb1GD1KspP+NcIfBJlHwUFQGHG56GCxPRmBrX6H2gNWfSt
mBmAgbVOv/PIN4T0EjFSjqGtvSMAHPzDwTQIYJqWtNjaH3AnzIZ0sOXLWsJLu/Yp18OLNrMx4KoE
Erg6N6gOlERjavBJRDKWWyw8gAUXc0EikDu5uZxeDDysoczH6MBQOHxGij2tCQtdtlVx+zW75eVN
oNlRnRPqEWOQV7ADncN1Iig7UVySgvOcQjiXSC/i3QhZvU/As2PnbrOeXFRdCFBk9j2h6OqZCF1S
qh6xKlHfK1wCC96h58YaQZtuuzVslTfysML+9589rYlGkbXw8eozRsZVSFzSQlpMCYVFvrS/sl0L
dOV7FbclU2tzY7hpfXtYK+/N7z57yLgaOBvEi968rGoZC5BNMBLV6qQrqlU+2eUdyyzO5SvKwfHe
DW3h4e+8KCC8EuZXaSGv2vnmWdqr5+16LAcS1thDrAEsmiua1E+k/BSQCHWS+9fnHNzwZVWEcuhC
lHUL/YblGpFvlPleDWkiUqY+QLBLhgP0OCxx0iCt6Zi4Eeq7c5dZHg0wNAGlfawgZ9q3ZD4YA3op
+PB5MGAMFDGAZK4sHLKMB+szQwBKIgIlx/HnVdO5g0BcKd4vdp6ybHlPN/Le6QKAABx4p/LvRLIU
EsMwMJ94/LvhE5/8fHjqhZftdN28cnM/ZkkIj/L16wANwIEZn+UhYnJAQGfhFhlHbDiMLetXGecB
gEA4IDFTwkkAHhDX8rJZI4XFgwCUtWtWWrIgsmbtO9xp9fryJts4AABAAElEQVR6ztu2Rf4LNQJi
OA6fwdGqJ8FRw5Zrg4roZAhTfz1U0IfIC5VcqdCgltckQ9hgXroZ+XmM904oLuaS9EFaMa4+4cio
NycnJyplLRtUJ5dxPBxLTaKcgwbxe1FCKKJ4iWc6Kk4HMZN/FMs2I+tZABb+Tzn/AIwPMvQAAMjw
YKK0tUjT1HcBL817ZCU4c3SPFA+joaNJzzjXF972ljuNG7UbEdCaWVlbCB8I94PgeN3KtvDQW9+q
xDsnw5AWjprfjIVEbvxLmi13CWDtli/qQ27RS440v0ivgHUEOiTF+dLmhXrfKpeIu35tu5Xzwffi
xxGF7CTniGxHRyPOC98RdH318uJsqM6J69B/KsIYQ5yKMFwIR2IAon04FFYb5N4Rc9bdtLXAbXn0
ca24sgRwpnQy3rdnYMKTCRSgSf/p9zmx1iTqZoGvmOBEskSZl6cpgBQMq2ehfwDI/7PXFUAk1n84
IMTgEO9nG4mP4UDgZl49fq4gwvj5vBRwToAJXnXf/PY3w2c/83nl5NwfDsrkigfr2x66LzzwlgfC
1i1brTqD8yrSg2pZusQUTXYOLkTEbI/o0Cs53v0cVskrEMABJHa9utdYQsy31CV3A0pP4zzEoUBo
1JkFMMm+7aGH7GVi0cGFHS6JWRNxpqOt3bYFE5wGL1p2iDLq8g+gQKz43taWasnT+6U85kKcM6E8
pqx/CA5F46flzi6xYkTiIDQxJxm8iDPQAlkQvDPgOemEMxhrvTi7ygzDzIi/A4QvBgOlKCGWpORm
Tw5h+0kBMI1U12ZNzf7tEpVIQQAN9/cqyZSejZaqaGqcLwfDxALi98h6Nt42+06It9RnQBw9tC+0
tnWEDUs322nagFBscy0DLjbz2jNmdpZyedGCWiX5aQqnjp0wGf+mzbfatdkPAzD8KlLQZWuAKrDi
95Kno09c6Kj2a2V9gQNyoKAtgCMmjq0McNE/cWhYd7Dy4JlNKAZxOwYu6fW9l5K+7+L5jAASf1G6
TwhHvGSsg4QDRbz1fS61fa1keHlMQMOKhvqPz2e/Sj97ihw8pkqSPS8HHHzf6xQr239CmbajxCQu
vrjiCQ4EAHnyyR+Ex7//tCkv+6VsJBwbcPn5j/6rMFdh4ETtmnOaOgQh2jEhzuDT4WIB52Df8Fic
RgIbFJkooaa6fwjfV3JhZy/xDXCugWsBFAiu44VnnrZ997LkALkbckWjc0P4Vzh5GccACVwNEhbK
WI5zAqk0f3TB1EtHd0BxMLGy4TPerG0T9lSJd+SSXSqWeMAWklLelb58GLhwXGIM8R/z9XsTcOEi
PFIhZrqe82dtn4/JoT71EUyRKMJVP8UBBgxgoizHCacBeKRghX7DBjnHKaig2ypTXWhYi2gz4CmD
mP2PyzFrVA5TA5oQLgqgVq/bFM4pJ+tOLaXpjl3ums81mPV7iWJFKSmCWySNYtfhrlCqrnBJK/at
VFzNzQ/eFR7+0t8ah8dzNdJ98T5jqwzPk/6BZ2e3XNsXt5TJinUq9AsEHnjgreHZZ54P33rsJRt0
eJ06YYk5myo1nONysYvlOivk49QgBzPSOcpZx6KkxyxdBYaT8xYhDZcTE0CCeJP0OYG1fiMBeqzD
g4/IJYmVXAvIkH5gJuL38HRi0T6u62EFRGkzUUxoJYU5GlcxxeCARQZFuxPHydOXO4IeydRT8RrJ
tgDzWXDwYzgLiK2XJZcmn3EZdXA0IkfIbATL/+df/EJ4+B+/qdlJiV/Ug9EpQL3q4OO9ZwxADh3Z
qwec/qjUXZsHhqLNPRM5nqZQUr918YWHTF0Uqa4X8fsCsO65c3tiMhNooO0GVBxAqMexLfuYXuSd
1PwU0sHj7dlWMy4cCv9QbH6Eq0ERi0jj5B62fuxbBxA/PiU9noszXsZ25arFYfLcEZsR0XeE0Qvh
VHfS6crk28JSB8i0NVoAzGmxTNus68Kqd9Dl8VRpq2txTCpGBgYRYFgdB5T0AkAF56th0EiEV6oT
/hskb/6HRx6ThUEWOJnka5a0K2fumvCD7z9rvhJed7ZtlYDh7x77jpbuPG3mRwZhU8vSMNkvfcOU
DjBpQn0RsTcWZ5hwcFJ75unnbBG0cYlflRKzylo6TDSCQwNkYoIbcTAslKd9Ej1PT6+SOCsfCwt3
4ycCIaogjiBmsdqgU5lCS/iHnCtxIGluqjZxCr1aW/tSv2RmjjCtYf1f+2x93xXRjBF0LKw3VKJE
2DEBKPzHNF5w6UhKAZT4P64b70/jROIT7McA4ucoy+sh+jkvZ3tFGurjnerxIleg5pSdDIILgQM5
rSzaT3znEVOW/eovfzSckcLuEXWue+/abuIMXEOv1PxXpPne/+ohUxTWq41R9ck6zRDms8BaLTEh
A4pVBTxg4bC7l5bJVCxtNhGIecVMkJZ/VGu+EqdgUbqqj2UFsQMF3GSa/xK2EVbY83uQdkATjl1D
ACNA4hwIt+CxOexLRLZ1b4kV4Xq2Tlyza+cOsa/SP6gQUHN227kPr5s9thypflJbZNyh89IfCKvX
rVsfLr6yS4skDYTcisUCCM2uUk4TAwX8wmlA6DtQFs5Xt+hWJydepkSOZurydj7+cLfyOXqW43rX
6Dac47B6DiDFgDRuSPvOfgMyR090aUbba9YZqr348kuhZ0iiZDoo40tLFSAIaGBRgjDLQphkLzwl
E7de9vpDpwSgF8O3DmuyiYj2tPijDaqRicS6xGnTKei3YFJlFUV8WSZzC0KzzL0AHMtM8C2TA+eU
T61J/bkkcWeXiIH44qKMcyK0ybPqPodZvzd0LG0S10YpQKIocYks+UygY4lExrJyOa1pW6X3MSy9
oXqXOaFt3LRVz6fMPJTHl3VYKktrbIYPREWbTNPE2jZ5ql+Pajw4kMB5ug4tbgaOBE5jVImcK5Qn
FwDhOJ+6+WcDNONrs/uzgohXdtBw4PAt6QudRgQSiDFYY0Ka+t6zTFMH2ZzFjU08kB3+t3/r38kv
ZFH4+B/9T3PeWiL9AoM6zGlRnoWGsPOl540TQPMNYUrDm7FTEb+FBcDtDGxWaqnRA0SRhK4CGj5y
QKnd8rJkVIdlKzqsrFmcz6mjnWHP8RMyq43KCafdAq3mzW9WcuFz0pucMxGKiOHGBUrVqDQE0MED
nZYv1LmRVuWRgO09oWzgECCxtqPd6jfI4++iEgyTzoAFmrhvllDAZdrdwY91nTMxDi4sy3lkQYT2
0YnE3Agh5yQZWn8uhLs2bQ5PCUhqZEmAjsq5b0X7SbH4l6c4DTuTfCySabHqygI7mKckRUZax0Ta
Zdu1+JRoYMPGY1UycLkGgOQ0UaBghRBJnCYE5jJZ2ERh71yITO4OBxATj7yytol+RhyqOAFnqRnI
cIGlEpPI9r/zpVfsCrgQ9zdBDMsDbnCVbsWI2nXOtkIi3OHTveHUF/4iaQM9kn4/34e/TC3Ka/0j
kMGhlc0V6DMzRxMDF8KluFjTIitihfKyYOlCJBmrSk0b9g1THwAIVJFyrOyjBwFwcunCLy1SGrNO
sa3jG3F11I0JkQXmBmc8Yslcd+J10LGwUiQAwSt17gPggHzLeSdy/uiMPK+T/gCgkJFwJmAxEIlF
Em+ILeBxLQI8oCPdWiwIMSYy5xa7lsHGrIJC1VLRybSFyPC5L3zJ3Nfv37Yl9HSfMitBA3k4FNCF
K7ErZfHjiImZzhMLw4WsWNYePvKh94dHpcsg7Lpfa6y896E7w30PPFS4DD0OC19Bv/iRnw3VZeNh
cCzB028//mx45NuPhf/34/8ltC5tCSMarLUyPXcNTIbf+73/ZHI5CaRv08JFZE7/1qPP2exIZvrf
/4+/qTU9SrX8grwaBYTH5FH6+//1v4Tf+LV/W2irUoDSM5APv/Obvx2eeXln4Z5m2yHRcgwg1B3U
b5iUEvcb+o536XiLOKxT2rLc5qOPPxl2ClwudR8L97QOGedSf6VfepFBZTmfDDfdfXdYsbZDnV3B
cBroZDhjwfRBKR0ZFC4ZMPBjnZOBi2Z4i5hNFa/Zwc+zyZIPcBMLdB7Rhn84nPh1lkm3Y3oR3atF
uKoO4kWp+ou3QdsOJkAV/Sk+5xwTZZXS8SAywvFlgdkjXtk6l+P3nehEkn5tZbrPeeUjWoReoCLd
AmRciUBNSgv7DbgjdJ2dF1Z2rBX7Jdi7knCAVjn9wBfHuRCKzp0+pmeZPG30H+S5xQmOaYvYljZN
hldGvlvgKpyrS5uzDVbFBomoy7X+DUrYMeUXgaNirR8o5kIcMOzEDB8AiINHtoqnNs2WJ1CTLU2P
4Tic68hWcS6ELWLMqTTQy/1BsvWxusCZ3HHH7fagMCV2KgUeiisn3HuxqOzeLTOgKK+FvCvl4lih
l2dbscROPFD+zVtRhSYTSoy5acsWUx5ha7/lplVhVceCcNOqJbI+nC/8XxJI5bWUJEosykfkc8D2
yiUCxy5K6daimbw9jF1WjI2UXbzs1qYGy0APe027a9dskj6nJbzjLbdbzkw07JUyvw5ePhWGe2Qi
1TKNHW1NchZaWwAQ2uqSsrh16XzL2Znt2P7bstvB3JROg3MoyiAUmPgRHJRCliUoW/vHQ1tJolvC
m/P8yYNWj/qX8NYV1chis1ys8mFxSVhnGuqTtnFUI9M5hBjj5JYJL8PT1weq1ym2RbF6mcVLUu9P
vx4AYCCaiKQLfbtYz9K/n/bI/uUD1rwyJR4WIwcQ1zWxrhFgx33DNfjCZfG1sd4qLvd7jQeeiy6A
GoAJEKILYR83BPst+j1k1zt34bKc3MSt6B5IGofyNEsAyUyEj09390VbAwi/LRJHodMoRg4o+Dyt
kaXp/9YE9guaPFe1t4W33LM5bFzVblw5C67novWBi7V1rbKZwMOvS6ZfP9IW0Ig5EBdlqOLAEVVX
Lta81n85ajoPB5DYF8TrehlZlxqbFofhSxdtQeWdx89qCcBcuPeOuxS/0W9a/bnVctDqPGUOQYIK
b8LMX8q3Nw08/KSzridOnQ0nj+0LdXKfh+65dUNYuHih7Q+nHpe4AJP8eHV7s5X7hzvWcNx9plOz
XMLqX5QiuF5pGiU4SvGqmBpxR/sPvGJsK3WR35l5AI6UG5WJWVYiZHpp7PtVzowJYQ0YOtelDjZs
8T2UuW6EfSgWbwAaLUGUnEg/iZFhJrToZrw6BSQ7S0rDMp2HI7momIwLI0fCwLDmtO2tdlVt4yJx
IhIL57eEbXK3/tKndocF3QKLtha1M2jAjtUCYqBreNs+gOFAMr+hRmb3m6z82aees+Q6sL0Q9wMh
WpBU6pJUEfOUKjyBLm/TqhT9YH0hY7BTUYhKDNhRzAJuMip6ZVoorrlZ6woz2Icl77teB6dDt4LN
dLlzJZxvXVQlk3zSd85qeQ0sTiiMURTnJRrg3g+X6VYT48404J0jwzDQtEC/JfXlGZbimry2MSG2
JLqRuQnQaMxBOYlLWGUGxOESaRsT+jX0gQ4evk/0M1HUew+dDnfcf1/o7joa9u1+IWzbuCSMyMjB
Iu3zSqbYQzgeW+c6bvwN7l8FIt6ecyC+9fJ4WyLTXeepo6HzjGA31YPE52faB1AuiuOgswIgbcuX
m1t1iXwVcC670NVpD/6Khk/CPCYtIZvi20HnYgZgRqANlJs+IyFnL5mvmUFmWIBk05ZtMr8pCG/w
uKKe20xs6Ty9Uw4+t0oXs8i4kErFcsCNsKATGnW064MDfXKfVm4JiQ2IP2e1HEKv/BuQpZlxzCMx
/YEkr8Ercc6cJEDOf/eZY8fshTmAUJ5Xhnx8HC6LW7keAlBwW8ZTFbKUh9oiKxOYiNqQfCvfFmex
VSu2bTl+IbxlyaLw/jseCM+dOmm+GINaSQ5ihkXRnWtbF9ZvXRkmlbzIyq2TywQa94ZIaYreolqD
ecvG1YW0e8O9Z03/c+CYdDt6HwwskvbMRNRJwCmtQfuuX1FRvUyk+FxADNgR5eMIs5g3rWL0AdeB
/ooBP5LTd8ksy8DOaXan1RiY/TI4Eqxybk2jnOzs7RKJoa6eg6bDsgMN9Gq9e6J412rJzV5F6Z5Q
0CZJpxywEM87lq+Qrq3HvFiZQFA1eAZM8xGxxpIPgCRXAWci6xIbwERj4LR0c3C5l5X4OSYAxAwL
aSH7ePBuv31TOHt0Z+hatDC87Z3vDxfEaZcIABFt6cuxviNuL7s/kxiTrZc9LnSbGCx8vxjn4Q0A
IMyqWGM8LoZzznF4vWJbFKzkEDHWOO1IOJSh5Yb65MTD6vEQjjxOyMywkLjKW7JbsY3MCCMTevhq
B+9ClHkEMUHI+c2t7bY/LD+yBQ3Nihm5Yg/2ti2rwvwlelH9C+RuD+q3hL3HnrUZ4pZ1C8MLzz9t
a9Tesf1eAVxTOKcV3lCYdgjw6CzlqWeixUfo627ftCoc3nMoPPP8C2HjmrVhjRyYzmrd13aJDtC3
v/63ygNRJ6/NW83HATbTlWAKbzIzt1XUh8vxfsy2WgAYci1WtLytN2ybPBSaJD7tl4MXM7+RlNCn
V9cqhWIy83z4534u5KQw/ru/+sswt3rcBgRWsjH5kixUBvNhDQbAEzMvfgTeye29XBk03Qgz7bjA
Gh3QxvXrNMCTLlM1PlcLTG8TEJ8Ozz39rH39pGKCihEAci1aIEAkxmpkqFfvR/1IYFCidwnwOJd5
FRBlGs1rlq2pVbZ3WaQswFJAgoMf7u4osGNy8IgBhPPkUi2rWRiOa/2YRQvrLUkW/Q7ODKV4ldZo
YkmIHXLbB0SI9IYLW7eyLXz0X39MgXMDFo+DF+sxXOH1KmJwdhNv1mrj92a+IeIMuzQZQlf0ft3f
w7kPKze2TUp0LR87LGvcAt3j/l3PaWGy1nD/W98t7ms4dH/zW4V4Kq4hvamMYeZ/AjeSBY3Z9CFc
PxPNqhOZ6SIAZFhmsh37j09zKrteADmLQkmEPqRBA6FSsxL+BQACogErn+NkliVeMOTZsv08nYtc
HW4N6Ne1dIAK5SwZvXxBytVDWlHtonJrnLdLFi9UomUNnguaTTlP+eV+eUMq+Q8vl5iB5pKEncQh
CpDp0pKKWIiY/SEysGHjr5LLOR6PdVh3zp83v4CzsopUyHWeoKWVK5YbAHV0rDHxBzMj6w4DSGZy
tNYS4Ij9RnwfkzRUtnBbqOnosH+C6jYp9gX/CHQPWEN4Breu2hJKV7WG8ZZVoe3mdeHw4eNyz1au
VXEgsLzMdJcEbJ//1KdC9/j5AsCS4cyJyFZP5+hlzOjogFirBqU3OSfy1QkwrFVgIlyRKUJ1Ae8x
r4zvxv7rGUCu9zDOg0nD/+1s8lGukTZ/vtIfCjyc8oQfoIMRxaZ0Px9v+f1wsu4VG5/z58z7cgI8
aDP7D4ghTu/a2xm6LyqbmQGIrCdpLBHXf/Gvvhp2vPy8NQUXQhzWb3zsX4Zj+3eH//7fP2H9l5ME
2F2RKd0p1pG4bgRQAbxjoIGhgxupaVgQtt+6WXlwGkyMcVHG22Pb1dMdfvBUci8sXY76YfGS9rB8
9bpw2+232rsHLBwwMP3zn+RLpo9P/XudpH0vT45m+yyACF8O5xH/+4WABsTW93Eqg2Nwgk3GgjLT
P/VQkDLbEOiFKa1J7Bdeknnls+DlYY4yzbg6OybS2Ou1St+NeEEnh2AjAR2Ag3/kb5dT62SahUOA
AAuoR2vRIpZU6nrcpjkuESxzHu9HKKekLLCYdYuWhxJZPpqXLdeKbhvD3LLEHIpyl45qpHsktwOD
iTotS8VxKGtU7YKlYeOmLUorsEi+BpVh+aq1Vp39tes2hMUr18qkrMAyzdp4YXoHTxpNwMRTHgAk
+Lw4lYw1hMvH+8OcJw6HsXtuDcvWtNpgJcIWWrZ1ebh7+/ZQ2lguncxlKZmVwU1p/lr39IeNAyVh
+6a2sCzVAy2TLgQAPa8FpzG/44zU3L7VrD6WZCniAGmbOJUS5flADMsP94cNq1dpmQaF9JOjNdUf
8n6cELGYHIqSyt20G59fnmZGg6MAhPx6npOLq4BFsX/aAYDa2xaYMjsnJ0O4KAjwiJ3OKItByXUi
WJZoY75yky6T+0G/rHvcC2RgoncOoYs6Ix8T+tsdsib+kw+8Jzz7wovhs5/+rJmtiVHCXaBc5l4I
p0WnGDy8zLcOJHAjpFJEL/KBf/LzoaOjPZkEpKQe1aCPRRq4lBe1DOoX//or4e8fld/TcKk5GfZ3
nwv79+0x8y4hLXFYi3/f1VsSW8PiJBOonka0jxm9eDvGm9KRAQdS0Dv5sYOG6wc4DxfiTmWF+pEZ
1st86yZa5D7vcK71Rs/BQwfp8aNghiakHFABcDTKrJkJKTQhTJs5uHWx25ADB/sAjHF5AsST8gHA
+uL6DpSHk4rsdHO2x5QAJvKTVci71Fp6gDXVcw0QzvX0huWLKsOqmzaEYSlJc0pRQMysdSr5o8iH
R7oRcSN6giyJiDWHID1EvOXr1iUseDp1tK9dJ6XmQdVZFnL1jQK9qcGW9aTldyiqhY2JO/iYYPbE
KiTeRmsll4bLC0rCbe+8P/zF179l9RAF+e2kUVi1pt0WHLr06tOhd3FNaFu5LRzfqFwQz8ri9fTZ
cEB5atfKr6Ri3gIptl/Q9WVhocLvK8qalK1rdcj9/d8JoFWqDgOYwJWg6/z6N74R7rnrTv0OAZtE
zZu23h5ePXAoPPE9JWSKZni77yhNADO+S1t2s3yIEylwJzpkvzLXEDZs2hoOHTkSXtl9QCKNbgIb
rog2zPtXfcUp1jN5GVzZqhXrQ+viVWGX2oDwb8Fy48GYiDEQuq6YknSLAj31nRoNXky1r+w6EOok
TiBeQQUlqybAibGusGL9lrBCOT5+8MjfaLGu80klfeKkBjVI7CbXKUTfp6/E3IiLNmxRwJqLP0Cl
e0B5jy5j05ZNFvF87NhxewbkQ0kfS8ELGxeHV45qstQ/KSm3rltmOkGc6Zi4nFi5AUqSsXvp1Jbn
LO+QqYICmDioRKeiXWv1tKI2GzXzVkkRyUztDxgA4RjyMvafU1o34xKKOJU1L5yvBZ7nhiv9ycOj
vvt4sM/LTJyuRsNAzzlD+CVKIjyodUoAEMvPIHFkWGiM8ipfpsEjLkcZZjUD0UICHCYrS1aHrBPq
RXsAGQlzH7znPrL+22BJfECUSV6/EW4EQqmaV8g3VCrFKhS7/W7ZcrOVASAsUIyNvT6NhER8WLG8
Q+KPVoxT5ik6/jZZLdralofR5uSeRmSrRys+qm2Tlge4ZdMaybaCB/k+kKzJXaRjPwz7wvSD1e9y
Evcq6hpDndY+xmxcv7TWzHUL79keymW2w7v3po1rwlqJU4tqNEPLu5ZZ9/YHHgzflpYeTqv/9DfC
2fxYOLO8OZSfnwgL6nrDytvajQt5fseh8Nb7ttg31i/pELjJNIp1QyEBMQECO3crz6zw9iMfep95
72LtudC3J5w5f9H0FoX68jUJaYgCol9Ty2KL9i2cL7IDZwE1NknXlXJACQegWBRxFHB8JEYqhBEY
R6D+IEA1y1HK8cDR5uqbw76jO6w9uFPMzNQjKJNF1gm2ZCDGZLliNXBjqm1QVj0piwGmulQPZOfT
ekvbVoXF87SaYNcLmkw018mLuK11kQwNskdhrVM90h6gW7kkUVr6TZtAEw4ZhWcyoOPvJChP2pvC
RHu2J5kouZeYsgpWJiLXm5yRuMp/rmQirNm0wbgZgJ9E7PwnNP33u36IcwCJkwOuH8+0LfySiz19
xtaTEi1XRU6GqcbiiwmNJ/wZctd29mOgaCjpCVMQwtkpgrtAPnf9RlCnK9cMU5sOLLlVGaufwy+A
Dpkk9rMGpgaeZjd1PH/tCWssPU0q3uBrgrNOk6Jn3brSolXel0jkwPRaXrFRuSqEMGJbqmtLpTht
sfZ5BsPyZ7mkgV6rDlSiAdkr3QfJfWAxV65comjjw6aDqK+pVmaq2xJ2Xr7OJAHi+yr0O3A2G5YY
AfsPASiUj6oTd3aeMb+a1vZV+p1aEDvpJwUlK1whnYRn1L6sSR25RhzZedPrzDuWzAg3332/eeJ+
8CffpoEhp63eA+GDP/U26XbOhdMnOkPrhrvC0rW3KpeEnLoEziMD4kKUS/xKsywL4oZWblgVvvHw
IzZbza+fmmUujMazkN26WR4k+Gk5kZwpEh9+5Ilwx+1DtlYQDoPmiaq50SOJk6umPt0PKFZusr9I
1pheTTaL9fxRss/Rj76o0Xj08D7NwNXWgFtpKiW6um5kqmU9o7QdyhAxIBSb44MXzX8GAMA8PCad
jjqHHkFV0Fg2Qs8TtwnHhX7D0iXIKsLi9PjgEKk7pizvHlzIshWLGuQufumCWb4Wty0OV57eKxf2
cvX5hEcgq1u9RGoIBfQJpWGQ5dgAHm4Dj1b1vGlAQn6TSwqmdMLPqVKT3GkBwrHDr8oh0Ht7UoM+
Qom5vgtEIPZle7N9zsHlm6eq9h1I7GTmIwaO+BTlMcDE5+L9gk4Ed1iiLElneLp7QN5viiOQWc9l
US4ya0xXoigCQFCkums7IguEE9m5PuxVxYlM2UYCCEQkzKX6pYWZWfrvwj4sfDYNgCtPaYOO4P9J
oyrTTMqL/8KXHzYAiUU0AKRKyrr5CoYDJPk90BCDXOU8cJZTYB8HnUq2AhLWPR1XZCYaeae9B46E
L//NV2wlP8qoV6qBz3+troNY87a7X0pPHVNOmxOyHA1pBb3uNGMY9XCUAzyIDWpWx12pdU2wAsGx
kSqv/0oy0MvD+VA2b4nNOmf3/SA05C4rF3CZ/XMOhzmnDbfeEXYd7JFodoulTqQcBd7am7aFHkUS
P/vky2HlUqVHFBc2UbowlAjgYkKUiYkZnf+nn305fPJ/fjr8+Zf/1oLPvA76CxMZUi6kYDFKK2Ad
YdDzX1YtjkNu9lU10ilJCQvHUpoCLhxItdYVcqJduJFrEW0AOtBAlIEN5Syimfu6FGuHe0pSYSYQ
MynHkoG8VtBTOQQYcV/N4tbue/Ahy9tyWQmfWlubdd/1YeOd67WanXyfpEjH3P++d70jtLc0hqVy
7INYroN0h+hGyNsCxwEn4voRq6QP/El4R1hOcIOHkz164GBBNLN6CvKEYr2IFegjFo0BGRwLmfyg
KS7EDq/7YyaAiRswEHF/ej/BgOm/1BdOnzxj/hIOJC+/eqCg7JzJEgOYZP+9XUQgOhcOT7lqxZdo
IPHy6Xx+jdflPHoST3BDOYpNclk6+1uoK8UqOgEAJrbcoLtBJEN8QBcCaAwolgbQgEMhXyT/1Lsg
RRYgimK1XuIH3AP/RHk2NChr+tmLYceuXYW4EEQasygxOHRftDMp0MOdG8CoVHDV2YuXzZLBfdIW
L3mBgATqPLTfANrAo65KIk+TLatI9i/SFJLRLSYc5a4obWDlwnItBbFTKQ+65RFbWfhnRbyO5Qu1
lEEimvWdOKQ1a04JLJ6T4vdWa+qmNUsMPF/49qt2vGBRq4l7HIyk65fYiSIfDDL/B0zcguOeqFdd
oknC84s4eGTr1CkP6RzpZkisBPHsIBy1cjoXE34f/k853w83w7UOWDW14i60wh1eo5CDigFiKvJQ
zsQD+W9gn3uEOlasDXV6R3NHe/RslKlOoO7UMK8iHNjzSugf6zbAeOq5nXZq2wM/ZWCCSPOTP/HO
MKicwrz7MU0sQ3PHk4RQ4gg96xzcyKUBFLMT04DEFbH4Kt1z7wNhibbnz3crkFS/Pc0RwxdmAaRC
HC3kpnA70AdJkrLEWHizaXpPzbQ+KrnuXI8Sm0hGZuGpfrHoOJV5ZC7Vsbggx8biTKYZAwjOj15O
Zn64i0TRlXAlzs3QVl4y65US6U2k2B6WyW9AsnBDrTgFnQNoYCcx4ULoQLDulIhNzQsU5pXJie2y
5GRxI3MVdOTUIKvPyLgc0AQiNfL27NESCS6yAQS47ZdP9yxX8NOI0kP0msL0kJRmh2V2dvJO68ds
eVbE2aADGRGInOo8YRp6FgsaUScgyzoczpDiUeiIEKkX6dDokbzDI0sDnm5a7Bsp1cyt4L0l8tFo
vyv0ndwfDu9+Omy8KRl41lD8UZMMvjO9V8KB3bvChd2HwoZ7typjuEBKSke8b/eee8U8dnFoej3E
oIwHYNE2xJHU1Iu7E9gm87HU1xJfxgalQBDVa3kKLRShIDT1ISl2l9UVmOKCTqVMMShVptwTdypR
VU1pFp9i+WkHS8rFc9KFCHQI1sxrkOCHBGEhUmxAwsnQf+hf8odBjPH7ZysthIEIHE+zAitJ02kc
Q9pGfuiMrHJzw74D+40zBG8WyjsWz2EI50FCCO7YfFN49MmntaJcVdh880Y7505k1QI33gxcxsi4
uAONB/Qjw6PJoCbEQ6YNu4YPkiQXW60vCyDUpSwLIJSbfpEdEWJJpRJBOQEm9Ps3g2YEEWZlD9gB
QI53Kt4k8koFFBjUTr7PYHdyJRnHnLeFqwQgcCC5SokI0nwvamn26ra1enqY8jwwL0asNOSvrKxa
rIeuGUP/zNQQrD5a7IQSFKjVwtLm9KSZsPPkqbBF8r8TDw7xAv2s63xMpJIlhqvLZZff/chjynHx
XNi4uk15NPvCE489aWHiZ+Qvskwu+w4gsOFQ1dwJM3U/9u3vhJvViaAdzz2jtVL/Qb+5Onz/iafC
2+/bauXHjx0Njz2zy9jTZR1tyUyqQREDCODhPgnuM3Hfu342LN98uxyI+sIz3/2actLeGerEWhOn
ExO+LvkjJCTaKQ38YFirWKRWAUXnkR3hLakCdc+efaF24TJjl5npRiZ7FICowaWGFlSM2r2MKoEv
JnQGVbFu5gMw/m50Ii568kyTSUIstjgosq8xGcyRWDBHv5fBxPMDACYVbAcNSA+RvEE7VK8nyTTP
OPHUTcRY9nWnWOYExue7ukwXgqsAhIOXphPb949GPU8EcOslAnQjXZ/q6PXSledc92vmZE0+AMU9
d90RRhl06i+NErXRt+BJDXeIASBJWKM1mCoXht0HTkuhjhhVGZ777g8C68uQdQ6x/maJL6MyDqBP
4bpq5Xe5rP6ac7yUWGM6EgFJDt9jmYThRs7IdX7/ESlHa5eZaFYwh0uUQXHOUp8xcJhiNY1YJiCP
nDjo1MrrknHCb47FkmLcyBsBFQORwS6tgNdcq8WLUERNJ8CEBxIDiNcw7kPyfEwARwwk8TncmgGF
oM5BR1vZtrnAesb1fB+OB4sN7uakGEBsgMxxSls6IzktC2yijityesnqIZVzc1JiHleW9qVyYLss
hZMW0DrYGXa/ciC85d47NWu12wCqLJ1vzl/Pvqys4dLX4Db//ac00wtE8Jl5/MlnLOdofWNjwjoL
NBKaSAeKHK+s7SMCmYXyC1mn9nZbToqapjXSLyk3hVzo8SN54vHHwrMv7giVdfNtEJXwLGIyq4P8
G1IHJ2Tyt73vPWH7W9+hUSat+/4d4f6H3htyrYn/QU3lSru6RBxOvuyyUgHMMTPvpPQcQ1f2hTJ5
1g5qxn/X2x4wseWZF18Ke1/abx193eqOsFCrtvVoDRqsV2gDYsWq6yHc14LjeF3h+LYxt7pPhwOI
K90BWaw6cAWKF7ZtTmsa1Yv7gFy3hlnV0zp62yYOiTNTLeMuLfOajsj3MZBXcJrYdUsVkD5H91sC
zNBjNNWXK4+M+gIKVgEES1BA5eJMp0iWDQGbAxHgBfcI4Y4AGALyrhfBT8iBpG6wxMIH9u44HF54
9amAxeqeW+4Jz7zwgnGXlyQiJik6lYM4BRL4Dvor/RYdCUDlnsLuxWpZ++VzNFc+QoPDqQ5RAEKw
qVlM5C+Sl4HCuQ/f2k2nHw2LWjRJaSFwKanR8RQDDqo6eGS5Ei+P25xp30DkewrjX6ZU/M1iP0nQ
4gSAHDtzxgZwDhdz6TRi0SPhNAi3xmlL6QfFbQAsxsKljTiHAosJgIDo+fEzNqNfEMLTXjHQsTIB
FCwZwWoJN6KXL/TOaYnFmDw5bvOSZbJW9FlINUt4Qjv37AlrVqzQql5aB0SKYGJqXty50+TN4ZE5
oV+r0HcphQGDm1mJf0ALsaRxIeJGYglikDCjNihTeJZwhOsZ6QsHZOoFRLbffptMonvDsVNdGlzN
4ZLEwXZ1llh8oC3AcExJiyHX/sNdwQ6ThPmnP/KRsOmuB8OlM0dDz4GdoaFVka5io/NKtoSrM+ZK
2iCxdMnYPIGZ9BACzzL9hjr5o0D4veATgtv+4YMHNN+Jt5BYulqu+RMTApk0BcKEZucr+QEbLFzn
nAj7EMeQ6Rdsb0qn4Doz022pc6MQb9B7TYZsUpnBt2hhMiHoISdci+oZx6K6+LhMI4lDiDNjV+QV
nNrhFomrunvb5vC1x59R3M85q441pV6ga89Bikk5iVs5Ax+9FWJOiTgIuLu8RF+8dx9661ttgjl4
SKv2yQeHpSK8ruevie+F4EApbIxzxmeEd7S0Y7lFQz/6xPe0QujBQI4WkgohojDxNWnSIDkU4qlx
l3Ji83cct+37saKVfZSsAABjziwzAg43uZLqE8Jfx8zcqaXJOWWAvGOZ1mtKnaEaU8D27/JtDCy+
nwUT6l4LUAxE5sn1vE/a4J6jZ8PZRnV42fYxcfVeljdilPbNvVIBBhdVfGtfpojCJLuC36aYz1Ts
ASzQbjMEmSnI8M45wCKXLm02PDQ9gI1WEmUqAXKAkLgRgRksoBFbWMKU+i6oY9k5BUUppJ/QhbaW
+rBAA3+475T8KZZbzd37lDFN9+A+I8dlrcDvhJZgbfGoRam8ZdstYctN68Ohg8dsxoMlH9J9O/Bh
6jb9kECE+2CQHlu9XrPTzeFDP/1eiTRfNRfoo3L62nLHnWH12rWB9ISDyPcCVOeo/P7pnBAAcv87
3msAMjbcE/7mS58N79Jatw3NbXZ+NLVemL+DxQkxq2uRLimNk/ldcUNaSPqBe263+iiRD+zdEeZr
duJ/cUtraNcgwFrFM6jPKd+GauavKJAyJedEDDTMsU8dO+VGvI5vUXQzaM05UIX48wxLMU8kPDon
ZveGeVXh/u2bw65XXtWEIHgpGPA00+v5kZ2+52y3N2nb5PkkQMIAXCE/jJbla0LL7v32jpIlLXXf
4mwbqmWBqUk8i+071YKJnvpuf86ADffRsmiBKT7zpWfse+zeBXIsqoVIhHL2imZCF8nIoTpC0IkI
gFi3YZsl1Po7eYmekF/IouUdFmaBYxkOZgThQb1pWDhiaRZAnBuhXjEHNMSa+rlXTI8ISDdUCXiV
HGrdyjYDetZAqsPKqP7KBAcntbh9bVja3q5cVZcMgGj7esgBhLoxYGTLZ2rLpLMrshqM5DUb1C8T
mJQptP+wcSCIMZapbKaro3IGO+DClv+Yu3CwYPCh4UZ5xXnqQYBHMQDx5uuUyRtdyCWtD0JMTYHT
iQDE62a3Z3ou25qmTzz+eDijiNMtW28ND921xRIRYbEhjQHLLKDcxKcBGRr7+uEjB6wpuIpVYv0x
lxGPA2jgIwIxaHg+eNMCbhdk53/m+WeTXCJr1ocPvfcdoWV+mYHLwIXDoamtI9x7713WPh2bGds6
l7HsAg/Jzfzfe+/d4V3vlggj+uLn/1rLLSoruSxGiRsywKoQAIk09q92pCFTVisx7roPp8s9p82c
jUn71PFOWzGPc8zEeNZCWKXijkKZW7ec8zD9gzgb9/dwcEEvgl8FwWcoh2221vVVWoydZ2GLOUnM
gch7gt8EPkhNmkjMWzn9zfQJnl9eOg7IdU4Kz5lGPC9iScokAixZKOWnfkd1yWXTUzTKxwKRoFnc
APlb/dqVbW2mbPWGGMzcB1nsOhYvtvfJObPqqH04XiY0zPUQ9wYZsChuC24Gvd6l3vNm7sd6g08I
GemPn72kSXfIHC2rJa4uqpfyFsWFiah6c7qWf945/3EUON+R+I6wlxC/D4ITb1u2OGzepFgYcWGJ
70sIzXKcdACxigLLEYk+k0NogKYIIHqtlO0T17reOBGvBJiUk0lKgWvuHegOXl7Ht4BAzIV4ebyN
68DRQA4AAIhzKfE1xfYBJ7wWuRZRw2YWvTgGkxPnABoIlrK2vsVyZHQePxlOneiSCKDV5a/sMe/U
9rb1irW5oOXdxpPgJbG0KM2sXbHRudLRsE/cR6cApkNg8M4H7w2P/eC50L58pSnc+A68V1dJTMIE
hxKuXgrdkb4uW8Bq984dYdsd240jwQr0zYf/Nryq+Ibt960MD9x1q5bz1HeL8MLsVdwOsxt6A2jz
HW8J7xYXg1z+D3/+qfDKD76pOI620NV5LLSJVZ9TJQeoi2dDr3KSoBxGTHFas2697eYHToW+s53i
CjXrKq6mXsrksuPHbOCtWr1BWv/F0tXIlV/3BgnObdve0RHWrF+jnBRaTAo9gghLFzM1IAHLj5LR
nzrm+W7puQBeWGiIWCJ8JGoU8Xuq61w42yd9m7jcBq1J26ds+CVlWtIjEgkr6hbL5R5z7NxEAZqC
R0P1HM3oG63NvgEpUkXjymB/UoA/qAlvace6hCtVOX0JUNh8+51K+7DQBnqdFJoE9d1+9z3mxn6i
X2kP0wE2kpfVSPqGjlXr5Rau3Cx6fwx8qL1lQSjXkqTllT8wfR2THu/6bfevkIfuFTObX5SPiP0m
/Y4li9vse+xifbTqty9Z1m7ervnde7z4qi2TxYR0I4nL2FTfdd+RudLn8H7uu22TElor4lxKaKhX
IvhY3wVzzgOkcNKDBpVw15+TFejj9QCIX/tatjbsSOnnVDouj9EcKdIkg0m/gPNXlkiEou41rRhA
ce4DcJgNYLye60umNTTDAXXxFMQkhv0bwGD2IebAZj1dZ4oqlRO9C5KTzZt9+neZzH+Y2r//5GOh
b90q40jmLymz9IjPvrQjdJ5NzM8AiBPeubiyb5ILPFG8wwo8q9MSjfgAoLCD8mP9oWZYWvyOxnDx
PLksy8Oeg4fsHEACCH34n/6c8oEeCucEBHAjiBk7dr6siEs5twlEmAFxFX/HOx4Kd7/rg5rBBg1A
Hv3m18xRCREN8/SczYlZFwB5VJwVHa5Eyj0G7qJFjeZ5W5c7q5QKSo6k2b2+fkmoWNgecvpeqGXB
QuVR2WK6FFv0Ww+GejjkdQ9PhtUSgX753/5q6EqTE9lF0QcWn6G8guO0hfoGJ8OXv/wXMmEnQGYT
jsCnX91j85rVYfs731u4ujTlGidTUdSPvQKgue/gQZt5S64kysRtWzeGjq0KKMxcu90v0nbueKIH
ooh6g4i0IkTCLiVBbm1pCpvueShsrmm1cp5tQnek2+kb7m9UHFqWluv33LOsLQwoMHRs6JKc86SQ
liuCU0legjwit5SpFQLVq8g5Es2lcJ9wRdWleu+y4DnBjZCXJnaJB0g2tiffc3lUHN1c3b+ymcXE
crXj6gdl0u9d6JLYt3mtTr92DiRu87Xsp3P31CXNdXK2kvGexCo4XpVPSFWlbTFQiDkNB4apljSY
Z+FWAJpi5MDiXEpcr7SiXuHV5KlMbptBZFmj3GAimd2JdVbmamV51vyonXrX9pI6u/rC5OU9Yd22
FWFZ+0L9vy0cOdytpTF3WoJd9xEgChKLy4Zt28P9990bXnz2mXC4a2rmh6NAoy41iQAr+T0AFxQD
Sc2CleJMJIcrsREKUYAFAghQCuPNePO99xmAUP75z3wxvPLMowYgACBgOROLiTOTVhMxwMQKNFl6
1jpyS2NTqGhdFRgU3X1DtlTD1jvX0Xy4IO6FcH58ZtS6sop3h57BhAVAl1K72Kpd86NOCl8WW+/T
qvToD0zxrqvIwI6nJaJF/bJVBWsHDc6Rb0gxYnDXptwAOgImhFf3n1ZkseJnhJ0M7EmVObEuEZTw
S1rISx7XNTUK5NQAh7DsnDgl3dPEy6YfWLd6dWAZDc6zLU25WNpkP26b6wkIrBJ7i6hFpPJLO/Ze
pbOhHqZpLEtsY2qROz8cMaIS4gtkJnuJcWO6dZSt5QKMSnGWceYz8vYyEbGeMPloMG6UjnSHCxKF
nDAQEJ7hfY1y1vPBgS3IcnWku804Kq9fKx0PpKdqmQhtf46SaE04oEpZXCZLEDf2OmgaiFRp9iaR
T4XS7FdIQVR+STOUOADIRQX2PRANNlBqziI0L9TnU9OUzvYrPDkGAy5g8AFOLvtRxsCvLklnAfXp
uVr4WI+bUykpS9V4jV1LgYOJb/WujSoUSMj6HXktej2uNtnnIUPOLr5y+rCFzOdyq6x8hdZzXbGS
+JPzZmUh1yWEXwWKWTgIOAutcmRAUidujXvTSg1G5/t6Ct/j93NQIgS0fsOmML91SeiQExNemSXS
XwAk90kp+uQTT5gy7t0f/Dmr+7Wv/J0ByKLG5MmSJwUl24Re+qTYesx5LWLlG/ccsdyvrLxGct/l
4pgQKYjzYVavaF2n+B1xL+Iakc/b2+4OE3rb5/S74ELmNy+SefdYWCwxgJwpQaIChCWo83QibllB
kQ84EcyxP5DHZldXogxtLFe/0cAeGlOsj/REL7z4cnj14NHQWquUA/L6bakveGYYWFwS++2gwT4Z
6JIAwnI9UwGSOIyXd75ocSPoJOaYAlmKP3XEOgGrAz0u7gx09CGb77hHfLP6pPRWDF50Mfgkfetb
3wlPPPF9U/jG4jkTVjz58R1bt2ywlQMRE2oEkKOKfYEQF/bo3zO00/edvAzQcKqaWCAdTlPYepPW
3FHHdHGe83wn343+hWuJkcHF3TKZ6XtzWp0LHy1c1isqBiWWLgoLK5IB7t7l9I5hLVLmhNF/cUt6
pJipeVISQyyv6qka54wplUZhOE2GQU2+nnjsegHE66ffZBuzh/327/5h4dc3lvabvMfZvp4uexHE
MiT+FymgYNuWCcrCl1XPX0wxzsMfmH2bPuLO4A+fcwtkiiRgDXMUA2aerEPEmbxWgj0vdh2zLi7v
EIMIYjZeINDEnHvhvCKZxVLUL0jeBEF4XXJmguACFktfQFQn7utdEg9gLbkecr8COyjyUV5VE+aL
w6vUPeDTQSQv+icSO/dKX1G7ZKlmJsn7ezVolNgGmdqJayF0BlVy482LZS7R/fRIZMGjlvV58MjN
zZO4pnvjNy5es1VpHDUQCR7TzJvTs4Q8mLBKOhhoznCfOIhcOHmu35aknL9SmfYP75zmL2IV9UFg
G8T9zB3Wd0usuR7C4lNSnvyGmerXVyvKVqZruIFLvV1S1hIIl8yerOYHYQJmjWEIcYE6WeL95ErH
bYU9b8OvydblGCsM5C7/HLtSdTjierIiSjbOyBqJPkrVB6EhQZp/B8d403KtbykrRvF5b4t6k+l4
oCzej9ug3CaS9B7ic7PtAzZOWUDJAsfqBz88VVkX2cG//w9/YKML3Qg6EWiytzM88vjTUv71F/Jb
2InMB+uHtixpC/ffudUyU8WnmTUgwAKFmiuBvA52bECjXBpvOnaV5ErzNVDIfFHSDFMgHmj8oIoA
ji/gw2JV7DOLYwaNaYR4DTnyMAB7tEA1AxIiraCHjI+PXQgXlFaxQb4XxNVAgAmu8bDssMc1FWm7
Sp8XE34b0Li8TclLWinZOCdLEEQ8RHlts4EQHMCxfbuUnV4rxOn8+Fyx3BldgF2kD9oCTEaGpMdR
Z/d7B+gaGpvFWsvEnbL1AF355Gg4q4BKBhYD7fS5HiUkln+OQuIRsYioXrROWdHS7+N7ssA4pUvw
u5h9ixgVt+e1XSeCLgPy5+PHXu81b1N/m+yiYSN6LQqINeIcRNJjX5zMCvThfSUvH4zEwCAxU1xN
geSvcS3Ka9Go10KsFTNXDBo5YtinHxZIfiHTjtMTE2OKNypLuDr2x3W/TAT0gWJULO8K9eLUHtnr
ABREH0jZY2zrxxxkQWSaOOPWGSoO1ywPN908qbVdT4Xzo1ODerI/mZ2p49QvefWpl/aGdRvnhFs2
rAtl9QvMVq0VW6xKkk7Ya09tCXRijqzWQ2iQmbBcchlEyDyh8zF5ZiqAIIlW1EvVgMx668UuwClG
po8h6UkEvOEj4pSvmCfF5qDMoSEsXZrM2GQygxMZlomSGb6iUqukCTvwb8FUy3nur1mAc0WmTqX6
UnPp/dKZIyDxwSEctbwnrEOrFa/CfIERAAJhju2XzwYLVI8My1dGpvVQIV2UvgMLlKu90RPkxT0A
XgAuxDIUdAiLTNbz6JXHLQ5XjXqeADKd66hka0C6pbEmdAkoERtGpf2cU630inK+A0RMQWktph9R
f/ZiBwA/zm79tzowUN/LvG5pOtj9eK4f+zPzY6+QbicU9FcSD7LM+bwGnZ93sKAKPTfhN5ILiHEq
HxJQABARMCRPM6kDGEwqB62yWEli1YtTvRggsKqMq6sAAE4cFxv0nJ+rKOKZzo96Fue0IUDBrpmT
AERaPG1jbaUlgMSwLFFZwrdkJgDxulj36Du+9XLEH0QftloSyxTvgImLRV7PtwYicCCOvpxgP6ew
+NyKDeHKsnVh2cR0pRHnqDMRlYOK/cO94SXpEDBHLWpZJrNs8jWASQwkeOLFhONVl/7xaSCPhwMI
YOKU6sGkD9G7TcZ6ckrPvDR6mRRSZ2aS6U8nuX8I9rJKnZNM7YADXAdgwX1A7GMORRwC8T1VYnxv
BHkNDfdbfT64fwc9jm3ZznQWhHMZkkKYRM3M9nAgKAlbl4qDkOZ/rjgHs5yo/qTa7JVXapYAEAcP
zvHcuLcRDZBKAVu99gHTfq23q/EinY6ckgQwXRcHzPJj4ozAiFgbnM0alHIAX5NpM0rKKcTfnQWA
+Fy878DAwJ+cYeA7d8h17CfTR9KKgwAD3iga7AxmkjtB8cCmbG5pArfjSuIUn7PK6QcAkNfMDyUm
1vSENnAEUFKe9r30Fgw45BfjRH+nmzlX4OXFtuPRdZznWsgBww4yH7Odc3BwT+H40myZg0S2DsmP
IAAkJgeUGDCIhAdMZiLrNw4gPrCo7PsAxZw5BW2MrfDmjcXl7JdXKg+nAOlE/5Bmv72WYHbdkoVh
gWzeWUKj7YR+AR0IIfqTF3CAqlWuCZRKSSIf6sXcCaARAwn7XhZvvf1iWwdOZpPxCWUckwv4hGZO
uA6t0mDgwQzC6nfzJG6NCfHhTjwnCYOWmT5LgA7/gNKVEdlNYD1BQBejxPkg/6MDAUB2PvuE6UAa
1HZO5ZWp2TCv0Hfa8e/Axd0oFV/yNc2hQY8V3xbNwbJAJPeCuIbylqRIOTnpNeLfIR0QHAhkqQgE
QnAhPVKg1jUkohUD1zke6rHGa8LxcTQ7IQIAmmyh+N1w7CBPn2KgM8jZjmrrNClxEzEDog+RViHL
AXjdYgBhZalIS9vpHGGXOFhMB4mktekDfKqfxtf4vpQ7BW7jesDD7ze75VoHkuy56znOAsVM11AP
z3dAJ3sNxw5GXO/gkd33tuPzXubbAifiBdmtAwWDLiaOh2XWjM/TSfjHjX5YD2qo71x4SY4xSxbW
hIXL1ocmRe7CheAEMzHN6pK0jEJUrgcKOmIhac3K6ph0cu+EPvs7p+Llfl9+7Fsvn2nrA5SHMDw5
z2z/DFwoEQUEHFJ8sk+Ws7oWuRRrsCGSDIuDuaAFuFDkOidAPUAnofpQPU/Y4QiuMT6cKmMrlIwH
HQP+GEuWJY5JIT9oospwOhD4PteuFGJklADHKMP6m3gmAHZTYqXq1cl3hBn+ohza0IWgELXlHuTf
AFnEb+V8czyTplIeowmoXws8AApAYk55Ahr++8pTAKFtnr8DCYARyxMOIFZO5UjPxXeT5g/w8nap
UozzoDxLV7UdVXAAocjFASYQJopiRP0CeKQVyNsxIYc5aDr4pBVewwYgmePi+wz6jNfQnFXNAoVf
P1O5n/dtzJXEoJHd9/q+NRDxAwcK50K8PLvlPHUdQDgfX8M+Ik+oXGaK2r1Kmlx3/jkFvSkTervY
uXSguZ0aa0zWopJYUgCTLg1imYLFDTh4OJgQf+Flfo/OlfjxbFsGBAPfZlDpNobFJUA4EvWOKh5E
+w4mGqHSHYgbUKdvZHhLEHPJGwAAHCVJREFU55AbVtIZcQHkgWA7pGvmyGsVmshJWYzeQmCAKMFA
rZD1BwCBSBrUIlf60NBm4sywFsYZUbRlb/8lDfA+q8MHilHEj7xMgMOjiYVkePSsnXdNv8IqdG9y
g5ZiB50PYkSfIlZN16N7a5QuxIBC4tGoxAt+U2+fxBhxPj5A5ygfKWSDuOBKZ0X24VwRHIeS0Bux
r19W4ECS0ukAAlcAqHj/oN/wjrzcr7lqm4owfn+cZ78YF+Ln2Do4xXUdQBwUYl2GXcP96B69HmVO
XFMMUPz8G93CkVShmxpMH+rraPB6QeJ1NF24JAaSQmG6UwARBwavwMv2F+9lbOMy6jg3EtdHBJKj
tV2GG329EkxeVmKevcfOyCypZTObl4dtq5vNlAuQ8M8gQqRxclBJwESKQKE1YMJM78ABmMRizmsB
EP8eZ8G5fw194xZQthpjLVDwwUP9kdTiwSC0TprWQ9AoyPTSeWBmTIhlNBVToYTSeeXqaFKyZPQg
mFEhd3gqkahSJmepMRnGyrXODFCGaRBTHzoUCEBwctDgGNBwgiO52JsADfeQkyjjVgdWY/PfgkUG
S5O5+Wuweh1vx60XHE9/PlPHsc7Hr5ttmzzfpIZzirQxoaAyuBoIDoRIZP/OpPb0zxhUAJT4GGBy
EOGq+Bx1HSQcTLzlmQDE63u97HWUm9I0o/Pw+tezNdFGorTesIEJ17wWQHkjAMK1sUiTPQY4prVf
RE/G/RqIxAASgwQV4pfPsZNfE3Mjfi4u8/Z4WLXyAjwlQ8bxvUr2fPaoHKRWWjRk4lGn2AZvoMgW
+zdAch4wydWZUxyh0HQ4vxfvnEUun7GIjkwbPqsqVFUKkdRcJuetvNyYXR8BeECJyCN/DQ4kJwM6
tpuKCs7RMJAtXFuLYpXJ9Op6EDOx1isSWmoKzMO6BXlbSoPfsLSQBSxr1ZA2w76j8JFaMWJLE+fq
JQS7bgHxQDeY6Be0x/2j1zEA0ffG1gmuLUZZsMgex9f4s/T3oDspiKJxvXjf68Zl7DsgZLfZesWO
/Zr4nIG+gASKwcE5jbjubPtT12bEGteXsIVmUCgnJ6d/wo0wQU5oDvXJkhrs/7BpGkjoy7LHsT4F
UClGBiJZoMgec6EPVPbj8/E+52ajwXHkQF0vBewphYh3Pfu0omgXFcAkp6xM6Bgg38KRACA4/FRq
i6MNjkDD5xWGL1HBPGw1OGabvWa6Jx8QvqWezcpqD8sAOgzDWT07AAHrh/mOoK9Ilx0AUBB/jGTB
yZdMWZ6GlVIPgsuokA8GehB8QZY2LywAD6ZddBVDIeEg7AJ9uCObH8+0jTmRbB2UkwXRTycBEDpr
pTLhG4AgYkUKTb8+AR8/ev3bmQDiWi26PsX7FmBUjGJOw4GD7RuhGGzidqbAQ/xqKuIk51PzrQ58
kkk4lgzIxI1l9plgIQcTP41OMKbZLDZxvTdzPwYV9mPOxb+nIM54AS/OAcNfIud8Pz5PuXMalGct
OZyH3BQMh+L75Rqo5Us3h+Pdp0NX19PheFd72Lau3TJkx+YlrscDDxqRKACQODmY1EgEqFaYufuQ
zAYoPlvGwOHtxVuWGVTeZ1NOYt0wQCiRV61ErsrIb8A7DiJWMmCnUvFYJ2egLmgqiDELpAchqbOb
fYmNsTDW9MuJAcHkyxbyGJHZwCK9tLABBLIA0idnM8tgj35GlNx34oBXuDDdmUkvkq3nx/4s/bn7
sZ+Pt9k6M9UFgDjn9WkjBohiSlTvow5C8fey76AT61UcHPzcTPXitvwaB5M50SgypzFVzupd4utn
2ncw4TyAYqJOuqXMFcLs/6jJwSMGFb+H6Od70RRgTJVM3+NloQsx5alOObDEIMEVLtZ4OQDCw+Ef
EAGAqhpaBCwLZBK+EE53Pq5FoZYpNeFyWQ0WTv9SHZnXpGbSLA1oVbeBoXNm0qxTgmbMnSZfRxaD
+Bo6pwNOXJ7dpw5jvJzsV1o9zAa08mVApBB23QedMp7xXWeDhQGHMfQg3Dum1xb50NjAkBUCZSdU
DgeWKjbFB6uEb2ULTYFmclz807kHwMOBnftgOUbIfEFSziNugeeUpvKIi6/r+Uy7QAczAUJcLwsM
8Tnfdw4mBhA/51sHlBg4YvDw815/Jl2Jny+2nYkr8boOJn7MNrHgJII5gz62/rwWi44Dim/j72Af
LuV6OJPrrZdtP3tcDDy8TgFECL4bkrurcyFega13yrjMyx1A/JwDhx+zjTmU+LxzJZRV1C4QuDQE
LDmnz+8ys/Bdt95swVDOidCW7+P85fEDlEP4Rmg0mx6CmdZ9J8znIKlS9PNagFKqSNka69ka0GrX
nKFkPpWgou9TIGHkpu+AYiAjywpOZRAh6hZ7IyVyXrkkgCGrI86mRCIFuhdfxcwuuMaHgwbVDDhS
0MFnhHcCqF26pPgcWJ0IrEoFVrH3J7+d4ykQm/7F13o202u/OUcxGAEkMVcCUDgXMtu3cU0MKl4X
cIkBxctn2l4LSGa6jnLnRgxMdD+vVQnr3AhtsZ8Vb/x4JjDx89cLJF5/pva4j2JkIJIFkCyQxEDh
+w4GxQDG6/gXUveKZkjjPtKtn2M7DWTkNTqoBwaYHDn61XDTmlWFyEr0IR5E51YbXOZjGpaz1bAy
iOfKWYRK1g1Zc2IwoVPGnZRrbTbWYGI7EzFo/TyKy8K36juIVYHgVNz3khX8cgLGEjmVuVt7EoSX
eMJSvwqfCLVr8TyIbGl6RKECp3V8NReCDsNEobSOO5pRk/tDR8NCUUEgy5o5cDlOMVDwG/hugCsj
env1q7ZvFqBkn/9VXxQVxHXZJ6LFdSRu1aG6m53j90tZgZvRq3XuJAaSeN+/1us52MSThNfJbrMi
UqIXSUQQBxOucc7keriSmAtx0Sb7vdZm9AIdABw4HBj8OK7vdb3N7LGXX2tb4ESoyOAHUNR7r7qO
c05ZkPBy3xYDFs4BJJC35WZgE3NSUYeHlfwnnMmTu48pLf+hcP/qTbbqPTqFGEziiEZrPP0AuYeU
DBkZldkYQCErmIOBcycOMA4QDBSnmDOwAZeeYx/y84Xgu1j0UNavEiXCQYwhiVDi6KWE08PJIzdR
KA3as+je0oRjsYYVVn/VCkWcsCxWZQIwwhASV3XuBRAqRCbr9h08YtCwdtMPL/f7j89l93ku056J
noE/q2zdH8UxQOKAUez7YtABQJwbcWDIXjMTV+PlDiTZ6+LjGEC83EWdWF/COQ+6i71f/ZprbWcD
Er/WQYPjeN+PAYoYLGJw8TZe69Z6NGKME/vOmXjZbNsCIKizxRyFX+MciAGDOJJiAASn4qINg98J
zqV2UYckht7w96/uDQ0HXwm3bF4XNqxdY2KO1dOMDJBAsXhzRZmt8LMgvwQzc7KMoxzG5E2bzMLJ
YIgHybTBgs4iQww6A5N06/uZahrsijVQPgdNhCbGwIG4E1iuoPuQQCO8JlHNiNYjQbwpULQLwBRI
5SNKNViMGhtmD7cvds1sZfxWdCXxb2Qfco6E5+hxLrO19eM654CDLwoUizgzgYqLTkHXsA/X44BC
Gw4qzsE4gBQTe1zx6luud64E3ckoga2Ygt08TIVrEOMIiseJX+LnZjpPuQOLA4lvvY14e70AUxBn
uDgGk2JAkhVz4i+81v5s4k+xawEQpytz5Rei5SEBk+++cEgZyPaF+7bcHjbcti7UamYCMBxI/BoA
JEtTYIKYw4LdSQ0fHNn6xY599vZtXMcHnC/bABdCSH5NOsCdA/AoX+4Qx16hTtyMuJBksFphmkPT
OBMS1nARCYC93MMH4mumt/aGjuLfGe8rY3ICMCln4uJR/GXU92f74+Re3EXf7y17DLfiAGP7Epmg
2bgYB5PZRJ0pbmSKu/V7YAugELfl29fiWzITYMTg4nXiMr43KZ9SzM4EFrMBDO04FcSZGED85PVs
Y2CJo3sdNIq14dyJizfU4Ye5zoRj50zYr1JHHRKnUyVnNRzWQt+h8NXnXwrPHTloqQc2b1qtVAJ1
5j9CfcgTxwwJTNj3ZDOcS8BEiY41IuFMSBSEx+BsNG0AzVZRXIjn0SCz2FX+Hh73co02rjod40y5
R1Wn+o4fEoBwDw6M2fuJn4eDsYPGtHMCEijL1aDMtfLX4JRlF7yBD+dMvAkXfVw8Qt8CcDh4UA9w
gbzMORDK4n2Or4ccWKib7Cdu9eMTCkqcJWXAbG0zdgAK/h04qJ89jutxHp8hiHozAYlVuMZHAUQS
XUhS20WaYtcW03c4kLjZ13UdXB9zFMXa8/MOKPEP9QdiAJLqI9gP1SsUqs/qYr3h608+b+kHHrx5
dVizbo2BRZyVyuNLEAKySywWOBOFz+cIbktnd5ZfmGnwFPsNxlloIDN4Yi6ETF3VEUflHEjRNq5V
CFAYAAEgU8pSu8yB6YcAJjEgXOsWOZ+t78/RORJvA64sOZcoeGOxkn3nbN4sDsYBw78/e2z3nipu
HTAcQDgH94JY5BxIMXFoJq7ERR7/7uwWPYkvyg2YmHhDpVTUcRFomp9IBnx9rMRtZ8scVNhCvvVr
XNTh+Hq5EOoW5bOKiTJUdv2Hb+MygMSsMNrG5x0cqBtTzI2w7+AR1/F9OBEn3wdMEjGnI3T1DIQ/
/85L4RNf+lrYufMVqxpzHn4tQXLFaESOWCzDMIxPhUQFUvEl3Emx2rOUZbiQQk0GuQ/0QuFr3LHr
nQMpcq0DyBv9niJNz1h0Hb/LQcW3xdriHKDB1vep5/uc8/9i17+ZZYAL4AFoOND4lnL6dgwg8T73
kT2+1r3BjQASbs0pVh/wKAog7mJf7KK0zIEjWyULMPF51APoFwGVGFjiOvG+jaqPf/yPzbNpWGvD
zCTWOLfhWxphfyYyi0uKeNRxjsPrx+Di5+Iyv6ZPgXtOMYB4mW85d6n7mK06v1YOa/fcfnPYKPMw
VAw8slyJt2PBd/LvMA9RH5A+QL1Ssa3qmjJVjmWsWkd+U7PaeBvFrrlmWRGuY9o1mfPXc5/Trn+T
DviNP8LvhoP5YXAr1/s0YqsP17ji1bmUa7WT5UwcQAAU93i1NpzbKAYWKZdyVT0vz17rx7ogBpaY
GwE8YsrqGf3cktveM202NnEG8IBcjCkGJM5d+NYbnGkLV2KcScYvxLkOB46ZrvdyBw6OTZTxE5kt
5+YqrB46cm4oHHn4B2F9295w2+b1BTCBPRxKBXgHlmlgIksIcTDDiqO17GI56VIQRwpAoEGLUjNL
EoNcjOEUyxu8cQChpYzYQtE0ypwv3Oe0SslBsUHu9YudK9LEjEVv9PoZG55+IisSZY+pXUwMcmvS
9NZe/xGcietR7DtlNjUq0jWKfUtW7PGUJoCLe7wmgBIrwjItxcBSbJ+yCDgKIpKamVOW3m+myfJ0
eVbAhH2PRc9Uu+qwoBPhTKwXydacScTJ1ouPE8CZspI4p2FIKJBxynItXu71OZ4NQLw+WweS8vH+
sLfzYti196tyVtsSHrxjiwW+ARoOIPF17FvwXKIHtFPme0FEr9jpApjwXuNBYwNxSsww13yu9gFq
Lf24P3R/6HtiAIzvL97nt2WPi90+deLnUKzOm1yGeBMDB8dGshTF52w/VZS/2QCCo5+nTjCnP7uB
vGWXo78XkilFKR2v9zFMgUti4y+qC7nexryeA0kWVNLzLtbEHIlxIAJKyMWZ2XQk00AkbbewceDw
beFEZifmTmIRx/djMOBSv/FseabZwiEA4hzJ9YIJ+pK5Wq8EevXQKfvftnZxwJWeKNpiVEJ2sSgK
t2z8sqExD8lWqYvBZFoDZQWLDMXVWuFsOmXEjuknfwRHKWA7AMYgMdu3/4hBYrZb8XMxcAAoheO0
gpfFPj+cgkN5M3xaHEBos+A9rH3v69OAJE3yTN3rJbiRxGqTXDFNF6IiBxbOZs8lV0SfMwBHVGPW
3esBkFkbuHHyxhO48QRuPIEbT+DGE7jxBG48gR/6EzAt6+QkC2zcoBtP4MYTuPEErv8JlJaWGn5M
t+lc//U3at54AjeewI0nYE/gBojc6Ag3nsCNJ/CGnsANEHlDj+/GxTeewI0ncANEbvSBG0/gxhN4
Q0/gBoi8ocd34+IbT+DGE7gBIjf6wI0ncOMJvKEn8P9LECm4jr+hn3bti1/v91iyIQXZ3aA39gRe
7/Of6Vvf7PZm+p4b5dOfwI8NRPr3PRx+/UFlJCu9K/zG//WH4T9/7CPa/0B4cSAf/vS2mlD6zk9O
v9M38Ygo28+9szSUVep7Sn/NvvN6mqeTPv6Z/2jX/c7vfy58/Df/RXjrbZvCJ3f1hn/4wEOF+7+e
tl5PHb/v7LPZ+4//Vd9dGuZt+XD42M++Vft3hf/z28dfz1dYBPKn/t19hd8y/OofWdv8xjeL8gPH
wu++497k+W/5k6uafeR3N4fS3/r+tHJ+4y3KQUIf+dyje6ad44B3k+03PK/4t+z+dPKODlzTX/yq
5t/Ugux9vamN/7gaw9nsx/H/4id/Tk5u78/vuzJm37/rHz+Vf75/Iv/YF/+f/Ge+u/uHdk+nHvk/
8r/2qUfyj/3Zr+Jkl3/oE7uu67uS+w35P93RU6j/td//QP53vnU0n/0tP6znueuTP5EPm/648P18
z+jg+fyfbFJk4dv/ND82MpDsh+32LF/PfQzu+ZSeS3L9+LlX86SK8Hf0etrLXpO0//78EydP5nc9
9+y033L+6d8r+k74XZ95e/Ibs+35cbF+E/+Wk0//Tf43//gvp32fX/uj3sb39aP+7jfr+xyvfmyc
CDdQFvr9PsKjX/pEKH/oF8L6vpfD9/7xsXBQE19+4FT4H//0neGf/cIvhn/xofeHd3/4D8KRpz8Z
3r19k820L3/650Ppg78WXh3oCp/7Dz8b7n/oPeHj//7DhVkUruHDP/M+uy6efZru+53wh7/4ULjn
w78QPqg7uG35tZMcT47sDn/wS38RNFDDL22eWvbhXf/6j8LbNnhE8lfDR9/5fn3/XcadMOP85X/7
N3b/zKB/2zkZ+l/+s/CBtz8Yfubdbw/v2jwvbPnnf2azv98/5X69cz7Tf0OUxTl9eqRjrGpJDkpH
u0M/eZk2fSjU5CbD0MmXwj97+yZ7Nv/8Tx+b9bv+8b/9tHEz/+Zjf6wGmqzBJx/+6/C9l4d1XXfh
Gf9/7V0NTJVVGH750YnTFC1JLP+dbXnZdOhGLSeROqMm0xEphPiTmaXiSt2Y6RJt2o+bTYOakmPp
EpnRLEvNNX9aTq1Nsahhc7mA1BlDFyY/fp3nnPvee77Ld7lc4Qp6z9ngnHu+97w/z3vuOe97GOfT
dXTykY61r3y8PmP7SoEjldHynRfINX6ClINft6/+SnO2dac3kj1dfhvwLfy9Zu16GaEgOuF5A9x8
belBf9Ohr0qp5rol5SxLTaLEDUep/JsdlBiZIv1VfThP8oR9iHpyNnxOW1e+6PGHrkwgWuiA+Qkd
8XO8qkpGS756gScwWpadTtnPT5FRFqJ0tDGO50jp1jyhRySxD/G9WL30ZTm3db06rd1RK1OwfNTu
nWRNf0bsMO7dlXec0Vt+smrPFMgdEbug3IVWHbWa6s9a4osvo4d/z2327Ji8g8376IhVXFRs8Up/
rq7KWi/oES346qdoclvsstABPzo9y8Vur/dzW0YIYvfG7gpdx+V/b7F+f54/JXVGH/NBu/JEoUd/
x/HuiEC34ewnKR6sWDZjhughNflJuZMDB0+/G7ex0REyivIvi6ySi00WIjVEiIgKGUe0ncY5+aiF
Xj7ydZ5MK6OpeQukL4Cfb3ToscWNPyIk2AN/7Plslwd3zBvFv6UtjJ3OC/5gXHicN7K0+5N1RR2I
lp8r3ITPhJ7c54sx7IXeag7n2uYIj4FOrD/rvGpvufVl6V7H+ajrGqo2L1hdIBKJo40HGqlsobgj
TiuDu0VT9xh1UwF2wZqDRKPje2kUohnljSB69sFWnESLMidRVk6Wm+5H2rXzGA0uKqasQfaLmLGD
bsopoFN1H9BIflmUGIWIY0KvBzznJW5GbaziaEDcw5K2f/9+FDMml06XzKBXZk2iEtGLPi5ox8fa
bcbur49XtP5tYF6eeuoc2n/kOIkUi4oWp9COigaJ2+Qh6p02o5osunih2k3uJCuNXIMsin1khKC5
7GFrb9jHteajyFu1rci3c71+toCWFG2n97Nm0tYjEXR48aekRzR2avGpdzPBnsKN6ZQ+exY98ZCy
EfNGlbbYoijBRy+PxqkrJJz9oVMS+aOt/esPQZgmo0H5KtSDv1F1Le42ddbr9wOn6dvK4bS31BuG
6fNFyVF38zRb8fS6WJc2pbvo7YoH7Qp1wqdOXUQa8QImd5k2N4Obsr7U2ETRQ9NoS2oPuRAM/K6c
KpaMlc8qo+X//VB9XY34HKfCdq0Nooab6l6mYROnUEbGNGqovyHH8q9Dm1NpXb+FVHN4H02fv427
xUvnXHSy7gqJnZEa/8v39FuRw2nuWhfRwUUyLeEHNWe+lpNdt4WfISwd/8IKWpi/W6ZN3G+vlf5O
451t8F7yxHxuN9tTnMH9b/Ej6pNAdO3aP/IzcBs2Ml68+sqLOxMqWWVUXhXhwZWfce00zp+PMAbX
RTrJZ35It7jEjphBe3bvoVczn6NRrqEibXyMHznXN6KI54FOgHnj3xaFnQ0vBz79+vahXjHeVFvn
79v2Rxs7cIAgvUw3buIrpvunJcb1mMaiZL40m5JHi1RZ6MSlgdTdN5AjrkSRJSqimhLXnSQRydPP
b+W1+Q8DzDMkdajCndb41v5SZoncV4beOORkWoSpSFeIct3hPlk52XPlDw7FEPbK1EaE7jOfnSzH
46DzizSxNItxfCDbXHfJTUdWz4RM2yGjCteVbIzxDZ1ZF99a8szLkHLeXP2ulb80y8rO3y11Kpjv
Ev1JVvHO7Up/Eb5WHiuRtAlZr1k5k8fINESlMCrd2eHmBZ2dxiONUbYqG/BZ0dkPd8/vf0fKgZ15
i3FYnSQPjqE/0o1xlGwtzXjaSphX4FdXryx3eulOAfkwGemRk44cbus+0nFzko/DaOCOcFynRZtT
DV+fwEaZvog0C3jpemGcPm/82aJjx+MnpqRKvrCP5wXaHy9/SuK4r6zM40/9cDkQLfsKvp8+dIhM
I71z0o4xzwlgAtn4bsBW+KvkQ6SWJP2p9FcH0vDpeyvmSxpfDO/WZ6GXLHJLh1Du6Eo1dvLYxzfR
tsIFdPtKBS1Z84NIP05QYm8VibRFVxxwRYnLkzuygCd2s27iPbt3o7TXBoxHaQsOwcpqi4+Ckd+R
eAayJdDzjtAFh+u+88RJrlNfa/JBj9IWn7bGpz3P+CoATiDbwyukY3smDKceIyfQgJirtGDZ1KAW
ECgWCpDBM4o6dmFqDcT22hDM+GBoWedAProTnsy7PXUguYGet0c2j/VdQNDvJNepj3k41cHSO/Ho
qL4uHYnASKy48k1yvfs6gt9RQBg+d46A8dGdY3cvj+RIpMsvIvcyyEZ3g8D9jAAvIp3615n7GWBj
m0EgXBAwi0i4eNrYaRAIEQJmEQkRsIatQSBcEDCLSLh42thpEAgRAmYRCRGwhq1BIFwQMItIuHja
2GkQCBECZhEJEbCGrUEgXBAwi0i4eNrYaRAwCBgEDAIGAYOAQcAgYBC47xD4H3kmrJ31T3flAAAA
AElFTkSuQmCC

--_004_D18A00472E32Dwilliamdivancicnasagov_
Content-Type: application/xml; name="default[1].xml"
Content-Description: default[1].xml
Content-Disposition: attachment; filename="default[1].xml"; size=3222;
	creation-date="Tue, 26 May 2015 15:03:26 GMT";
	modification-date="Tue, 26 May 2015 15:03:26 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF
94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr
vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d
CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL
LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr
/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz
hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn
IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ
ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j
U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv
dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b
1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt
td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE
IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY
DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH
1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO
FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb
wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs
bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR
Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc
vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC
QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f
//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+
/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u
RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv
Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+
AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E
pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9
DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV
Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX
hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe
jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC
s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb
GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT
S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ
kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE
9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz
VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6
Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA
sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3
6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr
HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb
dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT
B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1
LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl
6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA
GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC
dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs
jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9
oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D
AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U
eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y
ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo
ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA
AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf
tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu
eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA

--_004_D18A00472E32Dwilliamdivancicnasagov_--


From nobody Wed May 27 00:46:48 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484B41B2A47 for ; Tue, 26 May 2015 01:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCfVaSjDsmQj for ; Tue, 26 May 2015 01:13:23 -0700 (PDT)
Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FDD1B2A4C for ; Tue, 26 May 2015 01:13:22 -0700 (PDT)
From: "Appanasamy, Palanivelan" 
X-IronPort-AV: E=Sophos; i="5.13,497,1427731200"; d="scan'208,217"; a="49403513"
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2015 16:13:20 +0800
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]:51018) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Yx9zD-0001sB-45; Tue, 26 May 2015 08:13:19 +0000
Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Yx9zC-0001rz-5L; Tue, 26 May 2015 08:13:19 +0000
Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Tue, 26 May 2015 13:43:17 +0530
To: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" 
Date: Tue, 26 May 2015 13:43:15 +0530
Thread-Topic: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
Thread-Index: AdCXIGbJlcyJzZc0QTq9ehXtSyfb2QAay36w
Message-ID: <70AEAEC90FCAE0408586E94F491A07EC047B6C2FFE@MS-BAN-E7MB01.intl1.one.verizon.com>
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com> <556376D5.9050409@uclouvain.be>
In-Reply-To: <556376D5.9050409@uclouvain.be>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_70AEAEC90FCAE0408586E94F491A07EC047B6C2FFEMSBANE7MB01in_"
MIME-Version: 1.0
X-VZ-EMEA-INT-SIG: 42a2d368ab222c76db115fcce4d78a4a
X-APAC-E2-SIG: 42a2d368ab222c76db115fcce4d78a4a
Archived-At: 
X-Mailman-Approved-At: Wed, 27 May 2015 00:46:46 -0700
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 08:13:27 -0000

--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C2FFEMSBANE7MB01in_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Oliver and Nishida...Will talk to you further. Thanks.

Regards,
A.Palanivelan
DMTS-Engg, VerizonLabs
-----Original Message-----
From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]
Sent: Tuesday, May 26, 2015 12:54 AM
To: Appanasamy, Palanivelan; multipathtcp@ietf.org
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation

Hello,

> I appreciate the idea of MultipathTCP, the popularity it got and  the
> issues it tries solving.
> But, what are the challenges that  make implementers hesitant to adopt
> this? I believe the pace has slowed down immensely.
> Perhaps, we should get more data and see where we can improve. Any
> thoughts or pointers?

We see different types of deployments of Multipath TCP.

The first type of deployment is the end-to-end deployment with Apple as the=
 example. Apple has implemented Multipath TCP in iOS and uses it for the SI=
RI application. This end-to-end scenario is possible because Apple controls=
 the client and the server.

We've seen similar deployments in private networks. For example, a user of =
the Multipath TCP implementation in the Linux kernel has reported that he u=
ses Multipath TCP for support the CEPH storage service.
Apparently, he does this by assigning a loopback address to each storage se=
rver and one IP address per interface. The loopback addresses are advertise=
d by the routing protocol and Multipath TCP does the load balancing between=
 the different IP addresses of the physical interfaces.
An advantage of this setup is that a link failure does not necessarily resu=
lt in a reorganisation of the storage blocks.

On smartphones, we've performed lots of successful test with Android smartp=
hones using the Multipath TCP implementation in the Linux kernel.
This requires the utilisation of a proxy to reach servers running Multipath=
 TCP, but this setup works with all the Android applications that we have t=
ested. It enables Android smartphones to get higher capacity by bundling ce=
llular and WiFi and more importantly allows to seamlessly switch form cellu=
lar to WiFi. This is important in areas where the network operators have de=
ployed large WiFi networks, e.g. by providing a community WiFi service on t=
heir DSL routers.

Another growing use case is the utilisation of Multipath TCP in middleboxes=
 to bond different access links (ADSL+cable, ADSL+cellular).
In this case, a proxy in the CPE converts TCP into Multipath TCP to enable =
the efficient utilisation of the bonded links and another proxy inside the =
network converts Multipath TCP back to regular TCP to reach the normal serv=
er. There is a growing interest for this solution to support the hybrid acc=
ess network scenario withint the Broadband Forum.
Several implementations for this solution are being developed, but they are=
 not all public

Several companies are also working on bonding with solutions like OpenVPN o=
n top of Multipath TCP.

Feel free to contact me offline if you'd like additional details

Olivier


--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C2FFEMSBANE7MB01in_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks Oliver and Nishida...Will talk to you further. Thanks.


 


Regards,


A.Palanivelan


DMTS-Engg, VerizonLabs

-----Original Message-----


From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]



Sent: Tuesday, May 26, 2015 12:54 AM


To: Appanasamy, Palanivelan; multipathtcp@ietf.org


Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation


 


Hello,


 


> I appreciate the idea of MultipathTCP, the popularity it got and&=
nbsp; the 


> issues it tries solving.


> But, what are the challenges that  make implementers hesitan=
t to adopt 


> this? I believe the pace has slowed down immensely.


> Perhaps, we should get more data and see where we can improve. An=
y 


> thoughts or pointers?


 


We see different types of deployments of Multipath TCP.


 


The first type of deployment is the end-to-end deployment with Apple a=
s the example. Apple has implemented Multipath TCP in iOS and uses it for t=
he SIRI application. This end-to-end scenario is possible because Apple con=
trols the client and the server.


 


We've seen similar deployments in private networks. For example, a use=
r of the Multipath TCP implementation in the Linux kernel has reported that=
 he uses Multipath TCP for support the CEPH storage service. 


Apparently, he does this by assigning a loopback address to each stora=
ge server and one IP address per interface. The loopback addresses are adve=
rtised by the routing protocol and Multipath TCP does the load balancing be=
tween the different IP addresses
of the physical interfaces. 


An advantage of this setup is that a link failure does not necessarily=
 result in a reorganisation of the storage blocks.


 


On smartphones, we've performed lots of successful test with Android s=
martphones using the Multipath TCP implementation in the Linux kernel. 

This requires the utilisation of a proxy to reach servers running Mult=
ipath TCP, but this setup works with all the Android applications that we h=
ave tested. It enables Android smartphones to get higher capacity by bundli=
ng cellular and WiFi and more importantly
allows to seamlessly switch form cellular to WiFi. This is important in are=
as where the network operators have deployed large WiFi networks, e.g. by p=
roviding a community WiFi service on their DSL routers.


 


Another growing use case is the utilisation of Multipath TCP in middle=
boxes to bond different access links (ADSL+cable, ADSL+cellular).

In this case, a proxy in the CPE converts TCP into Multipath TCP to en=
able the efficient utilisation of the bonded links and another proxy inside=
 the network converts Multipath TCP back to regular TCP to reach the normal=
 server. There is a growing interest
for this solution to support the hybrid access network scenario withint the=
 Broadband Forum. 


Several implementations for this solution are being developed, but the=
y are not all public


 


Several companies are also working on bonding with solutions like Open=
VPN on top of Multipath TCP.


 


Feel free to contact me offline if you'd like additional details


 


Olivier


 


 


--


INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be


 





--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C2FFEMSBANE7MB01in_--


From nobody Wed May 27 00:46:49 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D409D1A6F87 for ; Tue, 26 May 2015 23:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Level: 
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhCBLspSbaLd for ; Tue, 26 May 2015 23:50:49 -0700 (PDT)
Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4F51A701C for ; Tue, 26 May 2015 23:50:48 -0700 (PDT)
From: "Appanasamy, Palanivelan" 
X-IronPort-AV: E=Sophos; i="5.13,502,1427731200"; d="scan'208,217"; a="49478331"
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2015 14:50:45 +0800
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]:63662) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1YxVAp-0005A0-63; Wed, 27 May 2015 06:50:43 +0000
Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1YxVAo-00059t-6M; Wed, 27 May 2015 06:50:43 +0000
Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Wed, 27 May 2015 12:20:41 +0530
To: "Ivancic, William D. (GRC-LCA0)" , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" 
Importance: high
X-Priority: 1
Date: Wed, 27 May 2015 12:20:40 +0530
Thread-Topic: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
Thread-Index: AQHQlyBnNJDQUosVZ0qhXgCbpw23qp2ObMgAgAD3FkA=
Message-ID: <70AEAEC90FCAE0408586E94F491A07EC047B6C32CB@MS-BAN-E7MB01.intl1.one.verizon.com>
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com> <556376D5.9050409@uclouvain.be> 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_70AEAEC90FCAE0408586E94F491A07EC047B6C32CBMSBANE7MB01in_"
MIME-Version: 1.0
X-VZ-EMEA-INT-SIG: 25ded3481b4bd670f987523dc5bd70e5
X-APAC-E2-SIG: 25ded3481b4bd670f987523dc5bd70e5
Archived-At: 
X-Mailman-Approved-At: Wed, 27 May 2015 00:46:46 -0700
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2015 06:50:53 -0000

--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C32CBMSBANE7MB01in_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Will,

Thanks for all the details.  This is exactly what I was looking for and thi=
s is very useful.
Should we not document this and add similar inputs from elsewhere... I thin=
k that will be really productive for this WG. Thoughts?

Regards,
A.Palanivelan
DMTS-Engg, Verizon Labs

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]
Sent: Tuesday, May 26, 2015 8:33 PM
To: Olivier.Bonaventure@uclouvain.be; Appanasamy, Palanivelan; multipathtcp=
@ietf.org
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation

I have recently been funded to look at some NASA specific problems with cha=
nnel bonding Iridium phones - work should begin in July.  I will not make t=
he Prague IETF, but hope to attend a few others.  Here is how we are trying=
 to use MPTCP.  If MPTCP works well we "may" consider looking at developing=
 some type of MPUDP, but that is To Be Determined.  There may be better / s=
impler solutions.

 - Will Ivancic


The fundamental problem of
multipath aggregation is the difficulty of fulfilling a range of conflictin=
g criteria. For example, it is difficult to schedule IP packets over hetero=
geneous paths without causing reordering and performance penalties at the t=
ransport layer. It is also hard to implement a generic multipath solution w=
ithout modifying standardized protocols or changing third-party network equ=
ipment.


A robust multipath aggregation
solution should be able to cope with any kind of path heterogeneity, throug=
hput fluctuations, or jitter. Solutions should also be able to deal with pe=
rsistent reordering of data packets. Finally, a complete multipath aggregat=
ion solution should support and be compatible with all existing transport p=
rotocols and applications.


The current solution (use on NASA's Atmospherice Reseach aircraft) to the c=
hannel multiplexing problem (bonding 4 Iridium modes to increase
bandwidht)  is to use the PPP
Multilink Protocol (PPP-MP). This has been serviceable, but has numerous fl=
aws that result in less-than optimal operations, costing precious time =AD =
particularly considering the limited time of an aeronautical science resear=
ch flight and the associated costs.  Thus, a robust, reliable solution is h=
ighly desirable.


In order to baseline current
system operations and obtain data necessary to model the existing implement=
ation (and our proposed solutions), we propose to measure the current opera=
tions of the iridium channels and modems and model this behavior.
The models will be needed to ensure that we have a full understanding of th=
e current failure mechanisms and validate our hypothesis the PPP-MP is susc=
eptible to high loss and unreliable links.


Next, we propose to study the
use of TCP Extensions for Multipath Operation with Multiple Addresses =AD a=
lso know as multipath-TCP (MPTCP) =AD to perform the channel bonding.  Mult=
ipath TCP (MPTCP) is a set of extensions to regular TCP to provide a Multip=
ath TCP service, which enables a transport connection to operate across mul=
tiple paths simultaneously.


Unlike PPP-MP, MPTCP does not
fragment packets across flows and treats each subflow independently. Also, =
the data sequence mapping specifies a mapping from subflow sequence space t=
o data sequence space. A mapping is fixed, in that the subflow sequence num=
ber is bound to the data sequence number after the mapping has been process=
ed.
MPTCP
allows the same data sequence number to mapped to by different subflows for=
 retransmission purposes.  Thus, if one channel (modem) fails, the failed s=
ubflow can be retransmitted over another path (channel). We believe such op=
eration will result in a robust communication system as when on modem loose=
s lock or rests, it should not affect the other subflows and MPTCP should a=
utomatically adapt.


This protocol specification does
not mandate any mechanisms for handling retransmissions. Rather, this will =
be dependent upon local policy. Aggressive connection-level retransmissions=
 policies could be implemented where every packet lost at subflow level is =
retransmitted on a different subflow (hence, wasting bandwidth but possibly=
 reducing application-to-application delays), or conservative retransmissio=
n policies where connection-level retransmits are only used after a few sub=
flow-level retransmission timeouts occur. This is an area that we will expe=
riment with.  Having good channel characteristics is also critical for unde=
rstanding the trade space(hence the need to first characterize the Iridium =
modem performance). Also, Multiple retransmissions are triggers that  can b=
e used to indicate that a subflow is performing badly and could lead to a h=
ost resetting the subflow. Additional research is required to understand th=
e heuristics of how and when to reset underperforming subflows. For example=
, a highly asymmetric path may be misdiagnosed as underperforming, unnecess=
arily triggering a subflow reset.

Once we fully understand MPTCP
applicability to channel bonding, we will utilize that knowledge to address=
 UPD communications.

Aircraft systems utilizing satellite links often utilize UDP packets to avo=
id TCP=B9s issues with latency.  Since UPD does not contain state or explic=
it feedback, developing a multipath UDP implementation has some unique chal=
lenges relative to MPTCP.  UDP is a single packet protocol with no state. T=
here's no relationship between two UDP packets - regardless of same/differe=
nt port or addresses. However, at the application level, two UDP packets th=
at take different paths could produce injury to the application. Thus, reor=
dering and losses will need to be studied and addressed. We will also consi=
der the use of the multipath Real-Time Protocol (MPRTP) as RTP has state an=
d can adopt many of the concepts of
MPTCP.   Lessons learned from our study of MPTCP and
MPRTP will be applied to a new multipath UPD protocol (whereby the subflows=
 would maintain some minimal state and receive some minimal feedback in rel=
ation to each subflow path). Finally, an alternative to Multipath UDP (MPUD=
P) may be capable of applying channel coding prior to splitting a UDP flow =
over multiple paths =AD analogous to a UDP performance enhancing proxy.
It will also be evaluated as well.


Since UDP was originally
designed to be an unreliable transport and we are basically attempting to m=
ake it reliable (at least at least over the channel-bonded link), we will n=
eed to evaluate our final results to ensure that we have not created someth=
ing unwieldy.  Understanding whether we need to develop a MPUDP implementat=
ion or perform a modification and update of PPP-MP will all be part of the =
research effort.


>



--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C32CBMSBANE7MB01in_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Will,


 


Thanks for all the details.  This is exactly what I was looking f=
or and this is very useful.


Should we not document this and add similar inputs from elsewhere... I=
 think that will be really productive for this WG. Thoughts?


 


Regards,


A.Palanivelan


DMTS-Engg, Verizon Labs


 


-----Original Message-----


From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]



Sent: Tuesday, May 26, 2015 8:33 PM


To: Olivier.Bonaventure@uclouvain.be; Appanasamy, Palanivelan; multipathtcp=
@ietf.org


Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation


 


I have recently been funded to look at some NASA specific problems wit=
h channel bonding Iridium phones - work should begin in July.  I will =
not make the Prague IETF, but hope to attend a few others.  Here is ho=
w we are trying to use MPTCP.  If MPTCP works
well we "may" consider looking at developing some type of MPUDP, =
but that is To Be Determined.  There may be better / simpler solutions=
.


 


 - Will Ivancic


 


 


The fundamental problem of


multipath aggregation is the difficulty of fulfilling a range of confl=
icting criteria. For example, it is difficult to schedule IP packets over h=
eterogeneous paths without causing reordering and performance penalties at =
the transport layer. It is also
hard to implement a generic multipath solution without modifying standardiz=
ed protocols or changing third-party network equipment.


 


 


A robust multipath aggregation


solution should be able to cope with any kind of path heterogeneity, t=
hroughput fluctuations, or jitter. Solutions should also be able to deal wi=
th persistent reordering of data packets. Finally, a complete multipath agg=
regation solution should support
and be compatible with all existing transport protocols and applications.

 


 


The current solution (use on NASA's Atmospherice Reseach aircraft) to =
the channel multiplexing problem (bonding 4 Iridium modes to increase


bandwidht)  is to use the PPP


Multilink Protocol (PPP-MP). This has been serviceable, but has numero=
us flaws that result in less-than optimal operations, costing precious time=
 =AD particularly considering the limited time of an aeronautical science r=
esearch flight and the associated
costs.  Thus, a robust, reliable solution is highly desirable.


 


 


In order to baseline current


system operations and obtain data necessary to model the existing impl=
ementation (and our proposed solutions), we propose to measure the current =
operations of the iridium channels and modems and model this behavior.

The models will be needed to ensure that we have a full understanding =
of the current failure mechanisms and validate our hypothesis the PPP-MP is=
 susceptible to high loss and unreliable links.


 


 


Next, we propose to study the


use of TCP Extensions for Multipath Operation with Multiple Addresses =
=AD also know as multipath-TCP (MPTCP) =AD to perform the channel bonding.&=
nbsp; Multipath TCP (MPTCP) is a set of extensions to regular TCP to provid=
e a Multipath TCP service, which enables
a transport connection to operate across multiple paths simultaneously.

 


 


Unlike PPP-MP, MPTCP does not


fragment packets across flows and treats each subflow independently. A=
lso, the data sequence mapping specifies a mapping from subflow sequence sp=
ace to data sequence space. A mapping is fixed, in that the subflow sequenc=
e number is bound to the data sequence
number after the mapping has been processed.


MPTCP


allows the same data sequence number to mapped to by different subflow=
s for retransmission purposes.  Thus, if one channel (modem) fails, th=
e failed subflow can be retransmitted over another path (channel). We belie=
ve such operation will result in a robust
communication system as when on modem looses lock or rests, it should not a=
ffect the other subflows and MPTCP should automatically adapt.


 


 


This protocol specification does


not mandate any mechanisms for handling retransmissions. Rather, this =
will be dependent upon local policy. Aggressive connection-level retransmis=
sions policies could be implemented where every packet lost at subflow leve=
l is retransmitted on a different
subflow (hence, wasting bandwidth but possibly reducing application-to-appl=
ication delays), or conservative retransmission policies where connection-l=
evel retransmits are only used after a few subflow-level retransmission tim=
eouts occur. This is an area that
we will experiment with.  Having good channel characteristics is also =
critical for understanding the trade space(hence the need to first characte=
rize the Iridium modem performance). Also, Multiple retransmissions are tri=
ggers that  can be used to indicate that
a subflow is performing badly and could lead to a host resetting the subflo=
w. Additional research is required to understand the heuristics of how and =
when to reset underperforming subflows. For example, a highly asymmetric pa=
th may be misdiagnosed as underperforming,
unnecessarily triggering a subflow reset.


 


Once we fully understand MPTCP


applicability to channel bonding, we will utilize that knowledge to ad=
dress UPD communications. 


 


Aircraft systems utilizing satellite links often utilize UDP packets t=
o avoid TCP=B9s issues with latency.  Since UPD does not contain state=
 or explicit feedback, developing a multipath UDP implementation has some u=
nique challenges relative to MPTCP.  UDP
is a single packet protocol with no state. There's no relationship between =
two UDP packets - regardless of same/different port or addresses. However, =
at the application level, two UDP packets that take different paths could p=
roduce injury to the application.
Thus, reordering and losses will need to be studied and addressed. We will =
also consider the use of the multipath Real-Time Protocol (MPRTP) as RTP ha=
s state and can adopt many of the concepts of


MPTCP.   Lessons learned from our study of MPTCP and


MPRTP will be applied to a new multipath UPD protocol (whereby the sub=
flows would maintain some minimal state and receive some minimal feedback i=
n relation to each subflow path). Finally, an alternative to Multipath UDP =
(MPUDP) may be capable of applying
channel coding prior to splitting a UDP flow over multiple paths =AD analog=
ous to a UDP performance enhancing proxy.


It will also be evaluated as well.


 


 


Since UDP was originally


designed to be an unreliable transport and we are basically attempting=
 to make it reliable (at least at least over the channel-bonded link), we w=
ill need to evaluate our final results to ensure that we have not created s=
omething unwieldy.  Understanding
whether we need to develop a MPUDP implementation or perform a modification=
 and update of PPP-MP will all be part of the research effort.


 


 


>


 


 





--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C32CBMSBANE7MB01in_--


From nobody Wed May 27 06:01:18 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0411A88BE for ; Wed, 27 May 2015 06:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cj8hp1fSJfcz for ; Wed, 27 May 2015 06:01:09 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id EB8721A88C6 for ; Wed, 27 May 2015 06:01:08 -0700 (PDT)
Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6FEC2A8063; Wed, 27 May 2015 08:01:08 -0500 (CDT)
Received: from NDJSCHT110.ndc.nasa.gov (ndjscht110-pub.ndc.nasa.gov [198.117.1.210]) by ndjsppt102.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id t4RD18XL015511;  Wed, 27 May 2015 08:01:08 -0500
Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.61]) by NDJSCHT110.ndc.nasa.gov ([198.117.1.210]) with mapi id 14.03.0224.002; Wed, 27 May 2015 08:01:08 -0500
From: "Ivancic, William D. (GRC-LCA0)" 
To: "Appanasamy, Palanivelan" , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" 
Thread-Topic: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
Thread-Index: AQHQlyBnNJDQUosVZ0qhXgCbpw23qp2ObMgAgAD3FkCAAHkVAA==
Importance: high
X-Priority: 1
Date: Wed, 27 May 2015 13:01:07 +0000
Message-ID: 
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com> <556376D5.9050409@uclouvain.be>  <70AEAEC90FCAE0408586E94F491A07EC047B6C32CB@MS-BAN-E7MB01.intl1.one.verizon.com>
In-Reply-To: <70AEAEC90FCAE0408586E94F491A07EC047B6C32CB@MS-BAN-E7MB01.intl1.one.verizon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [139.88.111.195]
Content-Type: multipart/alternative; boundary="_000_D18B38072E41Fwilliamdivancicnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-05-27_04:, , signatures=0
Archived-At: 
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2015 13:01:16 -0000

--_000_D18B38072E41Fwilliamdivancicnasagov_
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64

RG9jdW1lbnRpbmcgdGhlIHZhcmlvdXMgdXNlIGNhc2VzIGlzIHVzZWZ1bCBhbmQgc2hvdWxkIGhl
bHAgd2hlbiBlbmhhbmNpbmcgdGhlIHByb3RvY29sLg0KDQpMZXQgbWUga25vdyBob3cgSSBjYW4g
aGVscC4gIEkgd291bGQgY2VydGFpbmx5IGJlIHdpbGxpbmcgdG8gcHV0IHRvZ2V0aGVyIGEgc21h
bGwgc2VjdGlvbiBvbiBjaGFubmVsLWJvbmRpbmcuDQoNCldpbGwNCg0KRnJvbTogPEFwcGFuYXNh
bXk+LCBQYWxhbml2ZWxhbiA8cGFsYW5pdmVsYW4uYXBwYW5hc2FteUBpbi52ZXJpem9uLmNvbTxt
YWlsdG86cGFsYW5pdmVsYW4uYXBwYW5hc2FteUBpbi52ZXJpem9uLmNvbT4+DQpEYXRlOiBXZWRu
ZXNkYXksIE1heSAyNywgMjAxNSAyOjUwIEFNDQpUbzogV2lsbGlhbSBJdmFuY2ljIDx3aWxsaWFt
LmQuaXZhbmNpY0BuYXNhLmdvdjxtYWlsdG86d2lsbGlhbS5kLml2YW5jaWNAbmFzYS5nb3Y+Piwg
Ik9saXZpZXIuQm9uYXZlbnR1cmVAdWNsb3V2YWluLmJlPG1haWx0bzpPbGl2aWVyLkJvbmF2ZW50
dXJlQHVjbG91dmFpbi5iZT4iIDxPbGl2aWVyLkJvbmF2ZW50dXJlQHVjbG91dmFpbi5iZTxtYWls
dG86T2xpdmllci5Cb25hdmVudHVyZUB1Y2xvdXZhaW4uYmU+PiwgIm11bHRpcGF0aHRjcEBpZXRm
Lm9yZzxtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnPiIgPG11bHRpcGF0aHRjcEBpZXRmLm9y
ZzxtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbbXVsdGlwYXRo
dGNwXSBXaGF0IGFyZSB0aGUgZXhpc3RpbmcgY2hhbGxlbmdlcyB0byBNdWx0aXBhdGhUQ1AgSW1w
bGVtZW50YXRpb24NCg0KSGkgV2lsbCwNCg0KVGhhbmtzIGZvciBhbGwgdGhlIGRldGFpbHMuICBU
aGlzIGlzIGV4YWN0bHkgd2hhdCBJIHdhcyBsb29raW5nIGZvciBhbmQgdGhpcyBpcyB2ZXJ5IHVz
ZWZ1bC4NClNob3VsZCB3ZSBub3QgZG9jdW1lbnQgdGhpcyBhbmQgYWRkIHNpbWlsYXIgaW5wdXRz
IGZyb20gZWxzZXdoZXJlLi4uIEkgdGhpbmsgdGhhdCB3aWxsIGJlIHJlYWxseSBwcm9kdWN0aXZl
IGZvciB0aGlzIFdHLiBUaG91Z2h0cz8NCg0KUmVnYXJkcywNCkEuUGFsYW5pdmVsYW4NCkRNVFMt
RW5nZywgVmVyaXpvbiBMYWJzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJ
dmFuY2ljLCBXaWxsaWFtIEQuIChHUkMtTENBMCkgW21haWx0bzp3aWxsaWFtLmQuaXZhbmNpY0Bu
YXNhLmdvdl0NClNlbnQ6IFR1ZXNkYXksIE1heSAyNiwgMjAxNSA4OjMzIFBNDQpUbzogT2xpdmll
ci5Cb25hdmVudHVyZUB1Y2xvdXZhaW4uYmU8bWFpbHRvOk9saXZpZXIuQm9uYXZlbnR1cmVAdWNs
b3V2YWluLmJlPjsgQXBwYW5hc2FteSwgUGFsYW5pdmVsYW47IG11bHRpcGF0aHRjcEBpZXRmLm9y
ZzxtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttdWx0aXBhdGh0
Y3BdIFdoYXQgYXJlIHRoZSBleGlzdGluZyBjaGFsbGVuZ2VzIHRvIE11bHRpcGF0aFRDUCBJbXBs
ZW1lbnRhdGlvbg0KDQpJIGhhdmUgcmVjZW50bHkgYmVlbiBmdW5kZWQgdG8gbG9vayBhdCBzb21l
IE5BU0Egc3BlY2lmaWMgcHJvYmxlbXMgd2l0aCBjaGFubmVsIGJvbmRpbmcgSXJpZGl1bSBwaG9u
ZXMgLSB3b3JrIHNob3VsZCBiZWdpbiBpbiBKdWx5LiAgSSB3aWxsIG5vdCBtYWtlIHRoZSBQcmFn
dWUgSUVURiwgYnV0IGhvcGUgdG8gYXR0ZW5kIGEgZmV3IG90aGVycy4gIEhlcmUgaXMgaG93IHdl
IGFyZSB0cnlpbmcgdG8gdXNlIE1QVENQLiAgSWYgTVBUQ1Agd29ya3Mgd2VsbCB3ZSAibWF5IiBj
b25zaWRlciBsb29raW5nIGF0IGRldmVsb3Bpbmcgc29tZSB0eXBlIG9mIE1QVURQLCBidXQgdGhh
dCBpcyBUbyBCZSBEZXRlcm1pbmVkLiAgVGhlcmUgbWF5IGJlIGJldHRlciAvIHNpbXBsZXIgc29s
dXRpb25zLg0KDQotIFdpbGwgSXZhbmNpYw0KDQoNClRoZSBmdW5kYW1lbnRhbCBwcm9ibGVtIG9m
DQptdWx0aXBhdGggYWdncmVnYXRpb24gaXMgdGhlIGRpZmZpY3VsdHkgb2YgZnVsZmlsbGluZyBh
IHJhbmdlIG9mIGNvbmZsaWN0aW5nIGNyaXRlcmlhLiBGb3IgZXhhbXBsZSwgaXQgaXMgZGlmZmlj
dWx0IHRvIHNjaGVkdWxlIElQIHBhY2tldHMgb3ZlciBoZXRlcm9nZW5lb3VzIHBhdGhzIHdpdGhv
dXQgY2F1c2luZyByZW9yZGVyaW5nIGFuZCBwZXJmb3JtYW5jZSBwZW5hbHRpZXMgYXQgdGhlIHRy
YW5zcG9ydCBsYXllci4gSXQgaXMgYWxzbyBoYXJkIHRvIGltcGxlbWVudCBhIGdlbmVyaWMgbXVs
dGlwYXRoIHNvbHV0aW9uIHdpdGhvdXQgbW9kaWZ5aW5nIHN0YW5kYXJkaXplZCBwcm90b2NvbHMg
b3IgY2hhbmdpbmcgdGhpcmQtcGFydHkgbmV0d29yayBlcXVpcG1lbnQuDQoNCg0KQSByb2J1c3Qg
bXVsdGlwYXRoIGFnZ3JlZ2F0aW9uDQpzb2x1dGlvbiBzaG91bGQgYmUgYWJsZSB0byBjb3BlIHdp
dGggYW55IGtpbmQgb2YgcGF0aCBoZXRlcm9nZW5laXR5LCB0aHJvdWdocHV0IGZsdWN0dWF0aW9u
cywgb3Igaml0dGVyLiBTb2x1dGlvbnMgc2hvdWxkIGFsc28gYmUgYWJsZSB0byBkZWFsIHdpdGgg
cGVyc2lzdGVudCByZW9yZGVyaW5nIG9mIGRhdGEgcGFja2V0cy4gRmluYWxseSwgYSBjb21wbGV0
ZSBtdWx0aXBhdGggYWdncmVnYXRpb24gc29sdXRpb24gc2hvdWxkIHN1cHBvcnQgYW5kIGJlIGNv
bXBhdGlibGUgd2l0aCBhbGwgZXhpc3RpbmcgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgYXBwbGlj
YXRpb25zLg0KDQoNClRoZSBjdXJyZW50IHNvbHV0aW9uICh1c2Ugb24gTkFTQSdzIEF0bW9zcGhl
cmljZSBSZXNlYWNoIGFpcmNyYWZ0KSB0byB0aGUgY2hhbm5lbCBtdWx0aXBsZXhpbmcgcHJvYmxl
bSAoYm9uZGluZyA0IElyaWRpdW0gbW9kZXMgdG8gaW5jcmVhc2UNCmJhbmR3aWRodCkgIGlzIHRv
IHVzZSB0aGUgUFBQDQpNdWx0aWxpbmsgUHJvdG9jb2wgKFBQUC1NUCkuIFRoaXMgaGFzIGJlZW4g
c2VydmljZWFibGUsIGJ1dCBoYXMgbnVtZXJvdXMgZmxhd3MgdGhhdCByZXN1bHQgaW4gbGVzcy10
aGFuIG9wdGltYWwgb3BlcmF0aW9ucywgY29zdGluZyBwcmVjaW91cyB0aW1lIKGpIHBhcnRpY3Vs
YXJseSBjb25zaWRlcmluZyB0aGUgbGltaXRlZCB0aW1lIG9mIGFuIGFlcm9uYXV0aWNhbCBzY2ll
bmNlIHJlc2VhcmNoIGZsaWdodCBhbmQgdGhlIGFzc29jaWF0ZWQgY29zdHMuICBUaHVzLCBhIHJv
YnVzdCwgcmVsaWFibGUgc29sdXRpb24gaXMgaGlnaGx5IGRlc2lyYWJsZS4NCg0KDQpJbiBvcmRl
ciB0byBiYXNlbGluZSBjdXJyZW50DQpzeXN0ZW0gb3BlcmF0aW9ucyBhbmQgb2J0YWluIGRhdGEg
bmVjZXNzYXJ5IHRvIG1vZGVsIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiAoYW5kIG91ciBw
cm9wb3NlZCBzb2x1dGlvbnMpLCB3ZSBwcm9wb3NlIHRvIG1lYXN1cmUgdGhlIGN1cnJlbnQgb3Bl
cmF0aW9ucyBvZiB0aGUgaXJpZGl1bSBjaGFubmVscyBhbmQgbW9kZW1zIGFuZCBtb2RlbCB0aGlz
IGJlaGF2aW9yLg0KVGhlIG1vZGVscyB3aWxsIGJlIG5lZWRlZCB0byBlbnN1cmUgdGhhdCB3ZSBo
YXZlIGEgZnVsbCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjdXJyZW50IGZhaWx1cmUgbWVjaGFuaXNt
cyBhbmQgdmFsaWRhdGUgb3VyIGh5cG90aGVzaXMgdGhlIFBQUC1NUCBpcyBzdXNjZXB0aWJsZSB0
byBoaWdoIGxvc3MgYW5kIHVucmVsaWFibGUgbGlua3MuDQoNCg0KTmV4dCwgd2UgcHJvcG9zZSB0
byBzdHVkeSB0aGUNCnVzZSBvZiBUQ1AgRXh0ZW5zaW9ucyBmb3IgTXVsdGlwYXRoIE9wZXJhdGlv
biB3aXRoIE11bHRpcGxlIEFkZHJlc3NlcyChqSBhbHNvIGtub3cgYXMgbXVsdGlwYXRoLVRDUCAo
TVBUQ1ApIKGpIHRvIHBlcmZvcm0gdGhlIGNoYW5uZWwgYm9uZGluZy4gIE11bHRpcGF0aCBUQ1Ag
KE1QVENQKSBpcyBhIHNldCBvZiBleHRlbnNpb25zIHRvIHJlZ3VsYXIgVENQIHRvIHByb3ZpZGUg
YSBNdWx0aXBhdGggVENQIHNlcnZpY2UsIHdoaWNoIGVuYWJsZXMgYSB0cmFuc3BvcnQgY29ubmVj
dGlvbiB0byBvcGVyYXRlIGFjcm9zcyBtdWx0aXBsZSBwYXRocyBzaW11bHRhbmVvdXNseS4NCg0K
DQpVbmxpa2UgUFBQLU1QLCBNUFRDUCBkb2VzIG5vdA0KZnJhZ21lbnQgcGFja2V0cyBhY3Jvc3Mg
Zmxvd3MgYW5kIHRyZWF0cyBlYWNoIHN1YmZsb3cgaW5kZXBlbmRlbnRseS4gQWxzbywgdGhlIGRh
dGEgc2VxdWVuY2UgbWFwcGluZyBzcGVjaWZpZXMgYSBtYXBwaW5nIGZyb20gc3ViZmxvdyBzZXF1
ZW5jZSBzcGFjZSB0byBkYXRhIHNlcXVlbmNlIHNwYWNlLiBBIG1hcHBpbmcgaXMgZml4ZWQsIGlu
IHRoYXQgdGhlIHN1YmZsb3cgc2VxdWVuY2UgbnVtYmVyIGlzIGJvdW5kIHRvIHRoZSBkYXRhIHNl
cXVlbmNlIG51bWJlciBhZnRlciB0aGUgbWFwcGluZyBoYXMgYmVlbiBwcm9jZXNzZWQuDQpNUFRD
UA0KYWxsb3dzIHRoZSBzYW1lIGRhdGEgc2VxdWVuY2UgbnVtYmVyIHRvIG1hcHBlZCB0byBieSBk
aWZmZXJlbnQgc3ViZmxvd3MgZm9yIHJldHJhbnNtaXNzaW9uIHB1cnBvc2VzLiAgVGh1cywgaWYg
b25lIGNoYW5uZWwgKG1vZGVtKSBmYWlscywgdGhlIGZhaWxlZCBzdWJmbG93IGNhbiBiZSByZXRy
YW5zbWl0dGVkIG92ZXIgYW5vdGhlciBwYXRoIChjaGFubmVsKS4gV2UgYmVsaWV2ZSBzdWNoIG9w
ZXJhdGlvbiB3aWxsIHJlc3VsdCBpbiBhIHJvYnVzdCBjb21tdW5pY2F0aW9uIHN5c3RlbSBhcyB3
aGVuIG9uIG1vZGVtIGxvb3NlcyBsb2NrIG9yIHJlc3RzLCBpdCBzaG91bGQgbm90IGFmZmVjdCB0
aGUgb3RoZXIgc3ViZmxvd3MgYW5kIE1QVENQIHNob3VsZCBhdXRvbWF0aWNhbGx5IGFkYXB0Lg0K
DQoNClRoaXMgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkb2VzDQpub3QgbWFuZGF0ZSBhbnkgbWVj
aGFuaXNtcyBmb3IgaGFuZGxpbmcgcmV0cmFuc21pc3Npb25zLiBSYXRoZXIsIHRoaXMgd2lsbCBi
ZSBkZXBlbmRlbnQgdXBvbiBsb2NhbCBwb2xpY3kuIEFnZ3Jlc3NpdmUgY29ubmVjdGlvbi1sZXZl
bCByZXRyYW5zbWlzc2lvbnMgcG9saWNpZXMgY291bGQgYmUgaW1wbGVtZW50ZWQgd2hlcmUgZXZl
cnkgcGFja2V0IGxvc3QgYXQgc3ViZmxvdyBsZXZlbCBpcyByZXRyYW5zbWl0dGVkIG9uIGEgZGlm
ZmVyZW50IHN1YmZsb3cgKGhlbmNlLCB3YXN0aW5nIGJhbmR3aWR0aCBidXQgcG9zc2libHkgcmVk
dWNpbmcgYXBwbGljYXRpb24tdG8tYXBwbGljYXRpb24gZGVsYXlzKSwgb3IgY29uc2VydmF0aXZl
IHJldHJhbnNtaXNzaW9uIHBvbGljaWVzIHdoZXJlIGNvbm5lY3Rpb24tbGV2ZWwgcmV0cmFuc21p
dHMgYXJlIG9ubHkgdXNlZCBhZnRlciBhIGZldyBzdWJmbG93LWxldmVsIHJldHJhbnNtaXNzaW9u
IHRpbWVvdXRzIG9jY3VyLiBUaGlzIGlzIGFuIGFyZWEgdGhhdCB3ZSB3aWxsIGV4cGVyaW1lbnQg
d2l0aC4gIEhhdmluZyBnb29kIGNoYW5uZWwgY2hhcmFjdGVyaXN0aWNzIGlzIGFsc28gY3JpdGlj
YWwgZm9yIHVuZGVyc3RhbmRpbmcgdGhlIHRyYWRlIHNwYWNlKGhlbmNlIHRoZSBuZWVkIHRvIGZp
cnN0IGNoYXJhY3Rlcml6ZSB0aGUgSXJpZGl1bSBtb2RlbSBwZXJmb3JtYW5jZSkuIEFsc28sIE11
bHRpcGxlIHJldHJhbnNtaXNzaW9ucyBhcmUgdHJpZ2dlcnMgdGhhdCAgY2FuIGJlIHVzZWQgdG8g
aW5kaWNhdGUgdGhhdCBhIHN1YmZsb3cgaXMgcGVyZm9ybWluZyBiYWRseSBhbmQgY291bGQgbGVh
ZCB0byBhIGhvc3QgcmVzZXR0aW5nIHRoZSBzdWJmbG93LiBBZGRpdGlvbmFsIHJlc2VhcmNoIGlz
IHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlIGhldXJpc3RpY3Mgb2YgaG93IGFuZCB3aGVuIHRv
IHJlc2V0IHVuZGVycGVyZm9ybWluZyBzdWJmbG93cy4gRm9yIGV4YW1wbGUsIGEgaGlnaGx5IGFz
eW1tZXRyaWMgcGF0aCBtYXkgYmUgbWlzZGlhZ25vc2VkIGFzIHVuZGVycGVyZm9ybWluZywgdW5u
ZWNlc3NhcmlseSB0cmlnZ2VyaW5nIGEgc3ViZmxvdyByZXNldC4NCg0KT25jZSB3ZSBmdWxseSB1
bmRlcnN0YW5kIE1QVENQDQphcHBsaWNhYmlsaXR5IHRvIGNoYW5uZWwgYm9uZGluZywgd2Ugd2ls
bCB1dGlsaXplIHRoYXQga25vd2xlZGdlIHRvIGFkZHJlc3MgVVBEIGNvbW11bmljYXRpb25zLg0K
DQpBaXJjcmFmdCBzeXN0ZW1zIHV0aWxpemluZyBzYXRlbGxpdGUgbGlua3Mgb2Z0ZW4gdXRpbGl6
ZSBVRFAgcGFja2V0cyB0byBhdm9pZCBUQ1Cp9nMgaXNzdWVzIHdpdGggbGF0ZW5jeS4gIFNpbmNl
IFVQRCBkb2VzIG5vdCBjb250YWluIHN0YXRlIG9yIGV4cGxpY2l0IGZlZWRiYWNrLCBkZXZlbG9w
aW5nIGEgbXVsdGlwYXRoIFVEUCBpbXBsZW1lbnRhdGlvbiBoYXMgc29tZSB1bmlxdWUgY2hhbGxl
bmdlcyByZWxhdGl2ZSB0byBNUFRDUC4gIFVEUCBpcyBhIHNpbmdsZSBwYWNrZXQgcHJvdG9jb2wg
d2l0aCBubyBzdGF0ZS4gVGhlcmUncyBubyByZWxhdGlvbnNoaXAgYmV0d2VlbiB0d28gVURQIHBh
Y2tldHMgLSByZWdhcmRsZXNzIG9mIHNhbWUvZGlmZmVyZW50IHBvcnQgb3IgYWRkcmVzc2VzLiBI
b3dldmVyLCBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwsIHR3byBVRFAgcGFja2V0cyB0aGF0IHRh
a2UgZGlmZmVyZW50IHBhdGhzIGNvdWxkIHByb2R1Y2UgaW5qdXJ5IHRvIHRoZSBhcHBsaWNhdGlv
bi4gVGh1cywgcmVvcmRlcmluZyBhbmQgbG9zc2VzIHdpbGwgbmVlZCB0byBiZSBzdHVkaWVkIGFu
ZCBhZGRyZXNzZWQuIFdlIHdpbGwgYWxzbyBjb25zaWRlciB0aGUgdXNlIG9mIHRoZSBtdWx0aXBh
dGggUmVhbC1UaW1lIFByb3RvY29sIChNUFJUUCkgYXMgUlRQIGhhcyBzdGF0ZSBhbmQgY2FuIGFk
b3B0IG1hbnkgb2YgdGhlIGNvbmNlcHRzIG9mDQpNUFRDUC4gICBMZXNzb25zIGxlYXJuZWQgZnJv
bSBvdXIgc3R1ZHkgb2YgTVBUQ1AgYW5kDQpNUFJUUCB3aWxsIGJlIGFwcGxpZWQgdG8gYSBuZXcg
bXVsdGlwYXRoIFVQRCBwcm90b2NvbCAod2hlcmVieSB0aGUgc3ViZmxvd3Mgd291bGQgbWFpbnRh
aW4gc29tZSBtaW5pbWFsIHN0YXRlIGFuZCByZWNlaXZlIHNvbWUgbWluaW1hbCBmZWVkYmFjayBp
biByZWxhdGlvbiB0byBlYWNoIHN1YmZsb3cgcGF0aCkuIEZpbmFsbHksIGFuIGFsdGVybmF0aXZl
IHRvIE11bHRpcGF0aCBVRFAgKE1QVURQKSBtYXkgYmUgY2FwYWJsZSBvZiBhcHBseWluZyBjaGFu
bmVsIGNvZGluZyBwcmlvciB0byBzcGxpdHRpbmcgYSBVRFAgZmxvdyBvdmVyIG11bHRpcGxlIHBh
dGhzIKGpIGFuYWxvZ291cyB0byBhIFVEUCBwZXJmb3JtYW5jZSBlbmhhbmNpbmcgcHJveHkuDQpJ
dCB3aWxsIGFsc28gYmUgZXZhbHVhdGVkIGFzIHdlbGwuDQoNCg0KU2luY2UgVURQIHdhcyBvcmln
aW5hbGx5DQpkZXNpZ25lZCB0byBiZSBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgd2UgYXJl
IGJhc2ljYWxseSBhdHRlbXB0aW5nIHRvIG1ha2UgaXQgcmVsaWFibGUgKGF0IGxlYXN0IGF0IGxl
YXN0IG92ZXIgdGhlIGNoYW5uZWwtYm9uZGVkIGxpbmspLCB3ZSB3aWxsIG5lZWQgdG8gZXZhbHVh
dGUgb3VyIGZpbmFsIHJlc3VsdHMgdG8gZW5zdXJlIHRoYXQgd2UgaGF2ZSBub3QgY3JlYXRlZCBz
b21ldGhpbmcgdW53aWVsZHkuICBVbmRlcnN0YW5kaW5nIHdoZXRoZXIgd2UgbmVlZCB0byBkZXZl
bG9wIGEgTVBVRFAgaW1wbGVtZW50YXRpb24gb3IgcGVyZm9ybSBhIG1vZGlmaWNhdGlvbiBhbmQg
dXBkYXRlIG9mIFBQUC1NUCB3aWxsIGFsbCBiZSBwYXJ0IG9mIHRoZSByZXNlYXJjaCBlZmZvcnQu
DQoNCg0KPg0KDQoNCg==

--_000_D18B38072E41Fwilliamdivancicnasagov_
Content-Type: text/html; charset="euc-kr"
Content-ID: <966EC0DBFB55C148AF43C035ECDAD4AA@mail.nasa.gov>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13
cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i
cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog
MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkRvY3VtZW50
aW5nIHRoZSB2YXJpb3VzIHVzZSBjYXNlcyBpcyB1c2VmdWwgYW5kIHNob3VsZCBoZWxwIHdoZW4g
ZW5oYW5jaW5nIHRoZSBwcm90b2NvbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkxl
dCBtZSBrbm93IGhvdyBJIGNhbiBoZWxwLiAmbmJzcDtJIHdvdWxkIGNlcnRhaW5seSBiZSB3aWxs
aW5nIHRvIHB1dCB0b2dldGhlciBhIHNtYWxsIHNlY3Rpb24gb24gY2hhbm5lbC1ib25kaW5nLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2lsbDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh
bWlseTpMdWNpZGEgR3JhbmRlOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xv
cjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0g
bm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklH
SFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVk
aXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv
bGQiPkZyb206IDwvc3Bhbj4mbHQ7QXBwYW5hc2FteSZndDssIFBhbGFuaXZlbGFuICZsdDs8YSBo
cmVmPSJtYWlsdG86cGFsYW5pdmVsYW4uYXBwYW5hc2FteUBpbi52ZXJpem9uLmNvbSI+cGFsYW5p
dmVsYW4uYXBwYW5hc2FteUBpbi52ZXJpem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1heSAyNywgMjAxNSAy
OjUwIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+V2ls
bGlhbSBJdmFuY2ljICZsdDs8YSBocmVmPSJtYWlsdG86d2lsbGlhbS5kLml2YW5jaWNAbmFzYS5n
b3YiPndpbGxpYW0uZC5pdmFuY2ljQG5hc2EuZ292PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h
aWx0bzpPbGl2aWVyLkJvbmF2ZW50dXJlQHVjbG91dmFpbi5iZSI+T2xpdmllci5Cb25hdmVudHVy
ZUB1Y2xvdXZhaW4uYmU8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T2xpdmllci5Cb25h
dmVudHVyZUB1Y2xvdXZhaW4uYmUiPk9saXZpZXIuQm9uYXZlbnR1cmVAdWNsb3V2YWluLmJlPC9h
PiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcEBpZXRmLm9yZyI+bXVs
dGlwYXRodGNwQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0
aHRjcEBpZXRmLm9yZyI+bXVsdGlwYXRodGNwQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBbbXVsdGlwYXRodGNw
XSBXaGF0IGFyZSB0aGUgZXhpc3RpbmcgY2hhbGxlbmdlcyB0byBNdWx0aXBhdGhUQ1AgSW1wbGVt
ZW50YXRpb248YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i
TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj
YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+
DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2
ZXIiPg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSBydGYgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUg
eyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAw
MDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu
cy1zZXJpZiIgc2l6ZT0iMiI+DQo8ZGl2PkhpIFdpbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2
Pg0KPGRpdj5UaGFua3MgZm9yIGFsbCB0aGUgZGV0YWlscy4mbmJzcDsgVGhpcyBpcyBleGFjdGx5
IHdoYXQgSSB3YXMgbG9va2luZyBmb3IgYW5kIHRoaXMgaXMgdmVyeSB1c2VmdWwuPC9kaXY+DQo8
ZGl2PlNob3VsZCB3ZSBub3QgZG9jdW1lbnQgdGhpcyBhbmQgYWRkIHNpbWlsYXIgaW5wdXRzIGZy
b20gZWxzZXdoZXJlLi4uIEkgdGhpbmsgdGhhdCB3aWxsIGJlIHJlYWxseSBwcm9kdWN0aXZlIGZv
ciB0aGlzIFdHLiBUaG91Z2h0cz88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlJlZ2Fy
ZHMsPC9kaXY+DQo8ZGl2PkEuUGFsYW5pdmVsYW48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiND
MDAwMDAiPjxpPkRNVFMtRW5nZywgVmVyaXpvbiBMYWJzPC9pPjwvZm9udD48L2Rpdj4NCjxkaXY+
Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog
SXZhbmNpYywgV2lsbGlhbSBELiAoR1JDLUxDQTApIFs8YSBocmVmPSJtYWlsdG86d2lsbGlhbS5k
Lml2YW5jaWNAbmFzYS5nb3YiPm1haWx0bzp3aWxsaWFtLmQuaXZhbmNpY0BuYXNhLmdvdjwvYT5d
DQo8YnI+DQpTZW50OiBUdWVzZGF5LCBNYXkgMjYsIDIwMTUgODozMyBQTTxicj4NClRvOiA8YSBo
cmVmPSJtYWlsdG86T2xpdmllci5Cb25hdmVudHVyZUB1Y2xvdXZhaW4uYmUiPk9saXZpZXIuQm9u
YXZlbnR1cmVAdWNsb3V2YWluLmJlPC9hPjsgQXBwYW5hc2FteSwgUGFsYW5pdmVsYW47DQo8YSBo
cmVmPSJtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnIj5tdWx0aXBhdGh0Y3BAaWV0Zi5vcmc8
L2E+PGJyPg0KU3ViamVjdDogUmU6IFttdWx0aXBhdGh0Y3BdIFdoYXQgYXJlIHRoZSBleGlzdGlu
ZyBjaGFsbGVuZ2VzIHRvIE11bHRpcGF0aFRDUCBJbXBsZW1lbnRhdGlvbjwvZGl2Pg0KPGRpdj4m
bmJzcDs8L2Rpdj4NCjxkaXY+SSBoYXZlIHJlY2VudGx5IGJlZW4gZnVuZGVkIHRvIGxvb2sgYXQg
c29tZSBOQVNBIHNwZWNpZmljIHByb2JsZW1zIHdpdGggY2hhbm5lbCBib25kaW5nIElyaWRpdW0g
cGhvbmVzIC0gd29yayBzaG91bGQgYmVnaW4gaW4gSnVseS4mbmJzcDsgSSB3aWxsIG5vdCBtYWtl
IHRoZSBQcmFndWUgSUVURiwgYnV0IGhvcGUgdG8gYXR0ZW5kIGEgZmV3IG90aGVycy4mbmJzcDsg
SGVyZSBpcyBob3cgd2UgYXJlIHRyeWluZyB0byB1c2UgTVBUQ1AuJm5ic3A7IElmIE1QVENQIHdv
cmtzDQogd2VsbCB3ZSAmcXVvdDttYXkmcXVvdDsgY29uc2lkZXIgbG9va2luZyBhdCBkZXZlbG9w
aW5nIHNvbWUgdHlwZSBvZiBNUFVEUCwgYnV0IHRoYXQgaXMgVG8gQmUgRGV0ZXJtaW5lZC4mbmJz
cDsgVGhlcmUgbWF5IGJlIGJldHRlciAvIHNpbXBsZXIgc29sdXRpb25zLjwvZGl2Pg0KPGRpdj4m
bmJzcDs8L2Rpdj4NCjxkaXY+LSBXaWxsIEl2YW5jaWM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+
DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgZnVuZGFtZW50YWwgcHJvYmxlbSBvZjwvZGl2
Pg0KPGRpdj5tdWx0aXBhdGggYWdncmVnYXRpb24gaXMgdGhlIGRpZmZpY3VsdHkgb2YgZnVsZmls
bGluZyBhIHJhbmdlIG9mIGNvbmZsaWN0aW5nIGNyaXRlcmlhLiBGb3IgZXhhbXBsZSwgaXQgaXMg
ZGlmZmljdWx0IHRvIHNjaGVkdWxlIElQIHBhY2tldHMgb3ZlciBoZXRlcm9nZW5lb3VzIHBhdGhz
IHdpdGhvdXQgY2F1c2luZyByZW9yZGVyaW5nIGFuZCBwZXJmb3JtYW5jZSBwZW5hbHRpZXMgYXQg
dGhlIHRyYW5zcG9ydCBsYXllci4gSXQgaXMgYWxzbw0KIGhhcmQgdG8gaW1wbGVtZW50IGEgZ2Vu
ZXJpYyBtdWx0aXBhdGggc29sdXRpb24gd2l0aG91dCBtb2RpZnlpbmcgc3RhbmRhcmRpemVkIHBy
b3RvY29scyBvciBjaGFuZ2luZyB0aGlyZC1wYXJ0eSBuZXR3b3JrIGVxdWlwbWVudC48L2Rpdj4N
CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BIHJvYnVzdCBtdWx0
aXBhdGggYWdncmVnYXRpb248L2Rpdj4NCjxkaXY+c29sdXRpb24gc2hvdWxkIGJlIGFibGUgdG8g
Y29wZSB3aXRoIGFueSBraW5kIG9mIHBhdGggaGV0ZXJvZ2VuZWl0eSwgdGhyb3VnaHB1dCBmbHVj
dHVhdGlvbnMsIG9yIGppdHRlci4gU29sdXRpb25zIHNob3VsZCBhbHNvIGJlIGFibGUgdG8gZGVh
bCB3aXRoIHBlcnNpc3RlbnQgcmVvcmRlcmluZyBvZiBkYXRhIHBhY2tldHMuIEZpbmFsbHksIGEg
Y29tcGxldGUgbXVsdGlwYXRoIGFnZ3JlZ2F0aW9uIHNvbHV0aW9uIHNob3VsZCBzdXBwb3J0DQog
YW5kIGJlIGNvbXBhdGlibGUgd2l0aCBhbGwgZXhpc3RpbmcgdHJhbnNwb3J0IHByb3RvY29scyBh
bmQgYXBwbGljYXRpb25zLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k
aXY+DQo8ZGl2PlRoZSBjdXJyZW50IHNvbHV0aW9uICh1c2Ugb24gTkFTQSdzIEF0bW9zcGhlcmlj
ZSBSZXNlYWNoIGFpcmNyYWZ0KSB0byB0aGUgY2hhbm5lbCBtdWx0aXBsZXhpbmcgcHJvYmxlbSAo
Ym9uZGluZyA0IElyaWRpdW0gbW9kZXMgdG8gaW5jcmVhc2U8L2Rpdj4NCjxkaXY+YmFuZHdpZGh0
KSZuYnNwOyBpcyB0byB1c2UgdGhlIFBQUDwvZGl2Pg0KPGRpdj5NdWx0aWxpbmsgUHJvdG9jb2wg
KFBQUC1NUCkuIFRoaXMgaGFzIGJlZW4gc2VydmljZWFibGUsIGJ1dCBoYXMgbnVtZXJvdXMgZmxh
d3MgdGhhdCByZXN1bHQgaW4gbGVzcy10aGFuIG9wdGltYWwgb3BlcmF0aW9ucywgY29zdGluZyBw
cmVjaW91cyB0aW1lIKGpIHBhcnRpY3VsYXJseSBjb25zaWRlcmluZyB0aGUgbGltaXRlZCB0aW1l
IG9mIGFuIGFlcm9uYXV0aWNhbCBzY2llbmNlIHJlc2VhcmNoIGZsaWdodCBhbmQgdGhlIGFzc29j
aWF0ZWQNCiBjb3N0cy4mbmJzcDsgVGh1cywgYSByb2J1c3QsIHJlbGlhYmxlIHNvbHV0aW9uIGlz
IGhpZ2hseSBkZXNpcmFibGUuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8
L2Rpdj4NCjxkaXY+SW4gb3JkZXIgdG8gYmFzZWxpbmUgY3VycmVudDwvZGl2Pg0KPGRpdj5zeXN0
ZW0gb3BlcmF0aW9ucyBhbmQgb2J0YWluIGRhdGEgbmVjZXNzYXJ5IHRvIG1vZGVsIHRoZSBleGlz
dGluZyBpbXBsZW1lbnRhdGlvbiAoYW5kIG91ciBwcm9wb3NlZCBzb2x1dGlvbnMpLCB3ZSBwcm9w
b3NlIHRvIG1lYXN1cmUgdGhlIGN1cnJlbnQgb3BlcmF0aW9ucyBvZiB0aGUgaXJpZGl1bSBjaGFu
bmVscyBhbmQgbW9kZW1zIGFuZCBtb2RlbCB0aGlzIGJlaGF2aW9yLjwvZGl2Pg0KPGRpdj5UaGUg
bW9kZWxzIHdpbGwgYmUgbmVlZGVkIHRvIGVuc3VyZSB0aGF0IHdlIGhhdmUgYSBmdWxsIHVuZGVy
c3RhbmRpbmcgb2YgdGhlIGN1cnJlbnQgZmFpbHVyZSBtZWNoYW5pc21zIGFuZCB2YWxpZGF0ZSBv
dXIgaHlwb3RoZXNpcyB0aGUgUFBQLU1QIGlzIHN1c2NlcHRpYmxlIHRvIGhpZ2ggbG9zcyBhbmQg
dW5yZWxpYWJsZSBsaW5rcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwv
ZGl2Pg0KPGRpdj5OZXh0LCB3ZSBwcm9wb3NlIHRvIHN0dWR5IHRoZTwvZGl2Pg0KPGRpdj51c2Ug
b2YgVENQIEV4dGVuc2lvbnMgZm9yIE11bHRpcGF0aCBPcGVyYXRpb24gd2l0aCBNdWx0aXBsZSBB
ZGRyZXNzZXMgoakgYWxzbyBrbm93IGFzIG11bHRpcGF0aC1UQ1AgKE1QVENQKSChqSB0byBwZXJm
b3JtIHRoZSBjaGFubmVsIGJvbmRpbmcuJm5ic3A7IE11bHRpcGF0aCBUQ1AgKE1QVENQKSBpcyBh
IHNldCBvZiBleHRlbnNpb25zIHRvIHJlZ3VsYXIgVENQIHRvIHByb3ZpZGUgYSBNdWx0aXBhdGgg
VENQIHNlcnZpY2UsIHdoaWNoIGVuYWJsZXMNCiBhIHRyYW5zcG9ydCBjb25uZWN0aW9uIHRvIG9w
ZXJhdGUgYWNyb3NzIG11bHRpcGxlIHBhdGhzIHNpbXVsdGFuZW91c2x5LjwvZGl2Pg0KPGRpdj4m
bmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlVubGlrZSBQUFAtTVAsIE1QVENQ
IGRvZXMgbm90PC9kaXY+DQo8ZGl2PmZyYWdtZW50IHBhY2tldHMgYWNyb3NzIGZsb3dzIGFuZCB0
cmVhdHMgZWFjaCBzdWJmbG93IGluZGVwZW5kZW50bHkuIEFsc28sIHRoZSBkYXRhIHNlcXVlbmNl
IG1hcHBpbmcgc3BlY2lmaWVzIGEgbWFwcGluZyBmcm9tIHN1YmZsb3cgc2VxdWVuY2Ugc3BhY2Ug
dG8gZGF0YSBzZXF1ZW5jZSBzcGFjZS4gQSBtYXBwaW5nIGlzIGZpeGVkLCBpbiB0aGF0IHRoZSBz
dWJmbG93IHNlcXVlbmNlIG51bWJlciBpcyBib3VuZCB0byB0aGUgZGF0YSBzZXF1ZW5jZQ0KIG51
bWJlciBhZnRlciB0aGUgbWFwcGluZyBoYXMgYmVlbiBwcm9jZXNzZWQuPC9kaXY+DQo8ZGl2Pk1Q
VENQPC9kaXY+DQo8ZGl2PmFsbG93cyB0aGUgc2FtZSBkYXRhIHNlcXVlbmNlIG51bWJlciB0byBt
YXBwZWQgdG8gYnkgZGlmZmVyZW50IHN1YmZsb3dzIGZvciByZXRyYW5zbWlzc2lvbiBwdXJwb3Nl
cy4mbmJzcDsgVGh1cywgaWYgb25lIGNoYW5uZWwgKG1vZGVtKSBmYWlscywgdGhlIGZhaWxlZCBz
dWJmbG93IGNhbiBiZSByZXRyYW5zbWl0dGVkIG92ZXIgYW5vdGhlciBwYXRoIChjaGFubmVsKS4g
V2UgYmVsaWV2ZSBzdWNoIG9wZXJhdGlvbiB3aWxsIHJlc3VsdCBpbiBhIHJvYnVzdA0KIGNvbW11
bmljYXRpb24gc3lzdGVtIGFzIHdoZW4gb24gbW9kZW0gbG9vc2VzIGxvY2sgb3IgcmVzdHMsIGl0
IHNob3VsZCBub3QgYWZmZWN0IHRoZSBvdGhlciBzdWJmbG93cyBhbmQgTVBUQ1Agc2hvdWxkIGF1
dG9tYXRpY2FsbHkgYWRhcHQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8
L2Rpdj4NCjxkaXY+VGhpcyBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGRvZXM8L2Rpdj4NCjxkaXY+
bm90IG1hbmRhdGUgYW55IG1lY2hhbmlzbXMgZm9yIGhhbmRsaW5nIHJldHJhbnNtaXNzaW9ucy4g
UmF0aGVyLCB0aGlzIHdpbGwgYmUgZGVwZW5kZW50IHVwb24gbG9jYWwgcG9saWN5LiBBZ2dyZXNz
aXZlIGNvbm5lY3Rpb24tbGV2ZWwgcmV0cmFuc21pc3Npb25zIHBvbGljaWVzIGNvdWxkIGJlIGlt
cGxlbWVudGVkIHdoZXJlIGV2ZXJ5IHBhY2tldCBsb3N0IGF0IHN1YmZsb3cgbGV2ZWwgaXMgcmV0
cmFuc21pdHRlZCBvbiBhIGRpZmZlcmVudA0KIHN1YmZsb3cgKGhlbmNlLCB3YXN0aW5nIGJhbmR3
aWR0aCBidXQgcG9zc2libHkgcmVkdWNpbmcgYXBwbGljYXRpb24tdG8tYXBwbGljYXRpb24gZGVs
YXlzKSwgb3IgY29uc2VydmF0aXZlIHJldHJhbnNtaXNzaW9uIHBvbGljaWVzIHdoZXJlIGNvbm5l
Y3Rpb24tbGV2ZWwgcmV0cmFuc21pdHMgYXJlIG9ubHkgdXNlZCBhZnRlciBhIGZldyBzdWJmbG93
LWxldmVsIHJldHJhbnNtaXNzaW9uIHRpbWVvdXRzIG9jY3VyLiBUaGlzIGlzIGFuIGFyZWEgdGhh
dA0KIHdlIHdpbGwgZXhwZXJpbWVudCB3aXRoLiZuYnNwOyBIYXZpbmcgZ29vZCBjaGFubmVsIGNo
YXJhY3RlcmlzdGljcyBpcyBhbHNvIGNyaXRpY2FsIGZvciB1bmRlcnN0YW5kaW5nIHRoZSB0cmFk
ZSBzcGFjZShoZW5jZSB0aGUgbmVlZCB0byBmaXJzdCBjaGFyYWN0ZXJpemUgdGhlIElyaWRpdW0g
bW9kZW0gcGVyZm9ybWFuY2UpLiBBbHNvLCBNdWx0aXBsZSByZXRyYW5zbWlzc2lvbnMgYXJlIHRy
aWdnZXJzIHRoYXQmbmJzcDsgY2FuIGJlIHVzZWQgdG8gaW5kaWNhdGUNCiB0aGF0IGEgc3ViZmxv
dyBpcyBwZXJmb3JtaW5nIGJhZGx5IGFuZCBjb3VsZCBsZWFkIHRvIGEgaG9zdCByZXNldHRpbmcg
dGhlIHN1YmZsb3cuIEFkZGl0aW9uYWwgcmVzZWFyY2ggaXMgcmVxdWlyZWQgdG8gdW5kZXJzdGFu
ZCB0aGUgaGV1cmlzdGljcyBvZiBob3cgYW5kIHdoZW4gdG8gcmVzZXQgdW5kZXJwZXJmb3JtaW5n
IHN1YmZsb3dzLiBGb3IgZXhhbXBsZSwgYSBoaWdobHkgYXN5bW1ldHJpYyBwYXRoIG1heSBiZSBt
aXNkaWFnbm9zZWQgYXMNCiB1bmRlcnBlcmZvcm1pbmcsIHVubmVjZXNzYXJpbHkgdHJpZ2dlcmlu
ZyBhIHN1YmZsb3cgcmVzZXQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PbmNlIHdl
IGZ1bGx5IHVuZGVyc3RhbmQgTVBUQ1A8L2Rpdj4NCjxkaXY+YXBwbGljYWJpbGl0eSB0byBjaGFu
bmVsIGJvbmRpbmcsIHdlIHdpbGwgdXRpbGl6ZSB0aGF0IGtub3dsZWRnZSB0byBhZGRyZXNzIFVQ
RCBjb21tdW5pY2F0aW9ucy4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWlyY3Jh
ZnQgc3lzdGVtcyB1dGlsaXppbmcgc2F0ZWxsaXRlIGxpbmtzIG9mdGVuIHV0aWxpemUgVURQIHBh
Y2tldHMgdG8gYXZvaWQgVENQqfZzIGlzc3VlcyB3aXRoIGxhdGVuY3kuJm5ic3A7IFNpbmNlIFVQ
RCBkb2VzIG5vdCBjb250YWluIHN0YXRlIG9yIGV4cGxpY2l0IGZlZWRiYWNrLCBkZXZlbG9waW5n
IGEgbXVsdGlwYXRoIFVEUCBpbXBsZW1lbnRhdGlvbiBoYXMgc29tZSB1bmlxdWUgY2hhbGxlbmdl
cyByZWxhdGl2ZSB0byBNUFRDUC4mbmJzcDsgVURQDQogaXMgYSBzaW5nbGUgcGFja2V0IHByb3Rv
Y29sIHdpdGggbm8gc3RhdGUuIFRoZXJlJ3Mgbm8gcmVsYXRpb25zaGlwIGJldHdlZW4gdHdvIFVE
UCBwYWNrZXRzIC0gcmVnYXJkbGVzcyBvZiBzYW1lL2RpZmZlcmVudCBwb3J0IG9yIGFkZHJlc3Nl
cy4gSG93ZXZlciwgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsLCB0d28gVURQIHBhY2tldHMgdGhh
dCB0YWtlIGRpZmZlcmVudCBwYXRocyBjb3VsZCBwcm9kdWNlIGluanVyeSB0byB0aGUgYXBwbGlj
YXRpb24uDQogVGh1cywgcmVvcmRlcmluZyBhbmQgbG9zc2VzIHdpbGwgbmVlZCB0byBiZSBzdHVk
aWVkIGFuZCBhZGRyZXNzZWQuIFdlIHdpbGwgYWxzbyBjb25zaWRlciB0aGUgdXNlIG9mIHRoZSBt
dWx0aXBhdGggUmVhbC1UaW1lIFByb3RvY29sIChNUFJUUCkgYXMgUlRQIGhhcyBzdGF0ZSBhbmQg
Y2FuIGFkb3B0IG1hbnkgb2YgdGhlIGNvbmNlcHRzIG9mPC9kaXY+DQo8ZGl2Pk1QVENQLiZuYnNw
OyZuYnNwOyBMZXNzb25zIGxlYXJuZWQgZnJvbSBvdXIgc3R1ZHkgb2YgTVBUQ1AgYW5kPC9kaXY+
DQo8ZGl2Pk1QUlRQIHdpbGwgYmUgYXBwbGllZCB0byBhIG5ldyBtdWx0aXBhdGggVVBEIHByb3Rv
Y29sICh3aGVyZWJ5IHRoZSBzdWJmbG93cyB3b3VsZCBtYWludGFpbiBzb21lIG1pbmltYWwgc3Rh
dGUgYW5kIHJlY2VpdmUgc29tZSBtaW5pbWFsIGZlZWRiYWNrIGluIHJlbGF0aW9uIHRvIGVhY2gg
c3ViZmxvdyBwYXRoKS4gRmluYWxseSwgYW4gYWx0ZXJuYXRpdmUgdG8gTXVsdGlwYXRoIFVEUCAo
TVBVRFApIG1heSBiZSBjYXBhYmxlIG9mIGFwcGx5aW5nDQogY2hhbm5lbCBjb2RpbmcgcHJpb3Ig
dG8gc3BsaXR0aW5nIGEgVURQIGZsb3cgb3ZlciBtdWx0aXBsZSBwYXRocyChqSBhbmFsb2dvdXMg
dG8gYSBVRFAgcGVyZm9ybWFuY2UgZW5oYW5jaW5nIHByb3h5LjwvZGl2Pg0KPGRpdj5JdCB3aWxs
IGFsc28gYmUgZXZhbHVhdGVkIGFzIHdlbGwuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp
dj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2luY2UgVURQIHdhcyBvcmlnaW5hbGx5PC9kaXY+DQo8ZGl2
PmRlc2lnbmVkIHRvIGJlIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0IGFuZCB3ZSBhcmUgYmFzaWNh
bGx5IGF0dGVtcHRpbmcgdG8gbWFrZSBpdCByZWxpYWJsZSAoYXQgbGVhc3QgYXQgbGVhc3Qgb3Zl
ciB0aGUgY2hhbm5lbC1ib25kZWQgbGluayksIHdlIHdpbGwgbmVlZCB0byBldmFsdWF0ZSBvdXIg
ZmluYWwgcmVzdWx0cyB0byBlbnN1cmUgdGhhdCB3ZSBoYXZlIG5vdCBjcmVhdGVkIHNvbWV0aGlu
ZyB1bndpZWxkeS4mbmJzcDsgVW5kZXJzdGFuZGluZw0KIHdoZXRoZXIgd2UgbmVlZCB0byBkZXZl
bG9wIGEgTVBVRFAgaW1wbGVtZW50YXRpb24gb3IgcGVyZm9ybSBhIG1vZGlmaWNhdGlvbiBhbmQg
dXBkYXRlIG9mIFBQUC1NUCB3aWxsIGFsbCBiZSBwYXJ0IG9mIHRoZSByZXNlYXJjaCBlZmZvcnQu
PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0Ozwv
ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2ZvbnQ+PC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D18B38072E41Fwilliamdivancicnasagov_--


From nobody Thu May 28 02:29:40 2015
Return-Path: 
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D01A0282 for ; Thu, 28 May 2015 02:29:38 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IW-bh_D4MEm for ; Thu, 28 May 2015 02:29:34 -0700 (PDT)
Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75581A0222 for ; Thu, 28 May 2015 02:29:33 -0700 (PDT)
From: "Appanasamy, Palanivelan" 
To: "Ivancic, William D. (GRC-LCA0)" , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" , "Harsha, Chetan H" 
X-IronPort-AV: E=Sophos; i="5.13,512,1427731200"; d="scan'208,217"; a="49571510"
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2015 17:29:30 +0800
Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]:47115) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Yxu81-0005LK-3V; Thu, 28 May 2015 09:29:29 +0000
Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Yxu80-0005LH-3W; Thu, 28 May 2015 09:29:28 +0000
Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Thu, 28 May 2015 14:59:26 +0530
Importance: high
X-Priority: 1
Date: Thu, 28 May 2015 14:59:24 +0530
Thread-Topic: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
Thread-Index: AQHQlyBnNJDQUosVZ0qhXgCbpw23qp2ObMgAgAD3FkCAAHkVAIABRdDw
Message-ID: <70AEAEC90FCAE0408586E94F491A07EC047B6C36DE@MS-BAN-E7MB01.intl1.one.verizon.com>
References: <70AEAEC90FCAE0408586E94F491A07EC047B4E21D7@MS-BAN-E7MB01.intl1.one.verizon.com> <556376D5.9050409@uclouvain.be>  <70AEAEC90FCAE0408586E94F491A07EC047B6C32CB@MS-BAN-E7MB01.intl1.one.verizon.com> 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_70AEAEC90FCAE0408586E94F491A07EC047B6C36DEMSBANE7MB01in_"
MIME-Version: 1.0
X-VZ-EMEA-INT-SIG: 6cf6e015cb617b4b28d5b65d4cdcad68
X-APAC-E2-SIG: 6cf6e015cb617b4b28d5b65d4cdcad68
Archived-At: 
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTCP Implementation
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-path extensions for TCP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 May 2015 09:29:38 -0000

--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C36DEMSBANE7MB01in_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Wonderful. That will be a good start. I am getting few guys together on thi=
s and like to get to meaningful contributions from all those involved. Than=
ks.

Regards,
A.Palanivelan
DMTS-Engg, Verizon Labs


From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]
Sent: Wednesday, May 27, 2015 6:31 PM
To: Appanasamy, Palanivelan; Olivier.Bonaventure@uclouvain.be; multipathtcp=
@ietf.org
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation
Importance: High

Documenting the various use cases is useful and should help when enhancing =
the protocol.

Let me know how I can help.  I would certainly be willing to put together a=
 small section on channel-bonding.

Will

From: , Palanivelan >
Date: Wednesday, May 27, 2015 2:50 AM
To: William Ivancic >, "Olivier.Bonaventure@uclouvain.be" >, "multipathtcp@ietf.org" >
Subject: RE: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation

Hi Will,

Thanks for all the details.  This is exactly what I was looking for and thi=
s is very useful.
Should we not document this and add similar inputs from elsewhere... I thin=
k that will be really productive for this WG. Thoughts?

Regards,
A.Palanivelan
DMTS-Engg, Verizon Labs

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]
Sent: Tuesday, May 26, 2015 8:33 PM
To: Olivier.Bonaventure@uclouvain.be; Appanasamy, Palanivelan; multipathtcp@ietf.org
Subject: Re: [multipathtcp] What are the existing challenges to MultipathTC=
P Implementation

I have recently been funded to look at some NASA specific problems with cha=
nnel bonding Iridium phones - work should begin in July.  I will not make t=
he Prague IETF, but hope to attend a few others.  Here is how we are trying=
 to use MPTCP.  If MPTCP works well we "may" consider looking at developing=
 some type of MPUDP, but that is To Be Determined.  There may be better / s=
impler solutions.

- Will Ivancic


The fundamental problem of
multipath aggregation is the difficulty of fulfilling a range of conflictin=
g criteria. For example, it is difficult to schedule IP packets over hetero=
geneous paths without causing reordering and performance penalties at the t=
ransport layer. It is also hard to implement a generic multipath solution w=
ithout modifying standardized protocols or changing third-party network equ=
ipment.


A robust multipath aggregation
solution should be able to cope with any kind of path heterogeneity, throug=
hput fluctuations, or jitter. Solutions should also be able to deal with pe=
rsistent reordering of data packets. Finally, a complete multipath aggregat=
ion solution should support and be compatible with all existing transport p=
rotocols and applications.


The current solution (use on NASA's Atmospherice Reseach aircraft) to the c=
hannel multiplexing problem (bonding 4 Iridium modes to increase
bandwidht)  is to use the PPP
Multilink Protocol (PPP-MP). This has been serviceable, but has numerous fl=
aws that result in less-than optimal operations, costing precious time =AD =
particularly considering the limited time of an aeronautical science resear=
ch flight and the associated costs.  Thus, a robust, reliable solution is h=
ighly desirable.


In order to baseline current
system operations and obtain data necessary to model the existing implement=
ation (and our proposed solutions), we propose to measure the current opera=
tions of the iridium channels and modems and model this behavior.
The models will be needed to ensure that we have a full understanding of th=
e current failure mechanisms and validate our hypothesis the PPP-MP is susc=
eptible to high loss and unreliable links.


Next, we propose to study the
use of TCP Extensions for Multipath Operation with Multiple Addresses =AD a=
lso know as multipath-TCP (MPTCP) =AD to perform the channel bonding.  Mult=
ipath TCP (MPTCP) is a set of extensions to regular TCP to provide a Multip=
ath TCP service, which enables a transport connection to operate across mul=
tiple paths simultaneously.


Unlike PPP-MP, MPTCP does not
fragment packets across flows and treats each subflow independently. Also, =
the data sequence mapping specifies a mapping from subflow sequence space t=
o data sequence space. A mapping is fixed, in that the subflow sequence num=
ber is bound to the data sequence number after the mapping has been process=
ed.
MPTCP
allows the same data sequence number to mapped to by different subflows for=
 retransmission purposes.  Thus, if one channel (modem) fails, the failed s=
ubflow can be retransmitted over another path (channel). We believe such op=
eration will result in a robust communication system as when on modem loose=
s lock or rests, it should not affect the other subflows and MPTCP should a=
utomatically adapt.


This protocol specification does
not mandate any mechanisms for handling retransmissions. Rather, this will =
be dependent upon local policy. Aggressive connection-level retransmissions=
 policies could be implemented where every packet lost at subflow level is =
retransmitted on a different subflow (hence, wasting bandwidth but possibly=
 reducing application-to-application delays), or conservative retransmissio=
n policies where connection-level retransmits are only used after a few sub=
flow-level retransmission timeouts occur. This is an area that we will expe=
riment with.  Having good channel characteristics is also critical for unde=
rstanding the trade space(hence the need to first characterize the Iridium =
modem performance). Also, Multiple retransmissions are triggers that  can b=
e used to indicate that a subflow is performing badly and could lead to a h=
ost resetting the subflow. Additional research is required to understand th=
e heuristics of how and when to reset underperforming subflows. For example=
, a highly asymmetric path may be misdiagnosed as underperforming, unnecess=
arily triggering a subflow reset.

Once we fully understand MPTCP
applicability to channel bonding, we will utilize that knowledge to address=
 UPD communications.

Aircraft systems utilizing satellite links often utilize UDP packets to avo=
id TCP=B9s issues with latency.  Since UPD does not contain state or explic=
it feedback, developing a multipath UDP implementation has some unique chal=
lenges relative to MPTCP.  UDP is a single packet protocol with no state. T=
here's no relationship between two UDP packets - regardless of same/differe=
nt port or addresses. However, at the application level, two UDP packets th=
at take different paths could produce injury to the application. Thus, reor=
dering and losses will need to be studied and addressed. We will also consi=
der the use of the multipath Real-Time Protocol (MPRTP) as RTP has state an=
d can adopt many of the concepts of
MPTCP.   Lessons learned from our study of MPTCP and
MPRTP will be applied to a new multipath UPD protocol (whereby the subflows=
 would maintain some minimal state and receive some minimal feedback in rel=
ation to each subflow path). Finally, an alternative to Multipath UDP (MPUD=
P) may be capable of applying channel coding prior to splitting a UDP flow =
over multiple paths =AD analogous to a UDP performance enhancing proxy.
It will also be evaluated as well.


Since UDP was originally
designed to be an unreliable transport and we are basically attempting to m=
ake it reliable (at least at least over the channel-bonded link), we will n=
eed to evaluate our final results to ensure that we have not created someth=
ing unwieldy.  Understanding whether we need to develop a MPUDP implementat=
ion or perform a modification and update of PPP-MP will all be part of the =
research effort.


>



--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C36DEMSBANE7MB01in_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Wonderful=
. That will be a good start. I am getting few guys together on this and lik=
e to get to meaningful contributions from all those involved. Thanks.<=
/o:p>
 
Regards,
A.Palanivelan
D=
MTS-Engg, Verizon Labs
 
 
From: Ivancic, W=
illiam D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov] 
Sent: W=
ednesday, May 27, 2015 6:31 PM
To: Appanasamy, Palanivelan; Olivi=
er.Bonaventure@uclouvain.be; multipathtcp@ietf.org
Subject: Re: [=
multipathtcp] What are the existing challenges to MultipathTCP Implementati=
on
Importance: High
 
Documenting th=
e various use cases is useful and should help when enhancing the protocol.<=
o:p>
 =

Let me know how I can help.=
  I would certainly be willing to put together a small section on chan=
nel-bonding.
 
Will
 
From: <A=
ppanasamy>, Palanivelan <palanivelan.appanasamy@in.verizon.com>
Date: =
Wednesday, May 27, 2015 2:50 AM
To: William Ivancic <william.d.ivancic@nasa.gov>, =
"Olivier.Bonaventu=
re@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: RE:=
 [multipathtcp] What are the existing challenges to MultipathTCP Implementa=
tion
 <=
/o:p>
Hi Will,
=
 
Thanks for=
 all the details.  This is exactly what I was looking for and this is =
very useful.
Shou=
ld we not document this and add similar inputs from elsewhere... I think th=
at will be really productive for this WG. Thoughts?
 
<=
p class=3DMsoNormal>Regards,
A.Palanivelan
DMTS-Engg, Verizon Labs
 
-----Original Message-----
From: Ivanci=
c, William D. (GRC-LCA0) [mai=
lto:william.d.ivancic@nasa.gov] 
Sent: Tuesday, May 26, 2015 8:33 PM=

To: Olivier.Bonaven=
ture@uclouvain.be; Appanasamy, Palanivelan; multipathtcp@ietf.org
Subject: Re: [multipathtcp] What=
 are the existing challenges to MultipathTCP Implementation
 
I have recently been funded to look at som=
e NASA specific problems with channel bonding Iridium phones - work should =
begin in July.  I will not make the Prague IETF, but hope to attend a =
few others.  Here is how we are trying to use MPTCP.  If MPTCP wo=
rks well we "may" consider looking at developing some type of MPU=
DP, but that is To Be Determined.  There may be better / simpler solut=
ions.
 =

- Will Ivancic
 
 
The fundamental problem of
multipath aggregation is the diff=
iculty of fulfilling a range of conflicting criteria. For example, it is di=
fficult to schedule IP packets over heterogeneous paths without causing reo=
rdering and performance penalties at the transport layer. It is also hard t=
o implement a generic multipath solution without modifying standardized pro=
tocols or changing third-party network equipment.
 
 
A robust multipath aggregation
solution should be able to cope with any kind of=
 path heterogeneity, throughput fluctuations, or jitter. Solutions should a=
lso be able to deal with persistent reordering of data packets. Finally, a =
complete multipath aggregation solution should support and be compatible wi=
th all existing transport protocols and applications.
=

 
 
The current solution (use on NASA's Atmospherice Reseach =
aircraft) to the channel multiplexing problem (bonding 4 Iridium modes to i=
ncrease
bandwidht=
)  is to use the PPP
Multilink Protocol (PPP-MP). This has been serviceable, but has nu=
merous flaws that result in less-than optimal operations, costing precious =
time =AD particularly considering the limited time of an aeronautical scien=
ce research flight and the associated costs.  Thus, a robust, reliable=
 solution is highly desirable.
 
<=
span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:bla=
ck'> 
In ord=
er to baseline current
system operations and obtain data necessary to model the existing imp=
lementation (and our proposed solutions), we propose to measure the current=
 operations of the iridium channels and modems and model this behavior.
The models will be n=
eeded to ensure that we have a full understanding of the current failure me=
chanisms and validate our hypothesis the PPP-MP is susceptible to high loss=
 and unreliable links.
 
&nbs=
p;
Next, we propo=
se to study the
u=
se of TCP Extensions for Multipath Operation with Multiple Addresses =AD al=
so know as multipath-TCP (MPTCP) =AD to perform the channel bonding.  =
Multipath TCP (MPTCP) is a set of extensions to regular TCP to provide a Mu=
ltipath TCP service, which enables a transport connection to operate across=
 multiple paths simultaneously.
 
=
 
Unlik=
e PPP-MP, MPTCP does not
fragment packets across flows and treats each subflow independently=
. Also, the data sequence mapping specifies a mapping from subflow sequence=
 space to data sequence space. A mapping is fixed, in that the subflow sequ=
ence number is bound to the data sequence number after the mapping has been=
 processed.
MPTCP=

allows the same =
data sequence number to mapped to by different subflows for retransmission =
purposes.  Thus, if one channel (modem) fails, the failed subflow can =
be retransmitted over another path (channel). We believe such operation wil=
l result in a robust communication system as when on modem looses lock or r=
ests, it should not affect the other subflows and MPTCP should automaticall=
y adapt.
 =

 
This protocol specificatio=
n does
not mandat=
e any mechanisms for handling retransmissions. Rather, this will be depende=
nt upon local policy. Aggressive connection-level retransmissions policies =
could be implemented where every packet lost at subflow level is retransmit=
ted on a different subflow (hence, wasting bandwidth but possibly reducing =
application-to-application delays), or conservative retransmission policies=
 where connection-level retransmits are only used after a few subflow-level=
 retransmission timeouts occur. This is an area that we will experiment wit=
h.  Having good channel characteristics is also critical for understan=
ding the trade space(hence the need to first characterize the Iridium modem=
 performance). Also, Multiple retransmissions are triggers that  can b=
e used to indicate that a subflow is performing badly and could lead to a h=
ost resetting the subflow. Additional research is required to understand th=
e heuristics of how and when to reset underperforming subflows. For example=
, a highly asymmetric path may be misdiagnosed as underperforming, unnecess=
arily triggering a subflow reset.
 
Once we fully understand MPTCP
applicability to channel bonding, we will utilize tha=
t knowledge to address UPD communications. 
 
Aircraft systems utilizing satellite links often utilize =
UDP packets to avoid TCP=B9s issues with latency.  Since UPD does not =
contain state or explicit feedback, developing a multipath UDP implementati=
on has some unique challenges relative to MPTCP.  UDP is a single pack=
et protocol with no state. There's no relationship between two UDP packets =
- regardless of same/different port or addresses. However, at the applicati=
on level, two UDP packets that take different paths could produce injury to=
 the application. Thus, reordering and losses will need to be studied and a=
ddressed. We will also consider the use of the multipath Real-Time Protocol=
 (MPRTP) as RTP has state and can adopt many of the concepts of<=
/span>
MPTCP.   Lessons l=
earned from our study of MPTCP and
MPRTP will be applied to a new multipath UPD protocol (wh=
ereby the subflows would maintain some minimal state and receive some minim=
al feedback in relation to each subflow path). Finally, an alternative to M=
ultipath UDP (MPUDP) may be capable of applying channel coding prior to spl=
itting a UDP flow over multiple paths =AD analogous to a UDP performance en=
hancing proxy.
It=
 will also be evaluated as well.
 
 
Si=
nce UDP was originally
designed to be an unreliable transport and we are basically attemptin=
g to make it reliable (at least at least over the channel-bonded link), we =
will need to evaluate our final results to ensure that we have not created =
something unwieldy.  Understanding whether we need to develop a MPUDP =
implementation or perform a modification and update of PPP-MP will all be p=
art of the research effort.
 
 
>=
 
 
 <=
/p>
=

--_000_70AEAEC90FCAE0408586E94F491A07EC047B6C36DEMSBANE7MB01in_--