From nobody Tue May 3 00:49:19 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9627B12D51C; Tue, 3 May 2016 00:49:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503074917.7451.20321.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 00:49:17 -0700 Archived-At: Cc: multipathtcp@ietf.org, mptcp-chairs@ietf.org, ietf@kuehlewind.net Subject: [multipathtcp] mptcp - New Meeting Session Request for IETF 96 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 07:49:17 -0000 A new meeting session request has just been submitted by Philip Eardley, a Chair of the mptcp working group. --------------------------------------------------------- Working Group Name: Multipath TCP Area Name: Transport Area Session Requester: Philip Eardley Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: ippm tcpinc tcpm tsvarea tsvwg lmap tls Second Priority: taps netext mif iccrg rtcweb Third Priority: nfvrg sdnrg Special Requests: sessions on separate days - preferably separated by a day. please avoid any transport area BoFs --------------------------------------------------------- From nobody Tue May 17 23:28:42 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A412D0DA for ; Tue, 17 May 2016 23:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP25AwYLvs0x for ; Tue, 17 May 2016 23:28:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98BD12D0D1 for ; Tue, 17 May 2016 23:28:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E738B22CDFD; Wed, 18 May 2016 08:28:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C61224C06C; Wed, 18 May 2016 08:28:29 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 08:28:25 +0200 From: To: "Ivancic, William D. (GRC-LCA0)" , "JACQUENET Christian IMT/OLN" Thread-Topic: draft-boucadair-mptcp-plain-mode-06 Thread-Index: AQHRlNFDxf3fhSmS+EK/6L7CEYQck5++cbAw Date: Wed, 18 May 2016 06:28:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.18.60316 Archived-At: Cc: MultiPath WG Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-06 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 06:28:42 -0000 Hi Ivan, Apologies for the delay to answer this message.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov] > Envoy=E9=A0: mardi 12 avril 2016 17:38 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN > Cc=A0: MultiPath WG > Objet=A0: draft-boucadair-mptcp-plain-mode-06 >=20 > Mohamed and/or Christian, >=20 > Can you provide some clarification regarding the plain-mode draft? >=20 > I am interested in something like Multipath UDP and this draft appears to > handle that architecture. My question is, =B3Are the MP-TCP subflows > recombined such that the UDP datagram order is maintained coming out of > the concentrator proxy?" [Med] Yes.=20 >=20 > Also, will MP-TCP in plain-mode make adjustments if a link goes down or = a > new link becomes available? [Med] Yes, the plain mode relies on the full set of MPTCP features. Subflow= s are created/deleted based on local triggers, signals received from the co= ncentrator, processing a packet (e.g., RST), etc.=20 >=20 >=20 > The CPE and the Concentrator establish a set of MPTCP subflows. > These subflows are used to transport UDP datagrams that are > distributed among existent subflows. > ------- > "TCP session tracking may not be enabled for the set of subflows > that are dedicated to transport UDP traffic.=B2 > ------ >=20 > The establishment of these subflows is not conditioned by > the receipt of UDP packets; instead, these subflows are initiated > upon CPE reboot or when network conditions change (e.g., whenever a > new Concentrator is discovered or a new IP address is assigned to the > Concentrator). Additional MPTCP connections may be established to > anticipate UDP traffic to be distributed among several paths. The > maximum number of MPTCP connections that can be dedicated to UDP > traffic may be configured locally to the CPE and the Concentrator. > How this parameter is configured is implementation and deployment- > specific. [Med] We are working on an updated version with more details.=20 From nobody Thu May 19 22:46:58 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2212D69D; Thu, 19 May 2016 22:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4HHBiXag8Gx; Thu, 19 May 2016 22:46:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177BF12D69B; Thu, 19 May 2016 22:46:53 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 37477206A2; Fri, 20 May 2016 07:46:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 132554005B; Fri, 20 May 2016 07:46:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Fri, 20 May 2016 07:46:52 +0200 From: To: MultiPath WG Thread-Topic: draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09Mw== Date: Fri, 20 May 2016 05:46:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 05:46:56 -0000 Dear all,=20 An updated version of the specification is available online: https://datatr= acker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?include_text=3D1. This= version takes into account comments that were received during the IETF mee= ting and other bilateral meetings. The authors do think that this effort is within the scope of this WG, espec= ially this part of the charter:=20 "Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues." We would like to formally ask the WG to consider adoption of this draft. Comments, suggestions, and questions are more than welcome. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 19 mai 2016 17:45 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-mptcp-plain-mode-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : An MPTCP Option for Network-Assisted MPTCP > Deployments: Plain Transport Mode > Authors : Mohamed Boucadair > Christian Jacquenet > Denis Behaghel > Stefano Secci > Wim Henderickx > Robert Skog > Olivier Bonaventure > Suresh Vinapamula > SungHoon Seo > Filename : draft-boucadair-mptcp-plain-mode-07.txt > Pages : 31 > Date : 2016-05-19 >=20 > Abstract: > One of the promising deployment scenarios for Multipath TCP (MPTCP) > is to enable a Customer Premises Equipment (CPE) that is connected to > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its > network attachments. Because of the lack of MPTCP support at the > server side, some service providers now consider a network-assisted > model that relies upon the activation of a dedicated function called > MPTCP concentrator. This document focuses on a deployment scheme > where the identity of the MPTCP concentrator(s) is explicitly > configured on connected hosts. >=20 > This document specifies an MPTCP option that is used to avoid the > encapsulation of packets and out-of-band signaling between the CPE > and the MPTCP concentrator. Also, this document specifies how UDP > traffic, in particular, can be distributed among available paths by > leveraging MPTCP capabilities. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-mptcp-plain-mode-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 24 17:44:17 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F412112B025 for ; Tue, 24 May 2016 17:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlsRz_qrMr4o for ; Tue, 24 May 2016 17:44:14 -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 A0A1012D5E2 for ; Tue, 24 May 2016 17:44:14 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 May 2016 01:44:10 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 25 May 2016 01:44:11 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 01:44:11 +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.1104.000; Wed, 25 May 2016 01:44:11 +0100 From: To: Thread-Topic: MPTCP Interim (audio) - doodle for date Thread-Index: AQHRth6Nemh+Uzfxw028rjLRhnBDPw== Date: Wed, 25 May 2016 00:44:10 +0000 Message-ID: <1464137048262.13874@bt.com> References: <260545774.2496927.1463995812803.POLL_ADMIN_PARTICIPATELINK@worker2.doodle.com> In-Reply-To: <260545774.2496927.1463995812803.POLL_ADMIN_PARTICIPATELINK@worker2.doodle.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] MPTCP Interim (audio) - doodle for date X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 00:44:17 -0000 Hi,=0A= http://doodle.com/poll/9ne8wz67tdrtxzk2 =0A= =0A= In order to try and make good progress on draft-ietf-mptcp-rfc6824bis, we'd= like to have an interim meeting by audio. The proposal is sometime week of= 20th June. In the past we've found that 3pm GMT/UTC is a reasonable compro= mise for the time (we can adjust this if it isn't a suitable time). Hopeful= ly we can complete the call in less than 1 hour, but we'll book a timeslot = of 1.5 hours. Please fill in the doodle with the dates you can make. =0A= =0A= The topic for the call will be the proposal for a generic alternative keyin= g mechanism (support for front-end proxies) from Alan F & Christoph P - the= topic has been discussed before, and the detailed proposal will be distrib= uted soon. =0A= =0A= We believe that this is the only significant functional addition that has = wide-scale interest (ie beyond what's already in the bis doc) (*). Therefor= e our proposal is to hold a WG Last Call on the draft after the interim and= in the period leading up to the IETF. So that we can discuss issues during= the Berlin meeting. Beyond that, our current thinking is that we should ha= ve some implementation before progressing the doc to the IESG (and that exp= erience may of course lead to mods to the doc). =0A= =0A= (*) one of the things we'll ask in the WGLC is whether people think the doc= does include all the additional functionality that people want. Of course = you can raise things before the wglc. =0A= =0A= Best wishes,=0A= phil & Yoshi = From nobody Wed May 25 00:27:22 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654312D5F7; Wed, 25 May 2016 00:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsyjE1Ijo9_D; Wed, 25 May 2016 00:27:18 -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 E48B612D540; Wed, 25 May 2016 00:27:17 -0700 (PDT) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BFF5F278497; Wed, 25 May 2016 16:27:15 +0900 (JST) Received: by mail-yw0-f176.google.com with SMTP id c127so39471955ywb.1; Wed, 25 May 2016 00:27:15 -0700 (PDT) X-Gm-Message-State: ALyK8tISwmAWiHBV5ql+sbJ2Oxp/BvWa97bWaKqdSznYcrFfjazJuDPfjroGWq2o5soO+1DcIsjpWMNf8Y/xCg== MIME-Version: 1.0 X-Received: by 10.129.116.131 with SMTP id p125mr1507479ywc.201.1464161234358; Wed, 25 May 2016 00:27:14 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Wed, 25 May 2016 00:27:14 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 00:27:14 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a1147f726449f050533a59a1b Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:27:21 -0000 --001a1147f726449f050533a59a1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, I might want to see more feedback before the adoption call. I've read the draft, but I think I still have some unclear points in the draft. I particularly would like to understand the following points as starting point. Please let me know if I miss something. 1: This method requires CPEs to convert UDP or TCP into MPTCP and requires Concentrators to convert back MPTCP into UDP or TCP. This could be rather complex process than other approach such as GRE. So, what's the benefits to utilize MPTCP here? I think the draft should describe some useful scenarios to use MPTCP. 2: Including data in SYN is allowed in RFC793, but I'm not very sure how many implementations actually accept it. I think the draft should discuss this point. Also, what will happen if PM option is included in the payload, but it is removed by the middleboxes? Thanks, -- Yoshi On Thu, May 19, 2016 at 10:46 PM, wrote: > Dear all, > > An updated version of the specification is available online: > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?includ= e_text=3D1. > This version takes into account comments that were received during the IE= TF > meeting and other bilateral meetings. > > The authors do think that this effort is within the scope of this WG, > especially this part of the charter: > > "Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is MPTCP-enabled. > For example, potentially helping MPTCP's incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts as > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what real > problems an MPTCP-enabled middlebox might solve, how it would impact the > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, and > the likely feasibility of solving the technical and security issues." > > We would like to formally ask the WG to consider adoption of this draft. > > Comments, suggestions, and questions are more than welcome. > > Cheers, > Med > > > -----Message d'origine----- > > De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > > internet-drafts@ietf.org > > Envoy=C3=A9 : jeudi 19 mai 2016 17:45 > > =C3=80 : i-d-announce@ietf.org > > Objet : I-D Action: draft-boucadair-mptcp-plain-mode-07.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : An MPTCP Option for Network-Assisted MPTCP > > Deployments: Plain Transport Mode > > Authors : Mohamed Boucadair > > Christian Jacquenet > > Denis Behaghel > > Stefano Secci > > Wim Henderickx > > Robert Skog > > Olivier Bonaventure > > Suresh Vinapamula > > SungHoon Seo > > Filename : draft-boucadair-mptcp-plain-mode-07.txt > > Pages : 31 > > Date : 2016-05-19 > > > > Abstract: > > One of the promising deployment scenarios for Multipath TCP (MPTCP) > > is to enable a Customer Premises Equipment (CPE) that is connected t= o > > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of it= s > > network attachments. Because of the lack of MPTCP support at the > > server side, some service providers now consider a network-assisted > > model that relies upon the activation of a dedicated function called > > MPTCP concentrator. This document focuses on a deployment scheme > > where the identity of the MPTCP concentrator(s) is explicitly > > configured on connected hosts. > > > > This document specifies an MPTCP option that is used to avoid the > > encapsulation of packets and out-of-band signaling between the CPE > > and the MPTCP concentrator. Also, this document specifies how UDP > > traffic, in particular, can be distributed among available paths by > > leveraging MPTCP capabilities. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-mptcp-plain-mode-07 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a1147f726449f050533a59a1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

I might want to see more feedba= ck before the adoption call.
I've read the draft, but I think= I still have some unclear points in the draft.=C2=A0

<= div>I particularly would like to understand the following points as startin= g point. Please let me know if I miss something.

1= : This method requires CPEs to convert UDP or TCP into MPTCP and requires C= oncentrators to convert back MPTCP into UDP or TCP. This could be rather co= mplex process than other approach such as GRE. So, what's the benefits = to utilize MPTCP here? I think the draft should describe some useful scenar= ios to use MPTCP.

2: Including data in SYN is allo= wed in RFC793, but I'm not very sure how many implementations actually = accept it. I think the draft should discuss this point. Also, what will hap= pen if PM option is included in the payload, but it is removed by the middl= eboxes?

Thanks,
--
Yoshi



On Thu, May 19, 2016 at 10:46 PM, <<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com> wrote:
= Dear all,

An updated version of the specification is available online: https://datatracker.ietf.org/do= c/draft-boucadair-mptcp-plain-mode/?include_text=3D1. This version take= s into account comments that were received during the IETF meeting and othe= r bilateral meetings.

The authors do think that this effort is within the scope of this WG, espec= ially this part of the charter:

"Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by
allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially
helping some mobility scenarios, where the middlebox acts as an anchor
between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues."<= br>
We would like to formally ask the WG to consider adoption of this draft.
Comments, suggestions, and questions are more than welcome.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
> internet-drafts@ietf.org
> Envoy=C3=A9=C2=A0: jeudi 19 mai 2016 17:45
> =C3=80=C2=A0: i-d-announce@ie= tf.org
> Objet=C2=A0: I-D Action: draft-boucadair-mptcp-plain-mode-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: An MPTCP Option for Network-Assisted MPTCP
> Deployments: Plain Transport Mode
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Mohamed Boucadair
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Christian Jacquenet
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Denis Behaghel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefano Secci
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Wim Henderickx
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Robert Skog
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Olivier Bonaventure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Suresh Vinapamula
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SungHoon Seo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= boucadair-mptcp-plain-mode-07.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 31
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-05-19
>
> Abstract:
>=C2=A0 =C2=A0 One of the promising deployment scenarios for Multipath T= CP (MPTCP)
>=C2=A0 =C2=A0 is to enable a Customer Premises Equipment (CPE) that is = connected to
>=C2=A0 =C2=A0 multiple networks (e.g., DSL, LTE, WLAN) to optimize the = usage of its
>=C2=A0 =C2=A0 network attachments.=C2=A0 Because of the lack of MPTCP s= upport at the
>=C2=A0 =C2=A0 server side, some service providers now consider a networ= k-assisted
>=C2=A0 =C2=A0 model that relies upon the activation of a dedicated func= tion called
>=C2=A0 =C2=A0 MPTCP concentrator.=C2=A0 This document focuses on a depl= oyment scheme
>=C2=A0 =C2=A0 where the identity of the MPTCP concentrator(s) is explic= itly
>=C2=A0 =C2=A0 configured on connected hosts.
>
>=C2=A0 =C2=A0 This document specifies an MPTCP option that is used to a= void the
>=C2=A0 =C2=A0 encapsulation of packets and out-of-band signaling betwee= n the CPE
>=C2=A0 =C2=A0 and the MPTCP concentrator.=C2=A0 Also, this document spe= cifies how UDP
>=C2=A0 =C2=A0 traffic, in particular, can be distributed among availabl= e paths by
>=C2=A0 =C2=A0 leveraging MPTCP capabilities.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/= doc/draft-boucadair-mptcp-plain-mode/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draf= t-boucadair-mptcp-plain-mode-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfc= diff?url2=3Ddraft-boucadair-mptcp-plain-mode-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--001a1147f726449f050533a59a1b-- From nobody Wed May 25 00:51:04 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CF712D10C; Wed, 25 May 2016 00:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUA7KeGX8lTc; Wed, 25 May 2016 00:51:01 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB512D1D7; Wed, 25 May 2016 00:51:01 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2BEAE67DABF; Wed, 25 May 2016 09:50:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 2BEAE67DABF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1464162649; bh=C19c8aX49ICbdMiIR0APphGLifBtiOYoNW7D0RIqjU8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=CstL55yzdfj5nYjhHgdCFAd0XEUkuR4NgbNp0g1HvnLpgDOSdQgoPnMsjTewraTIf CRFOa/zmJWJyZGEQo5SGf4F/WmMg9Y3ZMyD8+G4VFhmMjNEduw8jtToI5/DeV6Z70o gedrS+bdKTimwOLzTWayM3yYz39fLHwZb9sIOhpU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at smtp-2 References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Yoshifumi Nishida , mohamed.boucadair@orange.com From: Olivier Bonaventure Message-ID: Date: Wed, 25 May 2016 09:50:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-Information: X-SGSI-MailScanner-ID: 2BEAE67DABF.A6F21 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 25 May 2016 07:51:03 -0000 Yoshifumi, > > I might want to see more feedback before the adoption call. > I've read the draft, but I think I still have some unclear points in the > draft. > > I particularly would like to understand the following points as starting > point. Please let me know if I miss something. > > 1: This method requires CPEs to convert UDP or TCP into MPTCP and > requires Concentrators to convert back MPTCP into UDP or TCP. This could > be rather complex process than other approach such as GRE. So, what's > the benefits to utilize MPTCP here? I think the draft should describe > some useful scenarios to use MPTCP. There is already operational experience with this type of solution and it turns out that using MPTCP to support TCP traffic in hybrid access networks is a much better approach than using a tunneling technique like GRE. In an hybrid access network such as DSL+LTE, there are two types of problems that need to be tackled : 1. How to hide the different addresses used on the DSL and LTE networks 2. How to achieve efficient load balancing over networks having different characteristics (delay, bandwidth, packet losses) that change dynamically GRE solves the first problem in a clean manner. However, it causes two issues when you consider the second problem : a. Since paths have different delays, doing per packet load balancing creates massive reording that results in bad TCP performance b. Since the two underlying paths are hidden by encapsulation, TCP's congestion control scheme cannot probe the different paths and adjust ths congestion window correctl. This results in bad TCP performance as well. An MPTCP-based solution solves these problems in a clean manner since MPTCP sees the different paths and can use them efficiently. You can find some additional information in the Tessares whitepaper published last year http://www.tessares.net/white-papers/ There is already operational experience with this type of MPTCP-based solutions and if you think that this would be useful, we could organise a presentation at the next IETF meeting on this experience > > 2: Including data in SYN is allowed in RFC793, but I'm not very sure how > many implementations actually accept it. Well, the deployment of TFO shows that this is possible. > I think the draft should > discuss this point. Also, what will happen if PM option is included in > the payload, but it is removed by the middleboxes? The assumption is that this solution will be deployed in controlled environments and only used between the CPE and the Concentrator. Since the operator controls the two networks that are bound together, he can verify that there are no middleboxes that drop the PM option. Olivier From nobody Wed May 25 10:51:48 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E2C12D19E for ; Wed, 25 May 2016 10:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLqW8HHZ_4TH for ; Wed, 25 May 2016 10:51:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8CE2212D162 for ; Wed, 25 May 2016 10:51:43 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4PHpgVK029033 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 May 2016 17:51:42 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4PHpf7F003770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 May 2016 17:51:42 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4PHpejA021879 for ; Wed, 25 May 2016 17:51:41 GMT Received: from [10.159.130.142] (/10.159.130.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 May 2016 10:51:39 -0700 To: multipathtcp@ietf.org References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Rao Shoaib Message-ID: <5745E628.6010302@oracle.com> Date: Wed, 25 May 2016 10:51:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 17:51:44 -0000 On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: > The assumption is that this solution will be deployed in controlled > environments and only used between the CPE and the Concentrator. Since > the operator controls the two networks that are bound together, he can > verify that there are no middleboxes that drop the PM option. > > > Olivier I am extremely interested in encapsulating UDP in MPTCP but this solution is very specific and hence why should it even be standardized ? The proposed solution does not deal with segmentation and message boundaries at all. We have developed a similar solution in which we pass the original IP/UDP header to the MPTCP receiver[1]. The Reciever waits for the complete length of the message to be received and recreates the complete IP/UDP message before passing it up to IP/UDP for processing. MPTCP guarantees in order delivery so a large message can be distributed over multiple connections and reconstructed on the receiver without having to worry about duplicate segments. Also the concentrator stuff is deployment specific and should added as an application header. What needed is a standard way (new option) to signal the other end that the current message needs special handling and that's it. How such a message is handled can be implementation specific. Rao. [1] We have not looked at all the implication of doing this but for our use case it is fine. Comment welcome. From nobody Wed May 25 12:07:32 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501B312D962 for ; Wed, 25 May 2016 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSXw_p8LSnXW for ; Wed, 25 May 2016 12:07:30 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id AD9A512D8FD for ; Wed, 25 May 2016 12:07:23 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1057067DF9D; Wed, 25 May 2016 21:07:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be 1057067DF9D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1464203230; bh=Qcvm6//0VujffaCtbztWE3vy8rX/SG7gpwaPJpCk3kY=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=JUBv0xSIRZ618gMwUERxOVZirLu0Ht3X833mVJpBJnHiODsECaIjTIDlfVZWH45Op mb5CXXhsmwz8W764rC23tXQBZfFKADxE7InhZx9CnnnEJilRmE5A/m4WBD46lO03F3 hXQ3NYKJ+r44Ymh61WxvGAdxHN8CmS341kgfYdMU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at smtp-1 References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> To: Rao Shoaib , multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: Date: Wed, 25 May 2016 21:07:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5745E628.6010302@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-Information: X-SGSI-MailScanner-ID: 1057067DF9D.A38C1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 25 May 2016 19:07:32 -0000 Rao, > > On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: >> The assumption is that this solution will be deployed in controlled >> environments and only used between the CPE and the Concentrator. Since >> the operator controls the two networks that are bound together, he can >> verify that there are no middleboxes that drop the PM option. >> >> >> Olivier > I am extremely interested in encapsulating UDP in MPTCP but this > solution is very specific and hence why should it even be standardized ? There is a clear demand from operators for a solution to this problem in hybrid access networks. > The proposed solution does not deal with segmentation and message > boundaries at all. This is covered with the length field. Basically, UDP is transported as follows : client --- cpe --------- concentrator ----- server client sends UDP CPE places data inside MPTCP segment containing len,payload Concentrator uses len to extract UDP payload from bytestream and then reconstructs the entire UDP segment that can be sent to the server The assumption here is that there is a one-to-one mapping between a UDP flow and one MPTCP connection. > We have developed a similar solution in which we pass the original > IP/UDP header to the MPTCP receiver[1]. The Reciever waits for the > complete length of the message to be received and recreates the complete > IP/UDP message before passing it up to IP/UDP for processing. MPTCP > guarantees in order delivery so a large message can be distributed over > multiple connections and reconstructed on the receiver without having to > worry about duplicate segments. This is similar to the approach proposed in the PM draft, except that in the PM draft the information about the UDP flow is sent in the SYN for the entire MPTCP connection and not attached to each data as when you place the entire IP packet in the bytestream > > Also the concentrator stuff is deployment specific and should added as > an application header. What do you mean by concentrator stuff ? > What needed is a standard way (new option) to signal the other end that > the current message needs special handling and that's it. How such a > message is handled can be implementation specific. In hybrid access networks, MPTCP_based bonding for UDP is mainly useful for large flows. In this case, creating an MPTCP connection per flow implies that you do not need to reproduce the IP and UDP headers in the MPTCP connection Olivier From nobody Wed May 25 23:31:34 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CC512D692; Wed, 25 May 2016 23:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsB-7sKbiZvi; Wed, 25 May 2016 23:31:30 -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 C39C412D6C7; Wed, 25 May 2016 23:31:29 -0700 (PDT) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.161.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 941502783D5; Thu, 26 May 2016 15:31:27 +0900 (JST) Received: by mail-yw0-f172.google.com with SMTP id c127so68054660ywb.1; Wed, 25 May 2016 23:31:27 -0700 (PDT) X-Gm-Message-State: ALyK8tJhH1lE8gsT/9UGj/BoDa5v6cOO7Jiq/NjIg70+jNDqdoMQKb/9ISadE96Baea0LlbqVw3XQ4vJe4OPag== MIME-Version: 1.0 X-Received: by 10.37.124.5 with SMTP id x5mr4570858ybc.43.1464244286271; Wed, 25 May 2016 23:31:26 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Wed, 25 May 2016 23:31:26 -0700 (PDT) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 23:31:26 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a114c6fbe8c6d870533b8f084 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:31:33 -0000 --001a114c6fbe8c6d870533b8f084 Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Yoshifumi, > >> >> I might want to see more feedback before the adoption call. >> I've read the draft, but I think I still have some unclear points in the >> draft. >> >> I particularly would like to understand the following points as starting >> point. Please let me know if I miss something. >> >> 1: This method requires CPEs to convert UDP or TCP into MPTCP and >> requires Concentrators to convert back MPTCP into UDP or TCP. This could >> be rather complex process than other approach such as GRE. So, what's >> the benefits to utilize MPTCP here? I think the draft should describe >> some useful scenarios to use MPTCP. >> > > There is already operational experience with this type of solution and it > turns out that using MPTCP to support TCP traffic in hybrid access networks > is a much better approach than using a tunneling technique like GRE. In an > hybrid access network such as DSL+LTE, there are two types of problems that > need to be tackled : > > 1. How to hide the different addresses used on the DSL and LTE networks > 2. How to achieve efficient load balancing over networks having different > characteristics (delay, bandwidth, packet losses) that change dynamically > > GRE solves the first problem in a clean manner. However, it causes two > issues when you consider the second problem : > > a. Since paths have different delays, doing per packet load balancing > creates massive reording that results in bad TCP performance > b. Since the two underlying paths are hidden by encapsulation, TCP's > congestion control scheme cannot probe the different paths and adjust ths > congestion window correctl. This results in bad TCP performance as well. > > An MPTCP-based solution solves these problems in a clean manner since > MPTCP sees the different paths and can use them efficiently. > > You can find some additional information in the Tessares whitepaper > published last year > > http://www.tessares.net/white-papers/ > > There is already operational experience with this type of MPTCP-based > solutions and if you think that this would be useful, we could organise a > presentation at the next IETF meeting on this experience I think I understand general idea. But, as far as I read the draft, I got an impression that a UDP or a TCP flow will be mapped to a single subflow of a mptcp session. There is no description about using multiple subflows for a single TCP/UDP flow, or updating subflow mappings in the middle of a session. I think the draft should mention these cases. >> 2: Including data in SYN is allowed in RFC793, but I'm not very sure how >> many implementations actually accept it. >> > > Well, the deployment of TFO shows that this is possible. > > I think the draft should >> discuss this point. Also, what will happen if PM option is included in >> the payload, but it is removed by the middleboxes? >> > > The assumption is that this solution will be deployed in controlled > environments and only used between the CPE and the Concentrator. Since the > operator controls the two networks that are bound together, he can verify > that there are no middleboxes that drop the PM option. Hmm. then, I think these presumptions should be listed in the draft. But, one concern is the proposal will be too specific to standardize if there're too much presumptions... Thanks, -- Yoshi --001a114c6fbe8c6d870533b8f084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
Yoshifumi,

I might want to see more feedback before the adoption call.
I've read the draft, but I think I still have some unclear points in th= e
draft.

I particularly would like to understand the following points as starting point. Please let me know if I miss something.

1: This method requires CPEs to convert UDP or TCP into MPTCP and
requires Concentrators to convert back MPTCP into UDP or TCP. This could be rather complex process than other approach such as GRE. So, what's the benefits to utilize MPTCP here? I think the draft should describe
some useful scenarios to use MPTCP.

 There is already operational experience with this type of solution and it t= urns out that using MPTCP to support TCP traffic in hybrid access networks = is a much better approach than using a tunneling technique like GRE. In an = hybrid access network such as DSL+LTE, there are two types of problems that= need to be tackled :

1. How to hide the different addresses used on the DSL and LTE networks
2. How to achieve efficient load balancing over networks having different c= haracteristics (delay, bandwidth, packet losses) that change dynamically
GRE solves the first problem in a clean manner. However, it causes two issu= es when you consider the second problem :

a. Since paths have different delays, doing per packet load balancing creat= es massive reording that results in bad TCP performance
b. Since the two underlying paths are hidden by encapsulation, TCP's co= ngestion control scheme cannot probe the different paths and adjust ths con= gestion window correctl. This results in bad TCP performance as well.

An MPTCP-based solution solves these problems in a clean manner since MPTCP= sees the different paths and can use them efficiently.

You can find some additional information in the Tessares whitepaper publish= ed last year

http://www.tessares.net/white-papers/

There is already operational experience with this type of MPTCP-based solut= ions and if you think that this would be useful, we could organise a presen= tation at the next IETF meeting on this experience

I think I understand general idea.
But, as far as I read = the draft, I got an impression that a UDP or a TCP flow will be mapped to a= single subflow of a mptcp session.=C2=A0
There is no descrip= tion about using multiple subflows for a single TCP/UDP flow, or updating s= ubflow mappings in the middle of a session.
I think the draft sho= uld mention these cases.


2: Including data in SYN is allowed in RFC793, but I'm not very sure ho= w
many implementations actually accept it.

 Well, the deployment of TFO shows that this is possible.

I think the draft should
discuss this point. Also, what will happen if PM option is included in
the payload, but it is removed by the middleboxes?

 The assumption is that this solution will be deployed in controlled environ= ments and only used between the CPE and the Concentrator. Since the operato= r controls the two networks that are bound together, he can verify that the= re are no middleboxes that drop the PM option.

<= div>Hmm. then, I think these presumptions should be listed in the draft.
But, one concern is the proposal will be too specific to standardiz= e if there're too much presumptions...

Thanks,=
--
Yoshi
--001a114c6fbe8c6d870533b8f084-- From nobody Thu May 26 08:36:01 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240A12D6FC for ; Thu, 26 May 2016 08:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtwoPKc5yJCZ for ; Thu, 26 May 2016 08:35:58 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653AB12D56E for ; Thu, 26 May 2016 08:35:58 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n129so104699170wmn.1 for ; Thu, 26 May 2016 08:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=J+H9KbYOcRucDqNJLEoeO+vP1icKodN44A1Es6utwL0=; b=WziZZE7jHYUh76Zgmp82ynzyNG8nTgnDGMSyNHU6xLskUr6Biflzve6lp8cIJMF3gB a/yYQ1XWP17YAbVgk2Hd0t6M/6W/3Yuo32Z3VFQQhsA8ErnIgnoC/l+IMaFit2eYnTGW +8PcoRqVQFx8Xfn4zAdvPpCaOvC+DpnTnGYuU/sIr4XaC1qQ8hemIjTCP7gX3PlOrHRA voEWBcOMy7uWCi5Iap9ekAkq0Xfh4D8NvKVdOJx0Uor8CBhV9S8UTKPp4VYbMb2vqe9R OC2O3C9hDZM8PuFSeorYr2vm7/VR5hS9lkknavvKjqHI1q5UXohbG7R1W95szV+/s0ih CfOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=J+H9KbYOcRucDqNJLEoeO+vP1icKodN44A1Es6utwL0=; b=NR80qro4CpAXuKrRaQjet0G5AhjoweOMHWb0BfVS4WbK+d+b22bEIuBupihZ3gpkqs bWVovQZMcGpknAmSj1HC68rCwxFjxNDSF5wsa4HBg524BiAbLw3HQenMykw3GGv2FGHa jNOB9sQXGCyexdT4STfM2L0As4YKr5sWBpEKIKqoa0AHlD4yhZBSIZvnZ6SVKM3luUcj SL4dctkf7NZ376ZszJHV0dyXMHHRcY8k8V3hDz0DW4ZFQQZmRcW28gifhAdM/PcD5T+q qLUjaPcHZjBO3cMGb7Cv0Zbu4Jyd2W3zxfNa74iwNj2TF8tspjLvmEZDfcsabbIsBw2/ VAWw== X-Gm-Message-State: ALyK8tI+iwKF8vKexS7g38BT90kSDJ1/WJ5K3IT9CcyhCKVo8mRdmpEdTLRHqoMu5C39QdQXrVtwAXVSznfwEkBgFP1YF4prsBuMpObaGGAkdNArpT7jrEGcn8SE8T+6E6o= X-Received: by 10.194.205.105 with SMTP id lf9mr9995704wjc.25.1464276956838; Thu, 26 May 2016 08:35:56 -0700 (PDT) Received: from mbpobo.local ([130.104.228.16]) by smtp.gmail.com with ESMTPSA id jd4sm14868569wjb.43.2016.05.26.08.35.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 08:35:56 -0700 (PDT) To: Yoshifumi Nishida , Olivier Bonaventure References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Olivier Bonaventure Message-ID: <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> Date: Thu, 26 May 2016 17:35:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:36:00 -0000 Yoshifumi, > > There is already operational experience with this type of > MPTCP-based solutions and if you think that this would be useful, we > could organise a presentation at the next IETF meeting on this > experience > > > I think I understand general idea. > But, as far as I read the draft, I got an impression that a UDP or a TCP > flow will be mapped to a single subflow of a mptcp session. No, since the PM option is carried in the SYN of the initial subflow, a TCP flow will be mapped onto an MPTCP connection (and thus will be able to use any of its subflows) > There is no description about using multiple subflows for a single > TCP/UDP flow, or updating subflow mappings in the middle of a session. > I think the draft should mention these cases. Since the mapping is between a TCP connection (UDP flow) and an MPTCP connection, it applies for all the subflows of the MPTCP connection automatically. I'm not in favor of changing the mapping during the lifetime of an MPTCP connection, it leads to implementation complexity that are not worth the effort given that we can establish another MPTCP connection bound to another flow. > > 2: Including data in SYN is allowed in RFC793, but I'm not very > sure how > many implementations actually accept it. > > > Well, the deployment of TFO shows that this is possible. > > I think the draft should > discuss this point. Also, what will happen if PM option is > included in > the payload, but it is removed by the middleboxes? > > > The assumption is that this solution will be deployed in controlled > environments and only used between the CPE and the Concentrator. > Since the operator controls the two networks that are bound > together, he can verify that there are no middleboxes that drop the > PM option. > > > Hmm. then, I think these presumptions should be listed in the draft. > But, one concern is the proposal will be too specific to standardize if > there're too much presumptions... We can add a section on middlebox interference and discuss how the proposal would work when there is a middlebox even if the most likely deployment is an environment without middleboxes that interfere with TCP. Having NAT on any of the paths does not create any problem. The problematic middleboxes are, as always with MPTCP, those that : - remove some TCP options - remove data from the SYN payload Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Fri May 27 00:31:14 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E612D164; Fri, 27 May 2016 00:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TclPi2a6dOQ; Fri, 27 May 2016 00:31:10 -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 847BC12D689; Fri, 27 May 2016 00:30:32 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 90828278604; Fri, 27 May 2016 16:30:30 +0900 (JST) Received: by mail-yw0-f180.google.com with SMTP id x189so98691711ywe.3; Fri, 27 May 2016 00:30:30 -0700 (PDT) X-Gm-Message-State: ALyK8tLAE7GwRwGdefxxnQH7fe3hFtWvhF8Dqnhdc+icOUG41qyHTg+i7eJu8LpqNkEDceAVpbpbC3KUsa+6Vg== MIME-Version: 1.0 X-Received: by 10.37.224.134 with SMTP id x128mr7459172ybg.78.1464334229024; Fri, 27 May 2016 00:30:29 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Fri, 27 May 2016 00:30:28 -0700 (PDT) In-Reply-To: <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> Date: Fri, 27 May 2016 00:30:28 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a114e5d968db86d0533cde14b Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 07:31:13 -0000 --001a114e5d968db86d0533cde14b Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Thu, May 26, 2016 at 8:35 AM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Yoshifumi, > > >> There is already operational experience with this type of >> MPTCP-based solutions and if you think that this would be useful, we >> could organise a presentation at the next IETF meeting on this >> experience >> >> >> I think I understand general idea. >> But, as far as I read the draft, I got an impression that a UDP or a TCP >> flow will be mapped to a single subflow of a mptcp session. >> > > No, since the PM option is carried in the SYN of the initial subflow, a > TCP flow will be mapped onto an MPTCP connection (and thus will be able to > use any of its subflows) > There is no description about using multiple subflows for a single >> TCP/UDP flow, or updating subflow mappings in the middle of a session. >> I think the draft should mention these cases. >> > > Since the mapping is between a TCP connection (UDP flow) and an MPTCP > connection, it applies for all the subflows of the MPTCP connection > automatically. I'm not in favor of changing the mapping during the lifetime > of an MPTCP connection, it leads to implementation complexity that are not > worth the effort given that we can establish another MPTCP connection bound > to another flow. > I see. Sorry. I might be confused by the name of Concentrator.. Then, my another question is if we can do the same thing with application level. I am wondering if we can write an application gateway for CPE and Concentrator to send mapping information just like PM option, (and do some segmentation tasks as well) so that we can mitigate middlebox interventions. 2: Including data in SYN is allowed in RFC793, but I'm not very >> sure how >> many implementations actually accept it. >> >> >> Well, the deployment of TFO shows that this is possible. >> >> I think the draft should >> discuss this point. Also, what will happen if PM option is >> included in >> the payload, but it is removed by the middleboxes? >> >> >> The assumption is that this solution will be deployed in controlled >> environments and only used between the CPE and the Concentrator. >> Since the operator controls the two networks that are bound >> together, he can verify that there are no middleboxes that drop the >> PM option. >> >> >> Hmm. then, I think these presumptions should be listed in the draft. >> But, one concern is the proposal will be too specific to standardize if >> there're too much presumptions... >> > > We can add a section on middlebox interference and discuss how the > proposal would work when there is a middlebox even if the most likely > deployment is an environment without middleboxes that interfere with TCP. > Having NAT on any of the paths does not create any problem. The problematic > middleboxes are, as always with MPTCP, those that : > - remove some TCP options > - remove data from the SYN payload Sounds good to me. Thanks, -- Yoshi --001a114e5d968db86d0533cde14b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Thu, May 26, 2016 at 8:35 AM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
Yoshifumi,


=C2=A0 =C2=A0 There is already operational experience with this type of
=C2=A0 =C2=A0 MPTCP-based solutions and if you think that this would be use= ful, we
=C2=A0 =C2=A0 could organise a presentation at the next IETF meeting on thi= s
=C2=A0 =C2=A0 experience


I think I understand general idea.
But, as far as I read the draft, I got an impression that a UDP or a TCP flow will be mapped to a single subflow of a mptcp session.

 No, since the PM option is carried in the SYN of the initial subflow, a TCP= flow will be mapped onto an MPTCP connection (and thus will be able to use= any of its subflows)

There is no description about using multiple subflows for a single
TCP/UDP flow, or updating subflow mappings in the middle of a session.
I think the draft should mention these cases.

 Since the mapping is between a TCP connection (UDP flow) and an MPTCP conne= ction, it applies for all the subflows of the MPTCP connection automaticall= y. I'm not in favor of changing the mapping during the lifetime of an M= PTCP connection, it leads to implementation complexity that are not worth t= he effort given that we can establish another MPTCP connection bound to ano= ther flow.

I see. Sorry. I might be confused by the name of Concentrator..

Then, my another question is if we can do the same thi= ng with application level.=C2=A0
I am wondering if we can write a= n application gateway for CPE and Concentrator to send mapping information = just like PM option, (and do some segmentation tasks as well) so that we ca= n mitigate middlebox interventions.

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2: Including data in SYN is allowed in RFC793, = but I'm not very
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sure how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 many implementations actually accept it.


=C2=A0 =C2=A0 Well, the deployment of TFO shows that this is possible.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think the draft should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 discuss this point. Also, what will happen if P= M option is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 included in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the payload, but it is removed by the middlebox= es?


=C2=A0 =C2=A0 The assumption is that this solution will be deployed in cont= rolled
=C2=A0 =C2=A0 environments and only used between the CPE and the Concentrat= or.
=C2=A0 =C2=A0 Since the operator controls the two networks that are bound =C2=A0 =C2=A0 together, he can verify that there are no middleboxes that dr= op the
=C2=A0 =C2=A0 PM option.


Hmm. then, I think these presumptions should be listed in the draft.
But, one concern is the proposal will be too specific to standardize if
there're too much presumptions...

 We can add a section on middlebox interference and discuss how the proposal= would work when there is a middlebox even if the most likely deployment is= an environment without middleboxes that interfere with TCP. Having NAT on = any of the paths does not create any problem. The problematic middleboxes a= re, as always with MPTCP, those that :
- remove some TCP options
- remove data from the SYN payload
=C2=A0
Sounds= good to me.=C2=A0
Thanks,
--
Yoshi
=
=C2=A0
--001a114e5d968db86d0533cde14b-- From nobody Fri May 27 00:38:12 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5E12D10F for ; Fri, 27 May 2016 00:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2XQbFMG5V9o for ; Fri, 27 May 2016 00:38:09 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC9712D0E1 for ; Fri, 27 May 2016 00:38:08 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id z87so2121142wmh.1 for ; Fri, 27 May 2016 00:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=L8/2RkMtXjqRL5LTETpoDgoi0306U3J2syrS/OYuWxo=; b=CxMb80Z6FBSzuGq5859/yjpSPFWvAEomXcNdHzQO5s7fUmiiAQltHBeEUah9iIxgkn l9jyZyX8taSjEHOk1OzjJ1VsYU0+mRcSSQKGfi/oR85AJvOiI3txfcjAuAQs/ZUg9brS gihoBz7XTAW42zoYyeIdUMAd6RigAyC1Fr7WurF2hJQKDo5h9tu+40rDBKWDigeQ/12y hpfyvpCV92MG3Q2X1KktTVHfcokEvzs/xhEOyYqddxTc/LSiIkZKis5qlu0DXD4MGgNg qoEuOCSC5T6CrCTCT8TnQ6LkPHlba2EspZvfgZSmOSP9LXSN679BGFXX5ehkwk92Bjqt 0fww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=L8/2RkMtXjqRL5LTETpoDgoi0306U3J2syrS/OYuWxo=; b=Kk35VNrvgJKqIM7x4XCrFk1wKvdvb9Im0efkFFbJNAkzEYBt+/9vrmgJ5OdkZHoI/g 10gbe7Hpd7ZFBt/OQRaoeKnrWGMiNAQL+Yx6symsPLX23sqr+l1IB5pa0pUl0j8v36LZ tSY8FsHdm+O9jFeByv23ZEGpHQam2SDY1DvmsYTD90SoxcnPcWyYuqkLXdUkuMFuvDd+ kBkao1TA2RtFpoPi9dcWHAqzP/YAUl49boapxBe6sB5zn8+Ea5WrrFgmr+Gh0W95k7DT 4/ZkSofV2b0NeT7R5ZD9oLwoFReXzrB8glTwBliUvaI39O8pOTwPmLTmsTsWvUr41drL TfHQ== X-Gm-Message-State: ALyK8tIZxlTZKTtn0yyICZIL1e/i5UFDLGVjJSn4YGkOrKZgmyH/gezK5w76ijBoDLlMrhWvHF3YFOT0GG+oyjvSZgtgJ7R9QUVUjzgsNPXz1euK4PMdoGKUAEoPTWxrHeg= X-Received: by 10.28.131.80 with SMTP id f77mr7755790wmd.80.1464334687087; Fri, 27 May 2016 00:38:07 -0700 (PDT) Received: from mbpobo.local ([130.104.228.16]) by smtp.gmail.com with ESMTPSA id m7sm7250186wma.10.2016.05.27.00.38.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 00:38:06 -0700 (PDT) To: Yoshifumi Nishida References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> From: Olivier Bonaventure Message-ID: <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> Date: Fri, 27 May 2016 09:38:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 07:38:11 -0000 Yoshifumi, > > > Since the mapping is between a TCP connection (UDP flow) and an > MPTCP connection, it applies for all the subflows of the MPTCP > connection automatically. I'm not in favor of changing the mapping > during the lifetime of an MPTCP connection, it leads to > implementation complexity that are not worth the effort given that > we can establish another MPTCP connection bound to another flow. > > > I see. Sorry. I might be confused by the name of Concentrator.. > > Then, my another question is if we can do the same thing with > application level. > I am wondering if we can write an application gateway for CPE and > Concentrator to send mapping information just like PM option, (and do > some segmentation tasks as well) so that we can mitigate middlebox > interventions. The closest solution in the application level is SOCKS. This is what KT is doing in Korea and what OVH is deploying for their OverTheBox solution. Both do this on top of MPTCP. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Fri May 27 00:50:59 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED0512D10F; Fri, 27 May 2016 00:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_wiz09oJ1Pk; Fri, 27 May 2016 00:50:56 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CACA12D0A0; Fri, 27 May 2016 00:50:56 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 018C940385; Fri, 27 May 2016 09:50:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id BB75640075; Fri, 27 May 2016 09:50:54 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0294.000; Fri, 27 May 2016 09:50:54 +0200 From: To: Olivier Bonaventure , Yoshifumi Nishida Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwFCVgCLAB0kBQAAAERmgAAEawRQ Date: Fri, 27 May 2016 07:50:53 +0000 Message-ID: <20094_1464335454_5747FC5E_20094_1043_1_81C77F07008CA24F9783A98CFD706F71161BA22D@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> In-Reply-To: <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 07:50:58 -0000 Hi, You probably already mention it, but another way is to run MPTCP on top of = IP tunnels between CPE and concentrator (I'm not advocating for tunnels, ju= st pointing alternative :-)).=20 Pierrick > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de = Olivier > Bonaventure > Envoy=E9=A0: vendredi 27 mai 2016 09:38 > =C0=A0: Yoshifumi Nishida > Cc=A0: MultiPath WG; draft-boucadair-mptcp-plain-mode@ietf.org > Objet=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > Yoshifumi, >=20 > > > > > > Since the mapping is between a TCP connection (UDP flow) and an > > MPTCP connection, it applies for all the subflows of the MPTCP > > connection automatically. I'm not in favor of changing the mapping > > during the lifetime of an MPTCP connection, it leads to > > implementation complexity that are not worth the effort given that > > we can establish another MPTCP connection bound to another flow. > > > > > > I see. Sorry. I might be confused by the name of Concentrator.. > > > > Then, my another question is if we can do the same thing with > > application level. > > I am wondering if we can write an application gateway for CPE and > > Concentrator to send mapping information just like PM option, (and do > > some segmentation tasks as well) so that we can mitigate middlebox > > interventions. >=20 > The closest solution in the application level is SOCKS. This is what KT i= s doing in > Korea and what OVH is deploying for their OverTheBox solution. Both do th= is on > top of MPTCP. >=20 >=20 > Olivier >=20 > -- >=20 > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intende= d solely for > the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for t= he > individual named. If you are not the named addressee you should not disse= minate, > distribute or copy this e-mail. Please notify the sender immediately by e= -mail if you > have received this e-mail by mistake and delete this e-mail from your sys= tem. If > you are not the intended recipient you are notified that disclosing, copy= ing, > distributing or taking any action in reliance on the contents of this inf= ormation is > strictly prohibited. >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri May 27 17:09:05 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A26312D1D3; Fri, 27 May 2016 17:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS5pJI7OrIPr; Fri, 27 May 2016 17:09:02 -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 0F1F212D0CF; Fri, 27 May 2016 17:09:01 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 059A927868F; Sat, 28 May 2016 09:09:00 +0900 (JST) Received: by mail-yw0-f171.google.com with SMTP id c127so119961697ywb.1; Fri, 27 May 2016 17:08:59 -0700 (PDT) X-Gm-Message-State: ALyK8tLNcCr/tGhUSSYadQMvzo9rU7npOO/aJnflYRwlVco82eWoEe00AtFk9Td7sv9eeEucrqQQIMu51iiYFQ== MIME-Version: 1.0 X-Received: by 10.13.253.1 with SMTP id n1mr11009099ywf.83.1464394138491; Fri, 27 May 2016 17:08:58 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Fri, 27 May 2016 17:08:58 -0700 (PDT) In-Reply-To: <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> Date: Fri, 27 May 2016 17:08:58 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=94eb2c06c9b06fa57c0533dbd4d8 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 00:09:04 -0000 --94eb2c06c9b06fa57c0533dbd4d8 Content-Type: text/plain; charset=UTF-8 Hi Olivier, On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Yoshifumi, > > >> >> Since the mapping is between a TCP connection (UDP flow) and an >> MPTCP connection, it applies for all the subflows of the MPTCP >> connection automatically. I'm not in favor of changing the mapping >> during the lifetime of an MPTCP connection, it leads to >> implementation complexity that are not worth the effort given that >> we can establish another MPTCP connection bound to another flow. >> >> >> I see. Sorry. I might be confused by the name of Concentrator.. >> >> Then, my another question is if we can do the same thing with >> application level. >> I am wondering if we can write an application gateway for CPE and >> Concentrator to send mapping information just like PM option, (and do >> some segmentation tasks as well) so that we can mitigate middlebox >> interventions. >> > > The closest solution in the application level is SOCKS. This is what KT is > doing in Korea and what OVH is deploying for their OverTheBox solution. > Both do this on top of MPTCP. I might want to understand pros and cons for the proposal and others. It would be good to have this sort of discussions in the draft. Thanks, -- Yoshi --94eb2c06c9b06fa57c0533dbd4d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
Yoshifumi,



=C2=A0 =C2=A0 Since the mapping is between a TCP connection (UDP flow) and = an
=C2=A0 =C2=A0 MPTCP connection, it applies for all the subflows of the MPTC= P
=C2=A0 =C2=A0 connection automatically. I'm not in favor of changing th= e mapping
=C2=A0 =C2=A0 during the lifetime of an MPTCP connection, it leads to
=C2=A0 =C2=A0 implementation complexity that are not worth the effort given= that
=C2=A0 =C2=A0 we can establish another MPTCP connection bound to another fl= ow.


I see. Sorry. I might be confused by the name of Concentrator..

Then, my another question is if we can do the same thing with
application level.
I am wondering if we can write an application gateway for CPE and
Concentrator to send mapping information just like PM option, (and do
some segmentation tasks as well) so that we can mitigate middlebox
interventions.

 The closest solution in the application level is SOCKS. This is what KT is = doing in Korea and what OVH is deploying for their OverTheBox solution. Bot= h do this on top of MPTCP.

I might want to = understand pros and cons for the proposal and others.=C2=A0
It wo= uld be good to have this sort of discussions in the draft.

Thanks,
--
Yoshi
--94eb2c06c9b06fa57c0533dbd4d8-- From nobody Sat May 28 01:32:39 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7B412D5B3 for ; Sat, 28 May 2016 01:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9GUe_y5a8YK for ; Sat, 28 May 2016 01:32:36 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 5629D12B05F for ; Sat, 28 May 2016 01:32:36 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a136so20231796wme.0 for ; Sat, 28 May 2016 01:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:to :mime-version; bh=gZYagOYxs53S8KQJkkUMZj8xXZ3H/tRfHhOpGgbMgVQ=; b=JzYPEC9Eel4lY6Tcd0tpkKZ1WgIa74SsDwKSZgXFcuuYLv6UZpn8wJ6NxAU182C8LN XQhP/1Z8ETD/qFaq4oCaDEBZ/AiCTTkPYd4qer0mmiYBMjilS3no1jLiwX64ScAuGZKf CL8Dd1CV2Ptl5guLuHz9o0wLIxULyuuiSkCiheNzdDvdZEis9cq+887HhU0d2FdI+hvf jvEB3QNUJfM9iEXV2QpapGT2nOkXVVZ1uNHcjp8fj8PUV3pGz9bxeeVpngYjb7W5UAu3 ppLytOuywtYGsIJYpoF2sLYYtL1zAkFihwVSc+vZ2kvtxUEC5biU3wW5bUpxaFt8y5BA URMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:to:mime-version; bh=gZYagOYxs53S8KQJkkUMZj8xXZ3H/tRfHhOpGgbMgVQ=; b=UkRgrYU+8RawFJHQXYcPiEycQ0aAQKdbvdCIxLrnWhS3Re/TBjkh+jxyuJEwPYUfI2 8jEqDiJZg3osn5f1X9NyQG7VEnxkW+ZTHdA0/LI/M3FMksoutv7sncaMLbjzy/jyOhvv yw07AbUqDMvce9GXQCpgqU7tem2wRjefN3M7tWBtp3PRYtYpUDTsWSSex/+UZb1xzrMm M2roIyB/e+UpPtK1RfKJE1zTjr6FHGae81rjLXMxaw10O5YLjLs6l9Vn/ieYu0/egFUu NQQSLh8TaTQj1C3BkTbu5JSRmG92ksPHvmo8zpubJf7DwIuE05/5Pc/Wb/bNpKkJd6wt QOBA== X-Gm-Message-State: ALyK8tIeYwOrAiMtHv5VeLtKWQB/0g4K2fTPA3m4BsY1BjVXvRS1D7uDie8tRm7pw3YEdw== X-Received: by 10.28.91.209 with SMTP id p200mr2359093wmb.19.1464424354896; Sat, 28 May 2016 01:32:34 -0700 (PDT) Received: from [192.168.0.29] (cpc99614-brnt2-2-0-cust252.4-2.cable.virginm.net. [81.98.160.253]) by smtp.gmail.com with ESMTPSA id x124sm12498475wmg.24.2016.05.28.01.32.34 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 May 2016 01:32:34 -0700 (PDT) From: Alan Ford Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 28 May 2016 09:32:37 +0100 Message-Id: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> To: multipathtcp Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: Subject: [multipathtcp] MPTCP external auth drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 08:32:38 -0000 Hi all, Following on from the discussion at the previous two IETFs, we have = submitted two drafts proposing a way forward for resolving the = loadbalancers issue (or in other words, separating tokens and keys), and = in turn have a proposal for using TLS keying material with MPTCP. This proposal comes in the form of two drafts, to separate protocol = changes (which we would be proposing for adoption into rfc6824bis), and = TLS-specific extensions (which we would suggest are kept separate). The protocol changes = (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.t= xt) propose an additional handshake mechanism to be negotiated in the = MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This = means that MPTCP queries the application layer for Token and Key = materials. This is negotiated by being offered by the initiator, and = chosen by the answerer. Only tokens are sent on the wire, and these can be used to contain any = information that could assist a far end to demultiplex connections (e.g. = including routing data which would help front-end proxies). Minor changes that fall out of this also mean the IDSN, in that = scenario, would be generated from the Token not the Key. Keying information may not be available at the SYN/ACK exchange, but = will be provided by the application when available. Only once that has = occurred can subflow setup continue. The TLS draft = (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) = shows how we can interface this proposal with TLS, using RFC5705 key = export from TLS. This requires no changes to the protocol, but would = register a new RFC5705 exporter with IANA. Exported keys from a TLS = session would be passed to the MPTCP layer and used in the HMAC = authentication algorithm. We would like to present and discuss these points in the upcoming = interim, to see if there is consensus to add the necessary protocol = changes to rfc6824bis. Best regards, Alan & Christoph= From nobody Sat May 28 01:55:51 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3512D5E8 for ; Sat, 28 May 2016 01:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoGp1vXuA8Fx for ; Sat, 28 May 2016 01:55:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 834F012D5E3 for ; Sat, 28 May 2016 01:55:49 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4S8tmdc022333 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 May 2016 08:55:48 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4S8tl2m005535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 May 2016 08:55:48 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4S8tkvj031373; Sat, 28 May 2016 08:55:47 GMT Received: from [10.159.64.69] (/10.159.64.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 May 2016 01:55:45 -0700 To: Olivier.Bonaventure@uclouvain.be, multipathtcp@ietf.org References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> From: Rao Shoaib Message-ID: <57495D0D.50100@oracle.com> Date: Sat, 28 May 2016 01:55:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 08:55:51 -0000 On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: > Rao, >> >> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: >>> The assumption is that this solution will be deployed in controlled >>> environments and only used between the CPE and the Concentrator. Since >>> the operator controls the two networks that are bound together, he can >>> verify that there are no middleboxes that drop the PM option. >>> >>> >>> Olivier >> I am extremely interested in encapsulating UDP in MPTCP but this >> solution is very specific and hence why should it even be standardized ? > > There is a clear demand from operators for a solution to this problem > in hybrid access networks. OK but this solution is very specific to the mobile network. We would prefer a generic encapsulation solution which has no address mapping. Maybe the address mapping part should be made optional based on a flag ? > >> The proposed solution does not deal with segmentation and message >> boundaries at all. > > This is covered with the length field. Basically, UDP is transported > as follows : Yes it does, sorry I missed that. > > The assumption here is that there is a one-to-one mapping between a > UDP flow and one MPTCP connection. I am not sure that is a good thing, we would prefer that it be used to send any protocol packet destined for the host. Not including encapsulated protocol's header works for UDP but wont for other protocols. > >> >> Also the concentrator stuff is deployment specific and should added as >> an application header. > > What do you mean by concentrator stuff ? Address mapping stuff -- Use of D bit. > >> What needed is a standard way (new option) to signal the other end that >> the current message needs special handling and that's it. How such a >> message is handled can be implementation specific. > > In hybrid access networks, MPTCP_based bonding for UDP is mainly > useful for large flows. In this case, creating an MPTCP connection per > flow implies that you do not need to reproduce the IP and UDP headers > in the MPTCP connection > For our use case (Host Environment) preserving ports and reducing number of connections is more important. Including protocol message header allows use of the same connection for encapsulating any protocol and any port. Also note that size of UDP header is only 8 bytes and we can omit checksum and reduce it to 6 bytes which is a very small fraction for even a 1K message size. After re-reading the draft I think the proposal for encapsulation is pretty good, only minor details need to be cleared up. Shoaib From nobody Mon May 30 01:49:00 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90612D1A0; Mon, 30 May 2016 01:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KCrijSnfaoR; Mon, 30 May 2016 01:48:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0073012D120; Mon, 30 May 2016 01:48:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D3E523B4460; Mon, 30 May 2016 10:48:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A364F35C05A; Mon, 30 May 2016 10:48:53 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0294.000; Mon, 30 May 2016 10:48:52 +0200 From: To: Yoshifumi Nishida , Olivier Bonaventure Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwD6x+gAAADSjoAAL4UoAADR1pxQ Date: Mon, 30 May 2016 08:48:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D8DAAC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D8DAACOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:48:59 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D8DAACOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBZ b3NoaWZ1bWkgTmlzaGlkYSBbbWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanBdDQpFbnZvecOp IDogamV1ZGkgMjYgbWFpIDIwMTYgMDg6MzENCsOAIDogT2xpdmllciBCb25hdmVudHVyZQ0KQ2Mg OiBZb3NoaWZ1bWkgTmlzaGlkYTsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgTXVsdGlQYXRo IFdHOyBkcmFmdC1ib3VjYWRhaXItbXB0Y3AtcGxhaW4tbW9kZUBpZXRmLm9yZw0KT2JqZXQgOiBS ZTogW211bHRpcGF0aHRjcF0gZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGUtMDcNCg0K SGkgT2xpdmllciwNCg0KT24gV2VkLCBNYXkgMjUsIDIwMTYgYXQgMTI6NTAgQU0sIE9saXZpZXIg Qm9uYXZlbnR1cmUgPE9saXZpZXIuQm9uYXZlbnR1cmVAdWNsb3V2YWluLmJlPG1haWx0bzpPbGl2 aWVyLkJvbmF2ZW50dXJlQHVjbG91dmFpbi5iZT4+IHdyb3RlOg0KWW9zaGlmdW1pLA0KDQpJIG1p Z2h0IHdhbnQgdG8gc2VlIG1vcmUgZmVlZGJhY2sgYmVmb3JlIHRoZSBhZG9wdGlvbiBjYWxsLg0K SSd2ZSByZWFkIHRoZSBkcmFmdCwgYnV0IEkgdGhpbmsgSSBzdGlsbCBoYXZlIHNvbWUgdW5jbGVh ciBwb2ludHMgaW4gdGhlDQpkcmFmdC4NCg0KSSBwYXJ0aWN1bGFybHkgd291bGQgbGlrZSB0byB1 bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgcG9pbnRzIGFzIHN0YXJ0aW5nDQpwb2ludC4gUGxlYXNl IGxldCBtZSBrbm93IGlmIEkgbWlzcyBzb21ldGhpbmcuDQoNCjE6IFRoaXMgbWV0aG9kIHJlcXVp cmVzIENQRXMgdG8gY29udmVydCBVRFAgb3IgVENQIGludG8gTVBUQ1AgYW5kDQpyZXF1aXJlcyBD b25jZW50cmF0b3JzIHRvIGNvbnZlcnQgYmFjayBNUFRDUCBpbnRvIFVEUCBvciBUQ1AuIFRoaXMg Y291bGQNCmJlIHJhdGhlciBjb21wbGV4IHByb2Nlc3MgdGhhbiBvdGhlciBhcHByb2FjaCBzdWNo IGFzIEdSRS4gU28sIHdoYXQncw0KdGhlIGJlbmVmaXRzIHRvIHV0aWxpemUgTVBUQ1AgaGVyZT8g SSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGRlc2NyaWJlDQpzb21lIHVzZWZ1bCBzY2VuYXJpb3Mg dG8gdXNlIE1QVENQLg0KDQpUaGVyZSBpcyBhbHJlYWR5IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ug d2l0aCB0aGlzIHR5cGUgb2Ygc29sdXRpb24gYW5kIGl0IHR1cm5zIG91dCB0aGF0IHVzaW5nIE1Q VENQIHRvIHN1cHBvcnQgVENQIHRyYWZmaWMgaW4gaHlicmlkIGFjY2VzcyBuZXR3b3JrcyBpcyBh IG11Y2ggYmV0dGVyIGFwcHJvYWNoIHRoYW4gdXNpbmcgYSB0dW5uZWxpbmcgdGVjaG5pcXVlIGxp a2UgR1JFLiBJbiBhbiBoeWJyaWQgYWNjZXNzIG5ldHdvcmsgc3VjaCBhcyBEU0wrTFRFLCB0aGVy ZSBhcmUgdHdvIHR5cGVzIG9mIHByb2JsZW1zIHRoYXQgbmVlZCB0byBiZSB0YWNrbGVkIDoNCg0K MS4gSG93IHRvIGhpZGUgdGhlIGRpZmZlcmVudCBhZGRyZXNzZXMgdXNlZCBvbiB0aGUgRFNMIGFu ZCBMVEUgbmV0d29ya3MNCjIuIEhvdyB0byBhY2hpZXZlIGVmZmljaWVudCBsb2FkIGJhbGFuY2lu ZyBvdmVyIG5ldHdvcmtzIGhhdmluZyBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzIChkZWxheSwg YmFuZHdpZHRoLCBwYWNrZXQgbG9zc2VzKSB0aGF0IGNoYW5nZSBkeW5hbWljYWxseQ0KDQpHUkUg c29sdmVzIHRoZSBmaXJzdCBwcm9ibGVtIGluIGEgY2xlYW4gbWFubmVyLiBIb3dldmVyLCBpdCBj YXVzZXMgdHdvIGlzc3VlcyB3aGVuIHlvdSBjb25zaWRlciB0aGUgc2Vjb25kIHByb2JsZW0gOg0K DQphLiBTaW5jZSBwYXRocyBoYXZlIGRpZmZlcmVudCBkZWxheXMsIGRvaW5nIHBlciBwYWNrZXQg bG9hZCBiYWxhbmNpbmcgY3JlYXRlcyBtYXNzaXZlIHJlb3JkaW5nIHRoYXQgcmVzdWx0cyBpbiBi YWQgVENQIHBlcmZvcm1hbmNlDQpiLiBTaW5jZSB0aGUgdHdvIHVuZGVybHlpbmcgcGF0aHMgYXJl IGhpZGRlbiBieSBlbmNhcHN1bGF0aW9uLCBUQ1AncyBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1l IGNhbm5vdCBwcm9iZSB0aGUgZGlmZmVyZW50IHBhdGhzIGFuZCBhZGp1c3QgdGhzIGNvbmdlc3Rp b24gd2luZG93IGNvcnJlY3RsLiBUaGlzIHJlc3VsdHMgaW4gYmFkIFRDUCBwZXJmb3JtYW5jZSBh cyB3ZWxsLg0KDQpBbiBNUFRDUC1iYXNlZCBzb2x1dGlvbiBzb2x2ZXMgdGhlc2UgcHJvYmxlbXMg aW4gYSBjbGVhbiBtYW5uZXIgc2luY2UgTVBUQ1Agc2VlcyB0aGUgZGlmZmVyZW50IHBhdGhzIGFu ZCBjYW4gdXNlIHRoZW0gZWZmaWNpZW50bHkuDQoNCllvdSBjYW4gZmluZCBzb21lIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gaW4gdGhlIFRlc3NhcmVzIHdoaXRlcGFwZXIgcHVibGlzaGVkIGxhc3Qg eWVhcg0KDQpodHRwOi8vd3d3LnRlc3NhcmVzLm5ldC93aGl0ZS1wYXBlcnMvDQoNClRoZXJlIGlz IGFscmVhZHkgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIHRoaXMgdHlwZSBvZiBNUFRDUC1i YXNlZCBzb2x1dGlvbnMgYW5kIGlmIHlvdSB0aGluayB0aGF0IHRoaXMgd291bGQgYmUgdXNlZnVs LCB3ZSBjb3VsZCBvcmdhbmlzZSBhIHByZXNlbnRhdGlvbiBhdCB0aGUgbmV4dCBJRVRGIG1lZXRp bmcgb24gdGhpcyBleHBlcmllbmNlDQoNCkkgdGhpbmsgSSB1bmRlcnN0YW5kIGdlbmVyYWwgaWRl YS4NCkJ1dCwgYXMgZmFyIGFzIEkgcmVhZCB0aGUgZHJhZnQsIEkgZ290IGFuIGltcHJlc3Npb24g dGhhdCBhIFVEUCBvciBhIFRDUCBmbG93IHdpbGwgYmUgbWFwcGVkIHRvIGEgc2luZ2xlIHN1YmZs b3cgb2YgYSBtcHRjcCBzZXNzaW9uLg0KDQpbTWVkXSBUaGUgZHJhZnQgc2F5cyB0aGUgZm9sbG93 aW5nOg0KDQpTZWN0aW9uIDUuMToNCg0KDQpUaGUgZGF0YSBjYXJyaWVkIGluIFVEUCBkYXRhZ3Jh bXMgYmVsb25naW5nIHRvDQoNCiAgIGEgZ2l2ZW4gVURQIGZsb3cgYXJlIHRoZXJlZm9yZSB0cmFu c3BvcnRlZCBpbiBhbiBNUFRDUCBjb25uZWN0aW9uLg0KDQoNCg0KICAgVGhlIG1hbmFnZW1lbnQg b2YgTVBUQ1AgY29ubmVjdGlvbnMgdGhhdCBhcmUgdHJpZ2dlcmVkIGJ5IFVEUA0KDQogICBkYXRh Z3JhbXMgZm9sbG93cyB0aGUgZ3VpZGVsaW5lcyBkb2N1bWVudGVkIGluIFtSRkM2ODI0PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODI0Pl0uDQoNClNlY3Rpb24gNS4yOg0KDQogICBB IGZsb3cgZXhhbXBsZSBpcyBzaG93biBpbiBGaWd1cmUgNSB0byBpbGx1c3RyYXRlIGhvdyBUQ1Ag cGFja2V0cyBhcmUNCiAgIGdlbmVyYXRlZCB0byByZWxheSBVRFAgZGF0YWdyYW1zIHVzaW5nIHNl dmVyYWwgc3ViZmxvd3MuICBOb24tU1lODQogICBtZXNzYWdlcyB0aGF0IGJlbG9uZyB0byBhIGdp dmVuIHN1YmZsb3cgZG8gbm90IGluY2x1ZGUgYW55IFBNIG9wdGlvbi4NCiAgIEFsc28sIHRoaXMg ZXhhbXBsZSBzaG93cyBob3cgc3Vic2VxdWVudCBVRFAgZGF0YWdyYW1zIG9mIHRoaXMgZmxvdw0K ICAgYXJlIHRyYW5zcG9ydGVkIG92ZXIgdGhlIGV4aXN0aW5nIHN1YmZsb3cgb3IgaG93IGEgbmV3 IHN1YmZsb3cgaXMNCiAgIGNyZWF0ZWQuICBJbiB0aGlzIGV4YW1wbGUsIHRoZSBTWU4gc2VnbWVu dCBpc3N1ZWQgdG8gYWRkIGEgbmV3DQogICBzdWJmbG93IGFsc28gaW5jbHVkZXMgZGF0YSByZWNl aXZlZCBpbiBhIFVEUCBkYXRhZ3JhbS4NCg0KYW5kDQoNCg0KICAgRmlndXJlIDYgc2hvd3MgYW4g ZXhhbXBsZSBvZiBVRFAgZGF0YWdyYW1zIHRoYXQgYXJlIHRyYW5zcG9ydGVkIG92ZXINCg0KICAg TVBUQ1Agc3ViZmxvd3MuICBVbmxpa2UgdGhlIHByZXZpb3VzIGV4YW1wbGUsIGFkZGl0aW9uYWwg c3ViZmxvd3MgdG8NCg0KICAgdHJhbnNwb3J0IFVEUCBkYXRhZ3JhbXMgb2YgdGhlIHNhbWUgZmxv dyBhcmUgZXN0YWJsaXNoZWQgaW4gYWR2YW5jZQ0KDQogICBiZXR3ZWVuIHRoZSBDUEUgYW5kIHRo ZSBjb25jZW50cmF0b3IuDQoNCkRvIHlvdSB0aGluayBhZGRpdGlvbmFsIHRleHQgaXMgbmVlZGVk IHRvIG1ha2UgaXQgY2xlYXI/IFRoYW5rIHlvdS4NCg0KVGhlcmUgaXMgbm8gZGVzY3JpcHRpb24g YWJvdXQgdXNpbmcgbXVsdGlwbGUgc3ViZmxvd3MgZm9yIGEgc2luZ2xlIFRDUC9VRFAgZmxvdywg b3IgdXBkYXRpbmcgc3ViZmxvdyBtYXBwaW5ncyBpbiB0aGUgbWlkZGxlIG9mIGEgc2Vzc2lvbi4N Cg0KW01lZF0gUGxlYXNlIHJlZmVyIHRvIEZpZ3VyZXMgNSAmIDYuDQoNCkkgdGhpbmsgdGhlIGRy YWZ0IHNob3VsZCBtZW50aW9uIHRoZXNlIGNhc2VzLg0KDQoNCjI6IEluY2x1ZGluZyBkYXRhIGlu IFNZTiBpcyBhbGxvd2VkIGluIFJGQzc5MywgYnV0IEknbSBub3QgdmVyeSBzdXJlIGhvdw0KbWFu eSBpbXBsZW1lbnRhdGlvbnMgYWN0dWFsbHkgYWNjZXB0IGl0Lg0KDQpXZWxsLCB0aGUgZGVwbG95 bWVudCBvZiBURk8gc2hvd3MgdGhhdCB0aGlzIGlzIHBvc3NpYmxlLg0KSSB0aGluayB0aGUgZHJh ZnQgc2hvdWxkDQpkaXNjdXNzIHRoaXMgcG9pbnQuIEFsc28sIHdoYXQgd2lsbCBoYXBwZW4gaWYg UE0gb3B0aW9uIGlzIGluY2x1ZGVkIGluDQp0aGUgcGF5bG9hZCwgYnV0IGl0IGlzIHJlbW92ZWQg YnkgdGhlIG1pZGRsZWJveGVzPw0KDQpUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoaXMgc29sdXRp b24gd2lsbCBiZSBkZXBsb3llZCBpbiBjb250cm9sbGVkIGVudmlyb25tZW50cyBhbmQgb25seSB1 c2VkIGJldHdlZW4gdGhlIENQRSBhbmQgdGhlIENvbmNlbnRyYXRvci4gU2luY2UgdGhlIG9wZXJh dG9yIGNvbnRyb2xzIHRoZSB0d28gbmV0d29ya3MgdGhhdCBhcmUgYm91bmQgdG9nZXRoZXIsIGhl IGNhbiB2ZXJpZnkgdGhhdCB0aGVyZSBhcmUgbm8gbWlkZGxlYm94ZXMgdGhhdCBkcm9wIHRoZSBQ TSBvcHRpb24uDQoNCkhtbS4gdGhlbiwgSSB0aGluayB0aGVzZSBwcmVzdW1wdGlvbnMgc2hvdWxk IGJlIGxpc3RlZCBpbiB0aGUgZHJhZnQuDQoNCltNZWRdIFRoZXNlIGFzc3VtcHRpb25zIGFyZSBh bHJlYWR5IGNhbGxlZCBvdXQgaW4gdGhlIGRyYWZ0LCBlLmcuLA0KDQpTZWN0aW9uIDE6DQoNCg0K QWxzbywgaXQgYXNzdW1lcyB0aGUgdmFyaW91cw0KDQogICBuZXR3b3JrIGF0dGFjaG1lbnRzIHBy b3ZpZGVkIHRvIGFuIE1QVENQLWVuYWJsZWQgQ1BFIGFyZSBtYW5hZ2VkIGJ5DQoNCiAgIHRoZSBz YW1lIGFkbWluaXN0cmF0aXZlIGVudGl0eS4NCg0KU2VjdGlvbiA0LjI6DQoNCg0KR2l2ZW4NCg0K ICAgICAgdGhhdCB0aGlzIG9wdGlvbiBpcyBkZXNpZ25lZCB0byBiZSB1c2VkIGluIGEgY29udHJv bGxlZA0KDQogICAgICBlbnZpcm9ubWVudCwgdGhpcyBzcGVjaWZpY2F0aW9uIHJlY29tbWVuZHMg dG8gYWx3YXlzIHBsYWNlIHRoZSBQTQ0KDQogICAgICBvcHRpb25zIGluc2lkZSB0aGUgcGF5bG9h ZCBvZiBhIFNZTiBzZWdtZW50Lg0KDQpEbyB5b3UgdGhpbmsgYWRkaXRpb25hbCB0ZXh0IGlzIHN0 aWxsIHJlcXVpcmVkPw0K --_000_787AE7BB302AE849A7480A190F8B933008D8DAACOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFlv c2hpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFlvc2hpZnVtaSBOaXNoaWRhIFttYWlsdG86bmlzaGlkYUBzZmMu d2lkZS5hZC5qcF0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAyNiBtYWkgMjAx NiAwODozMTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gT2xpdmllciBCb25hdmVudHVyZTxicj4NCjxi PkNjJm5ic3A7OjwvYj4gWW9zaGlmdW1pIE5pc2hpZGE7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE47IE11bHRpUGF0aCBXRzsgZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGVAaWV0Zi5v cmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBkcmFmdC1ib3Vj YWRhaXItbXB0Y3AtcGxhaW4tbW9kZS0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBPbGl2aWVyLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSAyNSwgMjAxNiBhdCAxMjo1MCBBTSwg T2xpdmllciBCb25hdmVudHVyZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9saXZpZXIuQm9uYXZlbnR1 cmVAdWNsb3V2YWluLmJlIiB0YXJnZXQ9Il9ibGFuayI+T2xpdmllci5Cb25hdmVudHVyZUB1Y2xv dXZhaW4uYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllvc2hpZnVtaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CkkgbWlnaHQgd2FudCB0byBzZWUgbW9yZSBmZWVkYmFjayBiZWZvcmUgdGhlIGFkb3B0aW9uIGNh bGwuPGJyPg0KSSd2ZSByZWFkIHRoZSBkcmFmdCwgYnV0IEkgdGhpbmsgSSBzdGlsbCBoYXZlIHNv bWUgdW5jbGVhciBwb2ludHMgaW4gdGhlPGJyPg0KZHJhZnQuPGJyPg0KPGJyPg0KSSBwYXJ0aWN1 bGFybHkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBmb2xsb3dpbmcgcG9pbnRzIGFzIHN0 YXJ0aW5nPGJyPg0KcG9pbnQuIFBsZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3Mgc29tZXRoaW5n Ljxicj4NCjxicj4NCjE6IFRoaXMgbWV0aG9kIHJlcXVpcmVzIENQRXMgdG8gY29udmVydCBVRFAg b3IgVENQIGludG8gTVBUQ1AgYW5kPGJyPg0KcmVxdWlyZXMgQ29uY2VudHJhdG9ycyB0byBjb252 ZXJ0IGJhY2sgTVBUQ1AgaW50byBVRFAgb3IgVENQLiBUaGlzIGNvdWxkPGJyPg0KYmUgcmF0aGVy IGNvbXBsZXggcHJvY2VzcyB0aGFuIG90aGVyIGFwcHJvYWNoIHN1Y2ggYXMgR1JFLiBTbywgd2hh dCdzPGJyPg0KdGhlIGJlbmVmaXRzIHRvIHV0aWxpemUgTVBUQ1AgaGVyZT8gSSB0aGluayB0aGUg ZHJhZnQgc2hvdWxkIGRlc2NyaWJlPGJyPg0Kc29tZSB1c2VmdWwgc2NlbmFyaW9zIHRvIHVzZSBN UFRDUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZXJlIGlz IGFscmVhZHkgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIHRoaXMgdHlwZSBvZiBzb2x1dGlv biBhbmQgaXQgdHVybnMgb3V0IHRoYXQgdXNpbmcgTVBUQ1AgdG8gc3VwcG9ydCBUQ1AgdHJhZmZp YyBpbiBoeWJyaWQgYWNjZXNzIG5ldHdvcmtzIGlzIGEgbXVjaCBiZXR0ZXIgYXBwcm9hY2ggdGhh biB1c2luZyBhIHR1bm5lbGluZyB0ZWNobmlxdWUgbGlrZSBHUkUuIEluIGFuIGh5YnJpZCBhY2Nl c3MgbmV0d29yayBzdWNoIGFzIERTTCYjNDM7TFRFLA0KIHRoZXJlIGFyZSB0d28gdHlwZXMgb2Yg cHJvYmxlbXMgdGhhdCBuZWVkIHRvIGJlIHRhY2tsZWQgOjxicj4NCjxicj4NCjEuIEhvdyB0byBo aWRlIHRoZSBkaWZmZXJlbnQgYWRkcmVzc2VzIHVzZWQgb24gdGhlIERTTCBhbmQgTFRFIG5ldHdv cmtzPGJyPg0KMi4gSG93IHRvIGFjaGlldmUgZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIG92ZXIg bmV0d29ya3MgaGF2aW5nIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MgKGRlbGF5LCBiYW5kd2lk dGgsIHBhY2tldCBsb3NzZXMpIHRoYXQgY2hhbmdlIGR5bmFtaWNhbGx5PGJyPg0KPGJyPg0KR1JF IHNvbHZlcyB0aGUgZmlyc3QgcHJvYmxlbSBpbiBhIGNsZWFuIG1hbm5lci4gSG93ZXZlciwgaXQg Y2F1c2VzIHR3byBpc3N1ZXMgd2hlbiB5b3UgY29uc2lkZXIgdGhlIHNlY29uZCBwcm9ibGVtIDo8 YnI+DQo8YnI+DQphLiBTaW5jZSBwYXRocyBoYXZlIGRpZmZlcmVudCBkZWxheXMsIGRvaW5nIHBl ciBwYWNrZXQgbG9hZCBiYWxhbmNpbmcgY3JlYXRlcyBtYXNzaXZlIHJlb3JkaW5nIHRoYXQgcmVz dWx0cyBpbiBiYWQgVENQIHBlcmZvcm1hbmNlPGJyPg0KYi4gU2luY2UgdGhlIHR3byB1bmRlcmx5 aW5nIHBhdGhzIGFyZSBoaWRkZW4gYnkgZW5jYXBzdWxhdGlvbiwgVENQJ3MgY29uZ2VzdGlvbiBj b250cm9sIHNjaGVtZSBjYW5ub3QgcHJvYmUgdGhlIGRpZmZlcmVudCBwYXRocyBhbmQgYWRqdXN0 IHRocyBjb25nZXN0aW9uIHdpbmRvdyBjb3JyZWN0bC4gVGhpcyByZXN1bHRzIGluIGJhZCBUQ1Ag cGVyZm9ybWFuY2UgYXMgd2VsbC48YnI+DQo8YnI+DQpBbiBNUFRDUC1iYXNlZCBzb2x1dGlvbiBz b2x2ZXMgdGhlc2UgcHJvYmxlbXMgaW4gYSBjbGVhbiBtYW5uZXIgc2luY2UgTVBUQ1Agc2VlcyB0 aGUgZGlmZmVyZW50IHBhdGhzIGFuZCBjYW4gdXNlIHRoZW0gZWZmaWNpZW50bHkuPGJyPg0KPGJy Pg0KWW91IGNhbiBmaW5kIHNvbWUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpbiB0aGUgVGVzc2Fy ZXMgd2hpdGVwYXBlciBwdWJsaXNoZWQgbGFzdCB5ZWFyPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0 cDovL3d3dy50ZXNzYXJlcy5uZXQvd2hpdGUtcGFwZXJzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cudGVzc2FyZXMubmV0L3doaXRlLXBhcGVycy88L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMg YWxyZWFkeSBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggdGhpcyB0eXBlIG9mIE1QVENQLWJh c2VkIHNvbHV0aW9ucyBhbmQgaWYgeW91IHRoaW5rIHRoYXQgdGhpcyB3b3VsZCBiZSB1c2VmdWws IHdlIGNvdWxkIG9yZ2FuaXNlIGEgcHJlc2VudGF0aW9uIGF0IHRoZSBuZXh0IElFVEYgbWVldGlu ZyBvbiB0aGlzIGV4cGVyaWVuY2U8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgSSB1bmRlcnN0YW5kIGdlbmVyYWwgaWRlYS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCwgYXMgZmFyIGFzIEkg cmVhZCB0aGUgZHJhZnQsIEkgZ290IGFuIGltcHJlc3Npb24gdGhhdCBhIFVEUCBvciBhIFRDUCBm bG93IHdpbGwgYmUgbWFwcGVkIHRvIGEgc2luZ2xlIHN1YmZsb3cgb2YgYSBtcHRjcCBzZXNzaW9u LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhlIGRyYWZ0IHNh eXMgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+U2VjdGlvbiA1LjE6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkYXRhIGNh cnJpZWQgaW4gVURQIGRhdGFncmFtcyBiZWxvbmdpbmcgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBhIGdpdmVuIFVEUCBmbG93 IGFyZSB0aGVyZWZvcmUgdHJhbnNwb3J0ZWQgaW4gYW4gTVBUQ1AgY29ubmVjdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFRo ZSBtYW5hZ2VtZW50IG9mIE1QVENQIGNvbm5lY3Rpb25zIHRoYXQgYXJlIHRyaWdnZXJlZCBieSBV RFA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyBkYXRhZ3JhbXMgZm9sbG93cyB0aGUgZ3VpZGVsaW5lcyBkb2N1bWVudGVkIGluIFs8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4MjQiIHRpdGxl PSImcXVvdDtUQ1AgRXh0ZW5zaW9ucyBmb3IgTXVsdGlwYXRoIE9wZXJhdGlvbiB3aXRoIE11bHRp cGxlIEFkZHJlc3NlcyZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzY4MjQ8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPlNlY3Rpb24gNS4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQSBmbG93IGV4YW1wbGUgaXMgc2hvd24gaW4gRmln dXJlIDUgdG8gaWxsdXN0cmF0ZSBob3cgVENQIHBhY2tldHMgYXJlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgZ2VuZXJhdGVkIHRvIHJlbGF5IFVEUCBkYXRhZ3JhbXMgdXNpbmcgc2V2ZXJhbCBzdWJm bG93cy4mbmJzcDsgTm9uLVNZTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2VzIHRoYXQg YmVsb25nIHRvIGEgZ2l2ZW4gc3ViZmxvdyBkbyBub3QgaW5jbHVkZSBhbnkgUE0gb3B0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFsc28sIHRoaXMgZXhhbXBsZSBzaG93cyBob3cgc3Vic2Vx dWVudCBVRFAgZGF0YWdyYW1zIG9mIHRoaXMgZmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFy ZSB0cmFuc3BvcnRlZCBvdmVyIHRoZSBleGlzdGluZyBzdWJmbG93IG9yIGhvdyBhIG5ldyBzdWJm bG93IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY3JlYXRlZC4mbmJzcDsgSW4gdGhpcyBleGFt cGxlLCB0aGUgU1lOIHNlZ21lbnQgaXNzdWVkIHRvIGFkZCBhIG5ldzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IHN1YmZsb3cgYWxzbyBpbmNsdWRlcyBkYXRhIHJlY2VpdmVkIGluIGEgVURQIGRhdGFn cmFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5h bmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBGaWd1cmUgNiBzaG93cyBhbiBleGFt cGxlIG9mIFVEUCBkYXRhZ3JhbXMgdGhhdCBhcmUgdHJhbnNwb3J0ZWQgb3ZlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IE1QVENQ IHN1YmZsb3dzLiZuYnNwOyBVbmxpa2UgdGhlIHByZXZpb3VzIGV4YW1wbGUsIGFkZGl0aW9uYWwg c3ViZmxvd3MgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyZuYnNwOyB0cmFuc3BvcnQgVURQIGRhdGFncmFtcyBvZiB0aGUgc2FtZSBmbG93 IGFyZSBlc3RhYmxpc2hlZCBpbiBhZHZhbmNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgYmV0d2VlbiB0aGUgQ1BFIGFuZCB0aGUg Y29uY2VudHJhdG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkRvIHlvdSB0aGluayBhZGRpdGlvbmFsIHRleHQgaXMgbmVlZGVkIHRvIG1ha2Ug aXQgY2xlYXI/IFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGVyZSBpcyBubyBkZXNjcmlwdGlvbiBhYm91dCB1c2luZyBtdWx0aXBs ZSBzdWJmbG93cyBmb3IgYSBzaW5nbGUgVENQL1VEUCBmbG93LCBvciB1cGRhdGluZyBzdWJmbG93 IG1hcHBpbmdzIGluIHRoZSBtaWRkbGUgb2YgYSBzZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBQbGVhc2UgcmVmZXIgdG8gRmln dXJlcyA1ICZhbXA7IDYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo ZSBkcmFmdCBzaG91bGQgbWVudGlvbiB0aGVzZSBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjI6IEluY2x1ZGluZyBkYXRhIGluIFNZTiBpcyBhbGxvd2VkIGluIFJGQzc5MywgYnV0IEknbSBu b3QgdmVyeSBzdXJlIGhvdzxicj4NCm1hbnkgaW1wbGVtZW50YXRpb25zIGFjdHVhbGx5IGFjY2Vw dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KV2VsbCwgdGhlIGRlcGxveW1lbnQg b2YgVEZPIHNob3dzIHRoYXQgdGhpcyBpcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZDxicj4NCmRpc2N1c3MgdGhp cyBwb2ludC4gQWxzbywgd2hhdCB3aWxsIGhhcHBlbiBpZiBQTSBvcHRpb24gaXMgaW5jbHVkZWQg aW48YnI+DQp0aGUgcGF5bG9hZCwgYnV0IGl0IGlzIHJlbW92ZWQgYnkgdGhlIG1pZGRsZWJveGVz PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhlIGFzc3VtcHRp b24gaXMgdGhhdCB0aGlzIHNvbHV0aW9uIHdpbGwgYmUgZGVwbG95ZWQgaW4gY29udHJvbGxlZCBl bnZpcm9ubWVudHMgYW5kIG9ubHkgdXNlZCBiZXR3ZWVuIHRoZSBDUEUgYW5kIHRoZSBDb25jZW50 cmF0b3IuIFNpbmNlIHRoZSBvcGVyYXRvciBjb250cm9scyB0aGUgdHdvIG5ldHdvcmtzIHRoYXQg YXJlIGJvdW5kIHRvZ2V0aGVyLCBoZSBjYW4gdmVyaWZ5IHRoYXQgdGhlcmUgYXJlIG5vIG1pZGRs ZWJveGVzIHRoYXQgZHJvcA0KIHRoZSBQTSBvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW0uIHRoZW4sIEkgdGhpbmsg dGhlc2UgcHJlc3VtcHRpb25zIHNob3VsZCBiZSBsaXN0ZWQgaW4gdGhlIGRyYWZ0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhlc2UgYXNzdW1wdGlvbnMgYXJlIGFscmVh ZHkgY2FsbGVkIG91dCBpbiB0aGUgZHJhZnQsIGUuZy4sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlNlY3Rpb24gMToNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+QWxzbywgaXQgYXNzdW1lcyB0aGUgdmFyaW91czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgYXR0YWNobWVudHMg cHJvdmlkZWQgdG8gYW4gTVBUQ1AtZW5hYmxlZCBDUEUgYXJlIG1hbmFnZWQgYnk8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB0aGUg c2FtZSBhZG1pbmlzdHJhdGl2ZSBlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiA0LjI6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5H aXZlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoYXQgdGhpcyBvcHRpb24gaXMgZGVzaWduZWQg dG8gYmUgdXNlZCBpbiBhIGNvbnRyb2xsZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnZpcm9u bWVudCwgdGhpcyBzcGVjaWZpY2F0aW9uIHJlY29tbWVuZHMgdG8gYWx3YXlzIHBsYWNlIHRoZSBQ TTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGlvbnMgaW5zaWRlIHRoZSBwYXlsb2FkIG9mIGEg U1lOIHNlZ21lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+RG8geW91IHRoaW5rIGFkZGl0aW9uYWwgdGV4dCBpcyBzdGlsbCByZXF1aXJlZD8N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933008D8DAACOPEXCLILMA3corp_-- From nobody Mon May 30 01:59:05 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6110112D1A8; Mon, 30 May 2016 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_40Ev6lXGv0; Mon, 30 May 2016 01:59:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD5112D106; Mon, 30 May 2016 01:59:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1A26B22C412; Mon, 30 May 2016 10:59:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E0A3C27C072; Mon, 30 May 2016 10:58:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0294.000; Mon, 30 May 2016 10:58:59 +0200 From: To: Yoshifumi Nishida , Olivier Bonaventure Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwD6x+gAAADSjoAAL4UoAAATA+oAACFWfQAAAERmgAAimuMAAHo+QPA= Date: Mon, 30 May 2016 08:58:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D8DAC3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D8DAC3OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:59:04 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D8DAC3OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogWW9zaGlm dW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwXQ0KRW52b3nDqSA6IHNh bWVkaSAyOCBtYWkgMjAxNiAwMjowOQ0Kw4AgOiBPbGl2aWVyIEJvbmF2ZW50dXJlDQpDYyA6IFlv c2hpZnVtaSBOaXNoaWRhOyBPbGl2aWVyIEJvbmF2ZW50dXJlOyBCT1VDQURBSVIgTW9oYW1lZCBJ TVQvT0xOOyBNdWx0aVBhdGggV0c7IGRyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlQGll dGYub3JnDQpPYmpldCA6IFJlOiBbbXVsdGlwYXRodGNwXSBkcmFmdC1ib3VjYWRhaXItbXB0Y3At cGxhaW4tbW9kZS0wNw0KDQpIaSBPbGl2aWVyLA0KDQpPbiBGcmksIE1heSAyNywgMjAxNiBhdCAx MjozOCBBTSwgT2xpdmllciBCb25hdmVudHVyZSA8b2xpdmllci5ib25hdmVudHVyZUB0ZXNzYXJl cy5uZXQ8bWFpbHRvOm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0Pj4gd3JvdGU6DQpZ b3NoaWZ1bWksDQoNCg0KICAgIFNpbmNlIHRoZSBtYXBwaW5nIGlzIGJldHdlZW4gYSBUQ1AgY29u bmVjdGlvbiAoVURQIGZsb3cpIGFuZCBhbg0KICAgIE1QVENQIGNvbm5lY3Rpb24sIGl0IGFwcGxp ZXMgZm9yIGFsbCB0aGUgc3ViZmxvd3Mgb2YgdGhlIE1QVENQDQogICAgY29ubmVjdGlvbiBhdXRv bWF0aWNhbGx5LiBJJ20gbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRoZSBtYXBwaW5nDQogICAg ZHVyaW5nIHRoZSBsaWZldGltZSBvZiBhbiBNUFRDUCBjb25uZWN0aW9uLCBpdCBsZWFkcyB0bw0K ICAgIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgdGhhdCBhcmUgbm90IHdvcnRoIHRoZSBlZmZv cnQgZ2l2ZW4gdGhhdA0KICAgIHdlIGNhbiBlc3RhYmxpc2ggYW5vdGhlciBNUFRDUCBjb25uZWN0 aW9uIGJvdW5kIHRvIGFub3RoZXIgZmxvdy4NCg0KDQpJIHNlZS4gU29ycnkuIEkgbWlnaHQgYmUg Y29uZnVzZWQgYnkgdGhlIG5hbWUgb2YgQ29uY2VudHJhdG9yLi4NCg0KVGhlbiwgbXkgYW5vdGhl ciBxdWVzdGlvbiBpcyBpZiB3ZSBjYW4gZG8gdGhlIHNhbWUgdGhpbmcgd2l0aA0KYXBwbGljYXRp b24gbGV2ZWwuDQpJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gd3JpdGUgYW4gYXBwbGljYXRpb24g Z2F0ZXdheSBmb3IgQ1BFIGFuZA0KQ29uY2VudHJhdG9yIHRvIHNlbmQgbWFwcGluZyBpbmZvcm1h dGlvbiBqdXN0IGxpa2UgUE0gb3B0aW9uLCAoYW5kIGRvDQpzb21lIHNlZ21lbnRhdGlvbiB0YXNr cyBhcyB3ZWxsKSBzbyB0aGF0IHdlIGNhbiBtaXRpZ2F0ZSBtaWRkbGVib3gNCmludGVydmVudGlv bnMuDQoNClRoZSBjbG9zZXN0IHNvbHV0aW9uIGluIHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBpcyBT T0NLUy4gVGhpcyBpcyB3aGF0IEtUIGlzIGRvaW5nIGluIEtvcmVhIGFuZCB3aGF0IE9WSCBpcyBk ZXBsb3lpbmcgZm9yIHRoZWlyIE92ZXJUaGVCb3ggc29sdXRpb24uIEJvdGggZG8gdGhpcyBvbiB0 b3Agb2YgTVBUQ1AuDQoNCkkgbWlnaHQgd2FudCB0byB1bmRlcnN0YW5kIHByb3MgYW5kIGNvbnMg Zm9yIHRoZSBwcm9wb3NhbA0KDQpbTWVkXSBCZWxvdyBpcyBwcm92aWRlZCBhbiBleGNlcnB0IGZy b20gdGhlIGRyYWZ0Og0KDQoNCiAgIG8gIE5vIGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQgKG5vIHR1 bm5lbHMsIHdoYXRzb2V2ZXIpLg0KDQogICBvICBObyBvdXQtb2YtYmFuZCBzaWduYWxpbmcgZm9y IGVhY2ggTVBUQ1Agc3ViZmxvdyByZXF1aXJlZC4NCg0KICAgbyAgQ2FycmllcyBhbnkgcHJvdG9j b2wgKGluY2wuICBVRFApIGZvciB0aGUgYmVuZWZpdCBvZiBtYXNzaXZlIE1QVENQDQoNCiAgICAg IGFkb3B0aW9uIChTZWN0aW9uIDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJv dWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3I3NlY3Rpb24tNT4pLg0KDQogICBvICBBY2NvbW1v ZGF0ZXMgdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzIChTZWN0aW9uIDY8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3I3NlY3Rp b24tNj4pLg0KDQpXaGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czoNCg0KwrcgICAg ICAgICBObyBjaGF0dHk6IHRoZSBzb2x1dGlvbiBkb2VzIG5vdCBvdmVybG9hZCB0aGUgY29uY2Vu dHJhdG9yIHdpdGggb3V0LW9mLWJhbmRpbmcgc2lnbmFsaW5nIG1lc3NhZ2VzLg0KDQrCtyAgICAg ICAgIE5vIGV4dHJhIGRlbGF5IHRvIGVzdGFibGlzaCBNUFRDUCBjb25uZWN0aW9ucy4NCg0Kwrcg ICAgICAgICBTdXBwb3J0cyBVRFANCg0KwrcgICAgICAgICBBbGxvd3MgdG8gc2hhcmUgdGhlIHNh bWUgZXh0ZXJuYWwgSVAgYWRkcmVzcyBhbW9uZyB2YXJpb3VzIHN1YnNjcmliZXJzIChkZXBsb3lt ZW50cyBzdWZmZXJpbmcgZnJvbSBJUHY0IGFkZHJlc3MgZGVwbGV0aW9uKQ0KDQrCtyAgICAgICAg IEFsbG93cyB0byBhc3NpZ24gYSBzaW5nbGUgSVAgYWRkcmVzcyBmb3IgY29ubmVjdGlvbnMgdGhh dCBiZWxvbmcgdG8gdGhlIHNhbWUgc3Vic2NyaWJlciAoZGVwbG95bWVudHMgd2l0aCBubyBwcmVz c3VyZSBvbiBJUHY0IGFkZHJlc3MgdXNhZ2UpDQoNCsK3ICAgICAgICAgQWxsb3dzIHRvIHByZXNl cnZlIHRoZSBzb3VyY2UgSVB2NiBhZGRyZXNzDQoNCsK3ICAgICAgICAg4oCmDQoNClRoZSBkcmFm dCBhY2tub3dsZWRnZXMgdGhlIG92ZXJoZWFkIGZvciBVRFAuDQoNCmFuZCBvdGhlcnMuDQpJdCB3 b3VsZCBiZSBnb29kIHRvIGhhdmUgdGhpcyBzb3J0IG9mIGRpc2N1c3Npb25zIGluIHRoZSBkcmFm dC4NCg0KW01lZF0gV2UgYWxyZWFkeSBoYXZlIHNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgYWJvdXQg dGhlIGNvbnMgb2YgdXNpbmcsIGUuZy4sIFNPQ0tTOg0KDQogICBDdXJyZW50IG9wZXJhdGlvbmFs IE1QVENQIGRlcGxveW1lbnRzIGJ5IG5ldHdvcmsgb3BlcmF0b3JzIGFyZQ0KICAgZm9jdXNlZCBv biB0aGUgZm9yd2FyZGluZyBvZiBUQ1AgdHJhZmZpYy4gIEluIGFkZGl0aW9uLCB0aGUgZGVzaWdu IG9mDQogICBzdWNoIGRlcGxveW1lbnRzIHNvbWV0aW1lcyBhc3N1bWVzIHRoZSB1c2Ugb2YgZXh0 cmEgc2lnbmFsbGluZw0KICAgcHJvdmlkZWQgYnkgU09DS1MgW1JGQzE5Mjg8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzE5Mjg+XSwgYXQgdGhlIGNvc3Qgb2YgYWRkaXRpb25hbCBtYW5h Z2VtZW50DQogICBjb21wbGV4aXR5IGFuZCBwb3NzaWJsZSBzZXJ2aWNlIGRlZ3JhZGF0aW9uIChl LmcuLCB1cCB0byA4IFNPQ0tTDQogICBtZXNzYWdlcyBtYXkgbmVlZCB0byBiZSBleGNoYW5nZWQg YmV0d2VlbiB0d28gTVBUQ1AgcHJveGllcyBiZWZvcmUgYW4NCiAgIE1QVENQIGNvbm5lY3Rpb24g aXMgZXN0YWJsaXNoZWQsIHRoZXJlYnkgeWllbGRpbmcgc2V2ZXJhbCB0ZW5zIG9mDQogICBtaWxs aXNlY29uZHMgb2YgZXh0cmEgZGVsYXkgYmVmb3JlIHRoZSBjb25uZWN0aW9uIGlzIGVzdGFibGlz aGVkKS4NCkZ1cnRoZXIsIGEgU09DS1MtYmFzZWQgc29sdXRpb24gZG9lcyBub3QgYWxsb3cgdG8g c3VwcG9ydCBuYXRpdmVseSBVRFAgYm9uZGluZy4NCg0KVGhhbmtzLA0KLS0NCllvc2hpDQo= --_000_787AE7BB302AE849A7480A190F8B933008D8DAC3OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjEyNTk1NTg5MTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE0NzE1NzAyMTggMTkzMzYzMTU3MCA2Nzg5NTI5OSA2Nzg5NTMw MSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ UmUtLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBZb3NoaWZ1bWkgTmlzaGlkYSBbbWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQu anBdDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gc2FtZWRpIDI4IG1haSAyMDE2IDAyOjA5 PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBPbGl2aWVyIEJvbmF2ZW50dXJlPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYTsgT2xpdmllciBCb25hdmVudHVyZTsgQk9VQ0FEQUlS IE1vaGFtZWQgSU1UL09MTjsgTXVsdGlQYXRoIFdHOyBkcmFmdC1ib3VjYWRhaXItbXB0Y3AtcGxh aW4tbW9kZUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFttdWx0aXBhdGh0 Y3BdIGRyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE9saXZpZXIsPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXkgMjcsIDIwMTYgYXQgMTI6 MzggQU0sIE9saXZpZXIgQm9uYXZlbnR1cmUgJmx0OzxhIGhyZWY9Im1haWx0bzpvbGl2aWVyLmJv bmF2ZW50dXJlQHRlc3NhcmVzLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm9saXZpZXIuYm9uYXZlbnR1 cmVAdGVzc2FyZXMubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPllvc2hpZnVtaSw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg U2luY2UgdGhlIG1hcHBpbmcgaXMgYmV0d2VlbiBhIFRDUCBjb25uZWN0aW9uIChVRFAgZmxvdykg YW5kIGFuPGJyPg0KJm5ic3A7ICZuYnNwOyBNUFRDUCBjb25uZWN0aW9uLCBpdCBhcHBsaWVzIGZv ciBhbGwgdGhlIHN1YmZsb3dzIG9mIHRoZSBNUFRDUDxicj4NCiZuYnNwOyAmbmJzcDsgY29ubmVj dGlvbiBhdXRvbWF0aWNhbGx5LiBJJ20gbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRoZSBtYXBw aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIGFuIE1QVENQIGNv bm5lY3Rpb24sIGl0IGxlYWRzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyBpbXBsZW1lbnRhdGlvbiBj b21wbGV4aXR5IHRoYXQgYXJlIG5vdCB3b3J0aCB0aGUgZWZmb3J0IGdpdmVuIHRoYXQ8YnI+DQom bmJzcDsgJm5ic3A7IHdlIGNhbiBlc3RhYmxpc2ggYW5vdGhlciBNUFRDUCBjb25uZWN0aW9uIGJv dW5kIHRvIGFub3RoZXIgZmxvdy48YnI+DQo8YnI+DQo8YnI+DQpJIHNlZS4gU29ycnkuIEkgbWln aHQgYmUgY29uZnVzZWQgYnkgdGhlIG5hbWUgb2YgQ29uY2VudHJhdG9yLi48YnI+DQo8YnI+DQpU aGVuLCBteSBhbm90aGVyIHF1ZXN0aW9uIGlzIGlmIHdlIGNhbiBkbyB0aGUgc2FtZSB0aGluZyB3 aXRoPGJyPg0KYXBwbGljYXRpb24gbGV2ZWwuPGJyPg0KSSBhbSB3b25kZXJpbmcgaWYgd2UgY2Fu IHdyaXRlIGFuIGFwcGxpY2F0aW9uIGdhdGV3YXkgZm9yIENQRSBhbmQ8YnI+DQpDb25jZW50cmF0 b3IgdG8gc2VuZCBtYXBwaW5nIGluZm9ybWF0aW9uIGp1c3QgbGlrZSBQTSBvcHRpb24sIChhbmQg ZG88YnI+DQpzb21lIHNlZ21lbnRhdGlvbiB0YXNrcyBhcyB3ZWxsKSBzbyB0aGF0IHdlIGNhbiBt aXRpZ2F0ZSBtaWRkbGVib3g8YnI+DQppbnRlcnZlbnRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhlIGNsb3Nlc3Qgc29sdXRpb24gaW4gdGhlIGFwcGxp Y2F0aW9uIGxldmVsIGlzIFNPQ0tTLiBUaGlzIGlzIHdoYXQgS1QgaXMgZG9pbmcgaW4gS29yZWEg YW5kIHdoYXQgT1ZIIGlzIGRlcGxveWluZyBmb3IgdGhlaXIgT3ZlclRoZUJveCBzb2x1dGlvbi4g Qm90aCBkbyB0aGlzIG9uIHRvcCBvZiBNUFRDUC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgbWlnaHQgd2FudCB0byB1bmRlcnN0YW5kIHByb3MgYW5kIGNv bnMgZm9yIHRoZSBwcm9wb3NhbDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gQmVsb3cgaXMgcHJvdmlkZWQgYW4gZXhj ZXJwdCBmcm9tIHRoZSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvJm5i c3A7IE5vIGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQgKG5vIHR1bm5lbHMsIHdoYXRzb2V2ZXIpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IG8mbmJzcDsgTm8gb3V0LW9mLWJhbmQgc2lnbmFsaW5nIGZvciBlYWNoIE1QVENQIHN1YmZs b3cgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBDYXJyaWVzIGFueSBwcm90b2NvbCAoaW5jbC4mbmJz cDsgVURQKSBmb3IgdGhlIGJlbmVmaXQgb2YgbWFzc2l2ZSBNUFRDUDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj5hZG9wdGlvbiAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3I3NlY3Rpb24tNSI+U2VjdGlv biA1PC9hPikuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQWNj b21tb2RhdGVzIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cyAoPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3I3Nl Y3Rpb24tNiI+U2VjdGlvbiA2PC9hPikuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5XaGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk5vIGNo YXR0eTogdGhlIHNvbHV0aW9uIGRvZXMgbm90IG92ZXJsb2FkIHRoZSBjb25jZW50cmF0b3Igd2l0 aCBvdXQtb2YtYmFuZGluZyBzaWduYWxpbmcgbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5ObyBleHRyYSBkZWxheSB0byBl c3RhYmxpc2ggTVBUQ1AgY29ubmVjdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TdXBwb3J0cyBVRFA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7 Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFsbG93cyB0byBzaGFy ZSB0aGUgc2FtZSBleHRlcm5hbCBJUCBhZGRyZXNzIGFtb25nIHZhcmlvdXMgc3Vic2NyaWJlcnMg KGRlcGxveW1lbnRzIHN1ZmZlcmluZyBmcm9tIElQdjQgYWRkcmVzcyBkZXBsZXRpb24pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGxv d3MgdG8gYXNzaWduIGEgc2luZ2xlIElQIGFkZHJlc3MgZm9yIGNvbm5lY3Rpb25zIHRoYXQgYmVs b25nIHRvIHRoZSBzYW1lIHN1YnNjcmliZXIgKGRlcGxveW1lbnRzIHdpdGggbm8gcHJlc3N1cmUg b24gSVB2NCBhZGRyZXNzIHVzYWdlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWxsb3dzIHRvIHByZXNlcnZlIHRoZSBzb3VyY2UgSVB2 NiBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+VGhlIGRyYWZ0IGFja25vd2xlZGdlcyB0aGUgb3ZlcmhlYWQgZm9yIFVEUC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48L3NwYW4+YW5kIG90aGVycy4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdv dWxkIGJlIGdvb2QgdG8gaGF2ZSB0aGlzIHNvcnQgb2YgZGlzY3Vzc2lvbnMgaW4gdGhlIGRyYWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2UgYWxyZWFkeSBoYXZlIHNv bWUgdGV4dCBpbiB0aGUgZHJhZnQgYWJvdXQgdGhlIGNvbnMgb2YgdXNpbmcsIGUuZy4sIFNPQ0tT Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBD dXJyZW50IG9wZXJhdGlvbmFsIE1QVENQIGRlcGxveW1lbnRzIGJ5IG5ldHdvcmsgb3BlcmF0b3Jz IGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGZvY3VzZWQgb24gdGhlIGZvcndhcmRpbmcgb2Yg VENQIHRyYWZmaWMuJm5ic3A7IEluIGFkZGl0aW9uLCB0aGUgZGVzaWduIG9mPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgc3VjaCBkZXBsb3ltZW50cyBzb21ldGltZXMgYXNzdW1lcyB0aGUgdXNlIG9m IGV4dHJhIHNpZ25hbGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwcm92aWRlZCBieSBTT0NL UyBbPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMTkyOCIgdGl0bGU9IiZxdW90O1NPQ0tTIFByb3RvY29sIFZlcnNpb24gNSZxdW90OyI+PHNw YW4gbGFuZz0iRU4tVVMiPlJGQzE5Mjg8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPl0sDQogYXQgdGhlIGNvc3Qgb2YgYWRkaXRpb25hbCBtYW5hZ2VtZW50PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgY29tcGxleGl0eSBhbmQgcG9zc2libGUgc2VydmljZSBkZWdyYWRhdGlv biAoZS5nLiwgdXAgdG8gOCBTT0NLUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2VzIG1h eSBuZWVkIHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBNUFRDUCBwcm94aWVzIGJlZm9yZSBh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE1QVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQs IHRoZXJlYnkgeWllbGRpbmcgc2V2ZXJhbCB0ZW5zIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg bWlsbGlzZWNvbmRzIG9mIGV4dHJhIGRlbGF5IGJlZm9yZSB0aGUgY29ubmVjdGlvbiBpcyBlc3Rh Ymxpc2hlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkZ1 cnRoZXIsIGEgU09DS1MtYmFzZWQgc29sdXRpb24gZG9lcyBub3QgYWxsb3cgdG8gc3VwcG9ydCBu YXRpdmVseSBVRFAgYm9uZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3NoaTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933008D8DAC3OPEXCLILMA3corp_-- From nobody Mon May 30 02:23:04 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5212D188 for ; Mon, 30 May 2016 02:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHa5fHhXggkW for ; Mon, 30 May 2016 02:23:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25E112D13E for ; Mon, 30 May 2016 02:23:00 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 3EC7640443; Mon, 30 May 2016 11:22:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 0A4381A0072; Mon, 30 May 2016 11:22:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0294.000; Mon, 30 May 2016 11:22:58 +0200 From: To: Rao Shoaib , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwD6x+gAAADSjoAAFPu4AAACo1IAAIGFBYAAaOrJoA== Date: Mon, 30 May 2016 09:22:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> In-Reply-To: <57495D0D.50100@oracle.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 09:23:03 -0000 Hi Shoaib,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de = Rao > Shoaib > Envoy=E9=A0: samedi 28 mai 2016 10:56 > =C0=A0: Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 >=20 >=20 > On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: > > Rao, > >> > >> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: > >>> The assumption is that this solution will be deployed in controlled > >>> environments and only used between the CPE and the Concentrator. Sinc= e > >>> the operator controls the two networks that are bound together, he ca= n > >>> verify that there are no middleboxes that drop the PM option. > >>> > >>> > >>> Olivier > >> I am extremely interested in encapsulating UDP in MPTCP but this > >> solution is very specific and hence why should it even be standardized > ? > > > > There is a clear demand from operators for a solution to this problem > > in hybrid access networks. >=20 > OK but this solution is very specific to the mobile network. [Med] The solution is not specific to the mobile network, but targets all n= etwork providers who want to allow their customers to make use of all avail= able network attachments (e.g., fixed, WLAN, cellular, etc.) We would > prefer a generic encapsulation solution which has no address mapping. [Med] It seems that you want to cover the case of an MPTCP-enabled host com= municating an MPTCP-enabled server exchanging any protocol data inside an M= PTCP connection? Can you please confirm/infirm? > Maybe the address mapping part should be made optional based on a flag ? [Med] The technical details can be worked out once we understand your deplo= yment case. [snip] > >> > >> Also the concentrator stuff is deployment specific and should added as > >> an application header. > > > > What do you mean by concentrator stuff ? > Address mapping stuff -- Use of D bit. > > > >> What needed is a standard way (new option) to signal the other end tha= t > >> the current message needs special handling and that's it. How such a > >> message is handled can be implementation specific. > > > > In hybrid access networks, MPTCP_based bonding for UDP is mainly > > useful for large flows. In this case, creating an MPTCP connection per > > flow implies that you do not need to reproduce the IP and UDP headers > > in the MPTCP connection > > > For our use case (Host Environment) preserving ports and reducing number > of connections is more important. Including protocol message header > allows use of the same connection for encapsulating any protocol and any > port. Also note that size of UDP header is only 8 bytes and we can omit > checksum and reduce it to 6 bytes which is a very small fraction for > even a 1K message size. >=20 > After re-reading the draft I think the proposal for encapsulation is > pretty good, only minor details need to be cleared up. >=20 [Med] Thank you. We are more than open to discuss those details. > Shoaib >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue May 31 01:35:25 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D223612B04F for ; Tue, 31 May 2016 01:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl2HYMFywzrr for ; Tue, 31 May 2016 01:35:21 -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 89BDB12B04E for ; Tue, 31 May 2016 01:35:21 -0700 (PDT) Received: from [141.85.233.104] (helo=[172.19.9.152]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1b7f8u-0005MQ-Pc; Tue, 31 May 2016 09:35:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Costin Raiciu In-Reply-To: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> Date: Tue, 31 May 2016 11:35:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> To: Alan Ford X-Mailer: Apple Mail (2.2104) Archived-At: Cc: multipathtcp Subject: [multipathtcp] Load balancing MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 08:35:24 -0000 Dear all, We have published a paper that presents the design and implementation of = a MPTCP load balancer for datacenters. The paper is called Datacenter = Scale Load Balancing for Multipath Transport, will appear in = HotMiddlebox 2016 and you can download it here: = http://nets.cs.pub.ro/~costin/files/mplb.pdf In short, we use the unmodified MPTCP protocol but encode the server = identifier in the least significant 10bits of the timestamps. This is a = hack and we acknowledge it, but it shows that one can build scalable = load balancers without changing the protocol. We are now working on a refinement of our design that will not rely on = timestamps. Following Olivier=E2=80=99s suggestion, we will use = destination port numbers for subsequent subflows for load balancing = purposes (as you know, destination port numbers don=E2=80=99t really = matter for subflow setup where the token is used instead). We will write = a draft about our solution and present it at the Berlin IETF. What this work shows is that there is no need to (drastically or at all) = change the MPTCP protocol for load balancer support. Best. Costin