From nobody Tue Apr 4 15:10:21 2017 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 33BAA129329 for ; Tue, 4 Apr 2017 15:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt9zDsZeh8lq for ; Tue, 4 Apr 2017 15:10:17 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B5A12778E for ; Tue, 4 Apr 2017 15:10:16 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id w11so222642646wrc.3 for ; Tue, 04 Apr 2017 15:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=916koTbDNiTbdfpu8WNc1e4oA4BL+XDSuoS6gZcpSyA=; b=VOyeQgKx/IAetx9zeTr6mfdgu81NOOpoNndzIYgBBDfrsHh0CrI40dGtCpFYjxR6Q2 cSWjaehYz88fJlc1Dt+NxWGa0qplzDXd37hK7daVSZgr7ueJh6neKM73dRrm86QwTMK7 O8pQG0z2Yw6Y61AWXmQWXiVqMwUiwC6DNi1ddUDzkQTox4QxLQmmUKh0OR/ZxRC97FrS Kk6w2/pIaDga/M9gpyIweUJ1XnqC+0Eow2ekY0G+DbPEWcdAamvwI3Zf+9UBlDAHjJ7+ Nme9PDYmcOXMJjhMrqYS4CxD6qRITfDUkxPnsPTIHAOF9MU/vyKDEPPqo+4QaZ1MdYFi sgTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=916koTbDNiTbdfpu8WNc1e4oA4BL+XDSuoS6gZcpSyA=; b=H+ktL8pM6aOyZ6kjJb+q9Yzois1RRNbnSV1fAlc70FL34unQ1jGWVnNdWrf1PbrDgS FqnV/jHZ5rKJDv14W2Kyy/SiSWRWSbHb9py0+1i7RRHqdwUA1ytkr9d65EcGbMpu0upz ECUZlX4ZG03aWplD/DELm4A8B8vrwGAmuXqdkbNItB/MymyAoVlXmx5kMjdw0qf1yFb0 DcYiY4m6p6yrCdKzreOQ+ojOgTK6Le+BDpYtdQ3KNPQ36TaMHRoK4JBUyOlTp2LmKPXU N2EqQHdxJDUPkp7jYRchMocYvhHjoROdarFQxKarpQ7tqpaC1+pPOcN2dg3mqS+PCg+7 Hvgw== X-Gm-Message-State: AFeK/H1o3nDaEScywSKLWBW2VRX8dL8o6exWExwyIwIzUqH3e5CqahW1sbV3n1mmK2XDSQ== X-Received: by 10.223.138.200 with SMTP id z8mr23979528wrz.49.1491343815236; Tue, 04 Apr 2017 15:10:15 -0700 (PDT) Received: from alans-mbp.lan ([83.216.156.174]) by smtp.gmail.com with ESMTPSA id 82sm23568263wmg.0.2017.04.04.15.10.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 15:10:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01EAB65A-F8FD-4C95-8CC6-1D9E127DD28F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <1412F543-0345-4C30-87DF-7E5F1DF54F5F@apple.com> Date: Tue, 4 Apr 2017 23:10:14 +0100 Cc: =?utf-8?Q?Fabien_Duch=C3=AAne?= , MultiPath TCP - IETF WG Message-Id: References: <57AB4BF2.7080405@uclouvain.be> <1412F543-0345-4C30-87DF-7E5F1DF54F5F@apple.com> To: Christoph Paasch X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] Multipath TCP Address advertisement 3/5 - Backup make after break X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:10:19 -0000 --Apple-Mail=_01EAB65A-F8FD-4C95-8CC6-1D9E127DD28F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Following up from discussion at IETF98=E2=80=A6 Does anyone else wish to = voice support for this proposal? > On 15 Aug 2016, at 22:03, Christoph Paasch wrote: >=20 >>=20 >> On Aug 10, 2016, at 8:44 AM, Fabien Duch=C3=AAne = wrote: >>=20 >> Hello, >>=20 >> As agreed in Berlin during IETF96, I'm sending a series of emails to >> discuss the different contributions proposed in: >> https://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/ >>=20 >> This is the part 3/5 : Backup make after break. >>=20 >> There are use cases where hosts would prefer to establish an = additional >> subflow only after the failure of the initial one. >> This would correspond to a break-before-make scenario. Multipath TCP = did >> not select between break-before-make and make-before-break. >> We propose to support this distinction by adding the "B" (for backup) >> flag in the ADD_ADDR option. >> When set, this flag would indicate that the announced address should >> only be used to establish subflows if all the subflows established = with >> addresses without the B flag have failed. >=20 > +1 on this proposal! >=20 >=20 > Christoph >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp = --Apple-Mail=_01EAB65A-F8FD-4C95-8CC6-1D9E127DD28F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Following up from discussion at IETF98=E2=80=A6 Does anyone = else wish to voice support for this proposal?

On 15 Aug 2016, at 22:03, Christoph Paasch <cpaasch@apple.com> = wrote:


On Aug 10, 2016, at = 8:44 AM, Fabien Duch=C3=AAne <fabien.duchene@uclouvain.be> wrote:

Hello,

As agreed in Berlin = during IETF96, I'm sending a series of emails to
discuss = the different contributions proposed in:
https://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/<= /a>

This is the part 3/5 : Backup make = after break.

There are use cases where = hosts would prefer to establish an additional
subflow only = after the failure of the initial one.
This would = correspond to a break-before-make scenario. Multipath TCP did
not select between break-before-make and = make-before-break.
We propose to support this distinction = by adding the "B" (for backup)
flag in the ADD_ADDR = option.
When set, this flag would indicate that the = announced address should
only be used to establish = subflows if all the subflows established with
addresses = without the B flag have failed.

+1 on this = proposal!


Christoph


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

= --Apple-Mail=_01EAB65A-F8FD-4C95-8CC6-1D9E127DD28F-- From nobody Tue Apr 4 15:25:10 2017 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 93FD61293DA for ; Tue, 4 Apr 2017 15:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_GxEDSJpTxB for ; Tue, 4 Apr 2017 15:25:01 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD46126E01 for ; Tue, 4 Apr 2017 15:25:00 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id t20so20512481wra.1 for ; Tue, 04 Apr 2017 15:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y8S2EKTsYVCdaIfuTx+0MdE+UMdSFiA1Ug/nmFqFjc4=; b=jInJivaP+XFN/Se87AbJUieaUY6fxxfXeTNUVgmcy4FLc45ov0o9pzWdHqvdZZS8El meFc0/vcqR5jpYQqPvvSbQiNqye1I4q64rOt7y9wziNfhZS2zkQ1NzRWs2zeWPTxEDBA JnThNoHAAZ6aAZ7Zvvsi5UA6pJq/WzfjbAgOED3h3q455sUzdey/SFbgg4Y7lMU7a3sl NVTRiHpOWZ4zhWZHvE1YhmtKtIpHdpyJhTL4yxdPUb6mFjVQfQVV7uD8L4xfnfNnCu33 kOqknKTLQnHjhY8C8he+QedCxmxrGFjK/bprnlJ027s1tO6UACud8LZXw9yl6ze4VMIs ok2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y8S2EKTsYVCdaIfuTx+0MdE+UMdSFiA1Ug/nmFqFjc4=; b=loPRDLBbKXwrlE2I9AiSvS5h4fC/zbUBm2exAhazSy+sjFUWS/t++pr+b9tAhPDhno uaaX6NLsB53zD+9XRwW80sVLB3Ut93SLNHnlp5zahz3rzTeJIf1M+ZYkeWRLafl861M3 v6WaBjNtaK9rk+WR6Ldvme4InMOBwblar0tX0o34ffhvi8pEOo3CH4uoZuRapJJqdBkM 6rSbHkdog6f2RCe5zxCsqTeowwvRomVDe87rzxN5l71qn51V2aOlRLEIrh9Jve7Bfsat J4iHn4cbW/csVm171GM1rQX7CrUvPtqLjrSamSMWqQtnEhAJBYormgWAVU5PQ9TEjtxN ms5w== X-Gm-Message-State: AFeK/H0b+2psN6BiPBhMBtVw3l8Xl5aHDw+QalJeTA+Dzp1eu2nAmDFqZOaAbbsi93oN8w== X-Received: by 10.223.151.80 with SMTP id r74mr80988wrb.6.1491344698585; Tue, 04 Apr 2017 15:24:58 -0700 (PDT) Received: from alans-mbp.lan ([83.216.156.174]) by smtp.gmail.com with ESMTPSA id v108sm23795936wrc.41.2017.04.04.15.24.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 15:24:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org> Date: Tue, 4 Apr 2017 23:24:57 +0100 Cc: Olivier Bonaventure , multipathtcp Content-Transfer-Encoding: quoted-printable Message-Id: <5C42A33B-7746-45D8-97A6-46F9F64BD617@gmail.com> References: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org> To: Christoph Paasch X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] Timestamp option for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:25:07 -0000 Hi Olivier, Following up from IETF98 here, could you clarify what docs changes would = be required for your proposals here to be applied, both in terms of = 6824bis, and for any references (e.g. 7323)? Regards, Alan > On 29 Mar 2017, at 16:14, Christoph Paasch wrote: >=20 > Hello Olivier, >=20 >=20 > On 23/03/17 - 15:33:57, Olivier Bonaventure wrote: >> The standard timestamp option for TCP is defined in RFC7323. It is = widely >> implemented and used. It has two main objectives : >>=20 >> - timing measurements >> - protection agains wrapped sequence numbers >>=20 >>=20 >> Given the importance of the second utilisation, RFC7323 has mandated = the >> presence of a timestamp option in each segment once negotiated in the >> three-way handshake. For Multipath TCP, the DSN option already = protects us >> from PAWS problems and it should not be mandatory to include = timestamps in >> each packet sent over a Multipath TCP connection. Given the length of = the >> timestamp and DSN options these two options already consume a large = number >> of bytes and could limit the number of SACK blocks that can be placed = inside >> acknowledgements. >>=20 >> I will only be able to attend the Chicago meeting remotely, but I = would like >> to start a discussion on the utilisation of timestamps by Multipath = TCP on >> the list. I see two possibilities, but there are possibly more : >>=20 >> 1. Ask for a revision of RFC7323 that allows timestamp options to be >> optional in packets of Multipath TCP connections >=20 > if we do this, how would MPTCP decide whether or not to put a = TS-option in > the segment? And will this decision-process still allow to be fully = protected > against PAWS (when TSO-is used and the DSS-option does not end up on = every > segment)? >=20 > I can't think of a way to achieve this, because whenever we would = decide to not put > a TS-option, later on after 2^32-bytes this original data might be = subject > to being the "victim" of PAWS, even if we then switch into a mode = where we > use TS. >=20 >> 2. Define a new Multipath TCP option to carry timestamps. The = utilisation of >> this option would be included in Multipath TCP and thus no option = besides >> MP_CAPABLE would need to be included in the SYN. >=20 > I like this approach, because it seems to me to consume less = option-space. >=20 > How would this timestamp look like in the DSS-option? Would it still = be 32-bits? > I think we can make it less than 32-bits, right? >=20 >=20 > Christoph >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Apr 4 15:25:55 2017 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 7CFC2129466 for ; Tue, 4 Apr 2017 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzipdDCJIdPO for ; Tue, 4 Apr 2017 15:25:51 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF652128BE1 for ; Tue, 4 Apr 2017 15:25:49 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id w11so222808159wrc.3 for ; Tue, 04 Apr 2017 15:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=sFcxAfHzBfDIpRlsoLMbQ4L1euQ55OQ1jEpG2TXf6o4=; b=SZgjibsxw459/q/gGJAmA5tQHcCCpqBJ0elCjUgY/FZ9Egu9cXW+UCFbbTJXau9awq uoBNPOBw1NalQ4lXkUXsf12HDgHaUjelC6aRaOzHTDcjESlCbdHEaMBwRIn6VHFjiunu lHzIn0fhjCUBaPDuKi2ChNAr04Z4rd058pjjyFom9rbsbcYtGUIKNgT5LEKZrXsvdt3f QxNLQjx6KUV0p739+VzZtq7i1xgpHsAbF1mVq6/TVfwhpedfnIBoJl3XCSmpz61hcM54 Pk4FHH0Ov6R8lY37JkiY6+gm1AOtQDczwwo0PUOuUEbHYwDZ0G6xrTff7YEurdZpyt88 FvFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=sFcxAfHzBfDIpRlsoLMbQ4L1euQ55OQ1jEpG2TXf6o4=; b=aTe5S5flvaybBAjcVdTv3TZ9QY7fNC7arhjXKEaGHwqV98j/xw37IASq44O3jFNQe/ L9wkohyTUD+2lya81Kg7crV64m/iEVqRgT5WprEpaP14h6HVAbCiXRhLrqPPGld9o/8n dsBmYXTbaYjt4d5JCeJPvGsnqs4HchOLtnknk0w7zFSOPk74ZQMqsCh5DoPjq2WDt6nK UXy+51H4UCvHODHffSTOUJJQfaawU4XF7wkRxbAtGnHUzzBWw7SUkSydcP3RuvJc+wSA ifDf9v+LdTWCY4zJC+i1w1e1NJ1HXvY7u+XYxn/7UHrUzunJMMPLMsEeF4B1Aurwzls2 U/wg== X-Gm-Message-State: AFeK/H2mQGTrDuvd6abu+jG2JQ4XZURKk8aRfJ377yK3Ht9tAps+hl0jm6rvJYgxmQKtcg== X-Received: by 10.223.133.1 with SMTP id 1mr16607925wrh.111.1491344748360; Tue, 04 Apr 2017 15:25:48 -0700 (PDT) Received: from alans-mbp.lan ([83.216.156.174]) by smtp.gmail.com with ESMTPSA id v108sm23795936wrc.41.2017.04.04.15.25.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 15:25:47 -0700 (PDT) From: Alan Ford Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 4 Apr 2017 23:25:48 +0100 To: multipathtcp Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [multipathtcp] Data on MP_JOIN X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:25:54 -0000 Hi all, We saw two proposals in IETF98 that said they would find support for = data-on-MP_JOIN to be useful. Could we gather here exactly what the requirements for such a signal = would be, in terms of proposed changes to 6824bis? Or, in draft form :-) Regards, Alan= From nobody Thu Apr 6 02:06:16 2017 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 1E9F31201FA for ; Thu, 6 Apr 2017 02:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxbLdmdFZdNg for ; Thu, 6 Apr 2017 02:06:12 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FB51200FC for ; Thu, 6 Apr 2017 02:06:11 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Apr 2017 10:06:09 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Apr 2017 10:06:09 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 10:06:08 +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.1210.000; Thu, 6 Apr 2017 10:06:08 +0100 From: To: CC: , Thread-Topic: charter discussion Thread-Index: AQHSqjbkeB8hza43kkeFp7zv6Q4DoKG4ExUg Date: Thu, 6 Apr 2017 09:06:07 +0000 Message-ID: <814660b2aedf47efb66f671ef668f3e9@rew09926dag03b.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_814660b2aedf47efb66f671ef668f3e9rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:06:15 -0000 --_000_814660b2aedf47efb66f671ef668f3e9rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVoY2V0LA0KDQpUaGUgc2xpZGUgd2FzIGludGVuZGVkIHRvIGJlIGp1c3QgYSB2ZXJ5IGhpZ2gt bGV2ZWwgc2tldGNoLiBJbiBib3RoICMxIGFuZCAjMiwgdGhlIG9iamVjdGl2ZSBvZiB0aGUgc2ln bmFsbGluZyBpcyB0byBnZXQgYW4gZW5kcG9pbnTigJlzIElQIGFkZHJlc3MgaW5mbyBpbnRvIHRo ZSDigJhvdGhlcuKAmSBwcm94eSwgc28gdGhlIHByb3h5IGNhbiBkbyBhZGRyZXNzIG1hcHBpbmcg KHRyYW5zbGF0aW9uKSBvbiBzdWJzZXF1ZW50IHBhY2tldHMgKGluY2x1ZGluZyB0aGUgQUNLKSBz byB0aGF0IHBhY2tldHMgY2FuIHRyYXZlbCBiZXR3ZWVuIHRoZSBlbmRwb2ludHMuIEluIGJvdGgg IzEgYW5kICMyLCB0aGUgaWRlYSBpcyB0aGF0IHRoaXMgc2lnbmFsbGluZyBpcyBkb25lIGFsb25n IHdpdGggdGhlIFRDUCBTWU4sIHNvIHRoYXQgdGhlIGNvbm5lY3Rpb24gdmlhIHRoZSBwcm94aWVz IGlzIHNldCB1cCB3aXRoIG5vIGRlbGF5ICjigJwwIFJUVOKAnSkNCg0KQmVzdCB3aXNoZXMsDQpw aGlsDQoNCkZyb206IEJlaGNldCBTYXJpa2F5YSBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5j b21dDQpTZW50OiAzMSBNYXJjaCAyMDE3IDE2OjUzDQpDYzogRWFyZGxleSxQTCxQaGlsaXAsVFVC OCBSIDxwaGlsaXAuZWFyZGxleUBidC5jb20+OyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmc7IEpvZSBU b3VjaCA8dG91Y2hAaXNpLmVkdT4NClN1YmplY3Q6IGNoYXJ0ZXIgZGlzY3Vzc2lvbg0KDQpIaSBh bGwsDQoNClJlZ2FyZGluZyB0aGUgY2hhcnRlciBkaXNjdXNzaW9ucyB0aGF0IGhhcHBlbmVkIGF0 IHRoZSBtcHRjcCBzZXNzaW9uIG9uIFRodXJzZGF5IE1hcmNoIDMwLCBJIGFza2VkIGEgcXVlc3Rp b24gYnV0IEkgY291bGQgbm90IHVuZGVyc3RhbmQgdGhlIGFuc3dlciwgbGV0IG1lIGFzayBpdCBh Z2Fpbi4NCg0KSW4gY2hhaXJzIHNsaWRlcyBwYWdlIDEyLCBUQ1AgU1lOIHNob3duIGluIE9wdGlv biAxIGFuZCBPcHRpb24gMiBhY3R1YWxseSB3ZXJlIGRpZmZlcmVudCBhbHRob3VnaCB0aGUgc2xp ZGVzIHNlZW1zIHRvIHNob3cgdGhhdCB0aGV5IGFyZSB0aGUgc2FtZS4NCg0KSW4gT3B0aW9uIDEs IGlmIHRoZSBwcm94eSBzZW5kcyBUQ1AgU1lOIHRoYW4gaXMgaXQgT0sgaW4gYSBjb252ZXJzYXRp b24gdGhlIGRlc3RpbmF0aW9uIGRvZXMgbm90IGtub3cgd2hvIHRoZSBzb3VyY2UgaXM/DQoNCklu IE9wdGlvbiAyLCBpZiBUQ1AgU1lOIHNlbnQgd2FzIHRoZSBvcmlnaW5hbCBUQ1AgU1lOIGZyb20g dGhlIHNvdXJjZSB0aGVuDQoNCmhvdyBjb21lIHRoZSBUQ1AtQUNLIGdvZXMgdGhyb3VnaCB0aGUg cHJveHk/DQpBIG5vZGUgc2VuZGluZyBhIHBhY2tldCB3aXRob3V0IGl0cyBhZGRyZXNzIGFzIHNv dXJjZSBhZGRyZXNzIG1lYW5zIGl0IGlzIHJvdXRlciwgcmlnaHQ/DQoNClJlZ2FyZHMsDQoNCkJl aGNldA0KDQoNCg0KDQoNCg== --_000_814660b2aedf47efb66f671ef668f3e9rew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZWhjZXQsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgc2xpZGUgd2FzIGludGVuZGVkIHRvIGJl IGp1c3QgYSB2ZXJ5IGhpZ2gtbGV2ZWwgc2tldGNoLiBJbiBib3RoICMxIGFuZCAjMiwgdGhlIG9i amVjdGl2ZSBvZiB0aGUgc2lnbmFsbGluZyBpcyB0byBnZXQgYW4gZW5kcG9pbnTigJlzDQogSVAg YWRkcmVzcyBpbmZvIGludG8gdGhlIOKAmG90aGVy4oCZIHByb3h5LCBzbyB0aGUgcHJveHkgY2Fu IGRvIGFkZHJlc3MgbWFwcGluZyAodHJhbnNsYXRpb24pIG9uIHN1YnNlcXVlbnQgcGFja2V0cyAo aW5jbHVkaW5nIHRoZSBBQ0spIHNvIHRoYXQgcGFja2V0cyBjYW4gdHJhdmVsIGJldHdlZW4gdGhl IGVuZHBvaW50cy4gSW4gYm90aCAjMSBhbmQgIzIsIHRoZSBpZGVhIGlzIHRoYXQgdGhpcyBzaWdu YWxsaW5nIGlzIGRvbmUgYWxvbmcgd2l0aCB0aGUNCiBUQ1AgU1lOLCBzbyB0aGF0IHRoZSBjb25u ZWN0aW9uIHZpYSB0aGUgcHJveGllcyBpcyBzZXQgdXAgd2l0aCBubyBkZWxheSAo4oCcMCBSVFTi gJ0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZXN0IHdpc2hlcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+cGhpbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJl aGNldCBTYXJpa2F5YSBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMzEgTWFyY2ggMjAxNyAxNjo1Mzxicj4NCjxiPkNjOjwvYj4gRWFyZGxleSxQTCxQ aGlsaXAsVFVCOCBSICZsdDtwaGlsaXAuZWFyZGxleUBidC5jb20mZ3Q7OyBtdWx0aXBhdGh0Y3BA aWV0Zi5vcmc7IEpvZSBUb3VjaCAmbHQ7dG91Y2hAaXNpLmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gY2hhcnRlciBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBjaGFydGVyIGRpc2N1c3Npb25zIHRoYXQg aGFwcGVuZWQgYXQgdGhlIG1wdGNwIHNlc3Npb24gb24gVGh1cnNkYXkgTWFyY2ggMzAsIEkgYXNr ZWQgYSBxdWVzdGlvbiBidXQgSSBjb3VsZCBub3QgdW5kZXJzdGFuZCB0aGUgYW5zd2VyLCBsZXQg bWUgYXNrIGl0IGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiBjaGFpcnMgc2xpZGVzIHBhZ2UgMTIsIFRDUCBTWU4gc2hvd24gaW4g T3B0aW9uIDEgYW5kIE9wdGlvbiAyIGFjdHVhbGx5IHdlcmUgZGlmZmVyZW50IGFsdGhvdWdoIHRo ZSBzbGlkZXMgc2VlbXMgdG8gc2hvdyB0aGF0IHRoZXkgYXJlIHRoZSBzYW1lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBPcHRpb24gMSwg aWYgdGhlIHByb3h5IHNlbmRzIFRDUCBTWU4gdGhhbiBpcyBpdCBPSyBpbiBhIGNvbnZlcnNhdGlv biB0aGUgZGVzdGluYXRpb24gZG9lcyBub3Qga25vdyB3aG8gdGhlIHNvdXJjZSBpcz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gT3B0aW9u IDIsIGlmIFRDUCBTWU4gc2VudCB3YXMgdGhlIG9yaWdpbmFsIFRDUCBTWU4gZnJvbSB0aGUgc291 cmNlIHRoZW4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ob3cgY29tZSB0aGUgVENQLUFDSyBnb2VzIHRocm91Z2ggdGhlIHByb3h5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBub2RlIHNl bmRpbmcgYSBwYWNrZXQgd2l0aG91dCBpdHMgYWRkcmVzcyBhcyBzb3VyY2UgYWRkcmVzcyBtZWFu cyBpdCBpcyByb3V0ZXIsIHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWhjZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_814660b2aedf47efb66f671ef668f3e9rew09926dag03bdomain1sy_-- From nobody Thu Apr 6 04:18:58 2017 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 0A5D512785F for ; Thu, 6 Apr 2017 04:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Wnm1c_k5nHho for ; Thu, 6 Apr 2017 04:18:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3889129453 for ; Thu, 6 Apr 2017 04:18:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF87322; Thu, 06 Apr 2017 11:18:49 +0000 (GMT) Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 12:18:48 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 16:48:44 +0530 From: Sayee Kompalli Chakravartula To: "multipathtcp@ietf.org" Thread-Topic: A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVg== Date: Thu, 6 Apr 2017 11:18:45 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: multipart/alternative; boundary="_000_5C068B455EB58047BBD492DA2B0829FA3763ADD5blreml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58E6241A.0024, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b78d7c405c4a2ef4396eed46f5b11330 Archived-At: Subject: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:18:57 -0000 --_000_5C068B455EB58047BBD492DA2B0829FA3763ADD5blreml501mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, This is the first time I'm posting a question to the group!! I work for Hua= wei Technologies, India at Bangalore. For quite some time I've been reading= material on MPTCP, and of late, I have been thinking of a potential issue = related to MPTCP control overhead. I'm wondering whether the issue I articu= lated in the following is worth considering, and if so, I would love to hea= r opinion from the members of the group. I thank you all in advance! Problem Statement MPTCP, by design, requires that transmitted data be identified at two level= s, namely, the connection-level and the subflow-level, using sequence numbe= rs drawn from the Data Sequence Space (DSS) and the Subflow Sequence Space = (SSS), respectively. Sequence numbers from DSS and SSS are called, respecti= vely, Data Sequence Numbers (DSN) and Subflow Sequence Numbers (SSN). This = is necessitated because of potential ambiguity that may arise when differen= t portions of the application data is scheduled on different subflows, and = also when the same data is replicated on more than one subflow to achieve p= rotection against packet losses. However the protocol, under certain limite= d specific scenarios, allows transmitted data to be identified using SNs fr= om SSS only. For instance, when MTCP options fail to go through a subflow (= either at the beginning or subsequent to the MPTCP connection establishment= ) or when payload gets modified by a middle box on the path. In other words= , MPTCP semantics of the transport connection are replaced with traditional= TCP semantics and the semantics change is conveyed, depending on the trigg= ering event, using either Fallback (MP_FAIL) option or DSS Option with Infi= nite Mapping. In both the cases the transport connection cannot revert to M= PTCP semantics later in the connection. But there are situations which, not covered by above scenarios, require tha= t data is identified using just one sequence space for protocol efficiency.= For instance a mobile device, on account of its potential mobility, may se= e the number of subflows vary with time and whenever there is just one subf= low associated with the MPTCP connection, it is generally expected, that ef= ficiency of MPTCP should be at least as good as traditional TCP. Also, with= just one subflow there is no data identification ambiguity present in the = case in which more than one subflow is associated with the MPTCP connection= . But MPTCP, by design, requires that data be identified and also acknowled= ged using two types sequence numbers in scenarios not covered by either los= s of options or payload modification and there is just one subflow under th= e connection. In other words when triggers, different from loss of option o= r detection of payload modification, reduce the number of subflows from 2 t= o 1 MPTCP continues to employ both types of SNs which represents unnecessar= y control overhead. The scenarios and the reasons alluded in the above paragraphs call for chan= ges to the protocol behavior which can result in efficient protocol operati= on. In other words, what we need is seamless switching between traditional = TCP semantics and MPTCP semantics for protocol efficiency. Best Regards, Sayee ________________________________ Dr. Sayee Kompalli Lead Architect, 2012 Labs Huawei Technologies India PVT. LTD. Bangalore, India --_000_5C068B455EB58047BBD492DA2B0829FA3763ADD5blreml501mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

This is the first time I’m posting a question = to the group!! I work for Huawei Technologies, India at Bangalore. For quit= e some time I’ve been reading material on MPTCP, and of late, I have = been thinking of a potential issue related to MPTCP control overhead. I’m wondering whether the issue I articulate= d in the following is worth considering, and if so, I would love to hear op= inion from the members of the group. I thank you all in advance!=

 

 

Problem Statement<= /span>

MPTCP, by design, requires that transmitted data be identifie= d at two levels, namely, the connection-level and the subflow-level, using = sequence numbers drawn from the Data Sequence Space (DSS) and the Subflow Sequence Space (SSS), respectively. Sequence numbers from = DSS and SSS are called, respectively, Data Sequence Numbers (DSN) and Subfl= ow Sequence Numbers (SSN). This is necessitated because of potential ambigu= ity that may arise when different portions of the application data is scheduled on different subflows, and a= lso when the same data is replicated on more than one subflow to achieve pr= otection against packet losses. However the protocol, under certain limited= specific scenarios, allows transmitted data to be identified using SNs from SSS only. For instance, when MTCP opt= ions fail to go through a subflow (either at the beginning or subsequent to= the MPTCP connection establishment) or when payload gets modified by a mid= dle box on the path. In other words, MPTCP semantics of the transport connection are replaced with traditional = TCP semantics and the semantics change is conveyed, depending on the trigge= ring event, using either Fallback (MP_FAIL) option or DSS Option with Infin= ite Mapping. In both the cases the transport connection cannot revert to MPTCP semantics later in the connect= ion.

 

But there are situations which, not covered by above scenario= s, require that data is identified using just one sequence space for protoc= ol efficiency. For instance a mobile device, on account of its potential mobility, may see the number of subflows vary with time a= nd whenever there is just one subflow associated with the MPTCP connection,= it is generally expected, that efficiency of MPTCP should be at least as g= ood as traditional TCP. Also, with just one subflow there is no data identification ambiguity present in the = case in which more than one subflow is associated with the MPTCP connection= . But MPTCP, by design, requires that data be identified and also acknowled= ged using two types sequence numbers in scenarios not covered by either loss of options or payload modification= and there is just one subflow under the connection. In other words when tr= iggers, different from loss of option or detection of payload modification,= reduce the number of subflows from 2 to 1 MPTCP continues to employ both types of SNs which represents unnece= ssary control overhead.

 

The scenarios and the reasons alluded in the above paragraphs= call for changes to the protocol behavior which can result in efficient pr= otocol operation. In other words, what we need is seamless switching between traditional TCP semantics and MPTCP semantics for protoc= ol efficiency.

 

 

 

 

 

Best Regards,

Sayee

Dr. Sayee Kompalli

Lead Architect, 2012 Labs

Huawei Technologies India PVT. LTD.

Bangalore, India

 

 



 

--_000_5C068B455EB58047BBD492DA2B0829FA3763ADD5blreml501mbs_-- From nobody Thu Apr 6 13:48:09 2017 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 73CB7129634 for ; Thu, 6 Apr 2017 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdV06jh1e4mi for ; Thu, 6 Apr 2017 13:48:05 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 6F1201294A4 for ; Thu, 6 Apr 2017 13:48:05 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id c55so6647177wrc.3 for ; Thu, 06 Apr 2017 13:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y8aUEhLTQ3cnBzRPW2l+c8FCs/qd5jJH2ffT3EUU8YQ=; b=ZotIW9XYQpCNUQqgEZDjdTjfs59R6mqbMWe/3zzeyvNB3+IAoL3Kr3oZ0Xsc1jxRuB UYZ5ULU4XF5XmOJHavE1FchxTi7XaralXIrIz55q2IhmwRWrXCBp6mQA/xbmbLtLUIwk 0s7nc+pgme/ivw5jJaoyU/PlZ3AShYxvLa+QE7xxF6QegUmpXsOlnAvFJ5ivTJfIGoyn gx98BGYvNe71ar6P54hwoxMZFDZ83W7VRyySFy19X99H1qf0wjyRfnU0yM1nhQnjBGhZ 8fUZPe5GlU9feBmv/ku8r9Lf1KxeTOf5ZHmveWouvSOpLajP1k89PLdqyF4ubPw9LIRY Zf1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=y8aUEhLTQ3cnBzRPW2l+c8FCs/qd5jJH2ffT3EUU8YQ=; b=GW1CuzKakR7NtkZY/zeJ2Sa4VGAgbzs8BoWqfe9pPV35VFXpilI8/S3gB/3ppa4Z+s bYz/Xqksre0TvNc/7/TVXiMkjaFDDhxUsZPiwLHEZfYD1xYZBLXMUIrv0G7fnHJ9LYSE bF5p7FLYWJkmRXOzUzp9kP2SXCgYTP/wdBuY9if3OvW6nGyezTVDrz27CL4+Fr85E084 tl5xvWMRD/MI8hsClTO1pbx2JB1tc0nBUX8gcEVNQuLIyJ22KbBuuygSkK8CjCVxysWK tGMqqmmD0NrEg3a/kzmwcSVZgwHjPTKx2dpY6jUyWNpL+eiwl5mLs6oOKdvD19kUN6ZH dhFg== X-Gm-Message-State: AFeK/H1jCJdZrcNnCS7qw7i7bNL/lb7StSFY46jtRmrJTVT/tsJs4s7ZLZtwWDK4y2ZhgraNkezj0Mt/PPALuQ== X-Received: by 10.223.162.198 with SMTP id t6mr33858917wra.155.1491511684009; Thu, 06 Apr 2017 13:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.228 with HTTP; Thu, 6 Apr 2017 13:48:03 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <814660b2aedf47efb66f671ef668f3e9@rew09926dag03b.domain1.systemhost.net> References: <814660b2aedf47efb66f671ef668f3e9@rew09926dag03b.domain1.systemhost.net> From: Behcet Sarikaya Date: Thu, 6 Apr 2017 15:48:03 -0500 Message-ID: To: philip.eardley@bt.com Cc: multipathtcp@ietf.org, Joe Touch Content-Type: multipart/alternative; boundary=f403045e9cf61a9335054c85a050 Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 20:48:08 -0000 --f403045e9cf61a9335054c85a050 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil, On Thu, Apr 6, 2017 at 4:06 AM, wrote: > Behcet, > > > > The slide was intended to be just a very high-level sketch. In both #1 an= d > #2, the objective of the signalling is to get an endpoint=E2=80=99s IP ad= dress info > into the =E2=80=98other=E2=80=99 proxy, so the proxy can do address mappi= ng (translation) > on subsequent packets (including the ACK) so that packets can travel > between the endpoints. In both #1 and #2, the idea is that this signallin= g > is done along with the TCP SYN, so that the connection via the proxies is > set up with no delay (=E2=80=9C0 RTT=E2=80=9D) > You did not answer the issues I raised below with each option, plus you raised another one, how does it work in 0 RTT, e.g. in Option #1 or #2? Regards, Behcet > > > Best wishes, > > phil > > > > *From:* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Sent:* 31 March 2017 16:53 > *Cc:* Eardley,PL,Philip,TUB8 R ; > multipathtcp@ietf.org; Joe Touch > *Subject:* charter discussion > > > > Hi all, > > > > Regarding the charter discussions that happened at the mptcp session on > Thursday March 30, I asked a question but I could not understand the > answer, let me ask it again. > > > > In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 actually > were different although the slides seems to show that they are the same. > > > > In Option 1, if the proxy sends TCP SYN than is it OK in a conversation > the destination does not know who the source is? > > > > In Option 2, if TCP SYN sent was the original TCP SYN from the source the= n > > > > how come the TCP-ACK goes through the proxy? > > A node sending a packet without its address as source address means it is > router, right? > > > > Regards, > > > > Behcet > > > > > > > > > > > --f403045e9cf61a9335054c85a050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil,

=
On Thu, Apr 6, 2017 at 4:06 AM, <phi= lip.eardley@bt.com> wrote:

Behcet,

=C2=A0

The slide was intended to be jus= t a very high-level sketch. In both #1 and #2, the objective of the signall= ing is to get an endpoint=E2=80=99s IP address info into the =E2=80=98other=E2=80=99 proxy, so the proxy can d= o address mapping (translation) on subsequent packets (including the ACK) s= o that packets can travel between the endpoints. In both #1 and #2, the ide= a is that this signalling is done along with the TCP SYN, so that the connection via the proxies is set up with no delay (= =E2=80=9C0 RTT=E2=80=9D)


=
You did not answer the issues I raised below with each option, plus yo= u raised another one, how does it work in 0 RTT, e.g. in Option #1 or #2?= =C2=A0

Regards,

Behcet
=

=C2=A0

Best wishes,

phil

=C2=A0

From: Behc= et Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: 31 March 2017 16:53
Cc: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; multipathtcp@ietf.org; Joe Touch= <touch@isi.edu&g= t;
Subject: charter discussion

=C2=A0

Hi all,

=C2=A0

Regarding the charter discussions that happened at t= he mptcp session on Thursday March 30, I asked a question but I could not u= nderstand the answer, let me ask it again.

=C2=A0

In chairs slides page 12, TCP SYN shown in Option 1 = and Option 2 actually were different although the slides seems to show that= they are the same.

=C2=A0

In Option 1, if the proxy sends TCP SYN than is it O= K in a conversation the destination does not know who the source is?=

=C2=A0

In Option 2, if TCP SYN sent was the original TCP SY= N from the source then

=C2=A0

how come the TCP-ACK goes through the proxy?<= u>

A node sending a packet without its address as sourc= e address means it is router, right?

=C2=A0

Regards,

=C2=A0

Behcet

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--f403045e9cf61a9335054c85a050-- From nobody Fri Apr 7 11:59:13 2017 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 118B112420B for ; Fri, 7 Apr 2017 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 sriI34RZgy10 for ; Fri, 7 Apr 2017 11:59:09 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAEE12704B for ; Fri, 7 Apr 2017 11:59:09 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3522B67DE95; Fri, 7 Apr 2017 20:59:02 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be 3522B67DE95 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491591542; bh=96zzEwb1Jt6aLhzyyd3woFceWFjcP2n1dhl2yHSw2YU=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=ip0Xt06iiDAx8Juf4if4e6FrWfzhkQj0k1J9oKLI+3eH0uVRBrxX1VwuGkofu2wTR pipDPv5DI7xd5sYOVZ24+CQfgwNOQ0/RSJBE5VNgI6ZviJbQ1ffww8oODFmg1ag0Lh bXA2VWXSC+c8kz9eo4+re1kCtX/dMdXzOQSU2ZJ0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5 Reply-To: Olivier.Bonaventure@uclouvain.be References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> To: Sayee Kompalli Chakravartula , "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> Date: Fri, 7 Apr 2017 15:40:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3522B67DE95.A20D7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:59:12 -0000 Hello, > > This is the first time I’m posting a question to the group!! I work for > Huawei Technologies, India at Bangalore. For quite some time I’ve been > reading material on MPTCP, and of late, I have been thinking of a > potential issue related to MPTCP control overhead. I’m wondering whether > the issue I articulated in the following is worth considering, and if > so, I would love to hear opinion from the members of the group. I thank > you all in advance! Thanks for your email. Bascially, you would like to have a Multipath TCP connection that starts without DSS on this initial subflow and then enables the DSS when a second subflow has been established. This would reduce the overhead when MPTCP connections are composed of a single subflow. However, in the presence of middleboxes, it looks very difficult to design a solution that would preserve connectivity under all circumstances. Assume that MPTCP starts without any DSS option and only uses them after the establishment of the second subflow. If the bytestream has been affected by a middlebox (e.g. a NAT with an FTP ALG) that adds or remove bytes in the payload, when MPTCP will switch to using the DSS? they will be desynchronised with the actual sequence numbers that the receiver observers. There are other corner cases where DSS options are removed from packets with data but not from SYNs that could also result in various problems. The idea looks nice, but there are unfortunately many devils hidden in the details Olivier From nobody Fri Apr 7 11:59:20 2017 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 47C8312957D for ; Fri, 7 Apr 2017 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 FHpGujml8-y3 for ; Fri, 7 Apr 2017 11:59:13 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2B912704B for ; Fri, 7 Apr 2017 11:59:13 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3B7C267DE96; Fri, 7 Apr 2017 20:59:06 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be 3B7C267DE96 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491591546; bh=0XJtOlxHWHY9OAsWv219b8kDzrT/4jWK9okB/YGDntA=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=0kyb0oplmoVvK71qsWKBkSxtV0TOJZkGW1ruoAF+mODpYXl7wjaweRGk1dML/u3Fn eHin0UBUDwVEbqh3bojyJJx0H2Y2GM7gI5QrcFlGf6YTLJBVRV8+4tpXFoSdwWYk7m Ek9FCIYzHrWMo8YCXse7+WAQNubM6e2qlWdUqWog= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5 Reply-To: Olivier.Bonaventure@uclouvain.be References: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org> To: Christoph Paasch Cc: multipathtcp From: Olivier Bonaventure Message-ID: Date: Fri, 7 Apr 2017 15:47:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3B7C267DE96.A3B27 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Timestamp option for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:59:15 -0000 Christoph, > >> 2. Define a new Multipath TCP option to carry timestamps. The utilisation of >> this option would be included in Multipath TCP and thus no option besides >> MP_CAPABLE would need to be included in the SYN. > > I like this approach, because it seems to me to consume less option-space. > > How would this timestamp look like in the DSS-option? The DSS option has several flags that are unused. We could easily define two flags to indicate the presence of locally generated timestamp and echoed timestamp. > Would it still be 32-bits? > I think we can make it less than 32-bits, right? I'm not sure that 32 bits would be required if the timestamp is only used for rtt measurements and not for PAWS. Olivier From nobody Fri Apr 7 12:04:38 2017 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 DF59E12420B for ; Fri, 7 Apr 2017 12:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQnoOCRDWdpE for ; Fri, 7 Apr 2017 12:04:35 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 431941200C1 for ; Fri, 7 Apr 2017 12:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491591873; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JIQ7Z0s5Y2ZH3F2nql4aeNeD/iWGxZOX8JX7l1nEOis=; b=JN1lmSo6umZ0yBmePiOFHZLETWi8rubNQlWORcg/3K/M9ssod1wLBX73bMGg596N spfOt7Btp13BukYeoLy3QqRwelePjlF6aApBVR10gR+gNxzSWjUCgj+7oExyFtZf FVtXBC0b1Ju4bC9kGgEvzRzGKtn58YY3KvnJcOwIeBsuNZ1husedegoqRUMPrlfr KHdO3DYO+F1uyyoQQRlBXWGM3qshGCg/P2i8kn+O6plilqcVW0C1545olRLzzttQ SVXdZWG0LEhDTiCq5HlEosjOXIeAT7odbnb4RjTe44gGxC5TjExNW1uq4+WatC3I M7iS+LJKNjEGkph6qmL2lw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 6F.EB.01216.1C2E7E85; Fri, 7 Apr 2017 12:04:33 -0700 (PDT) X-AuditID: 11ab0218-2dfdb9a0000004c0-c0-58e7e2c1e224 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay6.apple.com (Apple SCV relay) with SMTP id 53.D4.31597.0C2E7E85; Fri, 7 Apr 2017 12:04:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.226.23.47] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO10030YZNK2780@nwk-mmpp-sz11.apple.com>; Fri, 07 Apr 2017 12:04:32 -0700 (PDT) Sender: cpaasch@apple.com From: Christoph Paasch In-reply-to: Date: Fri, 07 Apr 2017 12:04:31 -0700 Cc: MultiPath TCP - IETF WG Message-id: References: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org> To: Olivier Bonaventure X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FAYpXvw0fMIg19/ZS0+r77OZnGj4QeL A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJXx4sYrloJe9oo9H86xNTCeYO1i5OSQEDCR 2DvzPnsXIxeHkMA+RolP8z6ywCRu9fxmhEgcYpR42zwLrINXQFDix+R7QEUcHMwC8hIHz8uC hJkFtCS+P2plgaj/wijRdnE2I0hCWEBSovvOHWYI207i6aZPbCA2G1DD29vtYDM5BRwkPu/a wQRiswioSlzct4ERYr6xxJSZRhBrbSTuLnzHBjF/FaPExzPdYIeKCFhJnDo9nR3iaFmJW7Mv MYMUSQj8ZZX4/fkm0wRG4VlI7p6FcPcsJHcvYGRexSicm5iZo5uZZ2Sil1hQkJOql5yfu4kR FNyrmSR2MH55bXiIUYCDUYmHN6D3eYQQa2JZcWXuIUZpDhYlcd5vS4BCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGKdEt2dnr5hy5ZXDo6UOqxew7OHgfP0u8c+BWRf8mw9ePlo4X6p5w82C sJoCaT0VcTXXStX9DwuPlXEzeHTHMW54VGwmacv01fnb8nsHY37eudTB6HvWcv3Zvc8nXzzW 9fX29aI3T7ul5rFrzf6Wydf5qqTj5pygOfs+1dks04+/93Qer/8/IW8lluKMREMt5qLiRAC1 JImuTwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FA8W/fAo+cRBqvPmFl8Xn2dzeJGww8W ByaPJUt+Mnm8OvadJYApissmJTUnsyy1SN8ugSvjxY1XLAW97BV7Ppxja2A8wdrFyMkhIWAi cavnN2MXIxeHkMAhRom3zbPAErwCghI/Jt9j6WLk4GAWkJc4eF4WJMwsoCXx/VErC0T9F0aJ touzGUESwgKSEt137jBD2HYSTzd9YgOx2YAa3t5uB5vJKeAg8XnXDiYQm0VAVeLivg2MEPON JabMNIJYayNxd+E7Noj5qxglPp7pZgFJiAhYSZw6PZ0d4mhZiVuzLzFPYBSYheTUWQinzkJy 6gJG5lWMAkWpOYmVZnqJBQU5qXrJ+bmbGMGhWBi1g7FhudUhRgEORiUe3h9dzyOEWBPLiitz gWHBwawkwjvvLlCINyWxsiq1KD++qDQntfgQozQHi5I47/XFQCmB9MSS1OzU1ILUIpgsEwen VANju6uEofDK7/cv//w8b/OtdPuWte+nMP2a9cbj24/Ns9ylNj5lMRHuEZUR4pvx5dyTP785 Q3LMDNbv/nmaZ6N5TmJ1yoQ5a6fdXsBx4KDGhWXrvIR7dySdy8q1e/pmkeO26jVxJ0sLrN/1 LZM4vXz7ervCopuc/GJRTt++y1bL2n3O+HVI8u4uTyWW4oxEQy3mouJEAPL7aX9BAgAA Archived-At: Subject: Re: [multipathtcp] Timestamp option for Multipath TCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:04:37 -0000 > On Apr 7, 2017, at 6:47 AM, Olivier Bonaventure wrote: > > Christoph, > >> >>> 2. Define a new Multipath TCP option to carry timestamps. The utilisation of >>> this option would be included in Multipath TCP and thus no option besides >>> MP_CAPABLE would need to be included in the SYN. >> >> I like this approach, because it seems to me to consume less option-space. >> >> How would this timestamp look like in the DSS-option? > > The DSS option has several flags that are unused. We could easily define two flags to indicate the presence of locally generated timestamp and echoed timestamp. > > > Would it still be 32-bits? > > I think we can make it less than 32-bits, right? > > I'm not sure that 32 bits would be required if the timestamp is only used for rtt measurements and not for PAWS. Yes, that sounds good to me! Christoph From nobody Fri Apr 7 12:04:56 2017 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 332EC1295B3 for ; Fri, 7 Apr 2017 12:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 exb1QGOlDPPb for ; Fri, 7 Apr 2017 12:04:50 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360511287A7 for ; Fri, 7 Apr 2017 12:04:44 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6795B67DD39; Fri, 7 Apr 2017 20:59:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be 6795B67DD39 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491591548; bh=6WEM3Rq9uE94TQMYHcRJuq8lT9fz1ELz7DI60Q6Qpg8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=FZCEGdBSgiNO5OwVL29gqkUE/HKO2OIpYk9RuwNXic6l9LYPUa0YBqy5hVxUsbkri Xg0gkM1mD06BEVb5AIMM2HnOMFjpjD5/ojhQW0kR8BSGj6W8iSqClmDIRUQ3UYfvVr iLEHGSU6r16khAjNsKEPNhkeSwktjg5khAJIMsnk= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6 Reply-To: Olivier.Bonaventure@uclouvain.be References: To: sarikaya@ieee.org Cc: "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: Date: Fri, 7 Apr 2017 15:54:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 6795B67DD39.A3563 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:04:52 -0000 Behcet, > > Regarding the charter discussions that happened at the mptcp session on > Thursday March 30, I asked a question but I could not understand the > answer, let me ask it again. > > In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 > actually were different although the slides seems to show that they are > the same. Option 2 is SOCKS. Option 1 places control information in the SYN and SYN+AC while SOCKS places this information in the bytestream. > In Option 1, if the proxy sends TCP SYN than is it OK in a conversation > the destination does not know who the source is? This is common with proxies. SOCKS and HTTP proxies for example often use their own address to contact remote servers and not the client address. draft-plain-mode proposes a method to allow the proxy to learn the client address and thus use it to reach the final detaintion > In Option 2, if TCP SYN sent was the original TCP SYN from the source then > how come the TCP-ACK goes through the proxy? Option 2 is SOCKS, thus the proxy uses its own address as a source to contact the final server. > A node sending a packet without its address as source address means it > is router, right? The node could have a pool of addresses like a CG-NAT Olivier From nobody Fri Apr 7 12:05:02 2017 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 9C9EE1200C1 for ; Fri, 7 Apr 2017 12:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 PzuEGf7E_AH2 for ; Fri, 7 Apr 2017 12:04:51 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ABF129531 for ; Fri, 7 Apr 2017 12:04:44 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (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 750E967DF50; Fri, 7 Apr 2017 20:59:09 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be 750E967DF50 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491591549; bh=vAX/WadT2VMrPV+qd6rd8nWZ3Iu6+17Ea/V1Ylb+Pe8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=Vet0MeB/WrcIVwO2LTWW+yt65ebQk4zk386/xO9/9FYgUlouzRPNyAWViRiinhcy5 PBRfbB+kUmjQZ2eQOZdQcX12DVa4YbH+dh4cmzRCSeTx1OivPlcrsv9GmUKn4+qqX4 ox2adctFkdsn7uXGjc1dEuG/m1a5NpohJIQ0M26c= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-1 Reply-To: Olivier.Bonaventure@uclouvain.be References: <814660b2aedf47efb66f671ef668f3e9@rew09926dag03b.domain1.systemhost.net> To: sarikaya@ieee.org, philip.eardley@bt.com Cc: multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <853a98c7-973c-e5ca-acb5-7f186e3f74be@uclouvain.be> Date: Fri, 7 Apr 2017 15:55:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 750E967DF50.A2E67 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:04:53 -0000 Behcet, > __ __ > > The slide was intended to be just a very high-level sketch. In both > #1 and #2, the objective of the signalling is to get an endpoint’s > IP address info into the ‘other’ proxy, so the proxy can do address > mapping (translation) on subsequent packets (including the ACK) so > that packets can travel between the endpoints. In both #1 and #2, > the idea is that this signalling is done along with the TCP SYN, so > that the connection via the proxies is set up with no delay (“0 RTT”) > > > You did not answer the issues I raised below with each option, plus you > raised another one, how does it work in 0 RTT, e.g. in Option #1 or #2? 0-rtt means that the proxy does not introduce an additional delay compared to the normal TCP handshake. In option 1, see draft-plain-mode, this is achieved by placing the control information in the SYN segments only. Olivier From nobody Fri Apr 7 13:19:10 2017 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 902E51289B0 for ; Fri, 7 Apr 2017 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaUCfNLAnrX9 for ; Fri, 7 Apr 2017 13:19:06 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C21B1243FE for ; Fri, 7 Apr 2017 13:19:06 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u2so341351wmu.0 for ; Fri, 07 Apr 2017 13:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XaTC75Xp3JQxLDrPlCr9/1b5jedjamySDNWA+b78Wg0=; b=ZBZ3mCEUE+cZ5fy8yf+41IZ/gzIjV93/ETqTAcqma8FWJu+NX/64vxqMtTEl3ERyik LD9wdDdx2tBwQm+CiS7NKmIiMptf3Q07InZGggCewI0X8OOndjIdAByfw+WMHaUEBz+T zuF1xPBBKuwm8WBx2IBnBODBn8wxHHCM0N3JKFux9dB5gEen0rbv7L674GPuqlAPVC2A e/ykUoWFjcg0gXLbhyvOr+MqPR0juUylkgAN8+fOpYaanuSJqwiZkph2b617nkj7Z243 rOjMGwfmMrM6nmgu8dXnrTmVj3AsuCt/XbhZRQ1jhuc1Y3Q9FPXsDITKJKkgNysMR3aY DSYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=XaTC75Xp3JQxLDrPlCr9/1b5jedjamySDNWA+b78Wg0=; b=Iu9mkYan51kHBht4UfsEQqvHdwCO0OLHUV68vckxUOEzuF8LEMa2ATR3mx3uttqXVg XDm1D7db4vKb4N0p65LSIG8AwSqF6KCLT7lT0bHwKYkb64dDKyNZBkIJEYvfzMXC3xcr qBaeY3HHJOwFbyS/8hGqj2huL1OgobRv3kiyxpzKpki0X7oTZKQ4UrO+hswPDH+fBX2j asr5Lfl2COQkAz/6IF07b2j+PmvaPTq+aonW0sAifUsyiz2TStwiF2VltdcLpKhMbcnd tMWTm0M/yXiUyYM/MYViY3m/N2pnXEb0vTmUn6l73zju2ukWiSYBniUQdEGOnucgfZ1O M1bg== X-Gm-Message-State: AN3rC/68A/3zD8/Xf/aA1olrPcShmfJwSK9Z1mwUzgT8am8OPl/vrsu+rCvIkiw0COUoine8+dmh6lBYuViwLQ== X-Received: by 10.28.143.135 with SMTP id r129mr865896wmd.54.1491596344802; Fri, 07 Apr 2017 13:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.228 with HTTP; Fri, 7 Apr 2017 13:19:04 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: From: Behcet Sarikaya Date: Fri, 7 Apr 2017 15:19:04 -0500 Message-ID: To: Olivier Bonaventure Cc: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=001a1145b59e47e071054c9956b6 Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:19:09 -0000 --001a1145b59e47e071054c9956b6 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 8:54 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Behcet, > >> >> Regarding the charter discussions that happened at the mptcp session on >> Thursday March 30, I asked a question but I could not understand the >> answer, let me ask it again. >> >> In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 >> actually were different although the slides seems to show that they are >> the same. >> > > Option 2 is SOCKS. Option 1 places control information in the SYN and > SYN+AC while SOCKS places this information in the bytestream. > > In Option 1, if the proxy sends TCP SYN than is it OK in a conversation >> the destination does not know who the source is? >> > > This is common with proxies. SOCKS and HTTP proxies for example often use > their own address to contact > remote servers and not the client address. draft-plain-mode proposes a > method to allow the proxy to learn the client address and thus use it to > reach the final detaintion > > In Option 2, if TCP SYN sent was the original TCP SYN from the source then >> how come the TCP-ACK goes through the proxy? >> > > Option 2 is SOCKS, thus the proxy uses its own address as a source to > contact the final server. > > So both Option 1 and Option 2 sends out TCP SYN with proxy own address as the source. I thought the two TCP SYN s were different? > A node sending a packet without its address as source address means it >> is router, right? >> > > The node could have a pool of addresses like a CG-NAT > > The way I understand is TCP SYN from each user (possibly many per user) is effectively tunneled to the proxy using different mechanisms in Option 1 and Option 2, actually Option 2 makes it more implicit. It seems like not only TCP SYN but all three-way TCP handshake needs to be tunneled. CPE has to deal with many parallel MPTCP connections to the same endpoint, the proxy. I think that HTTP proxy does not have this type of problem. This is my evaluation. Regards, Behcet > > Olivier > --001a1145b59e47e071054c9956b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 8:54 AM, Olivier Bonaventure &= lt;Ol= ivier.Bonaventure@uclouvain.be> wrote:
= Behcet,

Regarding the charter discussions that happened at the mptcp session on
Thursday March 30, I asked a question but I could not understand the
answer, let me ask it again.

In chairs slides page 12, TCP SYN shown in Option 1 and Option 2
actually were different although the slides seems to show that they are
the same.

 Option 2 is SOCKS. Option 1 places control information in the SYN and SYN+A= C while SOCKS places this information in the bytestream.

In Option 1, if the proxy sends TCP SYN than is it OK in a conversation
the destination does not know who the source is?

 This is common with proxies. SOCKS and HTTP proxies for example often use t= heir own address to contact
remote servers and not the client address. draft-plain-mode proposes a meth= od to allow the proxy to learn the client address and thus use it to reach = the final detaintion

In Option 2, if TCP SYN sent was the original TCP SYN from the source then<= br> how come the TCP-ACK goes through the proxy?

 Option 2 is SOCKS, thus the proxy uses its own address as a source to conta= ct the final server.


So both Option 1 and Option 2 s= ends out TCP SYN with proxy own address as=C2=A0the source. I thought the t= wo TCP SYN s=C2=A0were different?

=C2=A0=C2=A0
A node sending a packet without its address as source address means it
is router, right?

 The node could have a pool of addresses like a CG-NAT


The way I understand is = TCP SYN from each user (possibly many per user)=C2=A0is effectively=C2=A0tu= nneled to the proxy using different mechanisms in Option 1 and Option 2, ac= tually Option 2 makes it more implicit.=C2=A0
It seems like not o= nly TCP SYN but all three-way TCP handshake needs to be tunneled.

CPE has to deal with many parallel MPTCP connections to the= same endpoint, the proxy. I think that HTTP proxy does not have this type = of problem.


This is my evaluation.<= /div>

Regards,

Behcet
=C2=A0

Olivier

--001a1145b59e47e071054c9956b6-- From nobody Fri Apr 7 13:45:18 2017 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 37104128BBB for ; Fri, 7 Apr 2017 13:45:17 -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 Ta-0fcbrEWF0 for ; Fri, 7 Apr 2017 13:45:15 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B92126C26 for ; Fri, 7 Apr 2017 13:45:14 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 44B9E67D9B2; Fri, 7 Apr 2017 22:45:06 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 44B9E67D9B2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491597906; bh=DOsVv/x16cIvklqZbS2ZpiKlRhlRpP43cs6iZWRLFvA=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=Qj9IocFC4SkI9xtuqLGMk4Q8Eu7kTUhLIwVgneH4giCuBUoVACl7XQU9F/qq2TqNZ 6hPGnzC9hcjQe9t5ZyBho3aHoaILCIKxZY4TLHOKbN3ER4298dtdF3w2vo6ZLwRaE3 t2cr5dvZsrisBs1ysvhyvIUg7qfuNCehY3/WJXho= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be References: To: sarikaya@ieee.org Cc: "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: Date: Fri, 7 Apr 2017 22:45:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 44B9E67D9B2.A4C92 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] charter discussion X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:45:17 -0000 Behcet, > > > Regarding the charter discussions that happened at the mptcp > session on > Thursday March 30, I asked a question but I could not understand the > answer, let me ask it again. > > In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 > actually were different although the slides seems to show that > they are > the same. > > > Option 2 is SOCKS. Option 1 places control information in the SYN > and SYN+AC while SOCKS places this information in the bytestream. > > In Option 1, if the proxy sends TCP SYN than is it OK in a > conversation > the destination does not know who the source is? > > > This is common with proxies. SOCKS and HTTP proxies for example > often use their own address to contact > remote servers and not the client address. draft-plain-mode proposes > a method to allow the proxy to learn the client address and thus use > it to reach the final detaintion > > In Option 2, if TCP SYN sent was the original TCP SYN from the > source then > how come the TCP-ACK goes through the proxy? > > > Option 2 is SOCKS, thus the proxy uses its own address as a source > to contact the final server. > > > So both Option 1 and Option 2 sends out TCP SYN with proxy own address > as the source. I thought the two TCP SYN s were different? In Option1, this depends whether the source address has been included in the SYN as explained in draft-plain-mode > > > > A node sending a packet without its address as source address > means it > is router, right? > > > The node could have a pool of addresses like a CG-NAT > > > The way I understand is TCP SYN from each user (possibly many per > user) is effectively tunneled to the proxy using different mechanisms in > Option 1 and Option 2, actually Option 2 makes it more implicit. > It seems like not only TCP SYN but all three-way TCP handshake needs to > be tunneled. There are no tunnels. > > CPE has to deal with many parallel MPTCP connections to the same > endpoint, the proxy. I think that HTTP proxy does not have this type of > problem. The HTTP proxy only carries HTTP traffic. The proxy described in draft-plain-mode works with anytype of TCP application. Olivier From nobody Sun Apr 9 07:25:38 2017 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 9F95B128D19 for ; Sun, 9 Apr 2017 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7erbRgUgoXGA for ; Sun, 9 Apr 2017 07:25:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202F512785F for ; Sun, 9 Apr 2017 07:25:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKO47311; Sun, 09 Apr 2017 14:25:32 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 9 Apr 2017 15:25:32 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Sun, 9 Apr 2017 19:55:27 +0530 From: Sayee Kompalli Chakravartula To: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLA= Date: Sun, 9 Apr 2017 14:25:27 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> In-Reply-To: <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58EA445D.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 36dc4be7c02fd16e8af772bc154acd9d Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 14:25:37 -0000 Dear Olivier, Thanks for the response. While preparing reply to your observation, I came = across your 2013 Sigcomm paper "Are TCP Extensions Middlebox-proof?", and I= believe that I should read that paper before I reply you. I thought of a rough sketch of solution without regard to what middleboxes = can do, which essentially assumes a state-machine at both ends. Before I em= bark on designing a solution, if at all feasible, I wanted to know how othe= rs think of such an issue. Hope to reply you soon. Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Friday, April 07, 2017 9:41 PM To: Sayee Kompalli Chakravartula; multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Hello, > > This is the first time I'm posting a question to the group!! I work=20 > for Huawei Technologies, India at Bangalore. For quite some time I've=20 > been reading material on MPTCP, and of late, I have been thinking of a=20 > potential issue related to MPTCP control overhead. I'm wondering=20 > whether the issue I articulated in the following is worth considering,=20 > and if so, I would love to hear opinion from the members of the group.=20 > I thank you all in advance! Thanks for your email. Bascially, you would like to have a Multipath TCP co= nnection that starts without DSS on this initial subflow and then enables t= he DSS when a second subflow has been established. This would reduce the overhead when MPTCP connections are composed of a sin= gle subflow. However, in the presence of middleboxes, it looks very difficu= lt to design a solution that would preserve connectivity under all circumst= ances. Assume that MPTCP starts without any DSS option and only uses them after th= e establishment of the second subflow. If the bytestream has been affected = by a middlebox (e.g. a NAT with an FTP ALG) that adds or remove bytes in th= e payload, when MPTCP will switch to using the DSS? they will be desynchron= ised with the actual sequence numbers that the receiver observers. There ar= e other corner cases where DSS options are removed from packets with data b= ut not from SYNs that could also result in various problems. The idea looks nice, but there are unfortunately many devils hidden in the = details Olivier From nobody Sun Apr 9 23:18:08 2017 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 68F9B127775 for ; Sun, 9 Apr 2017 23:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ANnoz1Y93ac for ; Sun, 9 Apr 2017 23:18:05 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.12]) (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 CBCB6120727 for ; Sun, 9 Apr 2017 23:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491805082; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uezirBddUteDuXMWWKk9JYogTt8ZOag9qcblukFeLAs=; b=OxYuKupFl/GGYqqlI2gzBM0+bwF27OffTvZEI22hq3U5Ke1DrOsfy5bMxJmF2tdF f47BIq0cRk/ZaxFcI1d9gVZzm4ut7ErP+uhIsJUH5gzuuRq9YW5OxKyNNDC0i7h5 Z8ZlG9Sy7s5kKMp6N3ZDYkCo6eQLezBvz4XDHqESx9mk3+m38wUmrXGhVO2mTGkB kc+nwDEWsipdOb9ELeGJwQN58t7D6Qc9yZTniUFoea+GikhZHQNNgfcGKKBRZaPc ZIG+3cvtDcQPic/TjOuBds18PYQrH3BRu2ST59lerAFLS0azVmQlhuq5unusHhUX /DUtKWgBRZIfz2f+zT+zWQ==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id A2.1F.22441.A932BE85; Mon, 10 Apr 2017 07:18:02 +0100 (BST) X-AuditID: 1148940c-e67de9a0000057a9-51-58eb239a2b4d Received: from crk-mmpp-sz03 ( [17.66.12.165]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id B6.2F.04605.8932BE85; Mon, 10 Apr 2017 07:18:01 +0100 (BST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from localhost ([17.235.210.205]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OO600EBKK60IO20@crk-mmpp-sz03.euro.apple.com> for multipathtcp@ietf.org; Mon, 10 Apr 2017 07:18:00 +0100 (IST) Sender: cpaasch@apple.com Date: Mon, 10 Apr 2017 08:17:59 +0200 From: Christoph Paasch To: MultiPath WG Message-id: <20170410061759.GO11821@Chimay.local> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi6GTOoztL+XWEwYfnhhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpTfb1kKLkhW7G7+xNLAOE2ki5GTQ0LARGLXg6PMXYxcHEIC 25kkVr54yAiTWNl5CSqxmlHi38OFrCAJXgFBiR+T77F0MXJwMAvISxw8LwsSZhaQlnj0dwY7 hK0l8f1RKwtE7zImibOX3jKDJIQFJCW679wBs1kEVCUuPP4K1sAG1PD2djvYfBEBDYnbbcuZ IOptJT6+OAa2i1fAUOLTbFWQsKiAssTfw/fA5ksIPGWVmH+kiXkCo+AsJOfNQjhvFpLzZiE5 bwEjyypG8dzEzBzdzDwjvdTSony9xIKCnFS95PzcTYygsPWYwrOD8eJBw0OMAhyMSjy8HHKv I4RYE8uKK3MPMUpwMCuJ8N6QBgrxpiRWVqUW5ccXleakFh9ilOZgURLnrU0xjxASSE8sSc1O TS1ILYLJMnFwSjUwcm8wWZ5hZm197vmRt3MUZOpKmrcXXZZMcHFrubZtQkmyCMMX238HL9gd 2RombfjduLgqVyGdPeeNnvCPy8YbpMX23tJ05thueVg+9EGv4LKYvCkWXpXbduQImDXmvDE1 Lk8Xqf2RfM/57PamxOfLQl99UF//nvfY+cA5/3+/a1bhjRYsO9ClxFKckWioxVxUnAgA+5Oc 0lcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUi6MSzVHem8usIg2ev2Cw+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCm/37IUXJCs2N38iaWBcZpIFyMnh4SAicTKzkvMXYxcHEIC qxkl/j1cyAqS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBaYlHf2ewQ9haEt8ftbJA9C5jkjh7 6S0zSEJYQFKi+84dMJtFQFXiwuOvYA1sQA1vb7eDzRcR0JC43bacCaLeVuLji2Ngu3gFDCU+ zVYFCYsKKEv8PXyPZQIj3ywkF81CuGgWkotmIbloASPLKkbRotScxEojvdTSony9xIKCnFS9 5PzcTYzgMDPn2cH46qDhIUYBDkYlHt7/cq8jhFgTy4orcw8xSnAwK4nw3pAGCvGmJFZWpRbl xxeV5qQWH2KU5mBREuctPXouQkggPbEkNTs1tSC1CCbLxMEp1cDovaXEYW5k2IWF64vzll+0 W5Wh/oL/W03Gt09aMSdzSl54FYtEs6z5NnfVtjvKYvPy2aPWhRcpLf8uP3HB/gnpe64/Prn/ Ucf6xBlbPHeUL99suL3p/vsyrqBZnZ0Nx73fneR6dXRCprNb3ObN7dcuzZi7QHTN3d8tM5/H eq358yGMS0Vga8v8g0osxRmJhlrMRcWJAIBglB4vAgAA Archived-At: Subject: [multipathtcp] RFC6824bis - New Handshake - Implementation feedback X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 06:18:06 -0000 Hello, as mentioned during IETF'97 meeting, I implemented the new MP_CAPABLE-handshake from RFC6824bis in the Linux Kernel. Overall, it is not that complex to implement the new MP_CAPABLE-option. I am currently still fighting with a bug, but once this is fixed I will work on open-sourcing my code. Nevertheless, I have some feedback that might be good to add into RFC6824bis and also some notes of the style "watch out, this is tricky in the implementation!" : page 16: * "If, however, A..." - it might be good to show here again the new MP_CAPABLE-option (or refer to Figure 4 two pages higher). I was looking for the figure but didn't really found it right away. * "If B has data to send first, then the reliable delivery of the ACK can be inferred by the receipt of this data with an appropriate MPTCP Data Sequence Signal (DSS) option (Section 3.3)." Actually, it is the reception of a DATA_ACK that tells A that B has received the MP_CAPABLE. Not (as the above sentence states), the reception of a DSS-option. * It might be good to go through some scenarios with the new MP_CAPABLE-option. For example: A sends MP_CAPABLE in the third ACK (B receives this thid ACK) and then (a bit later) sends data + the new MP_CAPABLE-option (this latter packet gets lost). Then, B sends data to A with a DATA_ACK. A receives the data sent by B with the DATA_ACK. Now, A's retransmission-timer expires and it tries to resend the data. The question now is: Should it use a regular DSS-option in the retransmission, or should it use the new MP_CAPABLE-option. It ultimately does not matter (the server should support receiving both), but it's an interesting sceanrio that might be worth describing IMO. * We should describe, how this works with TSO. In particular, when using TSO, the new MP_CAPABLE-option will be copied to all segments (by the TSO-NIC). Now, when we have to retransmit one of these segments due to packet-loss, the sender might use a DSS-option this time or the new MP_CAPABLE-option (depending on whether or not he received a DATA_ACK). Basically, these last two points mean that the new MP_CAPABLE-option and DSS-option are "interchangeable". Meaning, if at one point I start sending data (sequence-number 1 to 100) and thus use the new MP_CAPABLE-option, later on I might decide to retransmit any byte within this sequence-range (1 to 100) with a regular DSS-option (if the server sent me a DATA_ACK back). Doing it that way, makes things on the sender-side a bit easier from an implementation-point-of-view. * When using TFO, it might be worth to specify that the server cannot send a DATA_ACK as long as he hasn't received the MP_CAPABLE with the key by the client. * What if the client wants to send an ADD_ADDR before sending the new MP_CAPABLE? It should be fine, but again the server should be graceful to this. * The server still has to support receiving out-of-order data (aka, data with a DSS-option). So, he will have to queue this and wait for the new MP_CAPABLE-option. This is nothing special from an implementation point-of-view, but might be worth mentioning in the RFC. Regards, Christoph From nobody Mon Apr 10 01:06:24 2017 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 22503129447 for ; Mon, 10 Apr 2017 01:06:23 -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 fiCIBGnJ3y4y for ; Mon, 10 Apr 2017 01:06:21 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A39129423 for ; Mon, 10 Apr 2017 01:06:21 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (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 A8D8167DCE3; Mon, 10 Apr 2017 10:06:12 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be A8D8167DCE3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491811572; bh=MVW9Fqx5pm/x+hMQzqcuplNVX0LO9eYJP7yqNfxxTPE=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=MvCJeul3HhoTBoqoRxlyuvcTI0AVqJrdT25fIIyuxy4i+MmzqxwAkfkpiM8bp1xd/ TncEwTkprQtc0k7ZKCg6wRj1R6T/mXJUqhRvixdQUFYvMkSu3wqAmDcwRI/I78X2VU TqC6SBE/QdXa3oGvYkE22eEyEwXSW9KEDxotS524= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> To: Sayee Kompalli Chakravartula , "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: Date: Mon, 10 Apr 2017 10:06:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: A8D8167DCE3.A4BEA X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:06:23 -0000 Hello, > Thanks for the response. While preparing reply to your observation, I came across your 2013 Sigcomm paper "Are TCP Extensions Middlebox-proof?", and I believe that I should read that paper before I reply you. > > I thought of a rough sketch of solution without regard to what middleboxes can do, which essentially assumes a state-machine at both ends. Before I embark on designing a solution, if at all feasible, I wanted to know how others think of such an issue. Hope to reply you soon. My fear is that any solution would introduce a significant change to Multipath TCP. We have evidence from the widespread utilisation of Multipath TCP by Apple for Siri that the current design (DSS in all segments, including initial subflow) works well in today's Internet. Changing this part for rfc6824bis looks very risky to me. Olivier From nobody Mon Apr 10 01:12:20 2017 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 A2547129458 for ; Mon, 10 Apr 2017 01:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EOK6Xb8zSXL for ; Mon, 10 Apr 2017 01:12:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF90129423 for ; Mon, 10 Apr 2017 01:12:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEK88775; Mon, 10 Apr 2017 08:12:13 +0000 (GMT) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 09:12:09 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Mon, 10 Apr 2017 13:42:04 +0530 From: Sayee Kompalli Chakravartula To: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gAALlJIA Date: Mon, 10 Apr 2017 08:12:04 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763CE4B@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58EB3E5E.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0463539eab111a4ad5997dd5aeeadcd Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:12:19 -0000 Hello, I do not intend to suggest any change to rfc6824bis in the immediate future= ! Nevertheless, I will try to design a solution and, when confident, I will= bring it to IETF's attention. Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Monday, April 10, 2017 4:06 PM To: Sayee Kompalli Chakravartula; multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Hello, > Thanks for the response. While preparing reply to your observation, I cam= e across your 2013 Sigcomm paper "Are TCP Extensions Middlebox-proof?", and= I believe that I should read that paper before I reply you. > > I thought of a rough sketch of solution without regard to what middleboxe= s can do, which essentially assumes a state-machine at both ends. Before I = embark on designing a solution, if at all feasible, I wanted to know how ot= hers think of such an issue. Hope to reply you soon. My fear is that any solution would introduce a significant change to Multip= ath TCP. We have evidence from the widespread utilisation of Multipath TCP = by Apple for Siri that the current design (DSS in all segments, including i= nitial subflow) works well in today's Internet.=20 Changing this part for rfc6824bis looks very risky to me. Olivier From nobody Tue Apr 11 05:31:16 2017 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 0084F129AE9 for ; Tue, 11 Apr 2017 05:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiuM4pTuuef4 for ; Tue, 11 Apr 2017 05:31:12 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 32212129B25 for ; Tue, 11 Apr 2017 05:31:07 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3Ae5MRpxarKhfLy6nZsNCKweL/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZoMi5bnLW6fgltlLVR4KTs6sC0LuK9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6ybL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjmk8qxlSgLniD?= =?us-ascii?q?0fOjA38G/ZlM9+gr9Urx29qBJxxJLUbZqJNPpnYqzRYckXSXZDU8tXSidPApm8?= =?us-ascii?q?b4wKD+cZM+hYtZPyp1QJrRm+GAKiHOLvxSNVhn/yw6I6yPguERzb1wEnAt0Oqm?= =?us-ascii?q?7brNryNKcJS+y1yqjIwineb/NSxzj985THcg06rP6QRrJ8a9LRyVQ0GA/flFWQ?= =?us-ascii?q?rpXoMjWI3eoOq2iW9/dsWO2yh2I9qAx8oiKjytkyhoTLnI4YxFbJ/jhjzokvP9?= =?us-ascii?q?23Ukt7bMahEJtXqi6VKZN7QtgnQ2F0oCY6zaAGuYKjcCgK1psnwxnfZuSZc4iN?= =?us-ascii?q?+B3jVeKRLS1ki3J+Yr6/nwuy/lO6xu3mUcm4yFdKrixbndnQrn0ByhPe5tWdRv?= =?us-ascii?q?Z+/kqtwyiD2x7R5+1eL004ja/bJIQgwr40mJoTq0PDHirulUrrlq+ZbEok+u+z?= =?us-ascii?q?6+j9ZLXmp4OTN5Jwig7gKaQhhtG/DP8kPQgVRWSb4fm826b58U3jR7VGluc2nb?= =?us-ascii?q?XBsJDGOcQboba0AwpI0oYn9xa/Di+m384EnXkHMFJKZAqHgpPoO17QPPD4A+2z?= =?us-ascii?q?g1O2kDdklLj6OejkH5HRL2DKjLf9dq5V6kNAxkw0198MyYhTD+QtOvv8Xa25kt?= =?us-ascii?q?3TExs0KAepi7LrEtxy0ZhYX2OEH6uUK6jPmVSToPoyKa+WY9lG637GN/E56qu2?= =?us-ascii?q?3jcCklgHcPzx0A=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2A6DQCay+xY/wPjVY1cHgYMGQYMhG+EC?= =?us-ascii?q?4sGkDmYBoYkhDgBAQEBAQEBAQIBaiiCMyCCbGgBIgINGQJbiiuZHJAIgiaLLYE?= =?us-ascii?q?Lh1OIBII6gl8FkGoBjBSURQGPXEiTNwJXgQU7hQEBAQgBAQEBgkSKRwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2A6DQCay+xY/wPjVY1cHgYMGQYMhG+EC4sGkDmYBoYkhDg?= =?us-ascii?q?BAQEBAQEBAQIBaiiCMyCCbGgBIgINGQJbiiuZHJAIgiaLLYELh1OIBII6gl8Fk?= =?us-ascii?q?GoBjBSURQGPXEiTNwJXgQU7hQEBAQgBAQEBgkSKRwEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,185,1488837600"; d="scan'208";a="674557" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 11 Apr 2017 15:31:05 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id C15F81A6005A for ; Tue, 11 Apr 2017 15:31:04 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uHf_-VPvU3Xu for ; Tue, 11 Apr 2017 15:31:04 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id A56371A600C3 for ; Tue, 11 Apr 2017 15:31:04 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id A268F1A6005A for ; Tue, 11 Apr 2017 15:31:04 +0300 (EEST) Date: Tue, 11 Apr 2017 15:31:04 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: multipathtcp@ietf.org Message-ID: <850517889.2298135.1491913864621.JavaMail.zimbra@cs.pub.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC55 (Linux)/8.6.0_GA_1194) Thread-Topic: MP_CONVERT implementation Thread-Index: to36taAvJ3NjhXjz52EKOasHj7a6uQ== Archived-At: Subject: [multipathtcp] MP_CONVERT implementation X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 12:31:15 -0000 Hello,=20 At University Politehnica of Bucharest we have an ongoing project, together= with with ORANGE Romania, to deploy an MPTCP pilot (phones and MCP).=20 Looking at the plain mode draft, we think the MP_CONVERT option is worth ex= ploring, and wanted to ask if there are any ongoing efforts regarding imple= mentation of this option in the Linux kernel. =20 Thanks,=20 --=20 Drago=C8=99 From nobody Tue Apr 11 06:34:06 2017 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 AFE81129BBF for ; Tue, 11 Apr 2017 06:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-LMh_NKfvVX for ; Tue, 11 Apr 2017 06:34:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9B6129BA5 for ; Tue, 11 Apr 2017 06:34:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR84269; Tue, 11 Apr 2017 13:33:58 +0000 (GMT) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Apr 2017 14:33:57 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Tue, 11 Apr 2017 19:03:51 +0530 From: Sayee Kompalli Chakravartula To: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gABJPHoQ Date: Tue, 11 Apr 2017 13:33:51 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58ECDB46.02A5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 36dc4be7c02fd16e8af772bc154acd9d Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:34:05 -0000 Dear Olivier, I read through the paper "Are TCP Extensions Middlebox-prrof?", and especia= lly focused on the Section 3.3 on Multipath TCP and midleboxes. My comments= are as follows: 1. Regarding middleboxes removing options from non-SYN segments: Currently, MPTCP handles this issue by attaching MPTCP option to every segm= ent in the first window worth of data. An appropriate behaviour is defined = for the sender and receiver to fallback to TCP in case middlebox removes th= e MPTCP option. In my proposal I say that, instead of appending MPTCP option to segments in= the first window worth of data, we defer appending the MPTCP option to seg= ments to a later time just before we establish the second flow and as descr= ibed below. We will define an additional state variable DSS_RCV at both the sender and = the receiver. At the beginning, this state variable will be initialized to = false at both the ends. Now assume that the state variable NUM_SUBFLOW =3D = 1 and DSS_RCV =3D false at the sender side and that the sender has send the= DSS option for the first time. When DSS option is received with its state = variable NUM_SUBFLOW =3D 1 and DSS_RCVD =3D false, the receiver will unders= tand that the sender has decided to utilize the DSS option, and so it will = update its state variable DSS_RCV =3D true and will ACK the segment that ca= rried the DSS option with its own DSS option. When the sender receives ACK = containing DSS option it will update its state variable DSS_RCV =3D true. A= ssuming that middlebox removes the DSS option included by the sender, the r= eceiver will acknowledge the segment without DSS option. Because the ACK se= gment does carry DSS option the sender will fall back. 2. To cope with sequence number randomizers: The same approach works with my proposal too, but with one little observati= on. Whenever the state variable NUM_SUBFLOW transitions from two to one, al= l the DSS related information is discarded, i.e., the space of DSNs and the= mapping are removed from the protocol control block. But, when the state v= ariable NUM_SUBFLOW again transitions from one to two, the space of DSNs wi= ll be created to establish mapping between SSS and DSS with one little diff= erence: unlike when the MPTCP connection is established, for the subflow 1 = we will not map the first DSN to subflow sequence zero but to the running s= ubflow SN at that time.=20 3. Regarding middlebox performing segment splitting or coalescing: This behaviour of middlebox poses as much risk to my way of doing things as= it does to the existing MPTCP specification. Because the existing mitigati= on does not depend on whether we continue to support DSNs on MPTCP connecti= on consisting of just one subflow, the same solution will continue to work = whether or not we support DSS for MPTCP connection consisting of just one s= ubflow. 4. ALG modifying the data stream by adding or removing bytes from the paylo= ad: This issue is relevant when a MPTCP option is included in a segment, and th= e same protocol behaviour will work in my case too. I haven't prepared a detailed write-up to share with IETF folks, which I wi= ll do once I am fairly confident that I have worked out all corner cases. Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Monday, April 10, 2017 4:06 PM To: Sayee Kompalli Chakravartula; multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Hello, > Thanks for the response. While preparing reply to your observation, I cam= e across your 2013 Sigcomm paper "Are TCP Extensions Middlebox-proof?", and= I believe that I should read that paper before I reply you. > > I thought of a rough sketch of solution without regard to what middleboxe= s can do, which essentially assumes a state-machine at both ends. Before I = embark on designing a solution, if at all feasible, I wanted to know how ot= hers think of such an issue. Hope to reply you soon. My fear is that any solution would introduce a significant change to Multip= ath TCP. We have evidence from the widespread utilisation of Multipath TCP = by Apple for Siri that the current design (DSS in all segments, including i= nitial subflow) works well in today's Internet.=20 Changing this part for rfc6824bis looks very risky to me. Olivier From nobody Tue Apr 11 06:51:55 2017 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 E5C0D129BF0 for ; Tue, 11 Apr 2017 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 012sWAvOH_jH for ; Tue, 11 Apr 2017 06:51:52 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DCF129BDB for ; Tue, 11 Apr 2017 06:51:41 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id g204so110584213oib.1 for ; Tue, 11 Apr 2017 06:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ienip16e4I9XBxR266qf8y/hwR9LIycceo0S8po/P6U=; b=Vz4BgU3hCr7k44v6d69E2FNk66XHCE/giLGc2BjGQINvW3GNd1cDMUzUnx3SXkXN85 tJf9tN7VyH83X6CuCfB4RZ9BTpSaJrGDBOfCBIgP+++B7mrmAXxvKCywHT3aNAq6uBaa lBPTEmYT+HzkLzyhZUdGZ3Clc8OVHx5UGERvXRovQhmYZrSFz8TxH9bIMgYUboVlhRv0 pk3YlP5J/1lDBqTR3c1AgI0+h9o/xdO+glrcYNMCSELxRFmHt3p5v55nZLs8a2kHTeKP xaB4b1Mne1JRgGVLXJShVDvIFQev8dzn/uJkVpxxGYbv/QYQ8nhBAZXDZIERqMfH0sih KGqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ienip16e4I9XBxR266qf8y/hwR9LIycceo0S8po/P6U=; b=EgIWnclT+EZxfKg26HSiqcNWI7vO5H63RCtIn0JRB4yKu7r052rCB7mj+krqwqYv8E k5nFI0g1qz/AXsNSyMhliMz4JNtOhh+NFTwdIz7utvqK7vS05+TK7HQCSBl4+qQxixsr 8NA2JGK2jeQ6aOnwnCjwdaykzRmiky/VUwqbvMOitPK2tZpozmVthVExdeV61nlz7Xwk +bI8fwZN5EZ6IAba4QjLKlE9DXilLVtCOMQ9Hd/GE3oVGqDfoeC/6KkECMHvzCdQWGG0 1bk1iytglF05SoZkdcLkxnEMZOLMr97j+iiz8ROtmoxkeTULIRUpawH0q7SMkEr5T2wi OMyg== X-Gm-Message-State: AN3rC/5kbDJLOap9+ypS9evgZaIrufQ/mAEGzDdWuNmMMrXrgdwqb523WUb5BBdodscLhh4OpioTeXbqEECzlQ== X-Received: by 10.157.37.248 with SMTP id q111mr6060971ota.58.1491918700795; Tue, 11 Apr 2017 06:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.15 with HTTP; Tue, 11 Apr 2017 06:51:20 -0700 (PDT) In-Reply-To: <850517889.2298135.1491913864621.JavaMail.zimbra@cs.pub.ro> References: <850517889.2298135.1491913864621.JavaMail.zimbra@cs.pub.ro> From: Alan Silva Date: Tue, 11 Apr 2017 10:51:20 -0300 Message-ID: To: =?UTF-8?Q?Drago=C8=99_Niculescu?= Cc: multipathtcp Content-Type: multipart/alternative; boundary=001a113acc6a31dce1054ce46452 Archived-At: Subject: Re: [multipathtcp] MP_CONVERT implementation X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:51:54 -0000 --001a113acc6a31dce1054ce46452 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Tue, Apr 11, 2017 at 9:31 AM, Drago=C8=99 Niculescu < dragos.niculescu@cs.pub.ro> wrote: > > Hello, > > At University Politehnica of Bucharest we have an ongoing project, > together with with ORANGE Romania, to deploy an MPTCP pilot (phones and > MCP). > Looking at the plain mode draft, we think the MP_CONVERT option is worth > exploring, and wanted to ask if there are any ongoing efforts regarding > implementation of this option in the Linux kernel. > I think that the best place to discuss this kind of issue is the in the Linux Multipath TCP development list at https://sympa-2.sipr.ucl.ac.be/sympa/info/mptcp-dev Regards, Alan --001a113acc6a31dce1054ce46452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Apr 11, 2017 at 9:31 AM, Drago=C8=99 Niculescu <dr= agos.niculescu@cs.pub.ro> wrote:

Hello,

At University Politehnica of Bucharest we have an ongoing project, together= with with ORANGE Romania, to deploy an MPTCP pilot (phones and MCP).
Looking at the plain mode draft, we think the MP_CONVERT option is worth ex= ploring, and wanted to ask if there are any ongoing efforts regarding imple= mentation of this option in the Linux kernel.

I think that the best place to discuss this kind of issue is the in = the Linux Multipath TCP development list at https://sympa-2.sipr.ucl.ac.be/sympa/info/= mptcp-dev

Regards,=C2=A0

<= div>Alan=C2=A0
--001a113acc6a31dce1054ce46452-- From nobody Tue Apr 11 07:04:29 2017 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 37CC51294AF for ; Tue, 11 Apr 2017 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hXNfpWifWtg for ; Tue, 11 Apr 2017 07:04:21 -0700 (PDT) Received: from ndmsvnpf103.ndc.nasa.gov (NDMSVNPF103.ndc.nasa.gov [198.117.0.153]) (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 A24AA1294C9 for ; Tue, 11 Apr 2017 07:04:21 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndmsvnpf103.ndc.nasa.gov 6118D4008DA3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1491919460; bh=ZTNZPDALQrkDBW7xMHdyWZ5cictV8xD7+4rJ0Juqmbg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=g+yIeRdNVfF1eJlVO7jytIYB16X168//1WnJrNIJlAapyqBE/75a0JEJbCH7CDxZz mJXLyzyP2847G8xND+UMKe4H0LPpcRY3OKwpdbayaQ1ByKefbtWn4uMJ3hJ4DogMeX EMx2GAtEW0/nsgGFftugA+1P5VL36qq3Bv2y1ZPz0/4qB7MUxjgUhzKm40KAP869d1 /bJY0a3TUGOA6HqI7IEmjur/AchHstmb3a5/vw0+F48swArOBQGuVO4ns8Qw0AKhD9 sun0O2IhRoSUzyU9wDsiKuwNwyvP8znpFS20WyF6WlB9Y0du3jxVAPc74H8oHgdEJB EiIQvUsn99s1A== Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf103.ndc.nasa.gov (Postfix) with ESMTP id 6118D4008DA3; Tue, 11 Apr 2017 09:04:20 -0500 (CDT) Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3BE0RFv020693; Tue, 11 Apr 2017 09:04:20 -0500 Received: from ndjscht106.ndc.nasa.gov (ndjscht106-pub.ndc.nasa.gov [198.117.1.206]) by ndjsppt103.ndc.nasa.gov with ESMTP id 29rxmwgh89-7; Tue, 11 Apr 2017 09:04:19 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.32]) by NDJSCHT106.ndc.nasa.gov ([198.117.1.176]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 09:02:50 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: Sayee Kompalli Chakravartula CC: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgBBumyAAGYmpIAAJQxLgAA9u5OAAAEC/IA= Date: Tue, 11 Apr 2017 14:02:50 +0000 Message-ID: <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <55FFD57CB0705640999A8568627F463C@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_12:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:04:28 -0000 Hi Sayee, I am not quite sure I understand how you are keeping sequence numbers strai= ght for the case where you drop from 2 subflows to 1 subflow and want to st= op using the DSS. Could you provide some details? What do you do when there= is outstanding data on the subflow that goes away? Thanks, Matt > On Apr 11, 2017, at 9:33 AM, Sayee Kompalli Chakravartula wrote: >=20 > Dear Olivier, > I read through the paper "Are TCP Extensions Middlebox-prrof?", and espec= ially focused on the Section 3.3 on Multipath TCP and midleboxes. My commen= ts are as follows: >=20 > 1. Regarding middleboxes removing options from non-SYN segments: > Currently, MPTCP handles this issue by attaching MPTCP option to every se= gment in the first window worth of data. An appropriate behaviour is define= d for the sender and receiver to fallback to TCP in case middlebox removes = the MPTCP option. >=20 > In my proposal I say that, instead of appending MPTCP option to segments = in the first window worth of data, we defer appending the MPTCP option to s= egments to a later time just before we establish the second flow and as des= cribed below. >=20 > We will define an additional state variable DSS_RCV at both the sender an= d the receiver. At the beginning, this state variable will be initialized t= o false at both the ends. Now assume that the state variable NUM_SUBFLOW = =3D 1 and DSS_RCV =3D false at the sender side and that the sender has send= the DSS option for the first time. When DSS option is received with its st= ate variable NUM_SUBFLOW =3D 1 and DSS_RCVD =3D false, the receiver will un= derstand that the sender has decided to utilize the DSS option, and so it w= ill update its state variable DSS_RCV =3D true and will ACK the segment tha= t carried the DSS option with its own DSS option. When the sender receives = ACK containing DSS option it will update its state variable DSS_RCV =3D tru= e. Assuming that middlebox removes the DSS option included by the sender, t= he receiver will acknowledge the segment without DSS option. Because the AC= K segment does carry DSS option the sender will fall back. >=20 > 2. To cope with sequence number randomizers: > The same approach works with my proposal too, but with one little observa= tion. Whenever the state variable NUM_SUBFLOW transitions from two to one, = all the DSS related information is discarded, i.e., the space of DSNs and t= he mapping are removed from the protocol control block. But, when the state= variable NUM_SUBFLOW again transitions from one to two, the space of DSNs = will be created to establish mapping between SSS and DSS with one little di= fference: unlike when the MPTCP connection is established, for the subflow = 1 we will not map the first DSN to subflow sequence zero but to the running= subflow SN at that time.=20 >=20 > 3. Regarding middlebox performing segment splitting or coalescing: > This behaviour of middlebox poses as much risk to my way of doing things = as it does to the existing MPTCP specification. Because the existing mitiga= tion does not depend on whether we continue to support DSNs on MPTCP connec= tion consisting of just one subflow, the same solution will continue to wor= k whether or not we support DSS for MPTCP connection consisting of just one= subflow. >=20 > 4. ALG modifying the data stream by adding or removing bytes from the pay= load: > This issue is relevant when a MPTCP option is included in a segment, and = the same protocol behaviour will work in my case too. >=20 > I haven't prepared a detailed write-up to share with IETF folks, which I = will do once I am fairly confident that I have worked out all corner cases. >=20 > Sayee From nobody Tue Apr 11 14:44:43 2017 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 BDA531200C5 for ; Tue, 11 Apr 2017 14:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21_tIZFti9KM for ; Tue, 11 Apr 2017 14:44:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B4912EBF0 for ; Tue, 11 Apr 2017 14:44:16 -0700 (PDT) Received: from [128.9.184.20] ([128.9.184.20]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3BLhrYo001652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Apr 2017 14:43:53 -0700 (PDT) To: "multipathtcp@ietf.org" From: Joe Touch Message-ID: <80634eeb-f568-7c6c-9686-21040029dd1c@isi.edu> Date: Tue, 11 Apr 2017 14:43:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3BLhrYo001652 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [multipathtcp] of possible interest - DOE Network2025 report X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:44:19 -0000 Hi, all, The US Department of Energy (DOE) recently issued its Network2025 report from its Feb 2016 workshop; both the report and workshop are linked here: https://science.energy.gov/ascr/community-resources/program-documents/ This report provides a roadmap of key networking issues for the short (1-3 yrs), medium (4-6 yrs), and long term (10-12 yrs), and includes links to white papers presented at the meeting. Of particular interest to MPTCP are its comments on the need for multipath transports, especially at very high speeds over heterogeneous paths. FYI. Joe NB: I was a member of the organizing and authoring committee. From nobody Wed Apr 12 00:16:04 2017 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 BC2751201FA for ; Wed, 12 Apr 2017 00:16:02 -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 iTj9QPROrCMa for ; Wed, 12 Apr 2017 00:16:00 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F2C124BFA for ; Wed, 12 Apr 2017 00:16:00 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3FCB167DA39; Wed, 12 Apr 2017 09:15:48 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 3FCB167DA39 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491981350; bh=18YGgX/4fiJD9wV46+udq0vG+2AcsBhODWPRVtx4k+0=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=T007A/QYReJ6KGroEJyQEN8FWfZ2JaY2/omzOTatRnpePYmP2FeSslqmkVKgrhPPy olyOyyhNBBtwyw4iISDaBFk/M+uHkKTSpc+rOsq58bH5F4Hmx7c0/6Ezgw9itRWq92 5LP/vP7kcsyGZcV0Sf6xkcszzgPe8RDrZdWO407I= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> To: Sayee Kompalli Chakravartula , "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <73b2cd58-2b82-2245-1893-b26dbc8b30ed@uclouvain.be> Date: Wed, 12 Apr 2017 09:15:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3FCB167DA39.A5553 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 07:16:03 -0000 Sayee, > I read through the paper "Are TCP Extensions Middlebox-prrof?", and especially focused on the Section 3.3 on Multipath TCP and midleboxes. My comments are as follows: > > 1. Regarding middleboxes removing options from non-SYN segments: > Currently, MPTCP handles this issue by attaching MPTCP option to every segment in the first window worth of data. An appropriate behaviour is defined for the sender and receiver to fallback to TCP in case middlebox removes the MPTCP option. > > In my proposal I say that, instead of appending MPTCP option to segments in the first window worth of data, we defer appending the MPTCP option to segments to a later time just before we establish the second flow and as described below. > > We will define an additional state variable DSS_RCV at both the sender and the receiver. At the beginning, this state variable will be initialized to false at both the ends. Now assume that the state variable NUM_SUBFLOW = 1 and DSS_RCV = false at the sender side and that the sender has send the DSS option for the first time. When DSS option is received with its state variable NUM_SUBFLOW = 1 and DSS_RCVD = false, the receiver will understand that the sender has decided to utilize the DSS option, and so it will update its state variable DSS_RCV = true and will ACK the segment that carried the DSS option with its own DSS option. When the sender receives ACK containing DSS option it will update its state variable DSS_RCV = true. Assuming that middlebox removes the DSS option included by the sender, the receiver will acknowledge the segment without DSS option. Because the ACK segment does carry DSS option the sender will fall back. MPTCP as defined in RFC6824 supports both make-before-break and break-before-make, i.e. the second subflow can be established at any time, either before or after the failure of the initial one. With your design, you force a make-before-break, this means that something has to be done (namely start uses DSS) before being able to create the second subflow. This is annoying because failover is one of the nice features of Multipath TCP. > 2. To cope with sequence number randomizers: > The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e., the space of DSNs and the mapping are removed from the protocol control block. But, when the state variable NUM_SUBFLOW again transitions from one to two, the space of DSNs will be created to establish mapping between SSS and DSS with one little difference: unlike when the MPTCP connection is established, for the subflow 1 we will not map the first DSN to subflow sequence zero but to the running subflow SN at that time. I fear that a solution that tries to avoid DSS when there is a single subflow and uses DSS as soon as there are two subflows would be very difficult to use. How do the client and the server agree that there are one or more subflows ? At a given time, they might have a different view of the state of the Multipath TCP connection. Olivier From nobody Wed Apr 12 00:34:53 2017 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 CC7D11287A7 for ; Wed, 12 Apr 2017 00:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMoUPJdsy5Z7 for ; Wed, 12 Apr 2017 00:34:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67391287A0 for ; Wed, 12 Apr 2017 00:34:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKT29542; Wed, 12 Apr 2017 07:34:44 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Apr 2017 08:34:04 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0301.000; Wed, 12 Apr 2017 13:03:58 +0530 From: Sayee Kompalli Chakravartula To: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gABJPHoQABmVrAAAC+MkkA== Date: Wed, 12 Apr 2017 07:33:57 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763D546@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <73b2cd58-2b82-2245-1893-b26dbc8b30ed@uclouvain.be> In-Reply-To: <73b2cd58-2b82-2245-1893-b26dbc8b30ed@uclouvain.be> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010206.58EDD895.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 36dc4be7c02fd16e8af772bc154acd9d Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 07:34:52 -0000 Olivier, I think I started on the wrong foot discussing solution first before reques= ting the group to discuss merits of disabling the DSS Option. A solution that I thought of will not work in all scenarios, so I need to t= hink of a more robust solution. But before we can do that, I would love to = hear others of their opinion on disabling the DSS Option. If there is conse= nsus, we can certainly work out a solution. I'm yet to write up my not to e= legant solution:( Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Wednesday, April 12, 2017 3:16 PM To: Sayee Kompalli Chakravartula; multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Sayee, > I read through the paper "Are TCP Extensions Middlebox-prrof?", and espec= ially focused on the Section 3.3 on Multipath TCP and midleboxes. My commen= ts are as follows: > > 1. Regarding middleboxes removing options from non-SYN segments: > Currently, MPTCP handles this issue by attaching MPTCP option to every se= gment in the first window worth of data. An appropriate behaviour is define= d for the sender and receiver to fallback to TCP in case middlebox removes = the MPTCP option. > > In my proposal I say that, instead of appending MPTCP option to segments = in the first window worth of data, we defer appending the MPTCP option to s= egments to a later time just before we establish the second flow and as des= cribed below. > > We will define an additional state variable DSS_RCV at both the sender an= d the receiver. At the beginning, this state variable will be initialized t= o false at both the ends. Now assume that the state variable NUM_SUBFLOW = =3D 1 and DSS_RCV =3D false at the sender side and that the sender has send= the DSS option for the first time. When DSS option is received with its st= ate variable NUM_SUBFLOW =3D 1 and DSS_RCVD =3D false, the receiver will un= derstand that the sender has decided to utilize the DSS option, and so it w= ill update its state variable DSS_RCV =3D true and will ACK the segment tha= t carried the DSS option with its own DSS option. When the sender receives = ACK containing DSS option it will update its state variable DSS_RCV =3D tru= e. Assuming that middlebox removes the DSS option included by the sender, t= he receiver will acknowledge the segment without DSS option. Because the AC= K segment does carry DSS option the sender will fall back. MPTCP as defined in RFC6824 supports both make-before-break and break-befor= e-make, i.e. the second subflow can be established at any time, either befo= re or after the failure of the initial one. With your design, you force a m= ake-before-break, this means that something has to be done (namely start us= es DSS) before being able to create the second subflow. This is annoying be= cause failover is one of the nice features of Multipath TCP. > 2. To cope with sequence number randomizers: > The same approach works with my proposal too, but with one little observa= tion. Whenever the state variable NUM_SUBFLOW transitions from two to one, = all the DSS related information is discarded, i.e., the space of DSNs and t= he mapping are removed from the protocol control block. But, when the state= variable NUM_SUBFLOW again transitions from one to two, the space of DSNs = will be created to establish mapping between SSS and DSS with one little di= fference: unlike when the MPTCP connection is established, for the subflow = 1 we will not map the first DSN to subflow sequence zero but to the running= subflow SN at that time. I fear that a solution that tries to avoid DSS when there is a single subfl= ow and uses DSS as soon as there are two subflows would be very difficult t= o use. How do the client and the server agree that there are one or more su= bflows ? At a given time, they might have a different view of the state of = the Multipath TCP connection. Olivier From nobody Wed Apr 12 06:03:42 2017 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 37921129AF4 for ; Wed, 12 Apr 2017 06:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_ekuJhTYRO9 for ; Wed, 12 Apr 2017 06:03:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DB4129B14 for ; Wed, 12 Apr 2017 06:03:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKT88128; Wed, 12 Apr 2017 13:03:31 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Apr 2017 14:03:30 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0301.000; Wed, 12 Apr 2017 18:33:25 +0530 From: Sayee Kompalli Chakravartula To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" CC: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gABJPHoQ//+sEQD//iJhoA== Date: Wed, 12 Apr 2017 13:03:24 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> In-Reply-To: <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.58EE25A4.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 36dc4be7c02fd16e8af772bc154acd9d Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:03:41 -0000 Hi Matt, I can think of two ways in which a TCP connection can go down: gracefully o= r ungracefully. Assume that there are two subflows, SF1 and SF2, and that S= F2 is to be brought down. If SF2 goes down ungracefully, we have no cleaner= way of informing the receiver that the sender is disabling DSS, and so thi= s leaves us with two choices: (i) continue to use DSS on SF1, or (ii) defin= e a new Option Subtype or a reserved bit of the DSS Option through which th= e sender can explicitly inform the receiver that it is disabling DSS. I bel= ieve that the later choice is the cleaner way of disabling the DSS option. = When SF2 goes down ungracefully, we of course need to retransmit the outsta= nding bytes on SF1, similar to what the MPTCP specification requires. The not-so-cleaner way of doing things is fragile and convoluted, so I woul= d not want to discuss that here. If the connection is closed using the RST bit: after sending RST, the sende= r immediately closes the socket, so the MPTCP sender has no way of knowing = whether the receiver indeed received the RST bit. In fact, the RST bit may = be lost in the transit. I would put this case in the category of ungraceful= shutdown. If the connection is closed using the FIN bit: Let us represent a SN as x_{= i,j} where the subscript i denotes the type of sequence space (SSN or DSN) = and the subscript j gives the subflow ID. Let x_{DSN, SF2} be the DSN of th= e last byte transmitted before FIN is sent on SF2 and that x_{DSN, SF1} be = the last DSN mapped to SF1 before the DSS Option is disabled by the sender.= In this context we need to consider two possibilities: x_{DSN, SF1} < x_{D= SN, SF2} and x_{DSN, SF1} >=3D x_{DSN, SF2}. Now consider the case x_{DSN, = SF1} < x_{DSN, SF2}. When a data byte is received on SF1 that is not covere= d by DSN we know where to place that data byte with respect to the data byt= e whose DSN is x_{DSN, SF1} using subflow sequence number of the data byte.= Because, eventually, data bytes need to be ordered based on DSN before rel= easing to the application layer we still need to decide where to place this= data byte at the connection-level with respect to x_{DSN, SF2}, and this i= s where the protocol will run into ambiguity: whether to place the data byt= e before or after x_{DSN, SF2}. This will lead to protocol dead-lock. Next,= we consider the possibility x_{DSN, SF1} >=3D x_{DSN, SF2}. Here we do not= have the ambiguity present in the previous context. The received data byte= on SF1 will have to be placed to the right of both x_{DSN, SF1} as well as= x_{DSN, SF2} and the actual placement on SF1 will be determined by the SSN= of the data byte. The above analysis helps us to decide how and when DSS Option can be disabl= ed. After sending the FIN on SF2, continue sending the DSS option on SF1 un= til the largest DSN used on SF1 is at least as large as x_{DSN, SF2} and th= e state variable NUM_SUBFLOW has transitioned to 1, and then disable the DS= S Option. To describe the receiver behaviour, the receiver expects to conti= nue to receive data bytes covered with DS mapping on SF1 until the largest = DSN mapped to SF1 is at least as large as x_{DSN, SF2}. After then, startin= g with the first received byte that is not covered with DSN, the receiver w= ill understand that the sender has disabled DS mapping on SF1. At this point, I like to believe that defining a new Option Subtype or util= izing an unused bit in the DSS option will be fruitful. Except in some specific scenarios, like a data center, I don't think a devi= ce can know in advance if second interface becomes available during the con= nection. So if the users goes with TCP then he is at disadvantage because h= e cannot utilize additional interfaces when they become available. If he op= ens MPTCP connection hoping that new interfaces may become available in the= future, until then the connection has to incur control overhead due to red= undant DSS Option.=20 As a first-cut solution I think we should allow a MPTCP connection not to u= se the DSS option until it opens the second subflow. To keep things simple,= we may say that once DSS Option is enabled it will be enforced until the M= PTCP connection is closed. Sayee -----Original Message----- From: Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies] [mailto:matthew= .t.sargent@nasa.gov]=20 Sent: Tuesday, April 11, 2017 10:03 PM To: Sayee Kompalli Chakravartula Cc: Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Hi Sayee, I am not quite sure I understand how you are keeping sequence numbers strai= ght for the case where you drop from 2 subflows to 1 subflow and want to st= op using the DSS. Could you provide some details? What do you do when there= is outstanding data on the subflow that goes away? Thanks, Matt > On Apr 11, 2017, at 9:33 AM, Sayee Kompalli Chakravartula wrote: >=20 > Dear Olivier, > I read through the paper "Are TCP Extensions Middlebox-prrof?", and espec= ially focused on the Section 3.3 on Multipath TCP and midleboxes. My commen= ts are as follows: >=20 > 1. Regarding middleboxes removing options from non-SYN segments: > Currently, MPTCP handles this issue by attaching MPTCP option to every se= gment in the first window worth of data. An appropriate behaviour is define= d for the sender and receiver to fallback to TCP in case middlebox removes = the MPTCP option. >=20 > In my proposal I say that, instead of appending MPTCP option to segments = in the first window worth of data, we defer appending the MPTCP option to s= egments to a later time just before we establish the second flow and as des= cribed below. >=20 > We will define an additional state variable DSS_RCV at both the sender an= d the receiver. At the beginning, this state variable will be initialized t= o false at both the ends. Now assume that the state variable NUM_SUBFLOW = =3D 1 and DSS_RCV =3D false at the sender side and that the sender has send= the DSS option for the first time. When DSS option is received with its st= ate variable NUM_SUBFLOW =3D 1 and DSS_RCVD =3D false, the receiver will un= derstand that the sender has decided to utilize the DSS option, and so it w= ill update its state variable DSS_RCV =3D true and will ACK the segment tha= t carried the DSS option with its own DSS option. When the sender receives = ACK containing DSS option it will update its state variable DSS_RCV =3D tru= e. Assuming that middlebox removes the DSS option included by the sender, t= he receiver will acknowledge the segment without DSS option. Because the AC= K segment does carry DSS option the sender will fall back. >=20 > 2. To cope with sequence number randomizers: > The same approach works with my proposal too, but with one little observa= tion. Whenever the state variable NUM_SUBFLOW transitions from two to one, = all the DSS related information is discarded, i.e., the space of DSNs and t= he mapping are removed from the protocol control block. But, when the state= variable NUM_SUBFLOW again transitions from one to two, the space of DSNs = will be created to establish mapping between SSS and DSS with one little di= fference: unlike when the MPTCP connection is established, for the subflow = 1 we will not map the first DSN to subflow sequence zero but to the running= subflow SN at that time.=20 >=20 > 3. Regarding middlebox performing segment splitting or coalescing: > This behaviour of middlebox poses as much risk to my way of doing things = as it does to the existing MPTCP specification. Because the existing mitiga= tion does not depend on whether we continue to support DSNs on MPTCP connec= tion consisting of just one subflow, the same solution will continue to wor= k whether or not we support DSS for MPTCP connection consisting of just one= subflow. >=20 > 4. ALG modifying the data stream by adding or removing bytes from the pay= load: > This issue is relevant when a MPTCP option is included in a segment, and = the same protocol behaviour will work in my case too. >=20 > I haven't prepared a detailed write-up to share with IETF folks, which I = will do once I am fairly confident that I have worked out all corner cases. >=20 > Sayee From nobody Wed Apr 12 06:34:03 2017 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 1EECB129B37 for ; Wed, 12 Apr 2017 06:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyzuLrGobCMT for ; Wed, 12 Apr 2017 06:33:59 -0700 (PDT) Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) (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 CE1B51294B3 for ; Wed, 12 Apr 2017 06:33:59 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.199; helo=ndjsppt105.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf104.ndc.nasa.gov CE60E4003BE8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492004038; bh=kvZkJPvGGC+JJbjCDWGcf94lDSsUKg5C1s8gJmRtSpU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=FJAcZxkZPq4t/JfwNfn0DUI0Uo7nB9D+gDKZc0e/V1yLmcWOJlw98PG3iauETdcqh HMpyFX4+HZDD3lNoNJRsfK4MQm77UmnZcG8eAZChIcRQcTEK4LuNs8pHEggVFwgDgL Aveq62lS5EOswn9sMcJ5P1PoSMELwgIPIEpuEAgwZQTil+wYjJeWDS3xVWCR50DtRo 7czMRCd1RVYl31DuXkpO8SF9L+VTqNo0q6gBmIBqJQq1QG48ugmZzfaUlxaSuNfBQ6 VnYqjJ1TIeOkl0DEeVPG+ZenSli6SYShSm2W07JIL+EQUBX35im6/DCdUt9+EG+HTN 7YEWwPhk547xA== Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id CE60E4003BE8; Wed, 12 Apr 2017 08:33:58 -0500 (CDT) Received: from pps.filterd (ndjsppt105.ndc.nasa.gov [127.0.0.1]) by ndjsppt105.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3CDW2gk028678; Wed, 12 Apr 2017 08:33:58 -0500 Received: from ndjscht109.ndc.nasa.gov (ndjscht109-pub.ndc.nasa.gov [198.117.1.209]) by ndjsppt105.ndc.nasa.gov with ESMTP id 29sm4ggbp5-1; Wed, 12 Apr 2017 08:33:58 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.32]) by NDJSCHT109.ndc.nasa.gov ([198.117.1.179]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 08:33:58 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: Sayee Kompalli Chakravartula CC: "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgBBumyAAGYmpIAAJQxLgAA9u5OAAAEC/IAAMDdgAAABESSA Date: Wed, 12 Apr 2017 13:33:57 +0000 Message-ID: <2D12D20B-E9C4-4340-ACD9-CA48F4EC6A14@nasa.gov> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <37C8903D90250D47A17F12833F39933A@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_09:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:34:01 -0000 Hi Sayee, Thanks for the response! What you are proposing is clearer to me now. I mis= understood part of a previous email: >=20 > On Apr 11, 2017, at 9:33 AM, Sayee Kompalli Chakravartula wrote: >=20 > The same approach works with my proposal too, but with one little observa= tion. Whenever the state variable NUM_SUBFLOW transitions from two to one, = all the DSS related information is discarded, i.e., the space of DSNs and t= he mapping are removed from the protocol control block. >=20 I thought the proposal was originally to stop using the DSS as soon as a su= bflow goes away without any sort of signaling, which I could not grok. :-) = I'm glad to see I was mistaken. I will try to think over your proposal in m= ore depth beyond my quick reading of it just now. Thanks, Matt= From nobody Wed Apr 12 07:08:28 2017 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 0EB1E129B5F for ; Wed, 12 Apr 2017 07:08:26 -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 UkHek0P6YhFt for ; Wed, 12 Apr 2017 07:08:23 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E50129B60 for ; Wed, 12 Apr 2017 07:08:22 -0700 (PDT) Received: from mbpobo.local (unknown [5.149.142.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 651CE67DCB1; Wed, 12 Apr 2017 16:08:09 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be 651CE67DCB1 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1492006094; bh=QwG1rJZOw4IaZLoYhYDpZaW4YiLHpkUh7OL7b/DAVWc=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=p8QPGveOVEqYwr8XUYbhH+niHtJtQVeYan5VJS/GdCQad/hHcaHUqmibaqP+i87XI 8/rgoZ8l3HLgwqCO7XQgXG2q5+Y2c1XzC2zxfJXoB525cEDaRTAizo/orEXWWaQYMR riYBPz8oInUG6M+OXM+5PtvGAUUzxMywvrypy4p8= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6 Reply-To: Olivier.Bonaventure@uclouvain.be References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> To: Sayee Kompalli Chakravartula , "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" Cc: "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <0b4a4dfb-ad38-168b-35b0-c8a0fd8c1903@uclouvain.be> Date: Wed, 12 Apr 2017 16:08:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 651CE67DCB1.A4615 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 14:08:26 -0000 SGkgU2F5ZWUsDQoNCj4gSSBjYW4gdGhpbmsgb2YgdHdvIHdheXMgaW4gd2hpY2ggYSBUQ1Ag Y29ubmVjdGlvbiBjYW4gZ28gZG93bjogZ3JhY2VmdWxseSBvciB1bmdyYWNlZnVsbHkuIEFz c3VtZSB0aGF0IHRoZXJlIGFyZSB0d28gc3ViZmxvd3MsIFNGMSBhbmQgU0YyLCBhbmQgdGhh dCBTRjIgaXMgdG8gYmUgYnJvdWdodCBkb3duLiBJZiBTRjIgZ29lcyBkb3duIHVuZ3JhY2Vm dWxseSwgd2UgaGF2ZSBubyBjbGVhbmVyIHdheSBvZiBpbmZvcm1pbmcgdGhlIHJlY2VpdmVy IHRoYXQgdGhlIHNlbmRlciBpcyBkaXNhYmxpbmcgRFNTLCBhbmQgc28gdGhpcyBsZWF2ZXMg dXMgd2l0aCB0d28gY2hvaWNlczogKGkpIGNvbnRpbnVlIHRvIHVzZSBEU1Mgb24gU0YxLCBv ciAoaWkpIGRlZmluZSBhIG5ldyBPcHRpb24gU3VidHlwZSBvciBhIHJlc2VydmVkIGJpdCBv ZiB0aGUgRFNTIE9wdGlvbiB0aHJvdWdoIHdoaWNoIHRoZSBzZW5kZXIgY2FuIGV4cGxpY2l0 bHkgaW5mb3JtIHRoZSByZWNlaXZlciB0aGF0IGl0IGlzIGRpc2FibGluZyBEU1MuIEkgYmVs aWV2ZSB0aGF0IHRoZSBsYXRlciBjaG9pY2UgaXMgdGhlIGNsZWFuZXIgd2F5IG9mIGRpc2Fi bGluZyB0aGUgRFNTIG9wdGlvbi4gV2hlbiBTRjIgZ29lcyBkb3duIHVuZ3JhY2VmdWxseSwg d2Ugb2YgY291cnNlIG5lZWQgdG8gcmV0cmFuc21pdCB0aGUgb3V0c3RhbmRpbmcgYnl0ZXMg b24gU0YxLCBzaW1pbGFyIHRvIHdoYXQgdGhlIE1QVENQIHNwZWNpZmljYXRpb24gcmVxdWly ZXMuDQoNCg0KRm9yIGEgTXVsdGlwYXRoIFRDUCBjb25uZWN0aW9uLCBzdWJmbG93cyBjYW4g ZmFpbCBpbiBvdGhlciB3YXlzIGFzIHdlbGwuIA0KSXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0 IHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBhc3NvY2lhdGVkIHRvIGEgc3ViZmxvdyANCmlzIG5v dCBhc3NpZ25lZCBhbnltb3JlIHRvIHRoZSBob3N0LCB0aGlzIGlzIHRoZSB0eXBpY2FsIGV4 YW1wbGUgb2YgYSANCnNtYXJ0cGhvbmUgdGhhdCBsb29zZXMgV2lGaS4gQW5vdGhlciBzdWJm bG93IGZhaWx1cmUgc2NlbmFyaW8gaXMgYSANCnN1YmZsb3cgdGhhdCBzdG9wcyBhZnRlciBu IHJldHJhbnNtaXNzaW9ucyBvZiB0aGUgc2FtZSBkYXRhLiBUaGVzZSANCmZhaWx1cmVzIGRv IG5vdCBzdG9wIHRoZSBNUFRDUCBjb25uZWN0aW9uLg0KDQo+IFRoZSBub3Qtc28tY2xlYW5l ciB3YXkgb2YgZG9pbmcgdGhpbmdzIGlzIGZyYWdpbGUgYW5kIGNvbnZvbHV0ZWQsIHNvIEkg d291bGQgbm90IHdhbnQgdG8gZGlzY3VzcyB0aGF0IGhlcmUuDQo+DQo+IElmIHRoZSBjb25u ZWN0aW9uIGlzIGNsb3NlZCB1c2luZyB0aGUgUlNUIGJpdDogYWZ0ZXIgc2VuZGluZyBSU1Qs IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgY2xvc2VzIHRoZSBzb2NrZXQsIHNvIHRoZSBNUFRD UCBzZW5kZXIgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoZXRoZXIgdGhlIHJlY2VpdmVyIGlu ZGVlZCByZWNlaXZlZCB0aGUgUlNUIGJpdC4gSW4gZmFjdCwgdGhlIFJTVCBiaXQgbWF5IGJl IGxvc3QgaW4gdGhlIHRyYW5zaXQuIEkgd291bGQgcHV0IHRoaXMgY2FzZSBpbiB0aGUgY2F0 ZWdvcnkgb2YgdW5ncmFjZWZ1bCBzaHV0ZG93bi4NCg0KQSBzdWJmbG93IGNhbiBmYWlsIGR1 ZSB0byBSU1Qgc2VudCBieSBhIG1pZGRsZWJveC4gVGhpcyBzaG91bGQgbm90IGNsb3NlIA0K dGhlIGNvcnJlc3BvbmRpbmcgTVBUQ1AgY29ubmVjdGlvbi4NCg0KPiBJZiB0aGUgY29ubmVj dGlvbiBpcyBjbG9zZWQgdXNpbmcgdGhlIEZJTiBiaXQ6IExldCB1cyByZXByZXNlbnQgYSBT TiBhcyB4X3tpLGp9IHdoZXJlIHRoZSBzdWJzY3JpcHQgaSBkZW5vdGVzIHRoZSB0eXBlIG9m IHNlcXVlbmNlIHNwYWNlIChTU04gb3IgRFNOKSBhbmQgdGhlIHN1YnNjcmlwdCBqIGdpdmVz IHRoZSBzdWJmbG93IElELiBMZXQgeF97RFNOLCBTRjJ9IGJlIHRoZSBEU04gb2YgdGhlIGxh c3QgYnl0ZSB0cmFuc21pdHRlZCBiZWZvcmUgRklOIGlzIHNlbnQgb24gU0YyIGFuZCB0aGF0 IHhfe0RTTiwgU0YxfSBiZSB0aGUgbGFzdCBEU04gbWFwcGVkIHRvIFNGMSBiZWZvcmUgdGhl IERTUyBPcHRpb24gaXMgZGlzYWJsZWQgYnkgdGhlIHNlbmRlci4gSW4gdGhpcyBjb250ZXh0 IHdlIG5lZWQgdG8gY29uc2lkZXIgdHdvIHBvc3NpYmlsaXRpZXM6IHhfe0RTTiwgU0YxfSA8 IHhfe0RTTiwgU0YyfSBhbmQgeF97RFNOLCBTRjF9ID49IHhfe0RTTiwgU0YyfS4gTm93IGNv bnNpZGVyIHRoZSBjYXNlIHhfe0RTTiwgU0YxfSA8IHhfe0RTTiwgU0YyfS4gV2hlbiBhIGRh dGEgYnl0ZSBpcyByZWNlaXZlZCBvbiBTRjEgdGhhdCBpcyBub3QgY292ZXJlZCBieSBEU04g d2Uga25vdyB3aGVyZSB0byBwbGFjZSB0aGF0IGRhdGEgYnl0ZSB3aXRoIHJlc3BlY3QgdG8g dGhlIGRhdGEgYnl0ZSB3aG9zZSBEU04gaXMgeF97RFNOLCBTRjF9IHVzaW5nIHN1YmZsb3cg c2VxdWVuY2UgbnVtYmVyIG9mIHRoZSBkYXRhIGJ5dGUuIEJlY2F1c2UsIGV2ZW50dWFsbHks IGRhdGEgYnl0ZXMgbmVlZCB0byBiZSBvcmRlcmVkIGJhc2VkIG9uIERTTiBiZWZvcmUgcmVs ZWFzaW5nIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXllciB3ZSBzdGlsbCBuZWVkIHRvIGRlY2lk ZSB3aGVyZSB0byBwbGFjZSB0aGlzIGRhdGEgYnl0ZSBhdCB0aGUgY29ubmVjdGlvbi1sZXZl bCB3aXRoIHJlc3BlY3QgdG8geF97RFNOLCBTRjJ9LCBhbmQgdGhpcyBpcyB3aGVyZSB0aGUg cHJvdG9jb2wgd2lsbCBydW4gaW50byBhbWJpZ3VpdHk6IHdoZXRoZXIgdG8gcGxhY2UgdGhl IGRhdGEgYnl0ZSBiZWZvcmUgb3IgYWZ0ZXIgeF97RFNOLCBTRjJ9LiBUaGlzIHdpbGwgbGVh ZCB0byBwcm90b2NvbCBkZWFkLWxvY2suIE5leHQsIHdlIGNvbnNpZGVyIHRoZSBwb3NzaWJp bGl0eSB4X3tEU04sIFNGMX0gPj0geF97RFNOLCBTRjJ9LiBIZXJlIHdlIGRvIG5vdCBoYXZl IHRoZSBhbWJpZ3VpdHkgcHJlc2VudCBpbiB0aGUgcHJldmlvdXMgY29udGV4dC4gVGhlIHJl Y2VpdmVkIGRhdGEgYnl0ZSBvbiBTRjEgd2lsbCBoYXZlIHRvIGJlIHBsYWNlZCB0byB0aGUg cmlnaHQgb2YgYm90aCB4X3tEU04sIFNGMX0gYXMgd2VsbCBhcyB4X3tEU04sIFNGMn0gYW5k IHRoZSBhY3R1YWwgcGxhY2VtZW50IG9uIFNGMSB3aWxsIGJlIGRldGVybWluZWQgYnkgdGhl IFNTTiBvZiB0aGUgZGF0YSBieXRlLg0KPg0KPiBUaGUgYWJvdmUgYW5hbHlzaXMgaGVscHMg dXMgdG8gZGVjaWRlIGhvdyBhbmQgd2hlbiBEU1MgT3B0aW9uIGNhbiBiZSBkaXNhYmxlZC4g QWZ0ZXIgc2VuZGluZyB0aGUgRklOIG9uIFNGMiwgY29udGludWUgc2VuZGluZyB0aGUgRFNT IG9wdGlvbiBvbiBTRjEgdW50aWwgdGhlIGxhcmdlc3QgRFNOIHVzZWQgb24gU0YxIGlzIGF0 IGxlYXN0IGFzIGxhcmdlIGFzIHhfe0RTTiwgU0YyfSBhbmQgdGhlIHN0YXRlIHZhcmlhYmxl IE5VTV9TVUJGTE9XIGhhcyB0cmFuc2l0aW9uZWQgdG8gMSwgYW5kIHRoZW4gZGlzYWJsZSB0 aGUgRFNTIE9wdGlvbi4gVG8gZGVzY3JpYmUgdGhlIHJlY2VpdmVyIGJlaGF2aW91ciwgdGhl IHJlY2VpdmVyIGV4cGVjdHMgdG8gY29udGludWUgdG8gcmVjZWl2ZSBkYXRhIGJ5dGVzIGNv dmVyZWQgd2l0aCBEUyBtYXBwaW5nIG9uIFNGMSB1bnRpbCB0aGUgbGFyZ2VzdCBEU04gbWFw cGVkIHRvIFNGMSBpcyBhdCBsZWFzdCBhcyBsYXJnZSBhcyB4X3tEU04sIFNGMn0uIEFmdGVy IHRoZW4sIHN0YXJ0aW5nIHdpdGggdGhlIGZpcnN0IHJlY2VpdmVkIGJ5dGUgdGhhdCBpcyBu b3QgY292ZXJlZCB3aXRoIERTTiwgdGhlIHJlY2VpdmVyIHdpbGwgdW5kZXJzdGFuZCB0aGF0 IHRoZSBzZW5kZXIgaGFzIGRpc2FibGVkIERTIG1hcHBpbmcgb24gU0YxLg0KPg0KPiBBdCB0 aGlzIHBvaW50LCBJIGxpa2UgdG8gYmVsaWV2ZSB0aGF0IGRlZmluaW5nIGEgbmV3IE9wdGlv biBTdWJ0eXBlIG9yIHV0aWxpemluZyBhbiB1bnVzZWQgYml0IGluIHRoZSBEU1Mgb3B0aW9u IHdpbGwgYmUgZnJ1aXRmdWwuDQo+DQo+IEV4Y2VwdCBpbiBzb21lIHNwZWNpZmljIHNjZW5h cmlvcywgbGlrZSBhIGRhdGEgY2VudGVyLCBJIGRvbid0IHRoaW5rIGEgZGV2aWNlIGNhbiBr bm93IGluIGFkdmFuY2UgaWYgc2Vjb25kIGludGVyZmFjZSBiZWNvbWVzIGF2YWlsYWJsZSBk dXJpbmcgdGhlIGNvbm5lY3Rpb24uIFNvIGlmIHRoZSB1c2VycyBnb2VzIHdpdGggVENQIHRo ZW4gaGUgaXMgYXQgZGlzYWR2YW50YWdlIGJlY2F1c2UgaGUgY2Fubm90IHV0aWxpemUgYWRk aXRpb25hbCBpbnRlcmZhY2VzIHdoZW4gdGhleSBiZWNvbWUgYXZhaWxhYmxlLiBJZiBoZSBv cGVucyBNUFRDUCBjb25uZWN0aW9uIGhvcGluZyB0aGF0IG5ldyBpbnRlcmZhY2VzIG1heSBi ZWNvbWUgYXZhaWxhYmxlIGluIHRoZSBmdXR1cmUsIHVudGlsIHRoZW4gdGhlIGNvbm5lY3Rp b24gaGFzIHRvIGluY3VyIGNvbnRyb2wgb3ZlcmhlYWQgZHVlIHRvIHJlZHVuZGFudCBEU1Mg T3B0aW9uLg0KPg0KPiBBcyBhIGZpcnN0LWN1dCBzb2x1dGlvbiBJIHRoaW5rIHdlIHNob3Vs ZCBhbGxvdyBhIE1QVENQIGNvbm5lY3Rpb24gbm90IHRvIHVzZSB0aGUgRFNTIG9wdGlvbiB1 bnRpbCBpdCBvcGVucyB0aGUgc2Vjb25kIHN1YmZsb3cuIFRvIGtlZXAgdGhpbmdzIHNpbXBs ZSwgd2UgbWF5IHNheSB0aGF0IG9uY2UgRFNTIE9wdGlvbiBpcyBlbmFibGVkIGl0IHdpbGwg YmUgZW5mb3JjZWQgdW50aWwgdGhlIE1QVENQIGNvbm5lY3Rpb24gaXMgY2xvc2VkLg0KDQpP biBzbWFydHBob25lcyBhIHNvbHV0aW9uIHdvdWxkIG5lZWQgdG8gc3VwcG9ydCBicmVhay1i ZWZvcmUtbWFrZSB0byBiZSANCnVzZWZ1bC4gVGhpcyBtZWFucyB0aGF0IHdlIGNhbm5vdCB0 ZXJtaW5hdGUgdGhlIHN1YmZsb3cgd2l0aCBhIEZJTiANCmJlZm9yZSBkZWNpZGluZyB0byBz d2l0Y2ggdG8gdGhlIHV0aWxpc2F0aW9uIG9mIERTUy4gVGhpcyBmYWN0LCBjb3VwbGVkIA0K d2l0aCBtaWRkbGVib3hlcyB0aGF0IGNhbiB0cmFuc3BhcmVudGx5IGFkZC9yZW1vdmUgZGF0 YSBmcm9tIHRoZSANCmJ5dGVzdHJlYW0gbWFrZSB0aGUgcHJvYmxlbSBkaWZmaWN1bHQgdG8g c29sdmUNCg0KDQpPbGl2aWVyDQo= From nobody Wed Apr 12 22:17:55 2017 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 4796212009C for ; Wed, 12 Apr 2017 22:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL4fAxSl94VW for ; Wed, 12 Apr 2017 22:17:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDD91267BB for ; Wed, 12 Apr 2017 22:17:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEP69674; Thu, 13 Apr 2017 05:17:48 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Apr 2017 06:17:47 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Thu, 13 Apr 2017 10:47:41 +0530 From: Sayee Kompalli Chakravartula To: "Olivier.Bonaventure@uclouvain.be" , "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gABJPHoQ//+sEQD//iJhoIADcW0A//6ugnA= Date: Thu, 13 Apr 2017 05:17:41 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763DA5D@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> <0b4a4dfb-ad38-168b-35b0-c8a0fd8c1903@uclouvain.be> In-Reply-To: <0b4a4dfb-ad38-168b-35b0-c8a0fd8c1903@uclouvain.be> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58EF09FD.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0463539eab111a4ad5997dd5aeeadcd Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 05:17:54 -0000 Hi Olivier, My comments are inline. I couldn't find a cleaner way of embedding my comme= nts inline using Outlook, sorry about that. My comments start with the tag = <>. Soon I will try to switch to gmail. Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Wednesday, April 12, 2017 10:08 PM To: Sayee Kompalli Chakravartula; Sargent, Matthew T. (GRC-LCA0)[Peerless T= echnologies] Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Hi Sayee, > I can think of two ways in which a TCP connection can go down: gracefully= or ungracefully. Assume that there are two subflows, SF1 and SF2, and that= SF2 is to be brought down. If SF2 goes down ungracefully, we have no clean= er way of informing the receiver that the sender is disabling DSS, and so t= his leaves us with two choices: (i) continue to use DSS on SF1, or (ii) def= ine a new Option Subtype or a reserved bit of the DSS Option through which = the sender can explicitly inform the receiver that it is disabling DSS. I b= elieve that the later choice is the cleaner way of disabling the DSS option= . When SF2 goes down ungracefully, we of course need to retransmit the outs= tanding bytes on SF1, similar to what the MPTCP specification requires. For a Multipath TCP connection, subflows can fail in other ways as well.=20 It is also possible that the source IP address associated to a subflow is n= ot assigned anymore to the host, this is the typical example of a smartphon= e that looses WiFi. Another subflow failure scenario is a subflow that stop= s after n retransmissions of the same data. These failures do not stop the = MPTCP connection. <> Agree with you that a subflow can fail in many more ways other th= an what I mentioned. I were only trying to bring out the observation that i= n not all scenarios the receiver and the sender can agree that a subflow we= nt down and accordingly update the state variable NUM_SUBFLOW, because such= a determination is fraught with unpredictable behavior. > The not-so-cleaner way of doing things is fragile and convoluted, so I wo= uld not want to discuss that here. > > If the connection is closed using the RST bit: after sending RST, the sen= der immediately closes the socket, so the MPTCP sender has no way of knowin= g whether the receiver indeed received the RST bit. In fact, the RST bit ma= y be lost in the transit. I would put this case in the category of ungracef= ul shutdown. A subflow can fail due to RST sent by a middlebox. This should not close th= e corresponding MPTCP connection. <> I didn't say that RST will close the MPTCP connection. I should h= ave, instead, said "if the subflow is closed using the RST bit:" > If the connection is closed using the FIN bit: Let us represent a SN as x= _{i,j} where the subscript i denotes the type of sequence space (SSN or DSN= ) and the subscript j gives the subflow ID. Let x_{DSN, SF2} be the DSN of = the last byte transmitted before FIN is sent on SF2 and that x_{DSN, SF1} b= e the last DSN mapped to SF1 before the DSS Option is disabled by the sende= r. In this context we need to consider two possibilities: x_{DSN, SF1} < x_= {DSN, SF2} and x_{DSN, SF1} >=3D x_{DSN, SF2}. Now consider the case x_{DSN= , SF1} < x_{DSN, SF2}. When a data byte is received on SF1 that is not cove= red by DSN we know where to place that data byte with respect to the data b= yte whose DSN is x_{DSN, SF1} using subflow sequence number of the data byt= e. Because, eventually, data bytes need to be ordered based on DSN before r= eleasing to the application layer we still need to decide where to place th= is data byte at the connection-level with respect to x_{DSN, SF2}, and this= is where the protocol will run into ambiguity: whether to place the data b= yte before or after x_{DSN, SF2}. This will lead to protocol dead-lock. Nex= t, we consider the possibility x_{DSN, SF1} >=3D x_{DSN, SF2}. Here we do n= ot have the ambiguity present in the previous context. The received data by= te on SF1 will have to be placed to the right of both x_{DSN, SF1} as well = as x_{DSN, SF2} and the actual placement on SF1 will be determined by the S= SN of the data byte. > > The above analysis helps us to decide how and when DSS Option can be disa= bled. After sending the FIN on SF2, continue sending the DSS option on SF1 = until the largest DSN used on SF1 is at least as large as x_{DSN, SF2} and = the state variable NUM_SUBFLOW has transitioned to 1, and then disable the = DSS Option. To describe the receiver behaviour, the receiver expects to con= tinue to receive data bytes covered with DS mapping on SF1 until the larges= t DSN mapped to SF1 is at least as large as x_{DSN, SF2}. After then, start= ing with the first received byte that is not covered with DSN, the receiver= will understand that the sender has disabled DS mapping on SF1. > > At this point, I like to believe that defining a new Option Subtype or ut= ilizing an unused bit in the DSS option will be fruitful. > > Except in some specific scenarios, like a data center, I don't think a de= vice can know in advance if second interface becomes available during the c= onnection. So if the users goes with TCP then he is at disadvantage because= he cannot utilize additional interfaces when they become available. If he = opens MPTCP connection hoping that new interfaces may become available in t= he future, until then the connection has to incur control overhead due to r= edundant DSS Option. > > As a first-cut solution I think we should allow a MPTCP connection not to= use the DSS option until it opens the second subflow. To keep things simpl= e, we may say that once DSS Option is enabled it will be enforced until the= MPTCP connection is closed. On smartphones a solution would need to support break-before-make to be use= ful. This means that we cannot terminate the subflow with a FIN before deci= ding to switch to the utilisation of DSS. This fact, coupled with middlebox= es that can transparently add/remove data from the bytestream make the prob= lem difficult to solve <> Can you please elaborate on this scenario, as I do not seems to g= et what you were implying? Olivier From nobody Thu Apr 13 03:20:25 2017 Return-Path: <13211134@bjtu.edu.cn> 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 AE2D2131801 for ; Thu, 13 Apr 2017 01:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfwv6x6WDiIk for ; Thu, 13 Apr 2017 01:43:24 -0700 (PDT) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2C13180D for ; Thu, 13 Apr 2017 01:43:22 -0700 (PDT) Received: by ajax-webmail-Jdweb4 (Coremail) ; Thu, 13 Apr 2017 16:45:00 +0800 (GMT+08:00) Date: Thu, 13 Apr 2017 16:45:00 +0800 (GMT+08:00) From: "Shuai Wang" <13211134@bjtu.edu.cn> To: multipathtcp Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1133359_50676351.1492073100500" X-Originating-IP: [116.117.134.28] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 4.0.8 dev build 20150608(70565.7215.7117) Copyright (c) 2002-2017 www.mailtech.cn bjtu X-SendMailWithSms: false X-CM-TRANSID: eJ5wygC3RUWMOu9YU+PtAA--.2014W X-CM-SenderInfo: yrtsiiartuquxmwxhvlgxou0/1tbiAg0JA1RyqAp6SwABsx X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: X-Mailman-Approved-At: Thu, 13 Apr 2017 03:20:20 -0700 Subject: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 08:43:26 -0000 ------=_Part_1133359_50676351.1492073100500 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi, As it is said in RFC 6824 that the 4th ACK packet (for responding ACK/MP_JOIN packet) is necessary in MP_JOIN handshake before sending data. And the reason is that "The initiator's authentication information is sent in its first ACK(the third packet of the handshake). This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regulat TCP ACK in response, and the packet MUST be retransmitte if this ACK is not received." But in my opinion, the receiver can check whether this HMAC included in the third ACK is correct, so the receiver can know whether the sender is the original sender or not. For the above considerations, I think the 4th ACK packet is unnecessary. If my opinion is wrong, please help me to correct. Thank you very much! Best wishes, Shuai ------=_Part_1133359_50676351.1492073100500 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit

Hi,

    As it is said in RFC 6824 that the 4th ACK packet (for responding ACK/MP_JOIN packet) is necessary in MP_JOIN handshake before sending data. And the reason is that "The initiator's authentication information is sent in its first ACK(the third packet of the handshake). This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regulat TCP ACK in response, and the packet MUST be retransmitte if this ACK is not received."

    But in my opinion, the receiver can check whether this HMAC included in the third ACK is correct, so the receiver can know whether the sender is the original sender or not. For the above considerations, I think the 4th ACK packet is unnecessary.

    If my opinion is wrong, please help me to correct. Thank you very much!

Best wishes,

Shuai

------=_Part_1133359_50676351.1492073100500-- From nobody Thu Apr 13 07:52:41 2017 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 6EA18129481 for ; Thu, 13 Apr 2017 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsmGe5wA6nV8 for ; Thu, 13 Apr 2017 07:52:38 -0700 (PDT) Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) (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 56EA61205D3 for ; Thu, 13 Apr 2017 07:52:38 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.198; helo=ndjsppt104.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf104.ndc.nasa.gov 62DF04022B41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492095157; bh=7PYvyplHOx1nadHL2MuwdXWsO7/HNY26e5fvILJ79PY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BrocKwRYv1tjiXlmf3L/dOGRuB1+ge2UVdK3EIlNNOIHlnxqa/zasRoRyFAoomqO+ SgfoLhO6TG//RwNBVv+MRSEZOalHWs4o420rX1yJ8N/V8H5x2Tyr9RdafogaxjK1JF J7Th6nS8Qw4zUoGERVhqVmXCsqMh7QYbcf9zYw1VgYiTKDAtKEOwPTEnsOTgApL+a2 +uSknZTrOhDxOdDuFWFZ13hGivmK+1j8pycLe28k9pXq9ZSWrjdRgknBxBIY8j4Oio 6cIBaAe7MTL/mKH0IiOAeUYE37xNBPvUybRld20AMAJ7XGj9qoGUzOrRsOKfRML9jN iIXlmwkTEsfqA== Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 62DF04022B41; Thu, 13 Apr 2017 09:52:37 -0500 (CDT) Received: from pps.filterd (ndjsppt104.ndc.nasa.gov [127.0.0.1]) by ndjsppt104.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3DEpmdU004713; Thu, 13 Apr 2017 09:52:37 -0500 Received: from ndjscht116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt104.ndc.nasa.gov with ESMTP id 29t9x5geed-1; Thu, 13 Apr 2017 09:52:37 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.32]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.186]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 09:52:36 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: Shuai Wang <13211134@bjtu.edu.cn> CC: multipathtcp Thread-Topic: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake Thread-Index: AQHStD+YzvgdzJGQOEOqE3JRFf2r2aHDtn6A Date: Thu, 13 Apr 2017 14:52:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-13_11:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 14:52:39 -0000 Hi Shuai, > On Apr 13, 2017, at 4:45 AM, Shuai Wang <13211134@bjtu.edu.cn> wrote: >=20 > As it is said in RFC 6824 that the 4th ACK packet (for responding ACK= /MP_JOIN packet) is necessary in MP_JOIN handshake before sending data. And= the reason is that "The initiator's authentication information is sent in = its first ACK(the third packet of the handshake). This data needs to be sen= t reliably, since it is the only time this HMAC is sent; therefore, receipt= of this packet MUST trigger a regulat TCP ACK in response, and the packet = MUST be retransmitte if this ACK is not received." >=20 > But in my opinion, the receiver can check whether this HMAC included = in the third ACK is correct, so the receiver can know whether the sender is= the original sender or not. For the above considerations, I think the 4th = ACK packet is unnecessary.=20 >=20 > If my opinion is wrong, please help me to correct. Thank you very muc= h! >=20 The trick here is to think of this from the other direction. Suppose Host A= opens a connection to Host B and that Host A sends the third packet of the= handshake (ACK with HMAC information). You are correct that if Host B receives this packet it has enough informati= on to authenticate Host A or not. The problem is that Host A does not know = whether Host B has received this packet and authenticated Host A or not. Th= is is the purpose of the fourth ACK of the handshake. It lets Host A know t= hat it has been authenticated and that it can send data to Host B. Suppose the spec changed and we no longer have to send the fourth packet of= the handshake. After Host A sends the third packet of the handshake you ge= t two scenarios: (1) Third packet of the handshake is lost. If A sends data to Host B right = now Host B cannot accept the data since Host A has not been authenticated. (2) Third packet of the handshake is received by Host B. If A sends data to= Host B right now Host B could accept the data since Host A has been authen= ticated. Note that with the changed spec Host A does not have enough information to = decide which case is true for a particular connection.=20 The fourth ACK in the handshake removes the ambiguity for Host A: (a) Third packet of the handshake is lost. Host A, expecting an ACK, is abl= e to timeout and retransmit.=20 (b) Third packet of the handshake is received. Host B sends an ACK, but the= ACK is lost. Host A, expecting an ACK, is able to timeout and retransmit. (c) The third packet of the handshake is received. Host B sends an ACK and = Host A receives the ACK and now knows that it has been authenticated and ca= n send data. The fourth ACK gives an explicit signal to Host A that is has been authenti= cated and is able to send data to Host B. Even with some loss, if (a) or (b= ) occur, the retransmissions should eventually lead to (c). Once (c) happen= s, Host A has enough information to know that it should be able to send dat= a to Host B. Please let me know if that made sense or not. Thanks, Matt= From nobody Fri Apr 14 02:50:53 2017 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 BF822126C22 for ; Fri, 14 Apr 2017 02:50:52 -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 8J-3lO6Tmzf5 for ; Fri, 14 Apr 2017 02:50:50 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DD11289C3 for ; Fri, 14 Apr 2017 02:50:50 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (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 29CF567DFD6; Fri, 14 Apr 2017 11:50:40 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 29CF567DFD6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1492163440; bh=oFkTE3D4qGOjQ+EnWdi9aZwdoWMEPF8OG7EquuzWSvA=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=Z0038AWKXlJP+wrzZo/8A3kzTyh87D1JVhPL2Zmf2yS/OVbyevKJkWnVvb3hrt13e 3NeHF0r37ETweIrS7vxGclNfUCGCei1h4lKtyfwemF/DGVA04b25y7RhkfmzGm1Hp9 UO5xhkDFF8+mO2/m5bka5EpQ2I9bXzH97rNMpP/w= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> <0b4a4dfb-ad38-168b-35b0-c8a0fd8c1903@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763DA5D@blreml501-mbs> To: Sayee Kompalli Chakravartula , "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" Cc: "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <4aac629c-8c56-cdca-59bd-d185c5a48e13@uclouvain.be> Date: Fri, 14 Apr 2017 11:50:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763DA5D@blreml501-mbs> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 29CF567DFD6.A4A90 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 09:50:53 -0000 U2F5ZWUsDQoNCj4+IElmIHRoZSBjb25uZWN0aW9uIGlzIGNsb3NlZCB1c2luZyB0aGUgRklO IGJpdDogTGV0IHVzIHJlcHJlc2VudCBhIFNOIGFzIHhfe2ksan0gd2hlcmUgdGhlIHN1YnNj cmlwdCBpIGRlbm90ZXMgdGhlIHR5cGUgb2Ygc2VxdWVuY2Ugc3BhY2UgKFNTTiBvciBEU04p IGFuZCB0aGUgc3Vic2NyaXB0IGogZ2l2ZXMgdGhlIHN1YmZsb3cgSUQuIExldCB4X3tEU04s IFNGMn0gYmUgdGhlIERTTiBvZiB0aGUgbGFzdCBieXRlIHRyYW5zbWl0dGVkIGJlZm9yZSBG SU4gaXMgc2VudCBvbiBTRjIgYW5kIHRoYXQgeF97RFNOLCBTRjF9IGJlIHRoZSBsYXN0IERT TiBtYXBwZWQgdG8gU0YxIGJlZm9yZSB0aGUgRFNTIE9wdGlvbiBpcyBkaXNhYmxlZCBieSB0 aGUgc2VuZGVyLiBJbiB0aGlzIGNvbnRleHQgd2UgbmVlZCB0byBjb25zaWRlciB0d28gcG9z c2liaWxpdGllczogeF97RFNOLCBTRjF9IDwgeF97RFNOLCBTRjJ9IGFuZCB4X3tEU04sIFNG MX0gPj0geF97RFNOLCBTRjJ9LiBOb3cgY29uc2lkZXIgdGhlIGNhc2UgeF97RFNOLCBTRjF9 IDwgeF97RFNOLCBTRjJ9LiBXaGVuIGEgZGF0YSBieXRlIGlzIHJlY2VpdmVkIG9uIFNGMSB0 aGF0IGlzIG5vdCBjb3ZlcmVkIGJ5IERTTiB3ZSBrbm93IHdoZXJlIHRvIHBsYWNlIHRoYXQg ZGF0YSBieXRlIHdpdGggcmVzcGVjdCB0byB0aGUgZGF0YSBieXRlIHdob3NlIERTTiBpcyB4 X3tEU04sIFNGMX0gdXNpbmcgc3ViZmxvdyBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIGRhdGEg Ynl0ZS4gQmVjYXVzZSwgZXZlbnR1YWxseSwgZGF0YSBieXRlcyBuZWVkIHRvIGJlIG9yZGVy ZWQgYmFzZWQgb24gRFNOIGJlZm9yZSByZWxlYXNpbmcgdG8gdGhlIGFwcGxpY2F0aW9uIGxh eWVyIHdlIHN0aWxsIG5lZWQgdG8gZGVjaWRlIHdoZXJlIHRvIHBsYWNlIHRoaXMgZGF0YSBi eXRlIGF0IHRoZSBjb25uZWN0aW9uLWxldmVsIHdpdGggcmVzcGVjdCB0byB4X3tEU04sIFNG Mn0sIGFuZCB0aGlzIGlzIHdoZXJlIHRoZSBwcm90b2NvbCB3aWxsIHJ1biBpbnRvIGFtYmln dWl0eTogd2hldGhlciB0byBwbGFjZSB0aGUgZGF0YSBieXRlIGJlZm9yZSBvciBhZnRlciB4 X3tEU04sIFNGMn0uIFRoaXMgd2lsbCBsZWFkIHRvIHByb3RvY29sIGRlYWQtbG9jay4gTmV4 dCwgd2UgY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IHhfe0RTTiwgU0YxfSA+PSB4X3tEU04s IFNGMn0uIEhlcmUgd2UgZG8gbm90IGhhdmUgdGhlIGFtYmlndWl0eSBwcmVzZW50IGluIHRo ZSBwcmV2aW91cyBjb250ZXh0LiBUaGUgcmVjZWl2ZWQgZGF0YSBieXRlIG9uIFNGMSB3aWxs IGhhdmUgdG8gYmUgcGxhY2VkIHRvIHRoZSByaWdodCBvZiBib3RoIHhfe0RTTiwgU0YxfSBh cyB3ZWxsIGFzIHhfe0RTTiwgU0YyfSBhbmQgdGhlIGFjdHVhbCBwbGFjZW1lbnQgb24gU0Yx IHdpbGwgYmUgZGV0ZXJtaW5lZCBieSB0aGUgU1NOIG9mIHRoZSBkYXRhIGJ5dGUuDQo+Pg0K Pj4gVGhlIGFib3ZlIGFuYWx5c2lzIGhlbHBzIHVzIHRvIGRlY2lkZSBob3cgYW5kIHdoZW4g RFNTIE9wdGlvbiBjYW4gYmUgZGlzYWJsZWQuIEFmdGVyIHNlbmRpbmcgdGhlIEZJTiBvbiBT RjIsIGNvbnRpbnVlIHNlbmRpbmcgdGhlIERTUyBvcHRpb24gb24gU0YxIHVudGlsIHRoZSBs YXJnZXN0IERTTiB1c2VkIG9uIFNGMSBpcyBhdCBsZWFzdCBhcyBsYXJnZSBhcyB4X3tEU04s IFNGMn0gYW5kIHRoZSBzdGF0ZSB2YXJpYWJsZSBOVU1fU1VCRkxPVyBoYXMgdHJhbnNpdGlv bmVkIHRvIDEsIGFuZCB0aGVuIGRpc2FibGUgdGhlIERTUyBPcHRpb24uIFRvIGRlc2NyaWJl IHRoZSByZWNlaXZlciBiZWhhdmlvdXIsIHRoZSByZWNlaXZlciBleHBlY3RzIHRvIGNvbnRp bnVlIHRvIHJlY2VpdmUgZGF0YSBieXRlcyBjb3ZlcmVkIHdpdGggRFMgbWFwcGluZyBvbiBT RjEgdW50aWwgdGhlIGxhcmdlc3QgRFNOIG1hcHBlZCB0byBTRjEgaXMgYXQgbGVhc3QgYXMg bGFyZ2UgYXMgeF97RFNOLCBTRjJ9LiBBZnRlciB0aGVuLCBzdGFydGluZyB3aXRoIHRoZSBm aXJzdCByZWNlaXZlZCBieXRlIHRoYXQgaXMgbm90IGNvdmVyZWQgd2l0aCBEU04sIHRoZSBy ZWNlaXZlciB3aWxsIHVuZGVyc3RhbmQgdGhhdCB0aGUgc2VuZGVyIGhhcyBkaXNhYmxlZCBE UyBtYXBwaW5nIG9uIFNGMS4NCj4+DQo+PiBBdCB0aGlzIHBvaW50LCBJIGxpa2UgdG8gYmVs aWV2ZSB0aGF0IGRlZmluaW5nIGEgbmV3IE9wdGlvbiBTdWJ0eXBlIG9yIHV0aWxpemluZyBh biB1bnVzZWQgYml0IGluIHRoZSBEU1Mgb3B0aW9uIHdpbGwgYmUgZnJ1aXRmdWwuDQo+Pg0K Pj4gRXhjZXB0IGluIHNvbWUgc3BlY2lmaWMgc2NlbmFyaW9zLCBsaWtlIGEgZGF0YSBjZW50 ZXIsIEkgZG9uJ3QgdGhpbmsgYSBkZXZpY2UgY2FuIGtub3cgaW4gYWR2YW5jZSBpZiBzZWNv bmQgaW50ZXJmYWNlIGJlY29tZXMgYXZhaWxhYmxlIGR1cmluZyB0aGUgY29ubmVjdGlvbi4g U28gaWYgdGhlIHVzZXJzIGdvZXMgd2l0aCBUQ1AgdGhlbiBoZSBpcyBhdCBkaXNhZHZhbnRh Z2UgYmVjYXVzZSBoZSBjYW5ub3QgdXRpbGl6ZSBhZGRpdGlvbmFsIGludGVyZmFjZXMgd2hl biB0aGV5IGJlY29tZSBhdmFpbGFibGUuIElmIGhlIG9wZW5zIE1QVENQIGNvbm5lY3Rpb24g aG9waW5nIHRoYXQgbmV3IGludGVyZmFjZXMgbWF5IGJlY29tZSBhdmFpbGFibGUgaW4gdGhl IGZ1dHVyZSwgdW50aWwgdGhlbiB0aGUgY29ubmVjdGlvbiBoYXMgdG8gaW5jdXIgY29udHJv bCBvdmVyaGVhZCBkdWUgdG8gcmVkdW5kYW50IERTUyBPcHRpb24uDQo+Pg0KPj4gQXMgYSBm aXJzdC1jdXQgc29sdXRpb24gSSB0aGluayB3ZSBzaG91bGQgYWxsb3cgYSBNUFRDUCBjb25u ZWN0aW9uIG5vdCB0byB1c2UgdGhlIERTUyBvcHRpb24gdW50aWwgaXQgb3BlbnMgdGhlIHNl Y29uZCBzdWJmbG93LiBUbyBrZWVwIHRoaW5ncyBzaW1wbGUsIHdlIG1heSBzYXkgdGhhdCBv bmNlIERTUyBPcHRpb24gaXMgZW5hYmxlZCBpdCB3aWxsIGJlIGVuZm9yY2VkIHVudGlsIHRo ZSBNUFRDUCBjb25uZWN0aW9uIGlzIGNsb3NlZC4NCj4NCj4gT24gc21hcnRwaG9uZXMgYSBz b2x1dGlvbiB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgYnJlYWstYmVmb3JlLW1ha2UgdG8gYmUg dXNlZnVsLiBUaGlzIG1lYW5zIHRoYXQgd2UgY2Fubm90IHRlcm1pbmF0ZSB0aGUgc3ViZmxv dyB3aXRoIGEgRklOIGJlZm9yZSBkZWNpZGluZyB0byBzd2l0Y2ggdG8gdGhlIHV0aWxpc2F0 aW9uIG9mIERTUy4gVGhpcyBmYWN0LCBjb3VwbGVkIHdpdGggbWlkZGxlYm94ZXMgdGhhdCBj YW4gdHJhbnNwYXJlbnRseSBhZGQvcmVtb3ZlIGRhdGEgZnJvbSB0aGUgYnl0ZXN0cmVhbSBt YWtlIHRoZSBwcm9ibGVtIGRpZmZpY3VsdCB0byBzb2x2ZQ0KPg0KPg0KPg0KPiA8PFNheWVl Pj4gQ2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlIG9uIHRoaXMgc2NlbmFyaW8sIGFzIEkgZG8g bm90IHNlZW1zIHRvIGdldCB3aGF0IHlvdSB3ZXJlIGltcGx5aW5nPw0KDQoNCkEgdmVyeSBh bm5veWluZyBjb3JuZXIgY2FzZSBpcyB0aGUgZm9sbG93aW5nIG9uZSA6DQoNCkEgc21hcnRw aG9uZSBjcmVhdGVzIGFuIE1QVENQIGNvbm5lY3Rpb24gb3ZlciBXaUZpLiBUaGUgDQp0aHJl ZS13YXktaGFuZHNoYWtlIGlzIGRvbmUgY29ycmVjdGx5LiBBZnRlciBhIGZldyBzZWNvbmRz LCB0aGUgDQpzbWFydHBob25lIHNlbmRzIHNvbWUgZGF0YSBidXQgaXQgaGFzIG1vdmVkIG91 dCBvZiByZWFjaCBvZiB0aGUgV2lGaSANCm5ldHdvcmsgYW5kIGl0IGRvZXMgbm90IHJlY2Vp dmUgYWNrbm93bGVkZ2VtZW50cyBmb3IgdGhpcyBkYXRhLiBGcm9tIHRoZSANCmluZm9ybWF0 aW9uIGV4Y2hhbmdlZCBvdmVyIHRoZSBXaUZpLCB0aGUgc21hcnRwaG9uZSBjYW5ub3Qga25v dyB3aGV0aGVyIA0KdGhlIGRhdGEgaGFzIGJlZW4gcmVjZWl2ZWQgYnkgdGhlIHNlcnZlciBv ciBub3QuDQoNClRoZSBzbWFydHBob25lIHRoZW4gb3BlbnMgYSBzdWJmbG93IG92ZXIgdGhl IExURSBpbnRlcmZhY2UuIE9uY2UgdGhlIA0Kc3ViZmxvdyBpcyBlc3RhYmxpc2hlZCwgaXQg Y2FuIGJlIHVzZWQgdG8gc2VuZCBkYXRhIHdpdGggdGhlIERTUyBvcHRpb24uIA0KTm90ZSB0 aGF0IGR1cmluZyB0aGUgdGhyZWUtd2F5IGhhbmRzaGFrZSBmb3IgdGhlIGluaXRpYWwgc3Vi ZmxvdywgdGhlIA0KY2xpZW50IGFuZCB0aGUgc2VydmVyIGhhdmUgYWdyZWVkIG9uIHRoZSBp bml0aWFsIHNlcXVlbmNlIG51bWJlcnMgZm9yIA0KdGhlIHR3byBkaXJlY3Rpb25zIG9mIHRo ZSB0cmFuc2Zlci4gVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlIGZpcnN0IGRhdGEgDQphcnJp dmVzIG9uIHRoZSBMVEUgc3ViZmxvdyB3aXRoIGEgRFNTIG9wdGlvbiwgdGhlIHNlcnZlciBj YW4gZGV0ZXJtaW5lIA0Kd2hldGhlciB0aGlzIGlzIHRoZSBmaXJzdCBkYXRhIG9mIHRoZSBi eXRlc3RyZWFtIG9yIG90aGVyIGRhdGEgYW5kIHRoZW4gDQppdCB3b3VsZCBuZWVkIHRvIHdh aXQgZm9yIHRoZSBmaXJzdCBkYXRhIGJlZm9yZSBkZWxpdmVyaW5nIGl0IHRvIGl0cyANCmFw cGxpY2F0aW9uLg0KDQpJZiB5b3UgcmVtb3ZlIHRoZSBEU1Mgb24gdGhlIGluaXRpYWwgc3Vi ZmxvdywgdGhlbiBJIGRvIG5vdCBzZWUgYW55IHdheSANCmZvciB0aGUgc2VydmVyIHRvIGNv cGUgY29ycmVjdGx5IHdpdGggdGhpcyBzY2VuYXJpby4gTm90ZSB0aGF0IHNlcXVlbmNlIA0K bnVtYmVyIHJhbmRvbWlzYXRpb24gYWZmZWN0cyB0aGUgc2VxdWVuY2UgbnVtYmVycyB0aGF0 IHRoZSBzbWFydHBob25lcyANCmFuZCB0aGUgc2VydmVyIHNlZS4NCg0KDQpPbGl2aWVyDQoN Cg0K From nobody Fri Apr 14 04:33:14 2017 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 67937129AF2 for ; Fri, 14 Apr 2017 04:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHvM3FOaT_nN for ; Fri, 14 Apr 2017 04:33:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150EB129BC4 for ; Fri, 14 Apr 2017 04:33:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DET33616; Fri, 14 Apr 2017 11:33:07 +0000 (GMT) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Apr 2017 12:33:06 +0100 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Fri, 14 Apr 2017 17:03:03 +0530 From: Sayee Kompalli Chakravartula To: "Olivier.Bonaventure@uclouvain.be" , "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] A question related to MPTCP control overhead Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gABJPHoQ//+sEQD//iJhoIADcW0A//6ugnCABC4/AP//iGhA Date: Fri, 14 Apr 2017 11:33:02 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763E0C7@blreml501-mbs> References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs> <10AC969E-5E0D-49BF-997A-6A71B55DE4CB@nasa.gov> <5C068B455EB58047BBD492DA2B0829FA3763D85B@blreml501-mbs> <0b4a4dfb-ad38-168b-35b0-c8a0fd8c1903@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763DA5D@blreml501-mbs> <4aac629c-8c56-cdca-59bd-d185c5a48e13@uclouvain.be> In-Reply-To: <4aac629c-8c56-cdca-59bd-d185c5a48e13@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58F0B374.0117, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0463539eab111a4ad5997dd5aeeadcd Archived-At: Subject: Re: [multipathtcp] A question related to MPTCP control overhead X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 11:33:13 -0000 Olivier, I got the point, and thanks for the clarification. I were under the impress= ion that existence of MPTCP connection implies that existence of at least o= ne subflow, which clearly cannot be true always as your corner case illustr= ates. Sayee -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Friday, April 14, 2017 3:21 PM To: Sayee Kompalli Chakravartula; Sargent, Matthew T. (GRC-LCA0)[Peerless T= echnologies] Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] A question related to MPTCP control overhead Sayee, >> If the connection is closed using the FIN bit: Let us represent a SN as = x_{i,j} where the subscript i denotes the type of sequence space (SSN or DS= N) and the subscript j gives the subflow ID. Let x_{DSN, SF2} be the DSN of= the last byte transmitted before FIN is sent on SF2 and that x_{DSN, SF1} = be the last DSN mapped to SF1 before the DSS Option is disabled by the send= er. In this context we need to consider two possibilities: x_{DSN, SF1} < x= _{DSN, SF2} and x_{DSN, SF1} >=3D x_{DSN, SF2}. Now consider the case x_{DS= N, SF1} < x_{DSN, SF2}. When a data byte is received on SF1 that is not cov= ered by DSN we know where to place that data byte with respect to the data = byte whose DSN is x_{DSN, SF1} using subflow sequence number of the data by= te. Because, eventually, data bytes need to be ordered based on DSN before = releasing to the application layer we still need to decide where to place t= his data byte at the connection-level with respect to x_{DSN, SF2}, and thi= s is where the protocol will run into ambiguity: whether to place the data = byte before or after x_{DSN, SF2}. This will lead to protocol dead-lock. Ne= xt, we consider the possibility x_{DSN, SF1} >=3D x_{DSN, SF2}. Here we do = not have the ambiguity present in the previous context. The received data b= yte on SF1 will have to be placed to the right of both x_{DSN, SF1} as well= as x_{DSN, SF2} and the actual placement on SF1 will be determined by the = SSN of the data byte. >> >> The above analysis helps us to decide how and when DSS Option can be dis= abled. After sending the FIN on SF2, continue sending the DSS option on SF1= until the largest DSN used on SF1 is at least as large as x_{DSN, SF2} and= the state variable NUM_SUBFLOW has transitioned to 1, and then disable the= DSS Option. To describe the receiver behaviour, the receiver expects to co= ntinue to receive data bytes covered with DS mapping on SF1 until the large= st DSN mapped to SF1 is at least as large as x_{DSN, SF2}. After then, star= ting with the first received byte that is not covered with DSN, the receive= r will understand that the sender has disabled DS mapping on SF1. >> >> At this point, I like to believe that defining a new Option Subtype or u= tilizing an unused bit in the DSS option will be fruitful. >> >> Except in some specific scenarios, like a data center, I don't think a d= evice can know in advance if second interface becomes available during the = connection. So if the users goes with TCP then he is at disadvantage becaus= e he cannot utilize additional interfaces when they become available. If he= opens MPTCP connection hoping that new interfaces may become available in = the future, until then the connection has to incur control overhead due to = redundant DSS Option. >> >> As a first-cut solution I think we should allow a MPTCP connection not t= o use the DSS option until it opens the second subflow. To keep things simp= le, we may say that once DSS Option is enabled it will be enforced until th= e MPTCP connection is closed. > > On smartphones a solution would need to support break-before-make to=20 > be useful. This means that we cannot terminate the subflow with a FIN=20 > before deciding to switch to the utilisation of DSS. This fact,=20 > coupled with middleboxes that can transparently add/remove data from=20 > the bytestream make the problem difficult to solve > > > > <> Can you please elaborate on this scenario, as I do not seems to= get what you were implying? A very annoying corner case is the following one : A smartphone creates an MPTCP connection over WiFi. The three-way-handshake= is done correctly. After a few seconds, the smartphone sends some data but= it has moved out of reach of the WiFi network and it does not receive ackn= owledgements for this data. From the information exchanged over the WiFi, t= he smartphone cannot know whether the data has been received by the server = or not. The smartphone then opens a subflow over the LTE interface. Once the subflo= w is established, it can be used to send data with the DSS option.=20 Note that during the three-way handshake for the initial subflow, the clien= t and the server have agreed on the initial sequence numbers for the two di= rections of the transfer. This means that when the first data arrives on th= e LTE subflow with a DSS option, the server can determine whether this is t= he first data of the bytestream or other data and then it would need to wai= t for the first data before delivering it to its application. If you remove the DSS on the initial subflow, then I do not see any way for= the server to cope correctly with this scenario. Note that sequence number= randomisation affects the sequence numbers that the smartphones and the se= rver see. Olivier From nobody Mon Apr 17 23:04:20 2017 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 45F8B129474 for ; Mon, 17 Apr 2017 23:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 frFcyLXmjtMu for ; Mon, 17 Apr 2017 23:04:17 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A9E129466 for ; Mon, 17 Apr 2017 23:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4076; q=dns/txt; s=iport; t=1492495456; x=1493705056; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MDq1oOjhMSvtxBtnLMaq9g9Tv6P4PGk6FSIRsCTt8Ls=; b=j2uSy015+UXGMaDtpGNDV50h6pJDpzsxG9jqMaJwtKFiGSwGV7vF/HTQ PsBfGZ27/Gbngw/1qVCYi0XYa3fRvbMPlrLZjo0fW8AANjxDJkSItDNF0 I9Q+0U5onwgyc4q5fntjS1qFfCD4NHgo2jzwmLOJ9Tl1fb+Trlext6e+Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AwAJq/VY/5hdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5lYYESg1+KFZE+kEyFNIIPhiQCGoNtPxgBAgEBAQEBAQFrHQuFFgY?= =?us-ascii?q?jZgIBDCAeAgICMCUCBIoqqkyCJiuKdwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GU?= =?us-ascii?q?oIICopALoIxBZ0bAZJlkUaUCQEfOD5HYxVVAYZTiQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,218,1488844800"; d="scan'208,217";a="410863235" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 06:04:16 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3I64GR8029103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Apr 2017 06:04:16 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 01:04:15 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 01:04:15 -0500 From: "Noopur Saraf (nosaraf)" To: "multipathtcp@ietfa.amsl.com" Thread-Topic: Multipath TCP related discussions Thread-Index: AQHSuAb8qsNtTD59TkiXRpToKfQUoKHLUy6A Date: Tue, 18 Apr 2017 06:04:15 +0000 Message-ID: References: <444E1AE1-A575-410D-8041-805ECFE01719@cisco.com> In-Reply-To: <444E1AE1-A575-410D-8041-805ECFE01719@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.142.40.160] Content-Type: multipart/alternative; boundary="_000_D4BFDADFD07A4507AD5FAAFE765504B6ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Multipath TCP related discussions X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 06:04:18 -0000 --_000_D4BFDADFD07A4507AD5FAAFE765504B6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KDQpJIHdvdWxkIGxpa2UgdG8gc3Vic2NyaWJlIHRvIGFsbCB1cGNvbWluZyBtdWx0 aXBhdGggVENQIHJlbGF0ZWQgZGlzY3Vzc2lvbi9tZWV0aW5ncy4NCg0KDQoNClRoYW5rcywNCg0K Tm9vcHVyDQoNCg== --_000_D4BFDADFD07A4507AD5FAAFE765504B6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnAx LCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250LWZhbWlseTpDYWxp YnJpO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnMxDQoJe21zby1z dHlsZS1uYW1lOnMxO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5I aSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IHdvdWxkIGxpa2UgdG8gc3Vic2NyaWJlIHRvIGFsbCB1cGNvbWluZyBtdWx0aXBhdGggVENQIHJl bGF0ZWQgZGlzY3Vzc2lvbi9tZWV0aW5ncy48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48 c3BhbiBjbGFzcz0iczEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMx Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tm9vcHVyPC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_D4BFDADFD07A4507AD5FAAFE765504B6ciscocom_-- From nobody Mon Apr 17 23:10:20 2017 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 9315512947A for ; Mon, 17 Apr 2017 23:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKQOBud33r00 for ; Mon, 17 Apr 2017 23:10:16 -0700 (PDT) Received: from dggrg03-dlp.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69E5129474 for ; Mon, 17 Apr 2017 23:10:13 -0700 (PDT) Received: from 172.30.72.53 (EHLO SZXEMA416-HUB.china.huawei.com) ([172.30.72.53]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AMA51300; Tue, 18 Apr 2017 14:09:55 +0800 (CST) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by SZXEMA416-HUB.china.huawei.com (10.82.72.35) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 18 Apr 2017 14:09:52 +0800 Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Tue, 18 Apr 2017 11:39:39 +0530 From: Sayee Kompalli Chakravartula To: "Noopur Saraf (nosaraf)" , "multipathtcp@ietfa.amsl.com" Thread-Topic: Multipath TCP related discussions Thread-Index: AQHSuAb8qsNtTD59TkiXRpToKfQUoKHLUy6A//9RFdA= Date: Tue, 18 Apr 2017 06:09:39 +0000 Message-ID: <5C068B455EB58047BBD492DA2B0829FA3764054F@blreml501-mbs> References: <444E1AE1-A575-410D-8041-805ECFE01719@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.198] Content-Type: multipart/alternative; boundary="_000_5C068B455EB58047BBD492DA2B0829FA3764054Fblreml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58F5ADB4.0044, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a958ef5d678956390c890bba46ce3c2e Archived-At: Subject: Re: [multipathtcp] Multipath TCP related discussions X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 06:10:18 -0000 --_000_5C068B455EB58047BBD492DA2B0829FA3764054Fblreml501mbs_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG5lZWQgdG8gc3Vic2NyaWJlIHVzaW5nIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXVsdGlwYXRodGNwDQoNClNheWVlDQoNCkZyb206IG11bHRpcGF0aHRjcCBbbWFp bHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9vcHVyIFNh cmFmIChub3NhcmFmKQ0KU2VudDogVHVlc2RheSwgQXByaWwgMTgsIDIwMTcgMjowNCBQTQ0KVG86 IG11bHRpcGF0aHRjcEBpZXRmYS5hbXNsLmNvbQ0KU3ViamVjdDogW211bHRpcGF0aHRjcF0gTXVs dGlwYXRoIFRDUCByZWxhdGVkIGRpc2N1c3Npb25zDQoNCg0KSGksDQoNCg0KSSB3b3VsZCBsaWtl IHRvIHN1YnNjcmliZSB0byBhbGwgdXBjb21pbmcgbXVsdGlwYXRoIFRDUCByZWxhdGVkIGRpc2N1 c3Npb24vbWVldGluZ3MuDQoNCg0KDQpUaGFua3MsDQoNCk5vb3B1cg0KDQo= --_000_5C068B455EB58047BBD492DA2B0829FA3764054Fblreml501mbs_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAucDEsIGxpLnAxLCBkaXYucDENCgl7bXNvLXN0eWxlLW5h bWU6cDE7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uczENCgl7bXNvLXN0 eWxlLW5hbWU6czE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+WW91IG5lZWQgdG8gc3Vic2NyaWJlIHVzaW5nIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPlNheWVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG11bHRpcGF0 aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Ob29wdXIgU2FyYWYgKG5vc2FyYWYpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEFwcmlsIDE4LCAyMDE3IDI6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IG11bHRpcGF0aHRjcEBpZXRm YS5hbXNsLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbXVsdGlwYXRodGNwXSBNdWx0aXBhdGgg VENQIHJlbGF0ZWQgZGlzY3Vzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGks PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSB3 b3VsZCBsaWtlIHRvIHN1YnNjcmliZSB0byBhbGwgdXBjb21pbmcgbXVsdGlwYXRoIFRDUCByZWxh dGVkIGRpc2N1c3Npb24vbWVldGluZ3MuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNw YW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5vb3B1cjwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_5C068B455EB58047BBD492DA2B0829FA3764054Fblreml501mbs_-- From nobody Tue Apr 18 01:17:33 2017 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 80F93131803 for ; Tue, 18 Apr 2017 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrpR0wCWcFxM for ; Tue, 18 Apr 2017 01:17:29 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8430F126DEE for ; Tue, 18 Apr 2017 01:17:28 -0700 (PDT) Received: from EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Apr 2017 09:17:23 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Apr 2017 09:17:25 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 09:17:24 +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.1210.000; Tue, 18 Apr 2017 09:17:24 +0100 From: To: Thread-Topic: Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53Icbg== Date: Tue, 18 Apr 2017 08:17:24 +0000 Message-ID: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_8c5ffa879686472594bfd3db2fa06076rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:17:31 -0000 --_000_8c5ffa879686472594bfd3db2fa06076rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. --_000_8c5ffa879686472594bfd3db2fa06076rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

During the MPTCP meeting in Chicago we did several hums about pote= ntial MPTCP proxy work. Our interpretation of these hums is that we should = do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’t support, such work = – so we can see if there’s consensus for it.

Thanks

Phil & Yoshi

 

Hums during the meeting:

·         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

·         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no

·         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

·         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 

--_000_8c5ffa879686472594bfd3db2fa06076rew09926dag03bdomain1sy_-- From nobody Tue Apr 18 01:24:46 2017 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 D77C31292AE for ; Tue, 18 Apr 2017 01:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 U4tlqfDGB7-a for ; Tue, 18 Apr 2017 01:24:43 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 37901131803 for ; Tue, 18 Apr 2017 01:24:43 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id DAE98202C8 for ; Tue, 18 Apr 2017 10:24:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 9FE4B1A0062; Tue, 18 Apr 2017 10:24:41 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 10:24:41 +0200 From: To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAAOnRw Date: Tue, 18 Apr 2017 08:24:40 +0000 Message-ID: <5406_1492503881_58F5CD49_5406_4781_1_88132E969123D14D9BD844E1CD516EDE142F90B5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.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: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE142F90B5OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:24:45 -0000 --_000_88132E969123D14D9BD844E1CD516EDE142F90B5OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello WG, I fully support the MPTCP proxy work. Cheers, Christian. De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : mardi 18 avril 2017 10:17 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Consensus call on potential MPTCP proxy work Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88132E969123D14D9BD844E1CD516EDE142F90B5OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello WG,

 

I fully support the MPTCP proxy work.

 

Cheers,

 

Christian.

 

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com
Envoy=E9 : mardi 18 avril 2017 10:17
=C0 : multipathtcp@ietf.org
Objet : [multipathtcp] Consensus call on potential MPTCP proxy = work

 

Hi,

During the MPTCP meeting in Chicago we did se= veral hums about potential MPTCP proxy work. Our interpretation of these hu= ms is that we should do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’= t support, such work – so we can see if there’s consensus for i= t.

Thanks

Phil & Yoshi

 

Hums during the meeting:

=B7         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

=B7         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no<= /o:p>

=B7         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

=B7         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 = 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88132E969123D14D9BD844E1CD516EDE142F90B5OPEXCLILMA3corp_-- From nobody Tue Apr 18 02:00:05 2017 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 70EBD13184A for ; Tue, 18 Apr 2017 02:00:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 hdEiJkc7Ng-v for ; Tue, 18 Apr 2017 02:00:00 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50DF131842 for ; Tue, 18 Apr 2017 01:59:59 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 2381020B8B for ; Tue, 18 Apr 2017 10:59:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id DA71A120079; Tue, 18 Apr 2017 10:59:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 10:59:57 +0200 From: To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgABRHLw Date: Tue, 18 Apr 2017 08:59:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4F892@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.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.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E4F892OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:00:02 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E4F892OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, Is there any particular reason for this mention "The WG does not develop a = mechanism for the two proxies to discover each other". Isn't this conflicti= ng partly with the need for some work to be done for configuring proxies (m= entioned in the sentence right before the one I'm quoting)? Putting that aside, I fully support this proxy work. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : mardi 18 avril 2017 10:17 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Consensus call on potential MPTCP proxy work Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. --_000_787AE7BB302AE849A7480A190F8B933009E4F892OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

Is there any particular reason = for this mention “The WG does not develop a mechanism for the two pro= xies to discover each other”. Isn’t this conflicting partly with the need for some work to be done for configuring proxies (mentioned = in the sentence right before the one I’m quoting)?<= /p>

 

Putting that aside, I fully sup= port this proxy work.

 

Cheers,

Med

 

De : mult= ipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com
Envoy=E9 : mardi 18 avril 2017 10:17
=C0 : multipathtcp@ietf.org
Objet : [multipathtcp] Consensus call on potential MPTCP proxy = work

 

Hi,

During the MPTCP meeting in Chicago we did se= veral hums about potential MPTCP proxy work. Our interpretation of these hu= ms is that we should do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’= t support, such work – so we can see if there’s consensus for i= t.

Thanks

Phil & Yoshi

 

Hums during the meeting:

=B7         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

=B7         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no<= /o:p>

=B7         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

=B7         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 =

--_000_787AE7BB302AE849A7480A190F8B933009E4F892OPEXCLILMA3corp_-- From nobody Tue Apr 18 06:30:45 2017 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 E569C12EC18 for ; Tue, 18 Apr 2017 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBr38QIOgxNT for ; Tue, 18 Apr 2017 06:30:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAEC12EC0D for ; Tue, 18 Apr 2017 06:30:42 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3IDTYg3020142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 06:29:44 -0700 (PDT) To: philip.eardley@bt.com, multipathtcp@ietf.org References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> From: Joe Touch Message-ID: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> Date: Tue, 18 Apr 2017 06:29:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------66C160299F4246C46A55F12D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:30:44 -0000 This is a multi-part message in MIME format. --------------66C160299F4246C46A55F12D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, all, The description below isn't sufficient to determine whether this work is either needed or safe. My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas. I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them. I am curious as to what's really intended here, though. Joe 1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion. 2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the data plane of the MPTCP connection? 3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in previous discussion. On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote: > > Hi, > > During the MPTCP meeting in Chicago we did several hums about > potential MPTCP proxy work. Our interpretation of these hums is that > we should do a consensus call for the following work: > > -- > MPTCP is now seeing widespread deployment in networks to bond together > two accesses, such as fixed and mobile broadband, by using two MPTCP > proxies, one in the home gateway or Customer Premises Equipment and > one in the network. The WG develops a solution where the proxies are > both under the control of the operator and where it is assumed that > they are not on the default path. The solution is based on using the > payload of an MPTCP packet to transfer a signalling message between > the proxies. It is believed the solution will not require changes to > RFC6824bis. The solution may require a means of configuring set-up > information in the proxies, which would be done in coordination with > other IETF WGs such as DHC. The WG does not develop a mechanism for > the two proxies to discover each other. > > -- > > Please say whether you support, or don’t support, such work – so we > can see if there’s consensus for it. > > Thanks > > Phil & Yoshi > > > > Hums during the meeting: > > · Should the MPTCP WG do any MPTCP proxy work, or do none – > about 2:1 or 3:1 in favour of doing work > > · Should the MPTCP WG do proxy work based on option #1 in > slide 12? Strongly more yes than no > > · Should the MPTCP WG do proxy work based on option #2 in > slide 12? more no than yes > > · Should the MPTCP WG do proxy work based on option #3 in > slide 12? Weak & roughly equal > > Ref: > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf > > We believe the work does not require an update to the MPTCP WG charter. > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------66C160299F4246C46A55F12D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi, all,

The description below isn't sufficient to determine whether this work is either needed or safe.

My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the data plane of the MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in previous discussion.

On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:

Hi,

During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.

--

Please say whether you support, or don’t support, such work – so we can see if there’s consensus for it.

Thanks

Phil & Yoshi

 

Hums during the meeting:

·         Should the MPTCP WG do any MPTCP proxy work, or do none – about 2:1 or 3:1 in favour of doing work

·         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

·         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

·         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf

We believe the work does not require an update to the MPTCP WG charter.

 



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

--------------66C160299F4246C46A55F12D-- From nobody Tue Apr 18 07:30:23 2017 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 02DF2128B44 for ; Tue, 18 Apr 2017 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 YWV59dHoSmg3 for ; Tue, 18 Apr 2017 07:30:17 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B168131809 for ; Tue, 18 Apr 2017 07:30:17 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 32F6E1204E2; Tue, 18 Apr 2017 16:30:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 05144180077; Tue, 18 Apr 2017 16:30:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 16:30:14 +0200 From: To: Joe Touch , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuEf/fdYfWY1wG0WtXqHcvFS6GqHLI5rg Date: Tue, 18 Apr 2017 14:30:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> In-Reply-To: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> 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_787AE7BB302AE849A7480A190F8B933009E4FBB2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:30:21 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E4FBB2OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, Some comments from my side : =B7 The main target use case is a CPE that is connected to many net= works (cellular and fixed, typically). Please refer to https://www.ietf.org= /mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf for more business driver= s. =B7 In order to enhance resilience and increase resource pooling, t= he CPE is MPTCP-capable. =B7 Because of the lack of MPTCP support at the servers side, a pro= xy is introduced at the network side to assisted MPTCP connections of that = CPE. Let's call this proxy: network-located proxy. =B7 Because the network provider does not control hosts that are lo= cated behind a given CPE, a proxy is enabled on the CPE to transform some T= CP connections into MPTCP ones. =B7 The CPE is configured with its network-located proxy by means o= f DHCP, for example. =B7 As mentioned in Phil's text, the proxies are both under the con= trol of the operator. In particular, ** both ** the CPE and the network-pro= xy support the mechanism detailed hereafter (that is parse and strip any su= pplied data before forwarding upstream). =B7 There is no tunnel/encapsulation at all. As such there is no **= TCP over TCP ** scheme. All is about plain transport mode. o The CPE forwards MPTCP connections it creates to its configured networ= k-located proxy. This is exactly the same as with the data plane of SOCKS. o In order to inform its proxy about the ultimate destination IP address= /port while ensuring 0-RTT, an information element is inserted in the paylo= ad of the SYN message of the initial subflow. o That information is stripped by the network-located proxy before forwa= rding the packet to its ultimate server. o In order to strengthen the solution, that information must be echoed b= y the proxy in the SYN/ACK as a guard against misconfigured proxies. o The information echoed in the SYN/ACK is used by the CPE to double che= ck that the network-proxy complies with the solution. If not, no further MP= TCP connection is established with that proxy till a TTL expires or a new p= roxy is configured. o More details can be found at https://www.ietf.org/proceedings/98/slide= s/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf So: =B7 "(TCP over TCP), which I already noted in previous discussion."= WAS NEVER proposed. =B7 The proposal does not "interfere with MPTCP's ability to silent= ly fall-back to TCP when talking to legacy endpoints". Legacy endpoints tha= t receive an MP_CAPABLE option (whether from an MPTCP-capable client or via= a proxy) will ignore it and silently fall back to TCP. I don't see a probl= em here. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe = Touch Envoy=E9 : mardi 18 avril 2017 15:30 =C0 : philip.eardley@bt.com; multipathtcp@ietf.org Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work Hi, all, The description below isn't sufficient to determine whether this work is ei= ther needed or safe. My initial conclusion is that this work is either (a) not needed at all, (b= ) out of scope, or (c) involves one if not two very bad ideas. I have a few questions that determine which of (a), (b), or (c) apply (belo= w), but I've already commented on my concerns that conclude (c) *based on p= reviously assuming this was intended as an IP tunnel and used an option wit= h control plane info in the SYN data) so I won't repeat them. I am curious as to what's really intended here, though. Joe 1) what is the reason for needing MPTCP work to support proxy-proxy use? Tr= ue proxies are applications and can already setup MTCP themselves. Protocol= s for operators to configure proxies seem out of scope here. And if this "p= roxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), w= hich I already noted in previous discussion. 2) what does "using the payload...to transfer a signalling message" mean? A= re you using the MPTCP control plane? or the data plane of the MPTCP connec= tion? 3) I'm not sure I fully understand the details of the optinns, but I unders= tand that at least one of them puts data in the SYN that is interpreted as = something other than TCP data (i.e., control plane). That is also a very ba= d idea - it interferes with MPTCPs ability to silently fall-back to TCP whe= n talking to legacy endpoints, and the reasons for not using TCP data as co= ntrol are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the re= ason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in p= revious discussion. On 4/18/2017 1:17 AM, philip.eardley@bt.com w= rote: Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_787AE7BB302AE849A7480A190F8B933009E4FBB2OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Some comments from my side = ;:

 

=B7    &n= bsp;    The main target use cas= e is a CPE that is connected to many networks (cellular and fixed, typicall= y). Please refer to https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf = for more business drivers.

=B7    &n= bsp;    In order to enhance res= ilience and increase resource pooling, the CPE is MPTCP-capable.

=B7    &n= bsp;    Because of the lack of = MPTCP support at the servers side, a proxy is introduced at the network sid= e to assisted MPTCP connections of that CPE. Let’s call this proxy: network-located proxy.

=B7    &n= bsp;    Because the network pro= vider does not control hosts that are located behind a given CPE, a proxy i= s enabled on the CPE to transform some TCP connections into MPTCP ones.

=B7    &n= bsp;    The CPE is configured w= ith its network-located proxy by means of DHCP, for example.

=B7    &n= bsp;    As mentioned in Phil= 217;s text, the proxies are both under the control of the operator. In part= icular, ** both ** the CPE and the network-proxy support the mechanism detailed hereafter (that is parse and strip any supplied dat= a before forwarding upstream).  

=B7    &n= bsp;    There is no tunnel/enca= psulation at all. As such there is no ** TCP over TCP ** scheme. All is abo= ut plain transport mode.  

o=     The CPE forwards MPTCP = connections it creates to its configured network-located proxy. This is exa= ctly the same as with the data plane of SOCKS.

o=     In order to inform its = proxy about the ultimate destination IP address/port while ensuring 0-RTT, = an information element is inserted in the payload of the SYN message of the initial subflow.

o=     That information is str= ipped by the network-located proxy before forwarding the packet to its ulti= mate server.

o=     In order to strengthen = the solution, that information must be echoed by the proxy in the SYN/ACK a= s a guard against misconfigured proxies.

o=     The information echoed = in the SYN/ACK is used by the CPE to double check that the network-proxy co= mplies with the solution. If not, no further MPTCP connection is established with that proxy till a TTL expires or a new prox= y is configured.

o=     More details can be fou= nd at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-as= sisted-mptcp-03.pdf

 

So:

=B7    &n= bsp;    “(TCP over TCP), = which I already noted in previous discussion.” WAS NEVER proposed. &n= bsp; 

=B7    &n= bsp;    The proposal does not &= #8220;interfere with MPTCP’s ability to silently fall-back to TCP whe= n talking to legacy endpoints”. Legacy endpoints that receive an MP_CAPABLE option (whether from an MPTCP-capable client or via a proxy)= will ignore it and silently fall back to TCP. I don’t see a problem = here.

 

Cheers,

Med

 

De&nb= sp;: multipathtcp [m= ailto:multipathtcp-bounces@ietf.org] De la part de Joe Touch
Envoy=E9 : mardi 18 avril 2017 15:30
=C0 : philip.eardley@bt.com= ; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

Hi, all,

The description below isn't sufficient to determine whether this work is= either needed or safe.

My initial conclusion is that this work is either (a) not needed at all,= (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (b= elow), but I've already commented on my concerns that conclude (c) *based o= n previously assuming this was intended as an IP tunnel and used an option = with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use?= True proxies are applications and can already setup MTCP themselves. Proto= cols for operators to configure proxies seem out of scope here. And if this= "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous d= iscussion.

2) what does "using the payload...to transfer a signalling message&= quot; mean? Are you using the MPTCP control plane? or the data plane of the= MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I und= erstand that at least one of them puts data in the SYN that is interpreted = as something other than TCP data (i.e., control plane). That is also a very= bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and= the reasons for not using TCP data as control are discussed in draft-ietf-= tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-= ext-opt), which I also already noted in previous discussion.

On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:

Hi,

During the MPTCP meeting in Chicago we did several hums about pote= ntial MPTCP proxy work. Our interpretation of these hums is that we should = do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’t support, such work = – so we can see if there’s consensus for it.

Thanks

Phil & Yoshi

 

Hums during the meeting:

=B7         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

=B7         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no

=B7         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

=B7         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 




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

 

--_000_787AE7BB302AE849A7480A190F8B933009E4FBB2OPEXCLILMA3corp_-- From nobody Tue Apr 18 08:01:47 2017 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 A2A91128D40 for ; Tue, 18 Apr 2017 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agPlZSbKsUIF for ; Tue, 18 Apr 2017 08:01:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8842126E01 for ; Tue, 18 Apr 2017 08:01:44 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3IF13Ud017021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 08:01:14 -0700 (PDT) To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> Date: Tue, 18 Apr 2017 08:01:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------BF24CAA6F0A8C1980E8C1D43" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:01:47 -0000 This is a multi-part message in MIME format. --------------BF24CAA6F0A8C1980E8C1D43 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Mohammed, I'm sorry, but when you talk about CPEs and network interconnection, you're clearly talking (AFAICT) about using MPTCP as an IP tunnel. That leads to TCP over TCP (where the first is inside the IP packets you're transiting). If that's what you're doing, it is a mistake. Layered congestion control is never beneficial. Joe On 4/18/2017 7:30 AM, mohamed.boucadair@orange.com wrote: > > Hi Joe, > > > > Some comments from my side : > > > > · The main target use case is a CPE that is connected to many > networks (cellular and fixed, typically). Please refer to > https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf > for more business drivers. > > · In order to enhance resilience and increase resource > pooling, the CPE is MPTCP-capable. > > · Because of the lack of MPTCP support at the servers side, a > proxy is introduced at the network side to assisted MPTCP connections > of that CPE. Let’s call this proxy: network-located proxy. > > · Because the network provider does not control hosts that are > located behind a given CPE, a proxy is enabled on the CPE to transform > some TCP connections into MPTCP ones. > > · The CPE is configured with its network-located proxy by > means of DHCP, for example. > > · As mentioned in Phil’s text, the proxies are both under the > control of the operator. In particular, ** both ** the CPE and the > network-proxy support the mechanism detailed hereafter (that is parse > and strip any supplied data before forwarding upstream). > > · There is no tunnel/encapsulation at all. As such there is no > ** TCP over TCP ** scheme. All is about plain transport mode. > > o The CPE forwards MPTCP connections it creates to its configured > network-located proxy. This is exactly the same as with the data plane > of SOCKS. > > o In order to inform its proxy about the ultimate destination IP > address/port while ensuring 0-RTT, an information element is inserted > in the payload of the SYN message of the initial subflow. > > o That information is stripped by the network-located proxy before > forwarding the packet to its ultimate server. > > o In order to strengthen the solution, that information must be > echoed by the proxy in the SYN/ACK as a guard against misconfigured > proxies. > > o The information echoed in the SYN/ACK is used by the CPE to > double check that the network-proxy complies with the solution. If > not, no further MPTCP connection is established with that proxy till a > TTL expires or a new proxy is configured. > > o More details can be found at > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf > > > > > So: > > · “(TCP over TCP), which I already noted in previous > discussion.” WAS NEVER proposed. > > · The proposal does not “interfere with MPTCP’s ability to > silently fall-back to TCP when talking to legacy endpoints”. Legacy > endpoints that receive an MP_CAPABLE option (whether from an > MPTCP-capable client or via a proxy) will ignore it and silently fall > back to TCP. I don’t see a problem here. > > > > Cheers, > > Med > > > > *De :*multipathtcp [mailto:multipathtcp-bounces@ietf.org] *De la part > de* Joe Touch > *Envoyé :* mardi 18 avril 2017 15:30 > *À :* philip.eardley@bt.com; multipathtcp@ietf.org > *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work > > > > Hi, all, > > The description below isn't sufficient to determine whether this work > is either needed or safe. > > My initial conclusion is that this work is either (a) not needed at > all, (b) out of scope, or (c) involves one if not two very bad ideas. > > I have a few questions that determine which of (a), (b), or (c) apply > (below), but I've already commented on my concerns that conclude (c) > *based on previously assuming this was intended as an IP tunnel and > used an option with control plane info in the SYN data) so I won't > repeat them. > > I am curious as to what's really intended here, though. > > Joe > > 1) what is the reason for needing MPTCP work to support proxy-proxy > use? True proxies are applications and can already setup MTCP > themselves. Protocols for operators to configure proxies seem out of > scope here. And if this "proxy" path is really an IP tunnel, that's a > very bad idea (TCP over TCP), which I already noted in previous > discussion. > > 2) what does "using the payload...to transfer a signalling message" > mean? Are you using the MPTCP control plane? or the data plane of the > MPTCP connection? > > 3) I'm not sure I fully understand the details of the optinns, but I > understand that at least one of them puts data in the SYN that is > interpreted as something other than TCP data (i.e., control plane). > That is also a very bad idea - it interferes with MPTCPs ability to > silently fall-back to TCP when talking to legacy endpoints, and the > reasons for not using TCP data as control are discussed in > draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for > draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in > previous discussion. > > On 4/18/2017 1:17 AM, philip.eardley@bt.com > wrote: > > Hi, > > During the MPTCP meeting in Chicago we did several hums about > potential MPTCP proxy work. Our interpretation of these hums is that > we should do a consensus call for the following work: > > -- > MPTCP is now seeing widespread deployment in networks to bond together > two accesses, such as fixed and mobile broadband, by using two MPTCP > proxies, one in the home gateway or Customer Premises Equipment and > one in the network. The WG develops a solution where the proxies are > both under the control of the operator and where it is assumed that > they are not on the default path. The solution is based on using the > payload of an MPTCP packet to transfer a signalling message between > the proxies. It is believed the solution will not require changes to > RFC6824bis. The solution may require a means of configuring set-up > information in the proxies, which would be done in coordination with > other IETF WGs such as DHC. The WG does not develop a mechanism for > the two proxies to discover each other. > > -- > > Please say whether you support, or don’t support, such work – so we > can see if there’s consensus for it. > > Thanks > > Phil & Yoshi > > > > Hums during the meeting: > > · Should the MPTCP WG do any MPTCP proxy work, or do none – > about 2:1 or 3:1 in favour of doing work > > · Should the MPTCP WG do proxy work based on option #1 in > slide 12? Strongly more yes than no > > · Should the MPTCP WG do proxy work based on option #2 in > slide 12? more no than yes > > · Should the MPTCP WG do proxy work based on option #3 in > slide 12? Weak & roughly equal > > Ref: > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf > > We believe the work does not require an update to the MPTCP WG charter. > > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > --------------BF24CAA6F0A8C1980E8C1D43 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Mohammed,

I'm sorry, but when you talk about CPEs and network interconnection, you're clearly talking (AFAICT) about using MPTCP as an IP tunnel.

That leads to TCP over TCP (where the first is inside the IP packets you're transiting).

If that's what you're doing, it is a mistake. Layered congestion control is never beneficial.

Joe


On 4/18/2017 7:30 AM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

Some comments from my side :

 

·         The main target use case is a CPE that is connected to many networks (cellular and fixed, typically). Please refer to https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf for more business drivers.

·         In order to enhance resilience and increase resource pooling, the CPE is MPTCP-capable.

·         Because of the lack of MPTCP support at the servers side, a proxy is introduced at the network side to assisted MPTCP connections of that CPE. Let’s call this proxy: network-located proxy.

·         Because the network provider does not control hosts that are located behind a given CPE, a proxy is enabled on the CPE to transform some TCP connections into MPTCP ones.

·         The CPE is configured with its network-located proxy by means of DHCP, for example.

·         As mentioned in Phil’s text, the proxies are both under the control of the operator. In particular, ** both ** the CPE and the network-proxy support the mechanism detailed hereafter (that is parse and strip any supplied data before forwarding upstream).  

·         There is no tunnel/encapsulation at all. As such there is no ** TCP over TCP ** scheme. All is about plain transport mode.  

o    The CPE forwards MPTCP connections it creates to its configured network-located proxy. This is exactly the same as with the data plane of SOCKS.

o    In order to inform its proxy about the ultimate destination IP address/port while ensuring 0-RTT, an information element is inserted in the payload of the SYN message of the initial subflow.

o    That information is stripped by the network-located proxy before forwarding the packet to its ultimate server.

o    In order to strengthen the solution, that information must be echoed by the proxy in the SYN/ACK as a guard against misconfigured proxies.

o    The information echoed in the SYN/ACK is used by the CPE to double check that the network-proxy complies with the solution. If not, no further MPTCP connection is established with that proxy till a TTL expires or a new proxy is configured.

o    More details can be found at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

 

So:

·         “(TCP over TCP), which I already noted in previous discussion.” WAS NEVER proposed.   

·         The proposal does not “interfere with MPTCP’s ability to silently fall-back to TCP when talking to legacy endpoints”. Legacy endpoints that receive an MP_CAPABLE option (whether from an MPTCP-capable client or via a proxy) will ignore it and silently fall back to TCP. I don’t see a problem here.

 

Cheers,

Med

 

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe Touch
Envoyé : mardi 18 avril 2017 15:30
À : philip.eardley@bt.com; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

 

Hi, all,

The description below isn't sufficient to determine whether this work is either needed or safe.

My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the data plane of the MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in previous discussion.

On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:

Hi,

During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.

--

Please say whether you support, or don’t support, such work – so we can see if there’s consensus for it.

Thanks

Phil & Yoshi

 

Hums during the meeting:

·         Should the MPTCP WG do any MPTCP proxy work, or do none – about 2:1 or 3:1 in favour of doing work

·         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

·         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

·         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf

We believe the work does not require an update to the MPTCP WG charter.

 




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

 


--------------BF24CAA6F0A8C1980E8C1D43-- From nobody Tue Apr 18 08:41:14 2017 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 88B1712EBEA for ; Tue, 18 Apr 2017 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWvudbvmn1kP for ; Tue, 18 Apr 2017 08:41:12 -0700 (PDT) Received: from ndjsvnpf102.ndc.nasa.gov (NDJSVNPF102.ndc.nasa.gov [198.117.1.152]) (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 606A212EBCD for ; Tue, 18 Apr 2017 08:41:12 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.196; helo=ndjsppt102.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf102.ndc.nasa.gov 37B71401337F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492530071; bh=Y5um1NvA1G4jB/RhwtJvWM1iyRYJ+ntAZhvRU2KmmhQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ClXpvEuhs2DFkB6wCmT8gxRQQgqOcawQDdc/eLILaoxXyR47VswwfUnzoFSiuV26a 6xZjRar4QM4OWrn4TvrgEViT3+sKOHjw169djam34Vb+N7X/d0HWMHqecbXLg+BFJi l+XGQZn8KwqqFdlMjVOrTWsEEGafOcyceyQtm9T+0OTbQXdIRyeRm0eRYcav2RTN6J cm0wC2XKFML/G4CtBJs635yAmFVgxZX2A/NIuUJMGcLfjQ+8EEeBDCF8tzDXOtJbL8 VHrFEXvmxFB92AQC9dDUIjlNymX3P7U94hbJDM4GUkso4c5ldZp+1W0PTqPZWEKeLR +WWN+ZL7etCBg== Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndjsvnpf102.ndc.nasa.gov (Postfix) with ESMTP id 37B71401337F; Tue, 18 Apr 2017 10:41:11 -0500 (CDT) Received: from pps.filterd (ndjsppt102.ndc.nasa.gov [127.0.0.1]) by ndjsppt102.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3IFdZts005582; Tue, 18 Apr 2017 10:41:11 -0500 Received: from ndjscht115.ndc.nasa.gov (ndjscht115-pub.ndc.nasa.gov [198.117.1.215]) by ndjsppt102.ndc.nasa.gov with ESMTP id 29wmfjgaa5-15; Tue, 18 Apr 2017 10:41:10 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.32]) by NDJSCHT115.ndc.nasa.gov ([198.117.1.185]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 10:39:29 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: "philip.eardley@bt.com" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuA Date: Tue, 18 Apr 2017 15:39:29 +0000 Message-ID: <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="utf-8" Content-ID: <2DB9D1BB9C6132418FE7FED2E8B2B2E0@mail.nasa.gov> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-18_13:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:41:13 -0000 SGkgUGhpbCwgYWxsLA0KDQpJIGhhdmUgYSBjbGFyaWZ5aW5nIHF1ZXN0aW9uIGFib3V0IGR1YWwg cHJveHkgd29yay4NCg0KRG9lcyB0aGUgZHVhbCBwcm94eSBzb2x1dGlvbiBoYXZlIHRoZSBhYmls aXR5IHRvIHN1cHBvcnQgbmF0aXZlIE1QVENQIGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciwgb3Ig aXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgc29sdXRpb24gZm9yY2VzIHRoZSB0d28gcHJveGll cyB0byBiZWNvbWUgcGFydCBvZiBhIGNvbm5lY3Rpb24gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZSBjbGllbnQgYW5kIHNlcnZlciBhcmUgTVBUQ1AgZW5hYmxlZD8NCg0KVGhhbmtzLA0KTWF0dA0K DQo+IE9uIEFwciAxOCwgMjAxNywgYXQgNDoxNyBBTSwgcGhpbGlwLmVhcmRsZXlAYnQuY29tIHdy b3RlOg0KPiANCj4gSGksDQo+IER1cmluZyB0aGUgTVBUQ1AgbWVldGluZyBpbiBDaGljYWdvIHdl IGRpZCBzZXZlcmFsIGh1bXMgYWJvdXQgcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsuIE91ciBp bnRlcnByZXRhdGlvbiBvZiB0aGVzZSBodW1zIGlzIHRoYXQgd2Ugc2hvdWxkIGRvIGEgY29uc2Vu c3VzIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcgd29yazoNCj4gLS0NCj4gTVBUQ1AgaXMgbm93IHNl ZWluZyB3aWRlc3ByZWFkIGRlcGxveW1lbnQgaW4gbmV0d29ya3MgdG8gYm9uZCB0b2dldGhlciB0 d28gYWNjZXNzZXMsIHN1Y2ggYXMgZml4ZWQgYW5kIG1vYmlsZSBicm9hZGJhbmQsIGJ5IHVzaW5n IHR3byBNUFRDUCBwcm94aWVzLCBvbmUgaW4gdGhlIGhvbWUgZ2F0ZXdheSBvciBDdXN0b21lciBQ cmVtaXNlcyBFcXVpcG1lbnQgYW5kIG9uZSBpbiB0aGUgbmV0d29yay4gVGhlIFdHIGRldmVsb3Bz IGEgc29sdXRpb24gd2hlcmUgdGhlIHByb3hpZXMgYXJlIGJvdGggdW5kZXIgdGhlIGNvbnRyb2wg b2YgdGhlIG9wZXJhdG9yIGFuZCB3aGVyZSBpdCBpcyBhc3N1bWVkIHRoYXQgdGhleSBhcmUgbm90 IG9uIHRoZSBkZWZhdWx0IHBhdGguIFRoZSBzb2x1dGlvbiBpcyBiYXNlZCBvbiB1c2luZyB0aGUg cGF5bG9hZCBvZiBhbiBNUFRDUCBwYWNrZXQgdG8gdHJhbnNmZXIgYSBzaWduYWxsaW5nIG1lc3Nh Z2UgYmV0d2VlbiB0aGUgcHJveGllcy4gSXQgaXMgYmVsaWV2ZWQgdGhlIHNvbHV0aW9uIHdpbGwg bm90IHJlcXVpcmUgY2hhbmdlcyB0byBSRkM2ODI0YmlzLiBUaGUgc29sdXRpb24gbWF5IHJlcXVp cmUgYSBtZWFucyBvZiBjb25maWd1cmluZyBzZXQtdXAgaW5mb3JtYXRpb24gaW4gdGhlIHByb3hp ZXMsIHdoaWNoIHdvdWxkIGJlIGRvbmUgaW4gY29vcmRpbmF0aW9uIHdpdGggb3RoZXIgSUVURiBX R3Mgc3VjaCBhcyBESEMuIFRoZSBXRyBkb2VzIG5vdCBkZXZlbG9wIGEgbWVjaGFuaXNtIGZvciB0 aGUgdHdvIHByb3hpZXMgdG8gZGlzY292ZXIgZWFjaCBvdGhlci4NCj4gLS0NCj4gUGxlYXNlIHNh eSB3aGV0aGVyIHlvdSBzdXBwb3J0LCBvciBkb27igJl0IHN1cHBvcnQsIHN1Y2ggd29yayDigJMg c28gd2UgY2FuIHNlZSBpZiB0aGVyZeKAmXMgY29uc2Vuc3VzIGZvciBpdC4NCj4gDQoNCg== From nobody Tue Apr 18 09:37:33 2017 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 C051E12EC18 for ; Tue, 18 Apr 2017 09:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4LoVx2OExwE for ; Tue, 18 Apr 2017 09:37:25 -0700 (PDT) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24601128E19 for ; Tue, 18 Apr 2017 09:37:24 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.15.2/lip6) with ESMTP id v3IGbERE017986 ; Tue, 18 Apr 2017 18:37:15 +0200 (CEST) X-pt: osiris.lip6.fr Received: from portablesecci3.rsr.lip6.fr (portablesecci3 [132.227.85.235]) (authenticated bits=0) by tibre.lip6.fr (8.15.1/8.14.7) with ESMTPSA id v3IGbENb016298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 18:37:14 +0200 (MEST) From: Stefano Secci Content-Type: multipart/alternative; boundary="Apple-Mail=_034777B7-503E-4601-831B-0F8662D1CA75" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 18 Apr 2017 18:37:12 +0200 References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> To: philip.eardley@bt.com, multipathtcp@ietf.org In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Message-Id: <9271EDB5-9D4A-4AA0-972C-0C08AF0427DC@lip6.fr> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Tue, 18 Apr 2017 18:37:15 +0200 (CEST) X-Scanned-By: MIMEDefang 2.78 on 132.227.60.30 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:37:28 -0000 --Apple-Mail=_034777B7-503E-4601-831B-0F8662D1CA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello WG, I do support the MPTCP proxy work. Cheers, Stefano > Le 18 avr. 2017 =C3=A0 10:17, philip.eardley@bt.com a =C3=A9crit : >=20 > Hi, > During the MPTCP meeting in Chicago we did several hums about = potential MPTCP proxy work. Our interpretation of these hums is that we = should do a consensus call for the following work: > -- > MPTCP is now seeing widespread deployment in networks to bond together = two accesses, such as fixed and mobile broadband, by using two MPTCP = proxies, one in the home gateway or Customer Premises Equipment and one = in the network. The WG develops a solution where the proxies are both = under the control of the operator and where it is assumed that they are = not on the default path. The solution is based on using the payload of = an MPTCP packet to transfer a signalling message between the proxies. It = is believed the solution will not require changes to RFC6824bis. The = solution may require a means of configuring set-up information in the = proxies, which would be done in coordination with other IETF WGs such as = DHC. The WG does not develop a mechanism for the two proxies to discover = each other. > -- > Please say whether you support, or don=E2=80=99t support, such work = =E2=80=93 so we can see if there=E2=80=99s consensus for it. > Thanks > Phil & Yoshi > =20 > Hums during the meeting: > =C2=B7 Should the MPTCP WG do any MPTCP proxy work, or do none = =E2=80=93 about 2:1 or 3:1 in favour of doing work >=20 > =C2=B7 Should the MPTCP WG do proxy work based on option #1 in = slide 12? Strongly more yes than no >=20 > =C2=B7 Should the MPTCP WG do proxy work based on option #2 in = slide 12? more no than yes >=20 > =C2=B7 Should the MPTCP WG do proxy work based on option #3 in = slide 12? Weak & roughly equal >=20 > Ref: = https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01= .pdf = > We believe the work does not require an update to the MPTCP WG = charter. > =20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp = --Apple-Mail=_034777B7-503E-4601-831B-0F8662D1CA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello WG,

I= do support the MPTCP proxy work.

Cheers,
Stefano

Le = 18 avr. 2017 =C3=A0 10:17, philip.eardley@bt.com a =C3=A9crit :

Hi,
During= the MPTCP meeting in Chicago we did several hums about potential MPTCP = proxy work. Our interpretation of these hums is that we should do a = consensus call for the following work:
--
MPTCP is now seeing = widespread deployment in networks to bond together two accesses, such as = fixed and mobile broadband, by using two MPTCP proxies, one in the home = gateway or Customer Premises Equipment and one in the network. The WG = develops a solution where the proxies are both under the control of the = operator and where it is assumed that they are not on the default path. = The solution is based on using the payload of an MPTCP packet to = transfer a signalling message between the proxies. It is believed the = solution will not require changes to RFC6824bis. The solution may = require a means of configuring set-up information in the proxies, which = would be done in coordination with other IETF WGs such as DHC. The WG = does not develop a mechanism for the two proxies to discover each = other.
--
Please say whether you support, or don=E2=80=99t support, = such work =E2=80=93 so we can see if there=E2=80=99s consensus for = it.
Thanks
Phil & Yoshi
 
Hums during the meeting:

=C2=B7         Should the MPTCP WG do any MPTCP proxy work, or do none =E2=80=93= about 2:1 or 3:1 in favour of doing work

=C2=B7         Should the MPTCP WG do proxy work based on option #1 in slide = 12? Strongly more yes than no

=C2=B7         Should the MPTCP WG do proxy work based on option #2 in slide = 12? more no than yes

=C2=B7         Should the MPTCP WG do proxy work based on option #3 in slide = 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sess= a-chairs-01.pdf
We believe = the work does not require an update to the MPTCP WG charter.
 
_______________________________________________
multipathtcp = mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

= --Apple-Mail=_034777B7-503E-4601-831B-0F8662D1CA75-- From nobody Tue Apr 18 11:14:16 2017 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 EEE5C12EB0F for ; Tue, 18 Apr 2017 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 d_c1Z5bOmU_Y for ; Tue, 18 Apr 2017 11:14:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 DC9881293DA for ; Tue, 18 Apr 2017 11:14:12 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3IIEA8N024919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 20:14:10 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3IIEA5T013687; Tue, 18 Apr 2017 20:14:10 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3D2FBD7935; Tue, 18 Apr 2017 20:14:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kVraAfLL4nfl; Tue, 18 Apr 2017 20:14:09 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 474F0D7924; Tue, 18 Apr 2017 20:14:09 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0Xdg-0002ra-Ru; Tue, 18 Apr 2017 20:14:08 +0200 Date: Tue, 18 Apr 2017 20:14:08 +0200 Message-ID: <7ir30plh1r.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Joe Touch Cc: multipathtcp@ietf.org In-Reply-To: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 18 Apr 2017 20:14:10 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 18 Apr 2017 20:14:10 +0200 (CEST) X-Miltered: at korolev with ID 58F65772.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F65772.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F65772.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F65772.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58F65772.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F65772.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:14:15 -0000 > My initial conclusion is that this work is either (a) not needed at all, > (b) out of scope, or (c) involves one if not two very bad ideas. Very well put. I'll add two more points. First, the plain mode draft requires doing some fairly low-level things, such as proxying a SYN and the corresponding SYN-ACK separately. This is not mere transport-layer proxying, and feels way too close to NAT for my comfort. Since in at least some deployments the plain mode proxy is on-path, and cannot be easily circumvented by the client, it will cause all the problems with middleboxes that this particular group is so sadly acquainted with. If we're going to do NAT for IPv6, then perhaps we shouldn't be doing it in this group. Or at all. Second, I don't understand whether this work is specific to MPTCP. As far as I understand, the proposal is about interception proxying at the transport layer, and does not rely on MPTCP: the link between the proxies could very well be using SCTP, or MP-QUIC, or whatever the next fashionable multipath protocol will be. As such, I'm not sure it's in scope. I'm opposed to this work, at least pending further clarification. -- Juliusz From nobody Tue Apr 18 13:09:43 2017 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 6977F127419 for ; Tue, 18 Apr 2017 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSPsatRnr_hb for ; Tue, 18 Apr 2017 13:09:40 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40105.outbound.protection.outlook.com [40.107.4.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83BD127876 for ; Tue, 18 Apr 2017 13:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/IA+8ewlnRy8AvCiYm21r79y7omTo9jalbG/8hBUTU=; b=MR2A06eLt1Ab1496EZaUZqEFNeHqyHGpkWShfjypYo2xNKiJyRcr68foarKgWF+jHmTeRWZWeyGhT04Ek/BiKHmAEkyUWQOFwCVkAAkQB3oIffCNvxnHAPw8KCa0TnvRkgATMaHDpbWkSZgvv5NdxlS+VRvdduz4i5/kDI6z+xA= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 18 Apr 2017 20:09:28 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::a1c4:2e6c:8c63:20f1]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::a1c4:2e6c:8c63:20f1%14]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 20:09:28 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuH+u1jXzvDFKRxmRsHBM53Icbg== Date: Tue, 18 Apr 2017 20:09:28 +0000 Message-ID: <88D8D21B-564E-47DA-B8CF-25F4FD4AAE61@nokia.com> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170403 authentication-results: bt.com; dkim=none (message not signed) header.d=none;bt.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.3] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:F8ppqVMFX7ogdLFA7lOdSpVK4OZDRzgL9PeCoMXWbaeJcjZiE9VyD4+jk5isTZZ6q2wAt9WTfuISin/KTXscqFwGMQRa8QpC51mzH/05vNTitiqIH17cik+kMxdQtYSikz2NIHSZasTpl0we6PoJ+TbGhtxBwj+4xeTcLypAj5RuGGGZfbzwUbaKBus3TQVOz5YI0J9hC4z+aXHKlqkSUTnuGMU8IMs09LhkorutVeBcKQdG5vUuee+l0DmPqG16AWaXwmXHZhvs3t0qPIGM4wRUzguK7t1cOfshOl0mDLl/SKxD3VLCfRLqABlw828Mhm4Fx/DZc6ULkMkWkPrpnA== x-ms-office365-filtering-correlation-id: 3eba8748-b6b6-4ede-d855-08d48696d1ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(146908506813832)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39860400002)(39850400002)(39410400002)(39450400003)(5250100002)(8676002)(7906003)(3280700002)(2900100001)(2501003)(25786009)(66066001)(83506001)(83716003)(6246003)(81166006)(33656002)(38730400002)(229853002)(5660300001)(86362001)(7736002)(82746002)(2906002)(6486002)(102836003)(54356999)(54896002)(6506006)(3846002)(189998001)(6436002)(606005)(236005)(36756003)(50986999)(53936002)(3660700001)(8936002)(6116002)(99286003)(6512007)(6306002)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_88D8D21B564E47DAB8CF25F4FD4AAE61nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 20:09:28.5944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:09:42 -0000 --_000_88D8D21B564E47DAB8CF25F4FD4AAE61nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmdWxseSBzdXBwb3J0IHRoaXMgd29yayBpbiBNUFRDUCBXRy4NCg0KRnJvbTogbXVsdGlwYXRo dGNwIDxtdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJwaGlsaXAu ZWFyZGxleUBidC5jb20iIDxwaGlsaXAuZWFyZGxleUBidC5jb20+DQpEYXRlOiBUdWVzZGF5LCAx OCBBcHJpbCAyMDE3IGF0IDEwOjE3DQpUbzogIm11bHRpcGF0aHRjcEBpZXRmLm9yZyIgPG11bHRp cGF0aHRjcEBpZXRmLm9yZz4NClN1YmplY3Q6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxs IG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCkhpLA0KRHVyaW5nIHRoZSBNUFRDUCBt ZWV0aW5nIGluIENoaWNhZ28gd2UgZGlkIHNldmVyYWwgaHVtcyBhYm91dCBwb3RlbnRpYWwgTVBU Q1AgcHJveHkgd29yay4gT3VyIGludGVycHJldGF0aW9uIG9mIHRoZXNlIGh1bXMgaXMgdGhhdCB3 ZSBzaG91bGQgZG8gYSBjb25zZW5zdXMgY2FsbCBmb3IgdGhlIGZvbGxvd2luZyB3b3JrOg0KLS0N Ck1QVENQIGlzIG5vdyBzZWVpbmcgd2lkZXNwcmVhZCBkZXBsb3ltZW50IGluIG5ldHdvcmtzIHRv IGJvbmQgdG9nZXRoZXIgdHdvIGFjY2Vzc2VzLCBzdWNoIGFzIGZpeGVkIGFuZCBtb2JpbGUgYnJv YWRiYW5kLCBieSB1c2luZyB0d28gTVBUQ1AgcHJveGllcywgb25lIGluIHRoZSBob21lIGdhdGV3 YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IGFuZCBvbmUgaW4gdGhlIG5ldHdvcmsu IFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0aW9uIHdoZXJlIHRoZSBwcm94aWVzIGFyZSBib3RoIHVu ZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQgd2hlcmUgaXQgaXMgYXNzdW1lZCB0 aGF0IHRoZXkgYXJlIG5vdCBvbiB0aGUgZGVmYXVsdCBwYXRoLiBUaGUgc29sdXRpb24gaXMgYmFz ZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1AgcGFja2V0IHRvIHRyYW5zZmVyIGEg c2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hpZXMuIEl0IGlzIGJlbGlldmVkIHRo ZSBzb2x1dGlvbiB3aWxsIG5vdCByZXF1aXJlIGNoYW5nZXMgdG8gUkZDNjgyNGJpcy4gVGhlIHNv bHV0aW9uIG1heSByZXF1aXJlIGEgbWVhbnMgb2YgY29uZmlndXJpbmcgc2V0LXVwIGluZm9ybWF0 aW9uIGluIHRoZSBwcm94aWVzLCB3aGljaCB3b3VsZCBiZSBkb25lIGluIGNvb3JkaW5hdGlvbiB3 aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMgREhDLiBUaGUgV0cgZG9lcyBub3QgZGV2ZWxvcCBh IG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94aWVzIHRvIGRpc2NvdmVyIGVhY2ggb3RoZXIuDQot LQ0KUGxlYXNlIHNheSB3aGV0aGVyIHlvdSBzdXBwb3J0LCBvciBkb27igJl0IHN1cHBvcnQsIHN1 Y2ggd29yayDigJMgc28gd2UgY2FuIHNlZSBpZiB0aGVyZeKAmXMgY29uc2Vuc3VzIGZvciBpdC4N ClRoYW5rcw0KUGhpbCAmIFlvc2hpDQoNCkh1bXMgZHVyaW5nIHRoZSBtZWV0aW5nOg0KDQrigKIg ICAgICAgICBTaG91bGQgdGhlIE1QVENQIFdHIGRvIGFueSBNUFRDUCBwcm94eSB3b3JrLCBvciBk byBub25lIOKAkyBhYm91dCAyOjEgb3IgMzoxIGluIGZhdm91ciBvZiBkb2luZyB3b3JrDQoNCuKA oiAgICAgICAgIFNob3VsZCB0aGUgTVBUQ1AgV0cgZG8gcHJveHkgd29yayBiYXNlZCBvbiBvcHRp b24gIzEgaW4gc2xpZGUgMTI/IFN0cm9uZ2x5IG1vcmUgeWVzIHRoYW4gbm8NCg0K4oCiICAgICAg ICAgU2hvdWxkIHRoZSBNUFRDUCBXRyBkbyBwcm94eSB3b3JrIGJhc2VkIG9uIG9wdGlvbiAjMiBp biBzbGlkZSAxMj8gbW9yZSBubyB0aGFuIHllcw0KDQrigKIgICAgICAgICBTaG91bGQgdGhlIE1Q VENQIFdHIGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMzIGluIHNsaWRlIDEyPyBXZWFr ICYgcm91Z2hseSBlcXVhbA0KUmVmOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 OC9zbGlkZXMvc2xpZGVzLTk4LW1wdGNwLXNlc3NhLWNoYWlycy0wMS5wZGYNCldlIGJlbGlldmUg dGhlIHdvcmsgZG9lcyBub3QgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhlIE1QVENQIFdHIGNoYXJ0 ZXIuDQoNCg== --_000_88D8D21B564E47DAB8CF25F4FD4AAE61nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <88DCBEBD1120F04FAD9C83CD57FD7ACB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tNjA0Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm02MDQ2NzYz MTYzMDY5NzM2MzE1bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm02MDQ2NzYzMTYzMDY5NzM2MzE1bXNv bGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzYwNDY3NjMxNjMwNjk3MzYzMTVtc29s aXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JIGZ1bGx5IHN1cHBvcnQgdGhpcyB3b3JrIGluIE1QVENQIFdHLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+bXVs dGlwYXRodGNwICZsdDttdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mICZxdW90O3BoaWxpcC5lYXJkbGV5QGJ0LmNvbSZxdW90OyAmbHQ7cGhpbGlwLmVhcmRsZXlA YnQuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAxOCBBcHJpbCAyMDE3IGF0IDEw OjE3PGJyPg0KPGI+VG86IDwvYj4mcXVvdDttdWx0aXBhdGh0Y3BAaWV0Zi5vcmcmcXVvdDsgJmx0 O211bHRpcGF0aHRjcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W211bHRpcGF0 aHRjcF0gQ29uc2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcms8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkR1cmlu ZyB0aGUgTVBUQ1AgbWVldGluZyBpbiBDaGljYWdvIHdlIGRpZCBzZXZlcmFsIGh1bXMgYWJvdXQg cG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsuIE91ciBpbnRlcnByZXRhdGlvbiBvZiB0aGVzZSBo dW1zIGlzIHRoYXQgd2Ugc2hvdWxkIGRvIGEgY29uc2Vuc3VzIGNhbGwgZm9yIHRoZSBmb2xsb3dp bmcgd29yazo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KLS08YnI+DQpNUFRDUCBpcyBub3cgc2VlaW5nIHdpZGVzcHJlYWQgZGVwbG95 bWVudCBpbiBuZXR3b3JrcyB0byBib25kIHRvZ2V0aGVyIHR3byBhY2Nlc3Nlcywgc3VjaCBhcyBm aXhlZCBhbmQgbW9iaWxlIGJyb2FkYmFuZCwgYnkgdXNpbmcgdHdvIE1QVENQIHByb3hpZXMsIG9u ZSBpbiB0aGUgaG9tZSBnYXRld2F5IG9yIEN1c3RvbWVyIFByZW1pc2VzIEVxdWlwbWVudCBhbmQg b25lIGluIHRoZSBuZXR3b3JrLiBUaGUgV0cgZGV2ZWxvcHMgYSBzb2x1dGlvbiB3aGVyZQ0KIHRo ZSBwcm94aWVzIGFyZSBib3RoIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQg d2hlcmUgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZXkgYXJlIG5vdCBvbiB0aGUgZGVmYXVsdCBwYXRo LiBUaGUgc29sdXRpb24gaXMgYmFzZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1Ag cGFja2V0IHRvIHRyYW5zZmVyIGEgc2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hp ZXMuIEl0IGlzIGJlbGlldmVkIHRoZSBzb2x1dGlvbg0KIHdpbGwgbm90IHJlcXVpcmUgY2hhbmdl cyB0byBSRkM2ODI0YmlzLiBUaGUgc29sdXRpb24gbWF5IHJlcXVpcmUgYSBtZWFucyBvZiBjb25m aWd1cmluZyBzZXQtdXAgaW5mb3JtYXRpb24gaW4gdGhlIHByb3hpZXMsIHdoaWNoIHdvdWxkIGJl IGRvbmUgaW4gY29vcmRpbmF0aW9uIHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcyBESEMuIFRo ZSBXRyBkb2VzIG5vdCBkZXZlbG9wIGEgbWVjaGFuaXNtIGZvciB0aGUgdHdvIHByb3hpZXMgdG8g ZGlzY292ZXINCiBlYWNoIG90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQotLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpQbGVhc2Ugc2F5IHdoZXRoZXIgeW91IHN1 cHBvcnQsIG9yIGRvbuKAmXQgc3VwcG9ydCwgc3VjaCB3b3JrIOKAkyBzbyB3ZSBjYW4gc2VlIGlm IHRoZXJl4oCZcyBjb25zZW5zdXMgZm9yIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpUaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KUGhpbCAmYW1wOyBZb3No aTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KSHVtcyBkdXJpbmcgdGhlIG1lZXRpbmc6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0ibTYwNDY3NjMxNjMwNjk3MzYzMTVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOIj5TaG91bGQgdGhlIE1QVENQIFdHIGRvIGFueSBNUFRDUCBwcm94eSB3b3JrLCBv ciBkbyBub25lIOKAkyBhYm91dCAyOjEgb3IgMzoxIGluIGZhdm91ciBvZiBkb2luZyB3b3JrPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02MDQ2NzYzMTYzMDY5NzM2MzE1bXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+U2hvdWxkIHRoZSBNUFRDUCBXRyBkbyBw cm94eSB3b3JrIGJhc2VkIG9uIG9wdGlvbiAjMSBpbiBzbGlkZSAxMj8gU3Ryb25nbHkgbW9yZSB5 ZXMgdGhhbiBubzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjA0Njc2MzE2MzA2 OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iPlNob3VsZCB0aGUg TVBUQ1AgV0cgZG8gcHJveHkgd29yayBiYXNlZCBvbiBvcHRpb24gIzIgaW4gc2xpZGUgMTI/IG1v cmUgbm8gdGhhbiB5ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTYwNDY3NjMx NjMwNjk3MzYzMTVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIj5TaG91bGQg dGhlIE1QVENQIFdHIGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMzIGluIHNsaWRlIDEy PyBXZWFrICZhbXA7IHJvdWdobHkgZXF1YWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOIj5SZWY6 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlk ZXMtOTgtbXB0Y3Atc2Vzc2EtY2hhaXJzLTAxLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNz YS1jaGFpcnMtMDEucGRmPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iPldlIGJlbGlldmUg dGhlIHdvcmsgZG9lcyBub3QgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhlIE1QVENQIFdHIGNoYXJ0 ZXIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_88D8D21B564E47DAB8CF25F4FD4AAE61nokiacom_-- From nobody Tue Apr 18 13:44:24 2017 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 B8AC31200FC for ; Tue, 18 Apr 2017 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnb4HyaFnGl3 for ; Tue, 18 Apr 2017 13:44:21 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE8E131477 for ; Tue, 18 Apr 2017 13:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cBcicA5dewFY9XmcUkX3le2S8QDz1YXvt200+qncgnY=; b=Iig3LKreLcbDKTY4ftzEeIrVjoz99CIyitf306jurd6ue5SKx+WPaWra9i12EaGGkP6oAAIk1n6Nh+ngsYMcXOno4clMcH+V/bCXN26u7+no5+1SXU7FQSFaDpFfsTJPRf8jb85kcvkPDa3ZkukPMkNp8ReWjS57DRVgC283GUs= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 18 Apr 2017 20:44:17 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::a1c4:2e6c:8c63:20f1]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::a1c4:2e6c:8c63:20f1%14]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 20:44:17 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" , "philip.eardley@bt.com" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAAARbgIA= Date: Tue, 18 Apr 2017 20:44:17 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> In-Reply-To: <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170403 authentication-results: nasa.gov; dkim=none (message not signed) header.d=none;nasa.gov; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.3] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:Qnet3EkT9OCF3mOMvZngM9zhJPMVYXIssM7QN+2IQ+tsPFHvLN9913eYua2kioMdNyO3vxrnAx4O0kK22a9IFO/XBlnQH4ylaegxASJgoC+ukTqB+QJ4yBGV6JGKFlYBgQiF56nE2ia5rJO7pu8i09Vrc0Ao54DkjQUzaT51QR5WjQcdty1t9+hOhaure4lcxN6FU2uZjqTTzJZlOEZ94CdMmpSCa1xqdLhA0lVoETAgST9y7FTGZ38CcyiudsLlo9WJiqjctn/1q5ZL/3Gend00nzoPYhiGCVj0/RaUhOt+nMtKhZiFXVaxrQrHL8omer36EaeZlvvilV1+NfsDWA== x-ms-office365-filtering-correlation-id: bf2cd0be-d0ab-4b7b-43e1-08d4869bae9d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(146908506813832)(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(377454003)(24454002)(33656002)(53936002)(6306002)(6512007)(99286003)(36756003)(2906002)(50986999)(76176999)(54356999)(3660700001)(6506006)(6436002)(6486002)(8656002)(3280700002)(2501003)(102836003)(6116002)(3846002)(229853002)(83506001)(25786009)(53546009)(82746002)(5250100002)(7736002)(305945005)(66066001)(2950100002)(5660300001)(189998001)(8676002)(81166006)(2900100001)(6246003)(38730400002)(86362001)(8936002)(4326008)(83716003)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0B48E2F0719B7743A1F127BD45CFEA47@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 20:44:17.2276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:44:23 -0000 SWYgdGhlIGNsaWVudCBhbmQgc2VydmVyIHN1cHBvcnQgbXB0Y3AgdGhlIHByb3hpZXMgc2hvdWxk IG5vdCBlbmQgdXAgaW4gdGhlIHBhdGgsIHNvIGl0IHdpbGwgYmUgdHJhbnNwYXJlbnQgRTJFDQoN Ck9uIDE4LzA0LzIwMTcsIDE3OjM5LCAibXVsdGlwYXRodGNwIG9uIGJlaGFsZiBvZiBTYXJnZW50 LCBNYXR0aGV3IFQuIChHUkMtTENBMClbUGVlcmxlc3MgVGVjaG5vbG9naWVzXSIgPG11bHRpcGF0 aHRjcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXR0aGV3LnQuc2FyZ2VudEBuYXNh Lmdvdj4gd3JvdGU6DQoNCiAgICBIaSBQaGlsLCBhbGwsDQogICAgDQogICAgSSBoYXZlIGEgY2xh cmlmeWluZyBxdWVzdGlvbiBhYm91dCBkdWFsIHByb3h5IHdvcmsuDQogICAgDQogICAgRG9lcyB0 aGUgZHVhbCBwcm94eSBzb2x1dGlvbiBoYXZlIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbmF0aXZl IE1QVENQIGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciwgb3IgaXMgdGhlIGFzc3VtcHRpb24gdGhh dCB0aGUgc29sdXRpb24gZm9yY2VzIHRoZSB0d28gcHJveGllcyB0byBiZWNvbWUgcGFydCBvZiBh IGNvbm5lY3Rpb24gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBjbGllbnQgYW5kIHNlcnZlciBh cmUgTVBUQ1AgZW5hYmxlZD8NCiAgICANCiAgICBUaGFua3MsDQogICAgTWF0dA0KICAgIA0KICAg ID4gT24gQXByIDE4LCAyMDE3LCBhdCA0OjE3IEFNLCBwaGlsaXAuZWFyZGxleUBidC5jb20gd3Jv dGU6DQogICAgPiANCiAgICA+IEhpLA0KICAgID4gRHVyaW5nIHRoZSBNUFRDUCBtZWV0aW5nIGlu IENoaWNhZ28gd2UgZGlkIHNldmVyYWwgaHVtcyBhYm91dCBwb3RlbnRpYWwgTVBUQ1AgcHJveHkg d29yay4gT3VyIGludGVycHJldGF0aW9uIG9mIHRoZXNlIGh1bXMgaXMgdGhhdCB3ZSBzaG91bGQg ZG8gYSBjb25zZW5zdXMgY2FsbCBmb3IgdGhlIGZvbGxvd2luZyB3b3JrOg0KICAgID4gLS0NCiAg ICA+IE1QVENQIGlzIG5vdyBzZWVpbmcgd2lkZXNwcmVhZCBkZXBsb3ltZW50IGluIG5ldHdvcmtz IHRvIGJvbmQgdG9nZXRoZXIgdHdvIGFjY2Vzc2VzLCBzdWNoIGFzIGZpeGVkIGFuZCBtb2JpbGUg YnJvYWRiYW5kLCBieSB1c2luZyB0d28gTVBUQ1AgcHJveGllcywgb25lIGluIHRoZSBob21lIGdh dGV3YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IGFuZCBvbmUgaW4gdGhlIG5ldHdv cmsuIFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0aW9uIHdoZXJlIHRoZSBwcm94aWVzIGFyZSBib3Ro IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQgd2hlcmUgaXQgaXMgYXNzdW1l ZCB0aGF0IHRoZXkgYXJlIG5vdCBvbiB0aGUgZGVmYXVsdCBwYXRoLiBUaGUgc29sdXRpb24gaXMg YmFzZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1AgcGFja2V0IHRvIHRyYW5zZmVy IGEgc2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hpZXMuIEl0IGlzIGJlbGlldmVk IHRoZSBzb2x1dGlvbiB3aWxsIG5vdCByZXF1aXJlIGNoYW5nZXMgdG8gUkZDNjgyNGJpcy4gVGhl IHNvbHV0aW9uIG1heSByZXF1aXJlIGEgbWVhbnMgb2YgY29uZmlndXJpbmcgc2V0LXVwIGluZm9y bWF0aW9uIGluIHRoZSBwcm94aWVzLCB3aGljaCB3b3VsZCBiZSBkb25lIGluIGNvb3JkaW5hdGlv biB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMgREhDLiBUaGUgV0cgZG9lcyBub3QgZGV2ZWxv cCBhIG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94aWVzIHRvIGRpc2NvdmVyIGVhY2ggb3RoZXIu DQogICAgPiAtLQ0KICAgID4gUGxlYXNlIHNheSB3aGV0aGVyIHlvdSBzdXBwb3J0LCBvciBkb27i gJl0IHN1cHBvcnQsIHN1Y2ggd29yayDigJMgc28gd2UgY2FuIHNlZSBpZiB0aGVyZeKAmXMgY29u c2Vuc3VzIGZvciBpdC4NCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdA0K ICAgIG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXVsdGlwYXRodGNwDQogICAgDQoNCg== From nobody Tue Apr 18 14:44:54 2017 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 D2D94131482 for ; Tue, 18 Apr 2017 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDYev67pR-IX for ; Tue, 18 Apr 2017 14:44:50 -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 17590131480 for ; Tue, 18 Apr 2017 14:44:49 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 62C4F27968A for ; Wed, 19 Apr 2017 06:44:47 +0900 (JST) Received: by mail-oi0-f47.google.com with SMTP id x184so7445803oia.1 for ; Tue, 18 Apr 2017 14:44:47 -0700 (PDT) X-Gm-Message-State: AN3rC/66P78CZttDuc/hpMGJbB0vVjV9XSfW6ODu7QQhj/gdbPCz3Aq1 wbj/PSKaBE4F0jvD3JW4FoRGHWiJDQ== X-Received: by 10.157.52.73 with SMTP id v67mr9613526otb.161.1492551885926; Tue, 18 Apr 2017 14:44:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Tue, 18 Apr 2017 14:44:45 -0700 (PDT) In-Reply-To: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> From: Yoshifumi Nishida Date: Tue, 18 Apr 2017 14:44:45 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: multipathtcp Content-Type: multipart/alternative; boundary=001a11417706f83be6054d77d047 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:44:53 -0000 --001a11417706f83be6054d77d047 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joe, It's not tunneling. The proxy converts a tcp connection into a mptcp connection and converts it back to a tcp connection (if necessary) So, it won't be tcp over tcp. MPTCP will convey control data for application (proxy) in payload. But, MPTCP of course doesn't care the contents of payload. It just carries data and app will parse the data. Putting data in SYN is trying to reduce the latency and no other meaning as far as I understand. -- Yoshi On Tue, Apr 18, 2017 at 6:29 AM, Joe Touch wrote: > Hi, all, > > The description below isn't sufficient to determine whether this work is > either needed or safe. > > My initial conclusion is that this work is either (a) not needed at all, > (b) out of scope, or (c) involves one if not two very bad ideas. > > I have a few questions that determine which of (a), (b), or (c) apply > (below), but I've already commented on my concerns that conclude (c) *bas= ed > on previously assuming this was intended as an IP tunnel and used an opti= on > with control plane info in the SYN data) so I won't repeat them. > > I am curious as to what's really intended here, though. > > Joe > > 1) what is the reason for needing MPTCP work to support proxy-proxy use? > True proxies are applications and can already setup MTCP themselves. > Protocols for operators to configure proxies seem out of scope here. And = if > this "proxy" path is really an IP tunnel, that's a very bad idea (TCP ove= r > TCP), which I already noted in previous discussion. > > 2) what does "using the payload...to transfer a signalling message" mean? > Are you using the MPTCP control plane? or the data plane of the MPTCP > connection? > > 3) I'm not sure I fully understand the details of the optinns, but I > understand that at least one of them puts data in the SYN that is > interpreted as something other than TCP data (i.e., control plane). That = is > also a very bad idea - it interferes with MPTCPs ability to silently > fall-back to TCP when talking to legacy endpoints, and the reasons for no= t > using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Secti= on > 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I > also already noted in previous discussion. > On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote: > > Hi, > > During the MPTCP meeting in Chicago we did several hums about potential > MPTCP proxy work. Our interpretation of these hums is that we should do a > consensus call for the following work: > > -- > MPTCP is now seeing widespread deployment in networks to bond together tw= o > accesses, such as fixed and mobile broadband, by using two MPTCP proxies, > one in the home gateway or Customer Premises Equipment and one in the > network. The WG develops a solution where the proxies are both under the > control of the operator and where it is assumed that they are not on the > default path. The solution is based on using the payload of an MPTCP pack= et > to transfer a signalling message between the proxies. It is believed the > solution will not require changes to RFC6824bis. The solution may require= a > means of configuring set-up information in the proxies, which would be do= ne > in coordination with other IETF WGs such as DHC. The WG does not develop = a > mechanism for the two proxies to discover each other. > > -- > > Please say whether you support, or don=E2=80=99t support, such work =E2= =80=93 so we can > see if there=E2=80=99s consensus for it. > > Thanks > > Phil & Yoshi > > > > Hums during the meeting: > > =C2=B7 Should the MPTCP WG do any MPTCP proxy work, or do none = =E2=80=93 about > 2:1 or 3:1 in favour of doing work > > =C2=B7 Should the MPTCP WG do proxy work based on option #1 in sl= ide > 12? Strongly more yes than no > > =C2=B7 Should the MPTCP WG do proxy work based on option #2 in sl= ide > 12? more no than yes > > =C2=B7 Should the MPTCP WG do proxy work based on option #3 in sl= ide > 12? Weak & roughly equal > > Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp- > sessa-chairs-01.pdf > > We believe the work does not require an update to the MPTCP WG charter. > > > > > _______________________________________________ > multipathtcp mailing listmultipathtcp@ietf.orghttps://www.ietf.org/mailma= n/listinfo/multipathtcp > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --001a11417706f83be6054d77d047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

It's not tunneling. The pro= xy converts a tcp connection into a mptcp connection and converts it back t= o a tcp connection (if necessary)
So, it won't be tcp over tc= p.

MPTCP will convey control data for application = (proxy) in payload. But, MPTCP of course doesn't care the contents of p= ayload.=C2=A0
It just carries data and app will parse the data. P= utting data in SYN is trying to reduce the latency and no other meaning as = far as I understand.

--
Yoshi
=

On Tue, Apr 18, 2= 017 at 6:29 AM, Joe Touch <touch@isi.edu> wrote:
=20 =20 =20

Hi, all,

The description below isn't sufficient to determine whether this work is either needed or safe.

My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is= really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the dat= a plane of the MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also alrea= dy noted in previous discussion.

On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:
=20 =20 =20

Hi,

During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:<= /u>

--
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.

--

Please say whether you support, or don=E2=80=99t support, such work =E2= =80=93 so we can see if there=E2=80=99s consensus for it.

Thanks

Phil & Yoshi

=C2=A0

Hums during the meeting:

= =C2=B7=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the MPTCP WG do any MPTCP proxy work, or do none =E2=80=93 about 2:1 or 3:1 in favour of doing = work

= =C2=B7=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

= =C2=B7=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes=

= =C2=B7=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-= chairs-01.pdf

We believe the work does n= ot require an update to the MPTCP WG charter.

=C2=A0



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


_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipa= thtcp


--001a11417706f83be6054d77d047-- From nobody Tue Apr 18 14:56:32 2017 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 8D71513147A for ; Tue, 18 Apr 2017 14:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04PwHYl_jIOH for ; Tue, 18 Apr 2017 14:56:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB9A129485 for ; Tue, 18 Apr 2017 14:56:30 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3ILuHde006091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 14:56:17 -0700 (PDT) To: Yoshifumi Nishida References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> Cc: multipathtcp From: Joe Touch Message-ID: <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> Date: Tue, 18 Apr 2017 14:56:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3ILuHde006091 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:56:31 -0000 On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote: > Hi Joe, > > It's not tunneling. The proxy converts a tcp connection into a mptcp > connection and converts it back to a tcp connection (if necessary) > So, it won't be tcp over tcp. OK, but that's not proxying either. That's (at best) connection hijacking. > MPTCP will convey control data for application (proxy) in payload. > But, MPTCP of course doesn't care the contents of payload. > It just carries data and app will parse the data. Putting data in SYN > is trying to reduce the latency and no other meaning as far as I > understand. MPTCP is TCP. Putting the data in the SYN of a TCP connection is hazardous. The goal is irrelevant. I thought we went through this all when MPTCP was created, but it appears insufficiently so. Joe From nobody Tue Apr 18 15:06:28 2017 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 1E3BB13149A for ; Tue, 18 Apr 2017 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_8t7WOm_S3R for ; Tue, 18 Apr 2017 15:06:25 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 49B8C12EC3F for ; Tue, 18 Apr 2017 15:06:25 -0700 (PDT) X-AuditID: c6180641-42bff700000058cf-e9-58f647836b67 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 0A.E2.22735.38746F85; Tue, 18 Apr 2017 19:06:13 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0339.000; Tue, 18 Apr 2017 18:06:21 -0400 From: David Allan I To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuH+u1jXzvDFKRxmRsHBM53IcbqHLrr7w Date: Tue, 18 Apr 2017 22:06:22 +0000 Message-ID: References: <88D8D21B-564E-47DA-B8CF-25F4FD4AAE61@nokia.com> In-Reply-To: <88D8D21B-564E-47DA-B8CF-25F4FD4AAE61@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C68D5BB5Ceusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrG6r+7cIg1UbLS0+r77OZrFs7QpG ByaPti+TmTyWLPnJFMAUxWWTkpqTWZZapG+XwJVx7KJpwZzyilVLlrM0MDaUdDFyckgImEhs +LaBpYuRi0NIYAOjRP+uxYwQznJGic/X+thBqtgEDCT2/P/CCGKLCKRJ7FnyhxnEFhbwkDiw 5C0rRNxT4tOru1A1RhIHDh5lA7FZBFQlHq5YCxbnFfCVOPPnNli9kICNxJFFU8DinAK2Euc3 HgOrZxQQk/h+ag0TiM0sIC5x68l8JohLBSSW7DnPDGGLSrx8/I8VwlaSmLT0HCtEfb7E5f53 rBC7BCVOznzCMoFReBaSUbOQlM1CUjaLkQMorimxfpc+RImixJTuh+wQtoZE65y57MjiCxjZ VzFylBYX5OSmGxluYgTGyDEJNscdjHt7PQ8xCnAwKvHwLnj8NUKINbGsuDL3EKMEB7OSCO/5 pm8RQrwpiZVVqUX58UWlOanFhxilOViUxHnflV+IEBJITyxJzU5NLUgtgskycXBKNTCueNdt 0OZSo2OmuvNRR8DC4hudlb/Va//s+L97/hMm+Xn7+9Iur6o+H7nn95UfHas0QrQ0dbd6vo3S 2m7pwvj3yUyulleGzNtVdS0+vNw3/dGWyTmx3sK8Fp9fnHzqHzux+u0JA6ltrkcZ/39huNd0 f3dET82m4OP8Cr3L9lQtXS29mqV7CXOLEktxRqKhFnNRcSIAwW+uPI0CAAA= Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:06:27 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C68D5BB5Ceusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uc2lkZXIgdGhpcyBlbWFpbCB0byBiZSBhIGh1bSBpbiBmYXZvdXIgb2YgdGhlIHdvcmsuDQoN CkNoZWVycyBEDQoNCkZyb206IG11bHRpcGF0aHRjcCA8bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m ICJwaGlsaXAuZWFyZGxleUBidC5jb208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4iIDxw aGlsaXAuZWFyZGxleUBidC5jb208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4+DQpEYXRl OiBUdWVzZGF5LCAxOCBBcHJpbCAyMDE3IGF0IDEwOjE3DQpUbzogIm11bHRpcGF0aHRjcEBpZXRm Lm9yZzxtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnPiIgPG11bHRpcGF0aHRjcEBpZXRmLm9y ZzxtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnPj4NClN1YmplY3Q6IFttdWx0aXBhdGh0Y3Bd IENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCkhpLA0KRHVy aW5nIHRoZSBNUFRDUCBtZWV0aW5nIGluIENoaWNhZ28gd2UgZGlkIHNldmVyYWwgaHVtcyBhYm91 dCBwb3RlbnRpYWwgTVBUQ1AgcHJveHkgd29yay4gT3VyIGludGVycHJldGF0aW9uIG9mIHRoZXNl IGh1bXMgaXMgdGhhdCB3ZSBzaG91bGQgZG8gYSBjb25zZW5zdXMgY2FsbCBmb3IgdGhlIGZvbGxv d2luZyB3b3JrOg0KLS0NCk1QVENQIGlzIG5vdyBzZWVpbmcgd2lkZXNwcmVhZCBkZXBsb3ltZW50 IGluIG5ldHdvcmtzIHRvIGJvbmQgdG9nZXRoZXIgdHdvIGFjY2Vzc2VzLCBzdWNoIGFzIGZpeGVk IGFuZCBtb2JpbGUgYnJvYWRiYW5kLCBieSB1c2luZyB0d28gTVBUQ1AgcHJveGllcywgb25lIGlu IHRoZSBob21lIGdhdGV3YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IGFuZCBvbmUg aW4gdGhlIG5ldHdvcmsuIFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0aW9uIHdoZXJlIHRoZSBwcm94 aWVzIGFyZSBib3RoIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQgd2hlcmUg aXQgaXMgYXNzdW1lZCB0aGF0IHRoZXkgYXJlIG5vdCBvbiB0aGUgZGVmYXVsdCBwYXRoLiBUaGUg c29sdXRpb24gaXMgYmFzZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1AgcGFja2V0 IHRvIHRyYW5zZmVyIGEgc2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hpZXMuIEl0 IGlzIGJlbGlldmVkIHRoZSBzb2x1dGlvbiB3aWxsIG5vdCByZXF1aXJlIGNoYW5nZXMgdG8gUkZD NjgyNGJpcy4gVGhlIHNvbHV0aW9uIG1heSByZXF1aXJlIGEgbWVhbnMgb2YgY29uZmlndXJpbmcg c2V0LXVwIGluZm9ybWF0aW9uIGluIHRoZSBwcm94aWVzLCB3aGljaCB3b3VsZCBiZSBkb25lIGlu IGNvb3JkaW5hdGlvbiB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMgREhDLiBUaGUgV0cgZG9l cyBub3QgZGV2ZWxvcCBhIG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94aWVzIHRvIGRpc2NvdmVy IGVhY2ggb3RoZXIuDQotLQ0KUGxlYXNlIHNheSB3aGV0aGVyIHlvdSBzdXBwb3J0LCBvciBkb27i gJl0IHN1cHBvcnQsIHN1Y2ggd29yayDigJMgc28gd2UgY2FuIHNlZSBpZiB0aGVyZeKAmXMgY29u c2Vuc3VzIGZvciBpdC4NClRoYW5rcw0KUGhpbCAmIFlvc2hpDQoNCkh1bXMgZHVyaW5nIHRoZSBt ZWV0aW5nOg0KDQrigKIgICAgICAgICBTaG91bGQgdGhlIE1QVENQIFdHIGRvIGFueSBNUFRDUCBw cm94eSB3b3JrLCBvciBkbyBub25lIOKAkyBhYm91dCAyOjEgb3IgMzoxIGluIGZhdm91ciBvZiBk b2luZyB3b3JrDQoNCuKAoiAgICAgICAgIFNob3VsZCB0aGUgTVBUQ1AgV0cgZG8gcHJveHkgd29y ayBiYXNlZCBvbiBvcHRpb24gIzEgaW4gc2xpZGUgMTI/IFN0cm9uZ2x5IG1vcmUgeWVzIHRoYW4g bm8NCg0K4oCiICAgICAgICAgU2hvdWxkIHRoZSBNUFRDUCBXRyBkbyBwcm94eSB3b3JrIGJhc2Vk IG9uIG9wdGlvbiAjMiBpbiBzbGlkZSAxMj8gbW9yZSBubyB0aGFuIHllcw0KDQrigKIgICAgICAg ICBTaG91bGQgdGhlIE1QVENQIFdHIGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMzIGlu IHNsaWRlIDEyPyBXZWFrICYgcm91Z2hseSBlcXVhbA0KUmVmOiBodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LW1wdGNwLXNlc3NhLWNoYWlycy0wMS5w ZGYNCldlIGJlbGlldmUgdGhlIHdvcmsgZG9lcyBub3QgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhl IE1QVENQIFdHIGNoYXJ0ZXIuDQoNCg== --_000_E6C17D2345AC7A45B7D054D407AA205C68D5BB5Ceusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm02MDQ2NzYzMTYz MDY5NzM2MzE1bXNvbGlzdHBhcmFncmFwaCwgbGkubTYwNDY3NjMxNjMwNjk3MzYzMTVtc29saXN0 cGFyYWdyYXBoLCBkaXYubTYwNDY3NjMxNjMwNjk3MzYzMTVtc29saXN0cGFyYWdyYXBoDQoJe21z by1zdHlsZS1uYW1lOm1fNjA0Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbnNpZGVyIHRoaXMgZW1haWwgdG8gYmUgYSBodW0g aW4gZmF2b3VyIG9mIHRoZSB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMgRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPm11bHRpcGF0aHRjcCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnIj5tdWx0aXBhdGh0 Y3AtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDs8YSBocmVmPSJt YWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxleUBidC5jb208L2E+JnF1 b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20iPnBoaWxpcC5l YXJkbGV5QGJ0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDE4IEFwcmls IDIwMTcgYXQgMTA6MTc8YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzptdWx0 aXBhdGh0Y3BAaWV0Zi5vcmciPm11bHRpcGF0aHRjcEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptdWx0aXBhdGh0Y3BAaWV0Zi5vcmciPm11bHRpcGF0aHRjcEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBj YWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4t R0IiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCjxzcGFuIGxhbmc9IkVOLUdCIj5EdXJpbmcgdGhlIE1QVENQIG1lZXRp bmcgaW4gQ2hpY2FnbyB3ZSBkaWQgc2V2ZXJhbCBodW1zIGFib3V0IHBvdGVudGlhbCBNUFRDUCBw cm94eSB3b3JrLiBPdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlc2UgaHVtcyBpcyB0aGF0IHdlIHNo b3VsZCBkbyBhIGNvbnNlbnN1cyBjYWxsIGZvciB0aGUgZm9sbG93aW5nIHdvcms6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gbGFuZz0iRU4tR0IiPi0tPGJyPg0KTVBUQ1AgaXMgbm93IHNlZWluZyB3aWRlc3ByZWFk IGRlcGxveW1lbnQgaW4gbmV0d29ya3MgdG8gYm9uZCB0b2dldGhlciB0d28gYWNjZXNzZXMsIHN1 Y2ggYXMgZml4ZWQgYW5kIG1vYmlsZSBicm9hZGJhbmQsIGJ5IHVzaW5nIHR3byBNUFRDUCBwcm94 aWVzLCBvbmUgaW4gdGhlIGhvbWUgZ2F0ZXdheSBvciBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1l bnQgYW5kIG9uZSBpbiB0aGUgbmV0d29yay4gVGhlIFdHIGRldmVsb3BzIGEgc29sdXRpb24gd2hl cmUNCiB0aGUgcHJveGllcyBhcmUgYm90aCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgb3BlcmF0 b3IgYW5kIHdoZXJlIGl0IGlzIGFzc3VtZWQgdGhhdCB0aGV5IGFyZSBub3Qgb24gdGhlIGRlZmF1 bHQgcGF0aC4gVGhlIHNvbHV0aW9uIGlzIGJhc2VkIG9uIHVzaW5nIHRoZSBwYXlsb2FkIG9mIGFu IE1QVENQIHBhY2tldCB0byB0cmFuc2ZlciBhIHNpZ25hbGxpbmcgbWVzc2FnZSBiZXR3ZWVuIHRo ZSBwcm94aWVzLiBJdCBpcyBiZWxpZXZlZCB0aGUgc29sdXRpb24NCiB3aWxsIG5vdCByZXF1aXJl IGNoYW5nZXMgdG8gUkZDNjgyNGJpcy4gVGhlIHNvbHV0aW9uIG1heSByZXF1aXJlIGEgbWVhbnMg b2YgY29uZmlndXJpbmcgc2V0LXVwIGluZm9ybWF0aW9uIGluIHRoZSBwcm94aWVzLCB3aGljaCB3 b3VsZCBiZSBkb25lIGluIGNvb3JkaW5hdGlvbiB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMg REhDLiBUaGUgV0cgZG9lcyBub3QgZGV2ZWxvcCBhIG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94 aWVzIHRvIGRpc2NvdmVyDQogZWFjaCBvdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+ LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+UGxlYXNlIHNheSB3aGV0aGVyIHlvdSBzdXBw b3J0LCBvciBkb27igJl0IHN1cHBvcnQsIHN1Y2ggd29yayDigJMgc28gd2UgY2FuIHNlZSBpZiB0 aGVyZeKAmXMgY29uc2Vuc3VzIGZvciBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+VGhh bmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gbGFuZz0iRU4tR0IiPlBoaWwgJmFtcDsgWW9zaGk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gbGFuZz0iRU4tR0IiPkh1bXMg ZHVyaW5nIHRoZSBtZWV0aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtNjA0 Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIj5TaG91 bGQgdGhlIE1QVENQIFdHIGRvIGFueSBNUFRDUCBwcm94eSB3b3JrLCBvciBkbyBub25lIOKAkyBh Ym91dCAyOjEgb3IgMzoxIGluIGZhdm91ciBvZiBkb2luZyB3b3JrPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTYwNDY3NjMxNjMwNjk3 MzYzMTVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+U2hvdWxkIHRoZSBNUFRD UCBXRyBkbyBwcm94eSB3b3JrIGJhc2VkIG9uIG9wdGlvbiAjMSBpbiBzbGlkZSAxMj8gU3Ryb25n bHkgbW9yZSB5ZXMgdGhhbiBubzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im02MDQ2NzYzMTYzMDY5NzM2MzE1bXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1m YW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iPlNob3VsZCB0aGUgTVBUQ1AgV0cgZG8gcHJveHkgd29yayBi YXNlZCBvbiBvcHRpb24gIzIgaW4gc2xpZGUgMTI/IG1vcmUgbm8gdGhhbiB5ZXM8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtNjA0Njc2 MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIj5TaG91bGQg dGhlIE1QVENQIFdHIGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMzIGluIHNsaWRlIDEy PyBXZWFrICZhbXA7IHJvdWdobHkgZXF1YWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIGxhbmc9IkVOIj5SZWY6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtbXB0Y3Atc2Vzc2EtY2hhaXJzLTAxLnBkZiIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xp ZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1jaGFpcnMtMDEucGRmPC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gbGFuZz0iRU4iPldlIGJlbGlldmUgdGhlIHdvcmsg ZG9lcyBub3QgcmVxdWlyZSBhbiB1cGRhdGUgdG8gdGhlIE1QVENQIFdHIGNoYXJ0ZXIuDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6C17D2345AC7A45B7D054D407AA205C68D5BB5Ceusaamb105erics_-- From nobody Tue Apr 18 18:12:57 2017 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 383E2129462 for ; Tue, 18 Apr 2017 18:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5Fknk9N5M4W for ; Tue, 18 Apr 2017 18:12:54 -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 5C1E21292F5 for ; Tue, 18 Apr 2017 18:12:53 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 37531279BBD for ; Wed, 19 Apr 2017 10:12:52 +0900 (JST) Received: by mail-oi0-f52.google.com with SMTP id x184so11516601oia.1 for ; Tue, 18 Apr 2017 18:12:52 -0700 (PDT) X-Gm-Message-State: AN3rC/60InPCfoLoX6UWxSu5cG6YvR1zAXvtQV3uRfqqdnOTy168n6zr Qk99AUbnhWtYlAaVeJzzoU6F6gN0Og== X-Received: by 10.157.15.172 with SMTP id d41mr137047otd.34.1492564370903; Tue, 18 Apr 2017 18:12:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Tue, 18 Apr 2017 18:12:50 -0700 (PDT) In-Reply-To: <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> From: Yoshifumi Nishida Date: Tue, 18 Apr 2017 18:12:50 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Yoshifumi Nishida , multipathtcp Content-Type: multipart/alternative; boundary=001a113dd77621dbed054d7ab970 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:12:56 -0000 --001a113dd77621dbed054d7ab970 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch wrote: > > > On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote: > > Hi Joe, > > > > It's not tunneling. The proxy converts a tcp connection into a mptcp > > connection and converts it back to a tcp connection (if necessary) > > So, it won't be tcp over tcp. > OK, but that's not proxying either. > > That's (at best) connection hijacking. > I won't deny it as I'm not 100% sure whether proxy is a good name or not. But, I am thinking you might want to call NAT hijacking as well. > MPTCP will convey control data for application (proxy) in payload. > > But, MPTCP of course doesn't care the contents of payload. > > It just carries data and app will parse the data. Putting data in SYN > > is trying to reduce the latency and no other meaning as far as I > > understand. > > MPTCP is TCP. Putting the data in the SYN of a TCP connection is > hazardous. The goal is irrelevant. In TCP, we already have a precedence such as TFO. I think what the solution does won't exceed what TFO does. Data in SYN will be used between the proxies and won't be sent to random destinations. -- Yoshi --001a113dd77621dbed054d7ab970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <= ;touch@isi.edu> wrote:


On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> It's not tunneling. The proxy converts a tcp connection into a mpt= cp
> connection and converts it back to a tcp connection (if necessary)
> So, it won't be tcp over tcp.
OK, but that's not proxying either.

That's (at best) connection hijacking.

<= div>I won't deny it as I'm not 100% sure whether proxy is a good na= me or not.=C2=A0
But, I am thinking you might want to call NAT hi= jacking as well.

> MPTCP will convey control data for application (proxy) in payload.
> But, MPTCP of course doesn't care the contents of payload.
> It just carries data and app will parse the data. Putting data in SYN<= br> > is trying to reduce the latency and no other meaning as far as I
> understand.

MPTCP is TCP. Putting the data in the SYN of a TCP connection is
hazardous. The goal is irrelevant.
=C2=A0
In TCP= , we already have a precedence such as TFO.=C2=A0
I think what th= e solution does won't exceed what TFO does.
Data in SYN will = be used between the proxies and won't be sent to random destinations.
--
Yoshi
--001a113dd77621dbed054d7ab970-- From nobody Tue Apr 18 18:19:01 2017 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 AA018129462 for ; Tue, 18 Apr 2017 18:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPKoVgWZuNJ7 for ; Tue, 18 Apr 2017 18:18:56 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F399129409 for ; Tue, 18 Apr 2017 18:18:56 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3J1IafH016620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 18:18:37 -0700 (PDT) To: Yoshifumi Nishida References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> Cc: multipathtcp From: Joe Touch Message-ID: <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> Date: Tue, 18 Apr 2017 18:18:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------367BE55E0CDE54025D670BA3" X-MailScanner-ID: v3J1IafH016620 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:18:58 -0000 This is a multi-part message in MIME format. --------------367BE55E0CDE54025D670BA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote: > Hi Joe, > > On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch > wrote: > > > > On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote: > > Hi Joe, > > > > It's not tunneling. The proxy converts a tcp connection into a mptcp > > connection and converts it back to a tcp connection (if necessary) > > So, it won't be tcp over tcp. > OK, but that's not proxying either. > > That's (at best) connection hijacking. > > > I won't deny it as I'm not 100% sure whether proxy is a good name or not. > But, I am thinking you might want to call NAT hijacking as well. Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 translation of only addresses and ports. Doing more than that has never been part of an IETF standard, AFAICT - for many reasons. > > > MPTCP will convey control data for application (proxy) in payload. > > But, MPTCP of course doesn't care the contents of payload. > > It just carries data and app will parse the data. Putting data > in SYN > > is trying to reduce the latency and no other meaning as far as I > > understand. > > MPTCP is TCP. Putting the data in the SYN of a TCP connection is > hazardous. The goal is irrelevant. > > > In TCP, we already have a precedence such as TFO. Sorry, to be more clear: Data in the SYN has been part of TCP since it was standardized. Using the SYN data as control information is the hazardous part. > I think what the solution does won't exceed what TFO does. TFO changes when the SYN data is delivered, based on the fact that past cookie information "accelerates" the 3WHS. It does not put control plane information in the data area of the SYN. Joe --------------367BE55E0CDE54025D670BA3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote:
Hi Joe,

On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <touch@isi.edu> wrote:


On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> It's not tunneling. The proxy converts a tcp connection into a mptcp
> connection and converts it back to a tcp connection (if necessary)
> So, it won't be tcp over tcp.
OK, but that's not proxying either.

That's (at best) connection hijacking.

I won't deny it as I'm not 100% sure whether proxy is a good name or not. 
But, I am thinking you might want to call NAT hijacking as well.
Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 translation of only addresses and ports.

Doing more than that has never been part of an IETF standard, AFAICT - for many reasons.


> MPTCP will convey control data for application (proxy) in payload.
> But, MPTCP of course doesn't care the contents of payload.
> It just carries data and app will parse the data. Putting data in SYN
> is trying to reduce the latency and no other meaning as far as I
> understand.

MPTCP is TCP. Putting the data in the SYN of a TCP connection is
hazardous. The goal is irrelevant.
 
In TCP, we already have a precedence such as TFO.

Sorry, to be more clear:
    Data in the SYN has been part of TCP since it was standardized.

Using the SYN data as control information is the hazardous part.

I think what the solution does won't exceed what TFO does.
TFO changes when the SYN data is delivered, based on the fact that past cookie information "accelerates" the 3WHS.

It does not put control plane information in the data area of the SYN.

Joe
--------------367BE55E0CDE54025D670BA3-- From nobody Tue Apr 18 19:06:38 2017 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 6869A127843 for ; Tue, 18 Apr 2017 19:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AewPge9KbvDz for ; Tue, 18 Apr 2017 19:06:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 3E8421200DF for ; Tue, 18 Apr 2017 19:06:35 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3J26XuO029020; Wed, 19 Apr 2017 04:06:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9976CD7924; Wed, 19 Apr 2017 04:06:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OmBSpOcMOBcm; Wed, 19 Apr 2017 04:06:32 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BB171D78E4; Wed, 19 Apr 2017 04:06:32 +0200 (CEST) Date: Wed, 19 Apr 2017 04:06:40 +0200 Message-ID: <87a87db173.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Henderickx, Wim (Nokia - BE/Antwerp)" Cc: "multipathtcp@ietf.org" In-Reply-To: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 19 Apr 2017 04:06:33 +0200 (CEST) X-Miltered: at korolev with ID 58F6C629.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F6C629.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58F6C629.004 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 02:06:36 -0000 >> Does the dual proxy solution have the ability to support native MPTCP >> at the client and server, or is the assumption that the solution forces >> the two proxies to become part of a connection regardless of whether >> the client and server are MPTCP enabled? > If the client and server support mptcp the proxies should not end up in > the path Could you please explain how that happens? -- Juliusz From nobody Tue Apr 18 22:26:47 2017 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 19789131519 for ; Tue, 18 Apr 2017 22:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9WzWWu1tnxl for ; Tue, 18 Apr 2017 22:26:41 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6398413151E for ; Tue, 18 Apr 2017 22:26:41 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 2062C100534; Wed, 19 Apr 2017 07:26:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id E71EF60060; Wed, 19 Apr 2017 07:26:39 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 07:26:39 +0200 From: To: Joe Touch , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuFS0FYN3Pf6Ey0Kw29UUSw2QvaHMKTqA Date: Wed, 19 Apr 2017 05:26:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> In-Reply-To: <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E503BEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:26:45 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E503BEOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe, As explained in my previous message, there is no layered congestion control= . All packets are transported over plain TCP: no encap, no tunnel. I really reiterate my comment to read https://www.ietf.org/proceedings/98/s= lides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoy=E9 : mardi 18 avril 2017 17:01 =C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.o= rg Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work Mohammed, I'm sorry, but when you talk about CPEs and network interconnection, you're= clearly talking (AFAICT) about using MPTCP as an IP tunnel. That leads to TCP over TCP (where the first is inside the IP packets you're= transiting). If that's what you're doing, it is a mistake. Layered congestion control is= never beneficial. Joe On 4/18/2017 7:30 AM, mohamed.boucadair@orange.com wrote: Hi Joe, Some comments from my side : =B7 The main target use case is a CPE that is connected to many net= works (cellular and fixed, typically). Please refer to https://www.ietf.org= /mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf for more business driver= s. =B7 In order to enhance resilience and increase resource pooling, t= he CPE is MPTCP-capable. =B7 Because of the lack of MPTCP support at the servers side, a pro= xy is introduced at the network side to assisted MPTCP connections of that = CPE. Let's call this proxy: network-located proxy. =B7 Because the network provider does not control hosts that are lo= cated behind a given CPE, a proxy is enabled on the CPE to transform some T= CP connections into MPTCP ones. =B7 The CPE is configured with its network-located proxy by means o= f DHCP, for example. =B7 As mentioned in Phil's text, the proxies are both under the con= trol of the operator. In particular, ** both ** the CPE and the network-pro= xy support the mechanism detailed hereafter (that is parse and strip any su= pplied data before forwarding upstream). =B7 There is no tunnel/encapsulation at all. As such there is no **= TCP over TCP ** scheme. All is about plain transport mode. o The CPE forwards MPTCP connections it creates to its configured network= -located proxy. This is exactly the same as with the data plane of SOCKS. o In order to inform its proxy about the ultimate destination IP address/= port while ensuring 0-RTT, an information element is inserted in the payloa= d of the SYN message of the initial subflow. o That information is stripped by the network-located proxy before forwar= ding the packet to its ultimate server. o In order to strengthen the solution, that information must be echoed by= the proxy in the SYN/ACK as a guard against misconfigured proxies. o The information echoed in the SYN/ACK is used by the CPE to double chec= k that the network-proxy complies with the solution. If not, no further MPT= CP connection is established with that proxy till a TTL expires or a new pr= oxy is configured. o More details can be found at https://www.ietf.org/proceedings/98/slides= /slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf So: =B7 "(TCP over TCP), which I already noted in previous discussion."= WAS NEVER proposed. =B7 The proposal does not "interfere with MPTCP's ability to silent= ly fall-back to TCP when talking to legacy endpoints". Legacy endpoints tha= t receive an MP_CAPABLE option (whether from an MPTCP-capable client or via= a proxy) will ignore it and silently fall back to TCP. I don't see a probl= em here. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe = Touch Envoy=E9 : mardi 18 avril 2017 15:30 =C0 : philip.eardley@bt.com; multipathtcp@ietf.or= g Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work Hi, all, The description below isn't sufficient to determine whether this work is ei= ther needed or safe. My initial conclusion is that this work is either (a) not needed at all, (b= ) out of scope, or (c) involves one if not two very bad ideas. I have a few questions that determine which of (a), (b), or (c) apply (belo= w), but I've already commented on my concerns that conclude (c) *based on p= reviously assuming this was intended as an IP tunnel and used an option wit= h control plane info in the SYN data) so I won't repeat them. I am curious as to what's really intended here, though. Joe 1) what is the reason for needing MPTCP work to support proxy-proxy use? Tr= ue proxies are applications and can already setup MTCP themselves. Protocol= s for operators to configure proxies seem out of scope here. And if this "p= roxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), w= hich I already noted in previous discussion. 2) what does "using the payload...to transfer a signalling message" mean? A= re you using the MPTCP control plane? or the data plane of the MPTCP connec= tion? 3) I'm not sure I fully understand the details of the optinns, but I unders= tand that at least one of them puts data in the SYN that is interpreted as = something other than TCP data (i.e., control plane). That is also a very ba= d idea - it interferes with MPTCPs ability to silently fall-back to TCP whe= n talking to legacy endpoints, and the reasons for not using TCP data as co= ntrol are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the re= ason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in p= revious discussion. On 4/18/2017 1:17 AM, philip.eardley@bt.com w= rote: Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_787AE7BB302AE849A7480A190F8B933009E503BEOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Joe,

 

As explained in my previous mes= sage, there is no layered congestion control. All packets are transported o= ver plain TCP: no encap, no tunnel.

 

I really reiterate my comment t= o read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-networ= k-assisted-mptcp-03.pdf

 

Cheers,

Med

 

De := Joe Touch [mailto:touch@isi.edu]
Envoy=E9 : mardi 18 avril 2017 17:01
=C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipa= thtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

Mohammed,

I'm sorry, but when you talk about CPEs and network interconnection, you= 're clearly talking (AFAICT) about using MPTCP as an IP tunnel.<= /p>

That leads to TCP over TCP (where the first is inside the IP packets you= 're transiting).

If that's what you're doing, it is a mistake. Layered congestion control= is never beneficial.

Joe

 

On 4/18/2017 7:30 AM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

Some comment= s from my side :

 

=B7         The = main target use case is a CPE that is connected to many networks (cellular = and fixed, typically). Please refer to https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf = for more business drivers.

=B7         In o= rder to enhance resilience and increase resource pooling, the CPE is MPTCP-= capable.

=B7         Beca= use of the lack of MPTCP support at the servers side, a proxy is introduced= at the network side to assisted MPTCP connections of that CPE. Let’s call this proxy: network-located proxy.

=B7         Beca= use the network provider does not control hosts that are located behind a g= iven CPE, a proxy is enabled on the CPE to transform some TCP connections into MPTCP ones.

=B7         The = CPE is configured with its network-located proxy by means of DHCP, for exam= ple.

=B7         As m= entioned in Phil’s text, the proxies are both under the control of th= e operator. In particular, ** both ** the CPE and the network-proxy support the mechanism detailed hereafter (that is parse and strip any supp= lied data before forwarding upstream).  

=B7         Ther= e is no tunnel/encapsulation at all. As such there is no ** TCP over TCP **= scheme. All is about plain transport mode.  

o   The = CPE forwards MPTCP connections it creates to its configured network-located= proxy. This is exactly the same as with the data plane of SOCKS.

o   In o= rder to inform its proxy about the ultimate destination IP address/port whi= le ensuring 0-RTT, an information element is inserted in the payload of the SYN message of the initial subflow. <= /p>

o   That= information is stripped by the network-located proxy before forwarding the= packet to its ultimate server.

o   In o= rder to strengthen the solution, that information must be echoed by the pro= xy in the SYN/ACK as a guard against misconfigured proxies.

o   The = information echoed in the SYN/ACK is used by the CPE to double check that t= he network-proxy complies with the solution. If not, no further MPTCP connection is established with that proxy till a TTL expires= or a new proxy is configured.

o   More= details can be found at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-as= sisted-mptcp-03.pdf

 

So:

=B7         R= 20;(TCP over TCP), which I already noted in previous discussion.” WAS= NEVER proposed.   

=B7         The = proposal does not “interfere with MPTCP’s ability to silently f= all-back to TCP when talking to legacy endpoints”. Legacy endpoints that receive an MP_CAPABLE option (whether from an MPTCP-capable client or= via a proxy) will ignore it and silently fall back to TCP. I don’t s= ee a problem here.

 

Cheers,

Med

 

De&nb= sp;: multipathtcp [<= a href=3D"mailto:multipathtcp-bounces@ietf.org">mailto:multipathtcp-bounces= @ietf.org] De la part de Joe Touch
Envoy=E9 : mardi 18 avril 2017 15:30
=C0 : philip.eardley@bt.com; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

Hi, all,

The description below isn't sufficient to determine whether this work is= either needed or safe.

My initial conclusion is that this work is either (a) not needed at all,= (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (b= elow), but I've already commented on my concerns that conclude (c) *based o= n previously assuming this was intended as an IP tunnel and used an option = with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use?= True proxies are applications and can already setup MTCP themselves. Proto= cols for operators to configure proxies seem out of scope here. And if this= "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous d= iscussion.

2) what does "using the payload...to transfer a signalling message&= quot; mean? Are you using the MPTCP control plane? or the data plane of the= MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I und= erstand that at least one of them puts data in the SYN that is interpreted = as something other than TCP data (i.e., control plane). That is also a very= bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and= the reasons for not using TCP data as control are discussed in draft-ietf-= tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-= ext-opt), which I also already noted in previous discussion.

On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:


Hi,

During the MPTCP meeting in Chicago we did several hums about pote= ntial MPTCP proxy work. Our interpretation of these hums is that we should = do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’t support, such work = – so we can see if there’s consensus for it.

Thanks

Phil & Yoshi

 

Hums during the meeting:

=B7         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

=B7         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no

=B7         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

=B7         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 





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

 

 

--_000_787AE7BB302AE849A7480A190F8B933009E503BEOPEXCLILMA3corp_-- From nobody Tue Apr 18 22:47:05 2017 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 78E44131514 for ; Tue, 18 Apr 2017 22:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ewa2efQlmxr for ; Tue, 18 Apr 2017 22:47:02 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6FD120724 for ; Tue, 18 Apr 2017 22:47:02 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id C6CAD1C070F; Wed, 19 Apr 2017 07:47:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id A7EE616005E; Wed, 19 Apr 2017 07:47:00 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 07:47:00 +0200 From: To: Joe Touch , Yoshifumi Nishida CC: multipathtcp Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuIz+FYN3Pf6Ey0Kw29UUSw2QvaHLipSAgAA26wCAAAGcAIAAadBQ Date: Wed, 19 Apr 2017 05:46:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> In-Reply-To: <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E503E2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 05:47:04 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E503E2OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogbXVsdGlw YXRodGNwIFttYWlsdG86bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgSm9lIFRvdWNoDQpFbnZvecOpIDogbWVyY3JlZGkgMTkgYXZyaWwgMjAxNyAwMzoxOQ0Kw4Ag OiBZb3NoaWZ1bWkgTmlzaGlkYQ0KQ2MgOiBtdWx0aXBhdGh0Y3ANCk9iamV0IDogUmU6IFttdWx0 aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoN Cg0KDQoNCk9uIDQvMTgvMjAxNyA2OjEyIFBNLCBZb3NoaWZ1bWkgTmlzaGlkYSB3cm90ZToNCkhp IEpvZSwNCg0KT24gVHVlLCBBcHIgMTgsIDIwMTcgYXQgMjo1NiBQTSwgSm9lIFRvdWNoIDx0b3Vj aEBpc2kuZWR1PG1haWx0bzp0b3VjaEBpc2kuZWR1Pj4gd3JvdGU6DQoNCg0KT24gNC8xOC8yMDE3 IDI6NDQgUE0sIFlvc2hpZnVtaSBOaXNoaWRhIHdyb3RlOg0KPiBIaSBKb2UsDQo+DQo+IEl0J3Mg bm90IHR1bm5lbGluZy4gVGhlIHByb3h5IGNvbnZlcnRzIGEgdGNwIGNvbm5lY3Rpb24gaW50byBh IG1wdGNwDQo+IGNvbm5lY3Rpb24gYW5kIGNvbnZlcnRzIGl0IGJhY2sgdG8gYSB0Y3AgY29ubmVj dGlvbiAoaWYgbmVjZXNzYXJ5KQ0KPiBTbywgaXQgd29uJ3QgYmUgdGNwIG92ZXIgdGNwLg0KT0ss IGJ1dCB0aGF0J3Mgbm90IHByb3h5aW5nIGVpdGhlci4NCg0KVGhhdCdzIChhdCBiZXN0KSBjb25u ZWN0aW9uIGhpamFja2luZy4NCg0KSSB3b24ndCBkZW55IGl0IGFzIEknbSBub3QgMTAwJSBzdXJl IHdoZXRoZXIgcHJveHkgaXMgYSBnb29kIG5hbWUgb3Igbm90Lg0KQnV0LCBJIGFtIHRoaW5raW5n IHlvdSBtaWdodCB3YW50IHRvIGNhbGwgTkFUIGhpamFja2luZyBhcyB3ZWxsLg0KWWVzLCBidXQg d2UgZG8ga25vdyB3aGF0IGEgTkFUIGlzIHJlc3BvbnNpYmxlIGZvciAtIGkuZS4sIGl0IGlzIDE6 MSB0cmFuc2xhdGlvbiBvZiBvbmx5IGFkZHJlc3NlcyBhbmQgcG9ydHMuDQpbTWVkXSBUaGF04oCZ cyB0aGUgc2FtZSBzaXR1YXRpb24gaGVyZTogdGhlIENQRSBpcyBhc3NpZ25lZCBOIGFkZHJlc3Nl cyBidXQgY2Fubm90IHVzZSBhbGwgdGhlc2UgYWRkcmVzc2VzIGFzIGV4dGVybmFsIG9uZXMgdG8g Y29tbXVuaWNhdGUgd2l0aCBhIHNpbmdsZSBwYXRoIHNlcnZlci4gSW4gb3JkZXIgdG8gYmVuZWZp dCBmcm9tIHRoZSBwYXRoIGRpdmVyc2l0eSBhbmQgdGhlIHJlc291cmNlcyBwb29saW5nLCB0aGUg Q1BFIGFuZCBwcm94eSB3aWxsIGNvbGxhYm9yYXRlIGFzIGFscmVhZHkgZGVzY3JpYmVkIGluIG90 aGVyIG1haWxzLiBPbmUgd2F5IHRvIGNvbGxhYm9yYXRlIGlzIHRvIGhpZGUgdGhlc2UgTiBhZGRy ZXNzZXMgKHlvdSBuYW1lIGl0KS4NCg0KDQpEb2luZyBtb3JlIHRoYW4gdGhhdCBoYXMgbmV2ZXIg YmVlbiBwYXJ0IG9mIGFuIElFVEYgc3RhbmRhcmQsIEFGQUlDVCAtIGZvciBtYW55IHJlYXNvbnMu DQoNCg0KDQoNCj4gTVBUQ1Agd2lsbCBjb252ZXkgY29udHJvbCBkYXRhIGZvciBhcHBsaWNhdGlv biAocHJveHkpIGluIHBheWxvYWQuDQo+IEJ1dCwgTVBUQ1Agb2YgY291cnNlIGRvZXNuJ3QgY2Fy ZSB0aGUgY29udGVudHMgb2YgcGF5bG9hZC4NCj4gSXQganVzdCBjYXJyaWVzIGRhdGEgYW5kIGFw cCB3aWxsIHBhcnNlIHRoZSBkYXRhLiBQdXR0aW5nIGRhdGEgaW4gU1lODQo+IGlzIHRyeWluZyB0 byByZWR1Y2UgdGhlIGxhdGVuY3kgYW5kIG5vIG90aGVyIG1lYW5pbmcgYXMgZmFyIGFzIEkNCj4g dW5kZXJzdGFuZC4NCg0KTVBUQ1AgaXMgVENQLiBQdXR0aW5nIHRoZSBkYXRhIGluIHRoZSBTWU4g b2YgYSBUQ1AgY29ubmVjdGlvbiBpcw0KaGF6YXJkb3VzLiBUaGUgZ29hbCBpcyBpcnJlbGV2YW50 Lg0KDQpJbiBUQ1AsIHdlIGFscmVhZHkgaGF2ZSBhIHByZWNlZGVuY2Ugc3VjaCBhcyBURk8uDQoN ClNvcnJ5LCB0byBiZSBtb3JlIGNsZWFyOg0KICAgIERhdGEgaW4gdGhlIFNZTiBoYXMgYmVlbiBw YXJ0IG9mIFRDUCBzaW5jZSBpdCB3YXMgc3RhbmRhcmRpemVkLg0KDQpVc2luZyB0aGUgU1lOIGRh dGEgYXMgY29udHJvbCBpbmZvcm1hdGlvbiBpcyB0aGUgaGF6YXJkb3VzIHBhcnQuDQpbTWVkXSBJ dCBpc27igJl0IGZvciB0aGUgZm9yIHRoZSBzaW1wbGUgcmVhc29uIHRoYXQgbGVnYWN5IEludGVy bmV0IG5vZGVzIHdpbGwgbmV2ZXIgcmVjZWl2ZSBhIFNZTiB3aXRoIENQRS1zdXBwbGllZCBkYXRh IGFuZCB0aGF0IHRoZSBUQ1AgcGVlciBpcyBrbm93biB0byBwcm9jZXNzIHRoZSBzdXBwbGllZCBk YXRhLiBBIEd1YXJkIGFnYWluc3QgbWlzY29uZmlndXJhdGlvbnMgaXMgc3VwcG9ydGVkOiBlY2hv IGluIGEgU1lOL0FDSy4NCg0KDQpJIHRoaW5rIHdoYXQgdGhlIHNvbHV0aW9uIGRvZXMgd29uJ3Qg ZXhjZWVkIHdoYXQgVEZPIGRvZXMuDQpURk8gY2hhbmdlcyB3aGVuIHRoZSBTWU4gZGF0YSBpcyBk ZWxpdmVyZWQsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgcGFzdCBjb29raWUgaW5mb3JtYXRpb24g ImFjY2VsZXJhdGVzIiB0aGUgM1dIUy4NCg0KSXQgZG9lcyBub3QgcHV0IGNvbnRyb2wgcGxhbmUg aW5mb3JtYXRpb24gaW4gdGhlIGRhdGEgYXJlYSBvZiB0aGUgU1lOLg0KDQpKb2UNCg== --_000_787AE7BB302AE849A7480A190F8B933009E503E2OPEXCLILMA3corp_ 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 ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA5NjgyNzYwMzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI5NzExNzk3MiAtMTgwMTUxOTc5MCA2Nzg5NTI5 OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2 Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBtdWx0aXBhdGh0Y3AgW21haWx0bzptdWx0aXBhdGh0Y3At Ym91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEpvZSBUb3VjaDxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxOSBhdnJpbCAyMDE3IDAzOjE5PGJyPg0KPGI+ w4AmbmJzcDs6PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gbXVs dGlwYXRodGNwPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW211bHRpcGF0aHRjcF0gQ29u c2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQv MTgvMjAxNyA2OjEyIFBNLCBZb3NoaWZ1bWkgTmlzaGlkYSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSm9lLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDE4LCAyMDE3IGF0IDI6NTYg UE0sIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlzaS5lZHUiIHRhcmdldD0i X2JsYW5rIj50b3VjaEBpc2kuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiA0LzE4LzIwMTcgMjo0NCBQTSwgWW9zaGlm dW1pIE5pc2hpZGEgd3JvdGU6PGJyPg0KJmd0OyBIaSBKb2UsPGJyPg0KJmd0Ozxicj4NCiZndDsg SXQncyBub3QgdHVubmVsaW5nLiBUaGUgcHJveHkgY29udmVydHMgYSB0Y3AgY29ubmVjdGlvbiBp bnRvIGEgbXB0Y3A8YnI+DQomZ3Q7IGNvbm5lY3Rpb24gYW5kIGNvbnZlcnRzIGl0IGJhY2sgdG8g YSB0Y3AgY29ubmVjdGlvbiAoaWYgbmVjZXNzYXJ5KTxicj4NCiZndDsgU28sIGl0IHdvbid0IGJl IHRjcCBvdmVyIHRjcC48YnI+DQpPSywgYnV0IHRoYXQncyBub3QgcHJveHlpbmcgZWl0aGVyLjxi cj4NCjxicj4NClRoYXQncyAoYXQgYmVzdCkgY29ubmVjdGlvbiBoaWphY2tpbmcuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvbid0IGRlbnkgaXQgYXMg SSdtIG5vdCAxMDAlIHN1cmUgd2hldGhlciBwcm94eSBpcyBhIGdvb2QgbmFtZSBvciBub3QuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C dXQsIEkgYW0gdGhpbmtpbmcgeW91IG1pZ2h0IHdhbnQgdG8gY2FsbCBOQVQgaGlqYWNraW5nIGFz IHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYnV0IHdlIGRvIGtub3cgd2hh dCBhIE5BVCBpcyByZXNwb25zaWJsZSBmb3IgLSBpLmUuLCBpdCBpcyAxOjEgdHJhbnNsYXRpb24g b2Ygb25seSBhZGRyZXNzZXMgYW5kIHBvcnRzLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGF04oCZcyB0aGUgc2FtZSBzaXR1YXRpb24gaGVy ZTogdGhlIENQRSBpcyBhc3NpZ25lZCBOIGFkZHJlc3NlcyBidXQgY2Fubm90IHVzZSBhbGwgdGhl c2UgYWRkcmVzc2VzIGFzIGV4dGVybmFsIG9uZXMgdG8gY29tbXVuaWNhdGUgd2l0aCBhIHNpbmds ZSBwYXRoDQogc2VydmVyLiBJbiBvcmRlciB0byBiZW5lZml0IGZyb20gdGhlIHBhdGggZGl2ZXJz aXR5IGFuZCB0aGUgcmVzb3VyY2VzIHBvb2xpbmcsIHRoZSBDUEUgYW5kIHByb3h5IHdpbGwgY29s bGFib3JhdGUgYXMgYWxyZWFkeSBkZXNjcmliZWQgaW4gb3RoZXIgbWFpbHMuIE9uZSB3YXkgdG8g Y29sbGFib3JhdGUgaXMgdG8gaGlkZSB0aGVzZSBOIGFkZHJlc3NlcyAoeW91IG5hbWUgaXQpLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KRG9pbmcgbW9yZSB0aGFuIHRoYXQgaGFzIG5ldmVyIGJl ZW4gcGFydCBvZiBhbiBJRVRGIHN0YW5kYXJkLCBBRkFJQ1QgLSBmb3IgbWFueSByZWFzb25zLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IE1QVENQIHdpbGwgY29udmV5IGNvbnRyb2wgZGF0YSBmb3IgYXBwbGljYXRpb24g KHByb3h5KSBpbiBwYXlsb2FkLjxicj4NCiZndDsgQnV0LCBNUFRDUCBvZiBjb3Vyc2UgZG9lc24n dCBjYXJlIHRoZSBjb250ZW50cyBvZiBwYXlsb2FkLjxicj4NCiZndDsgSXQganVzdCBjYXJyaWVz IGRhdGEgYW5kIGFwcCB3aWxsIHBhcnNlIHRoZSBkYXRhLiBQdXR0aW5nIGRhdGEgaW4gU1lOPGJy Pg0KJmd0OyBpcyB0cnlpbmcgdG8gcmVkdWNlIHRoZSBsYXRlbmN5IGFuZCBubyBvdGhlciBtZWFu aW5nIGFzIGZhciBhcyBJPGJyPg0KJmd0OyB1bmRlcnN0YW5kLjxicj4NCjxicj4NCk1QVENQIGlz IFRDUC4gUHV0dGluZyB0aGUgZGF0YSBpbiB0aGUgU1lOIG9mIGEgVENQIGNvbm5lY3Rpb24gaXM8 YnI+DQpoYXphcmRvdXMuIFRoZSBnb2FsIGlzIGlycmVsZXZhbnQuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBUQ1AsIHdlIGFs cmVhZHkgaGF2ZSBhIHByZWNlZGVuY2Ugc3VjaCBhcyBURk8uIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpT b3JyeSwgdG8gYmUgbW9yZSBjbGVhcjo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgRGF0YSBpbiB0 aGUgU1lOIGhhcyBiZWVuIHBhcnQgb2YgVENQIHNpbmNlIGl0IHdhcyBzdGFuZGFyZGl6ZWQuPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KVXNpbmcgdGhlIFNZTiBkYXRhIGFz IGNvbnRyb2wgaW5mb3JtYXRpb24gaXMgdGhlIGhhemFyZG91cyBwYXJ0Ljwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN ZWRdIEl0IGlzbuKAmXQgZm9yIHRoZSBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCBsZWdhY3kg SW50ZXJuZXQgbm9kZXMgd2lsbCBuZXZlciByZWNlaXZlIGEgU1lOIHdpdGggQ1BFLXN1cHBsaWVk IGRhdGEgYW5kIHRoYXQgdGhlIFRDUCBwZWVyIGlzIGtub3duIHRvDQogcHJvY2VzcyB0aGUgc3Vw cGxpZWQgZGF0YS4gQSBHdWFyZCBhZ2FpbnN0IG1pc2NvbmZpZ3VyYXRpb25zIGlzIHN1cHBvcnRl ZDogZWNobyBpbiBhIFNZTi9BQ0suPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgd2hhdCB0 aGUgc29sdXRpb24gZG9lcyB3b24ndCBleGNlZWQgd2hhdCBURk8gZG9lcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5URk8gY2hhbmdlcyB3aGVuIHRoZSBTWU4gZGF0YSBp cyBkZWxpdmVyZWQsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgcGE8L3NwYW4+c3QgY29va2llIGlu Zm9ybWF0aW9uICZxdW90O2FjY2VsZXJhdGVzJnF1b3Q7IHRoZSAzV0hTLjxicj4NCjxicj4NCkl0 IGRvZXMgbm90IHB1dCBjb250cm9sIHBsYW5lIGluZm9ybWF0aW9uIGluIHRoZSBkYXRhIGFyZWEg b2YgdGhlIFNZTi48YnI+DQo8YnI+DQpKb2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933009E503E2OPEXCLILMA3corp_-- From nobody Tue Apr 18 23:00:22 2017 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 8E65A13151E for ; Tue, 18 Apr 2017 23:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AQE0qmvYAjA for ; Tue, 18 Apr 2017 23:00:18 -0700 (PDT) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) (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 B3FF813151B for ; Tue, 18 Apr 2017 23:00:17 -0700 (PDT) Received: by mail.swisscom.com; Wed, 19 Apr 2017 08:00:14 +0200 From: To: , Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuNI11jXzvDFKRxmRsHBM53Icbg== Date: Wed, 19 Apr 2017 06:00:12 +0000 Message-ID: <6DA61EDB-0341-4FFA-8034-CA12F890E205@swisscom.com> Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [138.190.134.7] Content-Type: multipart/alternative; boundary="_000_6DA61EDB03414FFA8034CA12F890E205swisscomcom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:00:21 -0000 --_000_6DA61EDB03414FFA8034CA12F890E205swisscomcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIHN1cHBvcnQgdGhhdCB3b3JrIGFuZCBoYXZlIHB1dCBmb3J3YXJkIHNvbWUgdGlt ZSBhZ28gd2hhdCB0aGUgdXNlIGNhc2UgYW5kIHByb2JsZW1zIGFyZSB3ZSB3b3VsZCBsaWtlIHRv IHNlZSBzb2x2ZWQuIEnigJltIHN1cnByaXNlZCB0aGlzIGRpc2N1c3Npb24gc3RhcnRzIG92ZXIg YWdhaW4uDQoNCkFuZCB5ZXMgcHJveHkgbWlnaHQgYmUgYSBtaXNsZWFkaW5nIHRlcm0gZm9yIHNv bWUgd2l0aCBpdHMgbGVnYWN5IGNvLW5vdGF0aW9ucywgc28gZmVlbCBmcmVlIHRvIHByb3Bvc2Ug YW4gYXBwcm9wcmlhdGUgdGVybSAoSSB0aG91Z2h0IHNvbWUgb2YgdGhlIGRyYWZ0cyBoYXZlIHVz ZWQgZGlmZmVyZW50IHRlcm1pbm9sb2d5KS4NCg0KTWFyY3VzDQoNClZvbjogbXVsdGlwYXRodGNw IDxtdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZz4gaW0gQXVmdHJhZyB2b24gInBoaWxpcC5l YXJkbGV5QGJ0LmNvbSIgPHBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4NCkRhdHVtOiBEaWVuc3RhZywg MTguIEFwcmlsIDIwMTcgdW0gMTA6MTcNCkFuOiAibXVsdGlwYXRodGNwQGlldGYub3JnIiA8bXVs dGlwYXRodGNwQGlldGYub3JnPg0KQmV0cmVmZjogW211bHRpcGF0aHRjcF0gQ29uc2Vuc3VzIGNh bGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsNCg0KSGksDQpEdXJpbmcgdGhlIE1QVENQ IG1lZXRpbmcgaW4gQ2hpY2FnbyB3ZSBkaWQgc2V2ZXJhbCBodW1zIGFib3V0IHBvdGVudGlhbCBN UFRDUCBwcm94eSB3b3JrLiBPdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlc2UgaHVtcyBpcyB0aGF0 IHdlIHNob3VsZCBkbyBhIGNvbnNlbnN1cyBjYWxsIGZvciB0aGUgZm9sbG93aW5nIHdvcms6DQot LQ0KTVBUQ1AgaXMgbm93IHNlZWluZyB3aWRlc3ByZWFkIGRlcGxveW1lbnQgaW4gbmV0d29ya3Mg dG8gYm9uZCB0b2dldGhlciB0d28gYWNjZXNzZXMsIHN1Y2ggYXMgZml4ZWQgYW5kIG1vYmlsZSBi cm9hZGJhbmQsIGJ5IHVzaW5nIHR3byBNUFRDUCBwcm94aWVzLCBvbmUgaW4gdGhlIGhvbWUgZ2F0 ZXdheSBvciBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1lbnQgYW5kIG9uZSBpbiB0aGUgbmV0d29y ay4gVGhlIFdHIGRldmVsb3BzIGEgc29sdXRpb24gd2hlcmUgdGhlIHByb3hpZXMgYXJlIGJvdGgg dW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIG9wZXJhdG9yIGFuZCB3aGVyZSBpdCBpcyBhc3N1bWVk IHRoYXQgdGhleSBhcmUgbm90IG9uIHRoZSBkZWZhdWx0IHBhdGguIFRoZSBzb2x1dGlvbiBpcyBi YXNlZCBvbiB1c2luZyB0aGUgcGF5bG9hZCBvZiBhbiBNUFRDUCBwYWNrZXQgdG8gdHJhbnNmZXIg YSBzaWduYWxsaW5nIG1lc3NhZ2UgYmV0d2VlbiB0aGUgcHJveGllcy4gSXQgaXMgYmVsaWV2ZWQg dGhlIHNvbHV0aW9uIHdpbGwgbm90IHJlcXVpcmUgY2hhbmdlcyB0byBSRkM2ODI0YmlzLiBUaGUg c29sdXRpb24gbWF5IHJlcXVpcmUgYSBtZWFucyBvZiBjb25maWd1cmluZyBzZXQtdXAgaW5mb3Jt YXRpb24gaW4gdGhlIHByb3hpZXMsIHdoaWNoIHdvdWxkIGJlIGRvbmUgaW4gY29vcmRpbmF0aW9u IHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcyBESEMuIFRoZSBXRyBkb2VzIG5vdCBkZXZlbG9w IGEgbWVjaGFuaXNtIGZvciB0aGUgdHdvIHByb3hpZXMgdG8gZGlzY292ZXIgZWFjaCBvdGhlci4N Ci0tDQpQbGVhc2Ugc2F5IHdoZXRoZXIgeW91IHN1cHBvcnQsIG9yIGRvbuKAmXQgc3VwcG9ydCwg c3VjaCB3b3JrIOKAkyBzbyB3ZSBjYW4gc2VlIGlmIHRoZXJl4oCZcyBjb25zZW5zdXMgZm9yIGl0 Lg0KVGhhbmtzDQpQaGlsICYgWW9zaGkNCg0KSHVtcyBkdXJpbmcgdGhlIG1lZXRpbmc6DQoNCuKA oiAgICAgICAgIFNob3VsZCB0aGUgTVBUQ1AgV0cgZG8gYW55IE1QVENQIHByb3h5IHdvcmssIG9y IGRvIG5vbmUg4oCTIGFib3V0IDI6MSBvciAzOjEgaW4gZmF2b3VyIG9mIGRvaW5nIHdvcmsNCg0K 4oCiICAgICAgICAgU2hvdWxkIHRoZSBNUFRDUCBXRyBkbyBwcm94eSB3b3JrIGJhc2VkIG9uIG9w dGlvbiAjMSBpbiBzbGlkZSAxMj8gU3Ryb25nbHkgbW9yZSB5ZXMgdGhhbiBubw0KDQrigKIgICAg ICAgICBTaG91bGQgdGhlIE1QVENQIFdHIGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMy IGluIHNsaWRlIDEyPyBtb3JlIG5vIHRoYW4geWVzDQoNCuKAoiAgICAgICAgIFNob3VsZCB0aGUg TVBUQ1AgV0cgZG8gcHJveHkgd29yayBiYXNlZCBvbiBvcHRpb24gIzMgaW4gc2xpZGUgMTI/IFdl YWsgJiByb3VnaGx5IGVxdWFsDQpSZWY6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk4L3NsaWRlcy9zbGlkZXMtOTgtbXB0Y3Atc2Vzc2EtY2hhaXJzLTAxLnBkZg0KV2UgYmVsaWV2 ZSB0aGUgd29yayBkb2VzIG5vdCByZXF1aXJlIGFuIHVwZGF0ZSB0byB0aGUgTVBUQ1AgV0cgY2hh cnRlci4NCg0K --_000_6DA61EDB03414FFA8034CA12F890E205swisscomcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0ZWwiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJTdGljaHfDtnJ0ZXIiIGNv bnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3Jk IDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25z ICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubTYwNDY3NjMxNjMwNjk3MzYzMTVtc29saXN0cGFyYWdyYXBoLCBsaS5tNjA0 Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjA0Njc2MzE2MzA2OTczNjMx NW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV82MDQ2NzYzMTYzMDY5NzM2MzE1 bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNw YW4uRS1NYWlsLUZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWwtRm9y bWF0dm9ybGFnZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iREUiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBzdXBwb3J0 IHRoYXQgd29yayBhbmQgaGF2ZSBwdXQgZm9yd2FyZCBzb21lIHRpbWUgYWdvIHdoYXQgdGhlIHVz ZSBjYXNlIGFuZCBwcm9ibGVtcyBhcmUgd2Ugd291bGQgbGlrZSB0byBzZWUgc29sdmVkLiBJ4oCZ bSBzdXJwcmlzZWQgdGhpcyBkaXNjdXNzaW9uDQogc3RhcnRzIG92ZXIgYWdhaW4uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbmQgeWVzIHByb3h5IG1p Z2h0IGJlIGEgbWlzbGVhZGluZyB0ZXJtIGZvciBzb21lIHdpdGggaXRzIGxlZ2FjeSBjby1ub3Rh dGlvbnMsIHNvIGZlZWwgZnJlZSB0byBwcm9wb3NlIGFuIGFwcHJvcHJpYXRlIHRlcm0gKEkgdGhv dWdodCBzb21lIG9mIHRoZQ0KIGRyYWZ0cyBoYXZlIHVzZWQgZGlmZmVyZW50IHRlcm1pbm9sb2d5 KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1hcmN1 czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Vm9uOiA8L3NwYW4+DQo8L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPm11bHRpcGF0aHRjcCAm bHQ7bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IGltIEF1ZnRyYWcgdm9uICZxdW90 O3BoaWxpcC5lYXJkbGV5QGJ0LmNvbSZxdW90OyAmbHQ7cGhpbGlwLmVhcmRsZXlAYnQuY29tJmd0 Ozxicj4NCjxiPkRhdHVtOiA8L2I+RGllbnN0YWcsIDE4LiBBcHJpbCAyMDE3IHVtIDEwOjE3PGJy Pg0KPGI+QW46IDwvYj4mcXVvdDttdWx0aXBhdGh0Y3BAaWV0Zi5vcmcmcXVvdDsgJmx0O211bHRp cGF0aHRjcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5CZXRyZWZmOiA8L2I+W211bHRpcGF0aHRjcF0g Q29uc2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcms8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkR1cmluZyB0aGUgTVBUQ1AgbWVldGluZyBpbiBD aGljYWdvIHdlIGRpZCBzZXZlcmFsIGh1bXMgYWJvdXQgcG90ZW50aWFsIE1QVENQIHByb3h5IHdv cmsuIE91ciBpbnRlcnByZXRhdGlvbiBvZiB0aGVzZSBodW1zIGlzIHRoYXQgd2Ugc2hvdWxkIGRv IGEgY29uc2Vuc3VzIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcNCiB3b3JrOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLTxicj4NCk1QVENQIGlzIG5vdyBzZWVpbmcgd2lk ZXNwcmVhZCBkZXBsb3ltZW50IGluIG5ldHdvcmtzIHRvIGJvbmQgdG9nZXRoZXIgdHdvIGFjY2Vz c2VzLCBzdWNoIGFzIGZpeGVkIGFuZCBtb2JpbGUgYnJvYWRiYW5kLCBieSB1c2luZyB0d28gTVBU Q1AgcHJveGllcywgb25lIGluIHRoZSBob21lIGdhdGV3YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMg RXF1aXBtZW50IGFuZCBvbmUgaW4gdGhlIG5ldHdvcmsuIFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0 aW9uIHdoZXJlDQogdGhlIHByb3hpZXMgYXJlIGJvdGggdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhl IG9wZXJhdG9yIGFuZCB3aGVyZSBpdCBpcyBhc3N1bWVkIHRoYXQgdGhleSBhcmUgbm90IG9uIHRo ZSBkZWZhdWx0IHBhdGguIFRoZSBzb2x1dGlvbiBpcyBiYXNlZCBvbiB1c2luZyB0aGUgcGF5bG9h ZCBvZiBhbiBNUFRDUCBwYWNrZXQgdG8gdHJhbnNmZXIgYSBzaWduYWxsaW5nIG1lc3NhZ2UgYmV0 d2VlbiB0aGUgcHJveGllcy4gSXQgaXMgYmVsaWV2ZWQgdGhlIHNvbHV0aW9uDQogd2lsbCBub3Qg cmVxdWlyZSBjaGFuZ2VzIHRvIFJGQzY4MjRiaXMuIFRoZSBzb2x1dGlvbiBtYXkgcmVxdWlyZSBh IG1lYW5zIG9mIGNvbmZpZ3VyaW5nIHNldC11cCBpbmZvcm1hdGlvbiBpbiB0aGUgcHJveGllcywg d2hpY2ggd291bGQgYmUgZG9uZSBpbiBjb29yZGluYXRpb24gd2l0aCBvdGhlciBJRVRGIFdHcyBz dWNoIGFzIERIQy4gVGhlIFdHIGRvZXMgbm90IGRldmVsb3AgYSBtZWNoYW5pc20gZm9yIHRoZSB0 d28gcHJveGllcyB0byBkaXNjb3Zlcg0KIGVhY2ggb3RoZXIuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlBsZWFzZSBzYXkgd2hldGhlciB5b3Ugc3VwcG9ydCwgb3IgZG9u4oCZdCBzdXBwb3J0LCBz dWNoIHdvcmsg4oCTIHNvIHdlIGNhbiBzZWUgaWYgdGhlcmXigJlzIGNvbnNlbnN1cyBmb3IgaXQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGlsICZhbXA7IFlvc2hpPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IdW1zIGR1cmluZyB0aGUgbWVldGluZzo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtNjA0Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iPlNob3VsZCB0aGUgTVBU Q1AgV0cgZG8gYW55IE1QVENQIHByb3h5IHdvcmssIG9yIGRvIG5vbmUg4oCTIGFib3V0IDI6MSBv ciAzOjEgaW4gZmF2b3VyIG9mIGRvaW5nIHdvcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibTYwNDY3NjMxNjMwNjk3MzYzMTVtc29saXN0cGFyYWdyYXBoIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIj5TaG91bGQgdGhlIE1QVENQIFdH IGRvIHByb3h5IHdvcmsgYmFzZWQgb24gb3B0aW9uICMxIGluIHNsaWRlIDEyPyBTdHJvbmdseSBt b3JlIHllcyB0aGFuIG5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02MDQ2NzYz MTYzMDY5NzM2MzE1bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+U2hvdWxkIHRoZSBNUFRDUCBXRyBkbyBwcm94eSB3b3Jr IGJhc2VkIG9uIG9wdGlvbiAjMiBpbiBzbGlkZSAxMj8gbW9yZSBubyB0aGFuIHllczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjA0Njc2MzE2MzA2OTczNjMxNW1zb2xpc3RwYXJh Z3JhcGgiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4i PlNob3VsZCB0aGUgTVBUQ1AgV0cgZG8gcHJveHkgd29yayBiYXNlZCBvbiBvcHRpb24gIzMgaW4g c2xpZGUgMTI/IFdlYWsgJmFtcDsgcm91Z2hseSBlcXVhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPlJlZjoNCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtbXB0Y3At c2Vzc2EtY2hhaXJzLTAxLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1jaGFpcnMtMDEu cGRmPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4iPldlIGJlbGlldmUgdGhlIHdvcmsgZG9lcyBub3QgcmVxdWlyZSBhbiB1cGRh dGUgdG8gdGhlIE1QVENQIFdHIGNoYXJ0ZXIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_6DA61EDB03414FFA8034CA12F890E205swisscomcom_-- From nobody Tue Apr 18 23:00:44 2017 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 71452131523 for ; Tue, 18 Apr 2017 23:00:43 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1hVgic3w4eh for ; Tue, 18 Apr 2017 23:00:42 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE61B13151B for ; Tue, 18 Apr 2017 23:00:41 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 31A6AC05BE; Wed, 19 Apr 2017 08:00:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 1033D6008A; Wed, 19 Apr 2017 08:00:40 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 08:00:39 +0200 From: To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" , "philip.eardley@bt.com" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQAZ8zuAABNtuoA= Date: Wed, 19 Apr 2017 06:00:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> In-Reply-To: <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:00:43 -0000 SGkgTWF0dCwgDQoNClllcywgSSBjb25maXJtLiANCg0KKiBOYXRpdmUgTVBUQ1AgY29ubmVjdGlv bnMgY2FuIGJlIGVzdGFibGlzaGVkIGRpcmVjdGx5IHdpdGhvdXQgaW52b2x2aW5nIGEgcHJveHku IA0KKiBJZiB0aGUgY2xpZW50IGlzIG5vdCBNUFRDUC1jYXBhYmxlIGJ1dCB0aGUgc2VydmVyIGlz IE1QVENQLWNhcGFibGUsIHRoZSBjb21tdW5pY2F0aW9uIGxlZyBiZXR3ZWVuIHRoZSBwcm94eSBh bmQgdGhhdCBzZXJ2ZXIgd2lsbCBiZSBwbGFjZWQgdXNpbmcgTVBUQ1AuIA0KDQpQbGVhc2UgcmVm ZXIgdG8sIGUuZy4sIHNsaWRlIDEyIG9mIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk4L3NsaWRlcy9zbGlkZXMtOTgtbXB0Y3Atc2Vzc2EtbmV0d29yay1hc3Npc3RlZC1tcHRjcC0w My5wZGYgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBtdWx0aXBhdGh0Y3AgW21haWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZQ0KPiBTYXJnZW50LCBNYXR0aGV3IFQuIChHUkMtTENBMClbUGVlcmxl c3MgVGVjaG5vbG9naWVzXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDE4IGF2cmlsIDIwMTcgMTc6MzkN Cj4gw4DCoDogcGhpbGlwLmVhcmRsZXlAYnQuY29tDQo+IENjwqA6IG11bHRpcGF0aHRjcEBpZXRm Lm9yZw0KPiBPYmpldMKgOiBSZTogW211bHRpcGF0aHRjcF0gQ29uc2Vuc3VzIGNhbGwgb24gcG90 ZW50aWFsIE1QVENQIHByb3h5IHdvcmsNCj4gDQo+IEhpIFBoaWwsIGFsbCwNCj4gDQo+IEkgaGF2 ZSBhIGNsYXJpZnlpbmcgcXVlc3Rpb24gYWJvdXQgZHVhbCBwcm94eSB3b3JrLg0KPiANCj4gRG9l cyB0aGUgZHVhbCBwcm94eSBzb2x1dGlvbiBoYXZlIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbmF0 aXZlIE1QVENQIGF0DQo+IHRoZSBjbGllbnQgYW5kIHNlcnZlciwgb3IgaXMgdGhlIGFzc3VtcHRp b24gdGhhdCB0aGUgc29sdXRpb24gZm9yY2VzIHRoZQ0KPiB0d28gcHJveGllcyB0byBiZWNvbWUg cGFydCBvZiBhIGNvbm5lY3Rpb24gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZQ0KPiBjbGllbnQg YW5kIHNlcnZlciBhcmUgTVBUQ1AgZW5hYmxlZD8NCj4gDQo+IFRoYW5rcywNCj4gTWF0dA0KPiAN Cj4gPiBPbiBBcHIgMTgsIDIwMTcsIGF0IDQ6MTcgQU0sIHBoaWxpcC5lYXJkbGV5QGJ0LmNvbSB3 cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+IER1cmluZyB0aGUgTVBUQ1AgbWVldGluZyBpbiBDaGlj YWdvIHdlIGRpZCBzZXZlcmFsIGh1bXMgYWJvdXQgcG90ZW50aWFsDQo+IE1QVENQIHByb3h5IHdv cmsuIE91ciBpbnRlcnByZXRhdGlvbiBvZiB0aGVzZSBodW1zIGlzIHRoYXQgd2Ugc2hvdWxkIGRv IGENCj4gY29uc2Vuc3VzIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcgd29yazoNCj4gPiAtLQ0KPiA+ IE1QVENQIGlzIG5vdyBzZWVpbmcgd2lkZXNwcmVhZCBkZXBsb3ltZW50IGluIG5ldHdvcmtzIHRv IGJvbmQgdG9nZXRoZXINCj4gdHdvIGFjY2Vzc2VzLCBzdWNoIGFzIGZpeGVkIGFuZCBtb2JpbGUg YnJvYWRiYW5kLCBieSB1c2luZyB0d28gTVBUQ1ANCj4gcHJveGllcywgb25lIGluIHRoZSBob21l IGdhdGV3YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IGFuZCBvbmUgaW4NCj4gdGhl IG5ldHdvcmsuIFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0aW9uIHdoZXJlIHRoZSBwcm94aWVzIGFy ZSBib3RoIHVuZGVyDQo+IHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQgd2hlcmUgaXQg aXMgYXNzdW1lZCB0aGF0IHRoZXkgYXJlIG5vdCBvbg0KPiB0aGUgZGVmYXVsdCBwYXRoLiBUaGUg c29sdXRpb24gaXMgYmFzZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1ANCj4gcGFj a2V0IHRvIHRyYW5zZmVyIGEgc2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hpZXMu IEl0IGlzDQo+IGJlbGlldmVkIHRoZSBzb2x1dGlvbiB3aWxsIG5vdCByZXF1aXJlIGNoYW5nZXMg dG8gUkZDNjgyNGJpcy4gVGhlIHNvbHV0aW9uDQo+IG1heSByZXF1aXJlIGEgbWVhbnMgb2YgY29u ZmlndXJpbmcgc2V0LXVwIGluZm9ybWF0aW9uIGluIHRoZSBwcm94aWVzLA0KPiB3aGljaCB3b3Vs ZCBiZSBkb25lIGluIGNvb3JkaW5hdGlvbiB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMgREhD LiBUaGUNCj4gV0cgZG9lcyBub3QgZGV2ZWxvcCBhIG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94 aWVzIHRvIGRpc2NvdmVyIGVhY2gNCj4gb3RoZXIuDQo+ID4gLS0NCj4gPiBQbGVhc2Ugc2F5IHdo ZXRoZXIgeW91IHN1cHBvcnQsIG9yIGRvbuKAmXQgc3VwcG9ydCwgc3VjaCB3b3JrIOKAkyBzbyB3 ZSBjYW4NCj4gc2VlIGlmIHRoZXJl4oCZcyBjb25zZW5zdXMgZm9yIGl0Lg0KPiA+DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtdWx0aXBh dGh0Y3AgbWFpbGluZyBsaXN0DQo+IG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpcGF0aHRjcA0K From nobody Tue Apr 18 23:27:35 2017 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 044C4131508 for ; Tue, 18 Apr 2017 23:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq_dxfzDVPyC for ; Tue, 18 Apr 2017 23:27:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E799A129449 for ; Tue, 18 Apr 2017 23:27:30 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-65-58f7034e24f1 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id E4.66.21650.E4307F85; Wed, 19 Apr 2017 08:27:29 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 19 Apr 2017 08:27:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n6Ly0R3ZyT8CzZcom1a4UG2+EuPUGHuD0pb5ZNbitoY=; b=GZFjB/zwkJ2fWo5TkZaoSrj/+3rkezgXs3ubX7CbPH9At1qTqTdSs2J5+kjtQPrj0TGlbDflpvnx9Xpl7mJ7MYLAsB+HdKruUpsq7OM6/gBT7OreBBAXLwt2GXaaFZP/poIF7QfC1G5+HUpNrtzmlh58uWyKMhYg7HC/RNv7028= Received: from HE1PR07MB1258.eurprd07.prod.outlook.com (10.164.51.144) by HE1PR07MB1259.eurprd07.prod.outlook.com (10.164.51.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 06:27:24 +0000 Received: from HE1PR07MB1258.eurprd07.prod.outlook.com ([10.164.51.144]) by HE1PR07MB1258.eurprd07.prod.outlook.com ([10.164.51.144]) with mapi id 15.01.1047.008; Wed, 19 Apr 2017 06:27:24 +0000 From: Robert Skog To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAuaokA Date: Wed, 19 Apr 2017 06:27:24 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bt.com; dkim=none (message not signed) header.d=none;bt.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1259; 7:Pe6CuYGG4DRqqJPhSZgHhJsEEWw8NF1W9kwh/Y7qv4+IWa92ZdqImWpljBozDIZz3yL/vkgCv60RJHeFtFi1OwVTMPl5YWSgqVJ/9clvTGND9k4o1IjIYnfhLVDpyysfN+h0ewmjdz6Zo5gitH6qZVoFJ94jVNxpN7Xk2iRLRLVM9bVO+YFkQAJmZtSqedg2vRFUwR21Pu1zV65fb6d2bKW/PY/E35PdxdpzJPX6jE1QKFh1jyUNqyWAJF5TZWj8EXwJrP2XicNIV+UjNuvcbCabLP1pARhJRp+/sjbx8ebFiggf2xq3qVjv+RatP2CW+gatZ0DkjtgOzJs6A4XiHg== x-ms-office365-filtering-correlation-id: 1ea5cb24-e643-4ac1-5c4e-08d486ed24a4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB1259; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(146908506813832)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:HE1PR07MB1259; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1259; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(790700001)(3846002)(7696004)(6116002)(102836003)(53546009)(25786009)(38730400002)(54356999)(50986999)(76176999)(6506006)(55016002)(6436002)(3660700001)(3280700002)(5660300001)(606005)(77096006)(99286003)(6306002)(54896002)(2906002)(236005)(9686003)(33656002)(81166006)(2501003)(189998001)(8936002)(7736002)(229853002)(7906003)(2950100002)(86362001)(53936002)(66066001)(8676002)(74316002)(122556002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1259; H:HE1PR07MB1258.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB125809F486A89F80A383544B8B180HE1PR07MB1258eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 06:27:24.0810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1259 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUyM2K7tG4g8/cIg51PmCw+r77OZrFs7QpG ByaPti+TmTyWLPnJFMAUxWWTkpqTWZZapG+XwJXx8OdGtoK3IRXfetqZGhj3enUxcnJICJhI TFz7iL2LkYtDSGA9o8S13uvMEM4JRonZa08xgjgsAr3MEt+Xv4Mqm8Yk0Xx+OwuEc4xR4tSp eSwgw9gEdCQ2LlzPCmKLCKRJ7FnyB2gWB4ewgKXExjmOEGEriZaJz9khbCOJY1MeM4HYLAKq EltfNYGN4RWIkVg19yRYjZBAiMS0HUvBbE6BUInOWwfBxjMKiEl8P7UGrJdZQFzi1pP5TBD/ CEgs2XOeGcIWlXj5+B8ryJ2MAu2MElNfNrJAJBQkXnU3sIEkJAR6mCWOLrgE1eErsannBwtE op9RYvKLDlaIRLbEu/23GSHsGIkNZz5BFV1kklj6qQ2qW0ai/+wMVojEBFaJJ7Nvgh0lLCAl cfdKJyOELSPx4s5eVojD8yXWzNjKOIFRfRaSP2YhSc0Ch4egxMmZT1gg4joSC3Z/YoOwtSWW LXzNDGOfOfCYCVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzANHRwy2+rHYwHnzse YhTgYFTi4X0g/S1CiDWxrLgy9xCjBAezkgjvug9fI4R4UxIrq1KL8uOLSnNSiw8xSnOwKInz Ouy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgnPunz2ZDi17LsTBJ49tuM7dFl88+PeftnF7+1Vs9 /nQx5N2dlPEwIN7RQWYL36O5Sjo6wR4uYYbGa9hEjla8Z3x84O/TFZvNRP4ppky9HzhBp2aP yVWuk0lrf2i3HSi8JZ+n5bbO7vYJ7du/WXne9t/8YrzKOedo1rzo31PtP67l2BV79HjueiWW 4oxEQy3mouJEAF2BbmI/AwAA Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:27:33 -0000 --_000_HE1PR07MB125809F486A89F80A383544B8B180HE1PR07MB1258eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I fully support the work on MPTCP-Proxy. Cheers, /Robert From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: den 18 april 2017 10:17 To: multipathtcp@ietf.org Subject: [multipathtcp] Consensus call on potential MPTCP proxy work Hi, During the MPTCP meeting in Chicago we did several hums about potential MPT= CP proxy work. Our interpretation of these hums is that we should do a cons= ensus call for the following work: -- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control = of the operator and where it is assumed that they are not on the default pa= th. The solution is based on using the payload of an MPTCP packet to transf= er a signalling message between the proxies. It is believed the solution wi= ll not require changes to RFC6824bis. The solution may require a means of c= onfiguring set-up information in the proxies, which would be done in coordi= nation with other IETF WGs such as DHC. The WG does not develop a mechanism= for the two proxies to discover each other. -- Please say whether you support, or don't support, such work - so we can see= if there's consensus for it. Thanks Phil & Yoshi Hums during the meeting: * Should the MPTCP WG do any MPTCP proxy work, or do none - about 2= :1 or 3:1 in favour of doing work * Should the MPTCP WG do proxy work based on option #1 in slide 12?= Strongly more yes than no * Should the MPTCP WG do proxy work based on option #2 in slide 12?= more no than yes * Should the MPTCP WG do proxy work based on option #3 in slide 12?= Weak & roughly equal Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chair= s-01.pdf We believe the work does not require an update to the MPTCP WG charter. --_000_HE1PR07MB125809F486A89F80A383544B8B180HE1PR07MB1258eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

I fully support the work on MPTCP-Proxy.=

 

Cheers,

/Robert

 

From: multipathtcp [mailto:multipath= tcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: den 18 april 2017 10:17
To: multipathtcp@ietf.org
Subject: [multipathtcp] Consensus call on potential MPTCP proxy work=

 

Hi,

During the MPTCP meeting in Chicago we did se= veral hums about potential MPTCP proxy work. Our interpretation of these hu= ms is that we should do a consensus call for the following work:

--
MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband, by using two MPTCP proxies, o= ne in the home gateway or Customer Premises Equipment and one in the networ= k. The WG develops a solution where the proxies are both under the control of the operator and where it is ass= umed that they are not on the default path. The solution is based on using = the payload of an MPTCP packet to transfer a signalling message between the= proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means o= f configuring set-up information in the proxies, which would be done in coo= rdination with other IETF WGs such as DHC. The WG does not develop a mechan= ism for the two proxies to discover each other.

--

Please say whether you support, or don’= t support, such work – so we can see if there’s consensus for i= t.

Thanks

Phil & Yoshi

 

Hums during the meeting:

·         Should the MPTCP WG do any MPTCP proxy work, or do= none – about 2:1 or 3:1 in favour of doing work

·         Should the MPTCP WG do proxy work based on option = #1 in slide 12? Strongly more yes than no<= /o:p>

·         Should the MPTCP WG do proxy work based on option = #2 in slide 12? more no than yes

·         Should the MPTCP WG do proxy work based on option = #3 in slide 12? Weak & roughly equal

Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.= pdf

We believe the work does not require an update t= o the MPTCP WG charter.

 

--_000_HE1PR07MB125809F486A89F80A383544B8B180HE1PR07MB1258eurp_-- From nobody Wed Apr 19 00:23:30 2017 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 4843A131529 for ; Wed, 19 Apr 2017 00:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udDbG-8MBa6F for ; Wed, 19 Apr 2017 00:23:26 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80704126CD8 for ; Wed, 19 Apr 2017 00:23:26 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Apr 2017 08:23:21 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 19 Apr 2017 08:23:24 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 08:23:23 +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.1210.000; Wed, 19 Apr 2017 08:23:23 +0100 From: To: CC: Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAABZp5nA= Date: Wed, 19 Apr 2017 07:23:23 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> In-Reply-To: <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:23:29 -0000 TWF0dCwNCg0KRHVyaW5nIHRoZSBkaXNjdXNzaW9uIGluIENoaWNhZ28sIHdlIHB1dCB1cCBhIHNs aWRlIGFib3V0ICdhc3N1bXB0aW9ucyAmIGNyaXRlcmlhJyAoZm9yIHNvbHV0aW9ucykgLSBvbmUg b2Ygd2hpY2ggaXMgDQo+PkRvbuKAmXQgaW50ZXJmZXJlIHdpdGggbm9ybWFsIE1QVENQIChib3Ro IGVuZHBvaW50cyBNUFRDUCBlbmFibGVkKQ0KDQpbc2xpZGUgMTEgb2YgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1jaGFpcnMt MDEucGRmIF0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNhcmdlbnQsIE1h dHRoZXcgVC4gKEdSQy1MQ0EwKVtQZWVybGVzcyBUZWNobm9sb2dpZXNdIFttYWlsdG86bWF0dGhl dy50LnNhcmdlbnRAbmFzYS5nb3ZdIA0KU2VudDogMTggQXByaWwgMjAxNyAxNjozOQ0KVG86IEVh cmRsZXksUEwsUGhpbGlwLFRVRDEgUiA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPg0KQ2M6IG11bHRp cGF0aHRjcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBj YWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCkhpIFBoaWwsIGFsbCwNCg0KSSBo YXZlIGEgY2xhcmlmeWluZyBxdWVzdGlvbiBhYm91dCBkdWFsIHByb3h5IHdvcmsuDQoNCkRvZXMg dGhlIGR1YWwgcHJveHkgc29sdXRpb24gaGF2ZSB0aGUgYWJpbGl0eSB0byBzdXBwb3J0IG5hdGl2 ZSBNUFRDUCBhdCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIsIG9yIGlzIHRoZSBhc3N1bXB0aW9uIHRo YXQgdGhlIHNvbHV0aW9uIGZvcmNlcyB0aGUgdHdvIHByb3hpZXMgdG8gYmVjb21lIHBhcnQgb2Yg YSBjb25uZWN0aW9uIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIg YXJlIE1QVENQIGVuYWJsZWQ/DQoNClRoYW5rcywNCk1hdHQNCg0KPiBPbiBBcHIgMTgsIDIwMTcs IGF0IDQ6MTcgQU0sIHBoaWxpcC5lYXJkbGV5QGJ0LmNvbSB3cm90ZToNCj4gDQo+IEhpLA0KPiBE dXJpbmcgdGhlIE1QVENQIG1lZXRpbmcgaW4gQ2hpY2FnbyB3ZSBkaWQgc2V2ZXJhbCBodW1zIGFi b3V0IHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrLiBPdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhl c2UgaHVtcyBpcyB0aGF0IHdlIHNob3VsZCBkbyBhIGNvbnNlbnN1cyBjYWxsIGZvciB0aGUgZm9s bG93aW5nIHdvcms6DQo+IC0tDQo+IE1QVENQIGlzIG5vdyBzZWVpbmcgd2lkZXNwcmVhZCBkZXBs b3ltZW50IGluIG5ldHdvcmtzIHRvIGJvbmQgdG9nZXRoZXIgdHdvIGFjY2Vzc2VzLCBzdWNoIGFz IGZpeGVkIGFuZCBtb2JpbGUgYnJvYWRiYW5kLCBieSB1c2luZyB0d28gTVBUQ1AgcHJveGllcywg b25lIGluIHRoZSBob21lIGdhdGV3YXkgb3IgQ3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IGFu ZCBvbmUgaW4gdGhlIG5ldHdvcmsuIFRoZSBXRyBkZXZlbG9wcyBhIHNvbHV0aW9uIHdoZXJlIHRo ZSBwcm94aWVzIGFyZSBib3RoIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvciBhbmQg d2hlcmUgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZXkgYXJlIG5vdCBvbiB0aGUgZGVmYXVsdCBwYXRo LiBUaGUgc29sdXRpb24gaXMgYmFzZWQgb24gdXNpbmcgdGhlIHBheWxvYWQgb2YgYW4gTVBUQ1Ag cGFja2V0IHRvIHRyYW5zZmVyIGEgc2lnbmFsbGluZyBtZXNzYWdlIGJldHdlZW4gdGhlIHByb3hp ZXMuIEl0IGlzIGJlbGlldmVkIHRoZSBzb2x1dGlvbiB3aWxsIG5vdCByZXF1aXJlIGNoYW5nZXMg dG8gUkZDNjgyNGJpcy4gVGhlIHNvbHV0aW9uIG1heSByZXF1aXJlIGEgbWVhbnMgb2YgY29uZmln dXJpbmcgc2V0LXVwIGluZm9ybWF0aW9uIGluIHRoZSBwcm94aWVzLCB3aGljaCB3b3VsZCBiZSBk b25lIGluIGNvb3JkaW5hdGlvbiB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2ggYXMgREhDLiBUaGUg V0cgZG9lcyBub3QgZGV2ZWxvcCBhIG1lY2hhbmlzbSBmb3IgdGhlIHR3byBwcm94aWVzIHRvIGRp c2NvdmVyIGVhY2ggb3RoZXIuDQo+IC0tDQo+IFBsZWFzZSBzYXkgd2hldGhlciB5b3Ugc3VwcG9y dCwgb3IgZG9u4oCZdCBzdXBwb3J0LCBzdWNoIHdvcmsg4oCTIHNvIHdlIGNhbiBzZWUgaWYgdGhl cmXigJlzIGNvbnNlbnN1cyBmb3IgaXQuDQo+IA0KDQo= From nobody Wed Apr 19 00:37:30 2017 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 445F41314B4 for ; Wed, 19 Apr 2017 00:37:28 -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 Y4lXcwkjMU_0 for ; Wed, 19 Apr 2017 00:37:26 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0824129426 for ; Wed, 19 Apr 2017 00:37:25 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3732E67DA45; Wed, 19 Apr 2017 09:37:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 3732E67DA45 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1492587437; bh=opCfbUjt4njz7KH0xYKb3KgzbxztT7dXLPBhe4KpAcY=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=peQC4Ww4rRjx3vcxvS7BqSH1TskeVwsr/B5f8qyJ+xyqhmbSXPHUlCUUi1Zpv+DY/ KCUz385DuPuUCBv/3owM3ew8oErvavAAuuFVIvrNyjKb+iNs8sX3T8xZrBiiq0MfUM 5oytVp9ghH1CKWRv2DigCPjC2VpbGsds3oqQnzQA= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> To: philip.eardley@bt.com, multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: Date: Wed, 19 Apr 2017 09:37:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3732E67DA45.A2045 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:37:28 -0000 Phil, > > During the MPTCP meeting in Chicago we did several hums about potential > MPTCP proxy work. Our interpretation of these hums is that we should do > a consensus call for the following work: > > -- > MPTCP is now seeing widespread deployment in networks to bond together > two accesses, such as fixed and mobile broadband, by using two MPTCP > proxies, one in the home gateway or Customer Premises Equipment and one > in the network. The WG develops a solution where the proxies are both > under the control of the operator and where it is assumed that they are > not on the default path. The solution is based on using the payload of > an MPTCP packet to transfer a signalling message between the proxies. It > is believed the solution will not require changes to RFC6824bis. The > solution may require a means of configuring set-up information in the > proxies, which would be done in coordination with other IETF WGs such as > DHC. The WG does not develop a mechanism for the two proxies to discover > each other. > I fully support the work on MPTCP proxies. I would not focus on the current use case (how gateway and two proxies) but more on the importance of : - being able to terminate Multipath TCP connections on a proxy somewhere in the network to bond different access networks when the server is not MPTCP capable - using 0-rtt, i.e. the proposed solution should not require an additional rtt to create a connection The solution will use data in the SYN payload to achieve 0-rtt and should not require changes to RFC6824bis Then different use cases can be built on top of this protocol. The Home gateway case that we discussed in Chicago is the first one, but smartphones are another one. I would suggest to separate the work in different documents : - a first draft describing the syntax of the messages added to the SYN - a second draft describing how the above protocol can be used to support hybrid access networks with two proxies - a third draft describing how the above protocol can be used on smartphones Other use cases are possible Olivier From nobody Wed Apr 19 00:42:38 2017 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 83E95129426 for ; Wed, 19 Apr 2017 00:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tElh8FWCfUT for ; Wed, 19 Apr 2017 00:42:34 -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 ADCBD13153A for ; Wed, 19 Apr 2017 00:42:34 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 09D0A2790C8 for ; Wed, 19 Apr 2017 16:42:32 +0900 (JST) Received: by mail-oi0-f54.google.com with SMTP id x184so18460941oia.1 for ; Wed, 19 Apr 2017 00:42:31 -0700 (PDT) X-Gm-Message-State: AN3rC/64AedJOfEKn2zbPsOAP79jN0kkWjqrtpPRnlb/5PYEsPtXAKI5 sPaobwjR5aJbkWKA3xAMRGEiy+NyYA== X-Received: by 10.202.77.66 with SMTP id a63mr602079oib.136.1492587750865; Wed, 19 Apr 2017 00:42:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Wed, 19 Apr 2017 00:42:30 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 19 Apr 2017 00:42:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary=001a1135155cafd9d4054d802a7d Archived-At: Subject: [multipathtcp] draft minute for chicago meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:42:37 -0000 --001a1135155cafd9d4054d802a7d Content-Type: text/plain; charset=UTF-8 Hi, We've prepared a draft minute for Chicago meeting on the following URL. https://www.ietf.org/proceedings/98/minutes/minutes-98-mptcp-01.txt If you have corrections or questions or comments, please let chairs know. We appreciate Rolf and Christoph for precise note taking! Thanks, -- Yoshi & Phil --001a1135155cafd9d4054d802a7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
We've prepared a draft minute for Chicago meet= ing on the following URL.

If you have = corrections or questions or comments, please let chairs know. We appreciate= Rolf and Christoph for precise note taking!

Thank= s,
--
Yoshi & Phil
--001a1135155cafd9d4054d802a7d-- From nobody Wed Apr 19 01:04:55 2017 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 0F202131554 for ; Wed, 19 Apr 2017 01:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_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 izuswp1CPPq9 for ; Wed, 19 Apr 2017 01:04:51 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2E8131552 for ; Wed, 19 Apr 2017 01:04:50 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ANmibxhVMth+OtzQYqTrb9D6W9w3V8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbRKEt8tkgFKBZ4jH8fUM07OQ6PG8HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLd9IRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZHoyz?= =?us-ascii?q?YJYBAeoDMuhWoIfzpFUOowW5CwS3GOPv0zpIimP23aEmzegsFxzN0gw6H9IJtX?= =?us-ascii?q?TZtMv4NKAJUeCpzanIyyjIYe9M1jf89IfIcw0hquyLUL1sdsrR0lUvFwLDjlmK?= =?us-ascii?q?s4zqJTKV2fgMs2iG9OdvSfmvh3Q/qwFsuTej3N0sio7Qi48T11vK9j15zZ4oKd?= =?us-ascii?q?C3VUJ3e92pHZtKuy2EKYd7QNkuTm9wtConxbAKpIS3cSsKxZg92RLSZfKKf5KV?= =?us-ascii?q?7h/sSuqcJypzimh/d7KlnRmy9FCtyuj7VsapzllHtjFFktzQtnAV0BzT99SHRu?= =?us-ascii?q?N9/ki/3TaP0Bje6v9BIU8ulKrbL4QtzaIrlpYJqUTDAzT5lF/sjK+Rbkkk++6o?= =?us-ascii?q?5Pr7Yrj+u5OROJJ4hhv9P6kugMCzH/o0PwoUU2WV4ei80afs/Uz9QLVElP02la?= =?us-ascii?q?zZvYjGKsQcva65Hw5V0oA55xalFTim0cgXnXgaLF9eZB2HlJLlO0nTIP/jF/u/?= =?us-ascii?q?mVOsnC9xx//aJr3hHonNLn/bnbf5fbZ96kpcyAsrzdxF+Z1bEKsBL+/3WkDvtN?= =?us-ascii?q?3VFQQ2MxCuz+n7D9V905sUWXiTDa+BLKPSrViI6/oqI+mRYI8VpDf9K+A/6P7y?= =?us-ascii?q?jX85hUMSfbGy0JsWdn+4AvpmL1+eYXr2jdcLCX0KsRYmTOz2lF2CViZeaW+2X6?= =?us-ascii?q?I9+DE7CZypDZ3ZSo2wh7yB2j20HoNIaWBAFlCMDG3oeJufVvcRdC2SJshhkiEa?= =?us-ascii?q?Vbe7So8h0wuiuxTkxOkvEu2B3SkZq5PuzpBf4Ovaixw06SFuAozJ9GWMUWB5hC?= =?us-ascii?q?UiQDk/wq15vVFnx3+e2qx/nuJRFNoV7f4fASkgMpuJ5OthF9H0EjjIf9yIVR7y?= =?us-ascii?q?SdK9HTA3CMg4wtQPfm52AJO6kxqFxS38UOxdrKCCGJFhqvGU5HP2Pcsoji+ejK?= =?us-ascii?q?Q=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CCCgDrGPdY/wPjVY1cHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhA2Pd5Bwl3GGJAKEUgEBAQEBAQEBAgFqKIIzIgGCQAEEATo/BQs?= =?us-ascii?q?LRlcGLol2DK1mizABAQEHAQEBAQEjhlOCCIJuhEEWgzSCMQWQfowvggibVIZdj?= =?us-ascii?q?1SEOgJXgQUmHYEKAYJDhBOKBwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2CCCgDrGPdY/wPjVY1cHAEBBAEBCgEBFwEBBAEBCgEBhA2?= =?us-ascii?q?Pd5Bwl3GGJAKEUgEBAQEBAQEBAgFqKIIzIgGCQAEEATo/BQsLRlcGLol2DK1mi?= =?us-ascii?q?zABAQEHAQEBAQEjhlOCCIJuhEEWgzSCMQWQfowvggibVIZdj1SEOgJXgQUmHYE?= =?us-ascii?q?KAYJDhBOKBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,220,1488837600"; d="scan'208";a="689982" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 19 Apr 2017 11:04:47 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 72B1D1A6004C; Wed, 19 Apr 2017 11:04:47 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VJ0wcTrKF6wl; Wed, 19 Apr 2017 11:04:47 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 54E221A6005A; Wed, 19 Apr 2017 11:04:47 +0300 (EEST) Received: from [192.168.0.158] (unknown [141.85.233.142]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 4E2291A6004C; Wed, 19 Apr 2017 11:04:47 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Costin Raiciu In-Reply-To: Date: Wed, 19 Apr 2017 11:04:47 +0300 Cc: philip.eardley@bt.com, multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <262C92B8-A35E-4C46-B2F6-C0A82BEE21AF@cs.pub.ro> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> To: Olivier Bonaventure X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:04:54 -0000 > I fully support the work on MPTCP proxies. I would not focus on the = current use case (how gateway and two proxies) but more on the = importance of : >=20 > - being able to terminate Multipath TCP connections on a proxy = somewhere in the network to bond different access networks when the = server is not MPTCP capable > - using 0-rtt, i.e. the proposed solution should not require an = additional rtt to create a connection + 1. Also, the solution should be future proof - if the server does support = MPTCP, the proxy should simply relay the traffic, and not terminate the = connection, allowing the client to directly connect to the server with = other subflows. Best. Costin= From nobody Wed Apr 19 01:19:16 2017 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 8DBED13156E for ; Wed, 19 Apr 2017 01:19:15 -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 d7EYT_jZ_xVW for ; Wed, 19 Apr 2017 01:19:14 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250B313156C for ; Wed, 19 Apr 2017 01:19:14 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A1D4867DB04; Wed, 19 Apr 2017 10:19:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be A1D4867DB04 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1492589945; bh=Hrn8OTr52WPCZUoBQR71vltp5vYkSN43+BHWQCP/dIE=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=qt9xoznTsbYCxPMG4B1AzkmvM8p0kW4OOJnQ+VbgyUFoS4LKPPP1N5MtH8LTH/nsY X056BqRd4FJcoFQOqr3ss5jbcfnUoOiApeVo/sBKG2fMOCGCw631t+Pvj0pt0ecS7B pHIu0zidvLpu8hxP1XxcQ6tvDZDbTQ6VPO3Op0QE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6 Reply-To: Olivier.Bonaventure@uclouvain.be References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <262C92B8-A35E-4C46-B2F6-C0A82BEE21AF@cs.pub.ro> To: Costin Raiciu Cc: philip.eardley@bt.com, multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <231d1dd6-9d9f-4a5f-d1c6-bf8b33607430@uclouvain.be> Date: Wed, 19 Apr 2017 10:19:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <262C92B8-A35E-4C46-B2F6-C0A82BEE21AF@cs.pub.ro> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: A1D4867DB04.A5213 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:19:15 -0000 Costin, >> I fully support the work on MPTCP proxies. I would not focus on the current use case (how gateway and two proxies) but more on the importance of : >> >> - being able to terminate Multipath TCP connections on a proxy somewhere in the network to bond different access networks when the server is not MPTCP capable >> - using 0-rtt, i.e. the proposed solution should not require an additional rtt to create a connection > > + 1. > > Also, the solution should be future proof - if the server does support MPTCP, the proxy should simply relay the traffic, and not terminate the connection, allowing the client to directly connect to the server with other subflows. Since the proxy is explict, the client creates an MPTCP connection to the proxy and the proxy creates another MPTCP connection to the final server. Since the proxy was the destination of the SYN, it cannot simply relay the traffic, but it should indicate to the client that the server supports MPTCP so that the next connection established by the client towards this server can directly bypass the proxy. This information about the MPTCP support on the final server could be part of the signalling information contained in the payload of the SYN+ACK Olivier From nobody Wed Apr 19 06:38:18 2017 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 AE032129537 for ; Wed, 19 Apr 2017 06:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0bZQ91mguzK for ; Wed, 19 Apr 2017 06:38:07 -0700 (PDT) Received: from ndmsvnpf104.ndc.nasa.gov (NDMSVNPF104.ndc.nasa.gov [198.117.0.154]) (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 8D1F112956D for ; Wed, 19 Apr 2017 06:38:04 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.199; helo=ndjsppt105.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndmsvnpf104.ndc.nasa.gov 093C340913B7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492609083; bh=Y6MKw0DEVg4+TPnaMpNTQMCyVJuTEkmlsqY56cdb1bI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=FpPZZRA3A3fCWXnP/oNc9HRb4Pw2hnmGyk+ZD1HhP1oWM/9AVvB5Mko1A1IzFgDu4 ZgY2CObhgzftO80Y8e2uEtR+dezZQ93jYYh4th4agcDXSqCbqKCLvLE0beKBsPb/eB T4eR1K3D3uvvSlDU+vwBDtDiBZ8D1/TGPFxDLy9LkkE4tkeWGPNGHIoa8u40Df3uLo GXwpNwiS6erDjGiaLSxRVEijf8yvAw6a+FCiHkzSmwdZYjyBSaTR3leX0ed4a4KTEb PwJZ04LYdjcSFaDYKvVZyITCfMKC214EnYqcenOsRBoxenEhIC2I0GW32VhHRigZ/H B6NrVaD1o5jqg== Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndmsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 093C340913B7; Wed, 19 Apr 2017 08:38:03 -0500 (CDT) Received: from pps.filterd (ndjsppt105.ndc.nasa.gov [127.0.0.1]) by ndjsppt105.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3JDWmlr008912; Wed, 19 Apr 2017 08:38:02 -0500 Received: from ndjscht112.ndc.nasa.gov (ndjscht112-pub.ndc.nasa.gov [198.117.1.212]) by ndjsppt105.ndc.nasa.gov with ESMTP id 29x6fyrpnu-1; Wed, 19 Apr 2017 08:38:02 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.9]) by NDJSCHT112.ndc.nasa.gov ([198.117.1.182]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 08:38:01 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: "mohamed.boucadair@orange.com" CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAAB4TboAAD/kHAA== Date: Wed, 19 Apr 2017 13:38:00 +0000 Message-ID: <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-19_11:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:38:13 -0000 Hi Med, > On Apr 19, 2017, at 2:00 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Matt,=20 >=20 > Yes, I confirm.=20 >=20 > * Native MPTCP connections can be established directly without involving = a proxy.=20 > * If the client is not MPTCP-capable but the server is MPTCP-capable, the= communication leg between the proxy and that server will be placed using M= PTCP.=20 >=20 I am not sure I understand how you maintain native MPTCP connections in the= dual proxy case. I am assuming a network that is set up like you have on slide 10. 1 address= on the client, 1 address on the server, multiple paths are "hidden" by the= MCP's. Do you mean to claim that installing MPTCP on the client and server will re= sult in an MPTCP connection that "works" in the sense that it will contain = multiple subflows to use the available paths in the network? How would this= work without additional signaling? Sorry if I am missing something obvious here. Thanks, Matt= From nobody Wed Apr 19 11:12:33 2017 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 770571275AB for ; Wed, 19 Apr 2017 11:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j00TfaxpWw8 for ; Wed, 19 Apr 2017 11:12:29 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1379A129BAF for ; Wed, 19 Apr 2017 11:12:29 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3JIBwBF019808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 11:11:59 -0700 (PDT) To: mohamed.boucadair@orange.com, Yoshifumi Nishida References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: multipathtcp From: Joe Touch Message-ID: <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> Date: Wed, 19 Apr 2017 11:11:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------52F1CE6E337F51560B9D163A" X-MailScanner-ID: v3JIBwBF019808 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:12:31 -0000 This is a multi-part message in MIME format. --------------52F1CE6E337F51560B9D163A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 4/18/2017 10:46 PM, mohamed.boucadair@orange.com wrote: > ... > > Using the SYN data as control information is the hazardous part. > > [Med] It isn’t for the for the simple reason that legacy Internet > nodes will never receive a SYN with CPE-supplied data and that the TCP > peer is known to process the supplied data. A Guard against > misconfigurations is supported: echo in a SYN/ACK. > The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics. Putting data in the SYN of TFO is permitted only because of previous state. MPTCP doesn't have that state and so it is hazardous to put data in the SYN. I.e., if you want TFO-like performance, figure out how to use TFO. Period. Joe --------------52F1CE6E337F51560B9D163A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/18/2017 10:46 PM, mohamed.boucadair@orange.com wrote:
...

Using the SYN data as control information is the hazardous part.

[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.


The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics.

Putting data in the SYN of TFO is permitted only because of previous state.

MPTCP doesn't have that state and so it is hazardous to put data in the SYN.

I.e., if you want TFO-like performance, figure out how to use TFO. Period.

Joe
--------------52F1CE6E337F51560B9D163A-- From nobody Wed Apr 19 11:17:22 2017 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 69BE5129BC5 for ; Wed, 19 Apr 2017 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w7ExFTisvEE for ; Wed, 19 Apr 2017 11:17:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8F7129BC1 for ; Wed, 19 Apr 2017 11:17:16 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3JIGsGJ020457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 11:16:54 -0700 (PDT) To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Apr 2017 11:16:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------482EB168584017596E8E48D7" X-MailScanner-ID: v3JIGsGJ020457 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:17:20 -0000 This is a multi-part message in MIME format. --------------482EB168584017596E8E48D7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote: > > As explained in my previous message, there is no layered congestion > control. All packets are transported over plain TCP: no encap, no tunnel. > I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed: > I really reiterate my comment to read > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf > Here's what those slides do not explain: - is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples? - what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection? NOTE: if the latter, then you still end up with layered congestion control - what is the proxy relaying? is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet? NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO? There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things: a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea So which is it? Or is it something else? Joe --------------482EB168584017596E8E48D7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:

 I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?
   
    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?

Joe

--------------482EB168584017596E8E48D7-- From nobody Wed Apr 19 11:59:29 2017 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 5C772129BEE for ; Wed, 19 Apr 2017 11:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.08 X-Spam-Level: X-Spam-Status: No, score=-4.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=Jordan.Melzer@telus.com header.d=telus.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 Y17wxWcaRmpt for ; Wed, 19 Apr 2017 11:59:25 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDBD129B1D for ; Wed, 19 Apr 2017 11:59:25 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:Received:Received:From:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=vNtCLMo3Zeqde85EeErEE84lfJxccHcqCM575adrw4YHjqFI9BlSH6w4 9j9g/qfW0EdizkoHhdfa6VuPOD0LVBlAXfUT82/7Ls5fwBnY+boRhQ9A2 g1UJ8pflstj4lgzKc+gJ2rSR5wUUNPNwbOL/bJ8WRJ2GakpI5gh+jgwmI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CEAgDwsvdY/5Jjso5cDg0BAQEDAQEBCQEBAYJuIUVREIELB411kWOVYoIPByeFdgKEBD8YAQIBAQEBAQEBayiFFQEBAQEBAi0mNgIBCA0EBAEBKAcCMBQJCAIEARIIBooLAQQJrGIminwBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgUJAYZJgV2DGYRuH4UvBZ0vhAiCEYxaggmGIYJlDIY6lBEfOIEFJh0ghT8cgSY9dQGHXQGBDAEBAQ X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="p7s'?scan'208,217";a="630702717" Received: from unknown (HELO WP40081.corp.ads) ([142.178.99.146]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 19 Apr 2017 18:59:20 +0000 Received: from BTWP000356.corp.ads (142.174.108.66) by WP40081.corp.ads (142.178.99.146) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 19 Apr 2017 12:59:20 -0600 Received: from BTWP000357.corp.ads (142.174.108.67) by BTWP000356.corp.ads (142.174.108.66) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 19 Apr 2017 11:59:19 -0700 Received: from BTWP000357.corp.ads ([fe80::3d29:ad33:93d3:ea45]) by BTWP000357.corp.ads ([fe80::3d29:ad33:93d3:ea45%14]) with mapi id 15.00.1236.000; Wed, 19 Apr 2017 11:59:18 -0700 From: Jordan Melzer To: Joe Touch , "mohamed.boucadair@orange.com" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZmmuAAAIejQAAAROGgAAeOxGAABrmbIAADYFJwA== Date: Wed, 19 Apr 2017 18:59:18 +0000 Message-ID: <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [142.63.9.82] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0026_01D2B91D.849CE2B0" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:59:28 -0000 ------=_NextPart_000_0026_01D2B91D.849CE2B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0027_01D2B91D.849CE2B0" ------=_NextPart_001_0027_01D2B91D.849CE2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It's a conventional proxy. There are different sockets on each side of the proxy, different RTTs, different congestion control. The proposal is to find a near-zero overhead way to do this when the proxy is off-path (ie, when it's not a simple connection hijack). This may be totally possible without a new RFC - Christoph Paasch suggested that SOCKS + TFO could basically become this, but I am not sure anyone who cared either caught it or agreed. Re b), it's off-topic, but what would you think of a multipath tunnel that was basically MPTCP with the retransmissions gutted out? I had thought this would be what BANANA is doing, but I am not clear there are any two people in BANANA who agree on what it is. From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch Sent: April 19, 2017 02:17 PM To: mohamed.boucadair@orange.com; philip.eardley@bt.com; multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote: As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel. I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed: I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-ass isted-mptcp-03.pdf Here's what those slides do not explain: - is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples? - what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection? NOTE: if the latter, then you still end up with layered congestion control - what is the proxy relaying? is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet? NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO? There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things: a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea So which is it? Or is it something else? Joe ------=_NextPart_001_0027_01D2B91D.849CE2B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s a conventional proxy.  There are different sockets on = each side of the proxy, different RTTs, different congestion = control.  The proposal is to find a near-zero overhead way to do = this when the proxy is off-path (ie, when it’s not a simple = connection hijack).  This may be totally possible without a new RFC = – Christoph Paasch suggested that SOCKS + TFO could basically = become this, but I am not sure anyone who cared either caught it or = agreed.

 

Re b), it’s off-topic, but what would you think of a multipath = tunnel that was basically MPTCP with the retransmissions gutted out? =  I had thought this would be what BANANA is doing, but I am not = clear there are any two people in BANANA who agree on what it = is.

 

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf = Of Joe Touch
Sent: April 19, 2017 02:17 PM
To: = mohamed.boucadair@orange.com; philip.eardley@bt.com; = multipathtcp@ietf.org
Subject: Re: [multipathtcp] Consensus = call on potential MPTCP proxy work

 

 

 

On = 4/18/2017 10:26 PM, mohamed.boucadair@orange.com= wrote:

As explained in my previous message, there is no = layered congestion control. All packets are transported over plain TCP: = no encap, no tunnel.

I did say "if"; I now understand better what = you're trying to do, but there are plenty of parts still not = addressed:


 I really reiterate my comment to read = https://www.ietf.org/proceedings/98/slides= /slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

Here's what = those slides do not explain:

- is this system 1:1 per client TCP = connection, or are you expecting a single MPTCP between proxies to = support multiples?
- what is the congestion control interaction? = I.e., does the client think the RTT is to the proxy (which will work), = or to the TCP receiver past the end of the MPTCP connection? =
    NOTE: if the latter, then you still end up with = layered congestion control
- what is the proxy = relaying?
    is it TCP data, or is it somehow trying = to tunnel and reconstitute the entire packet?
    =
    NOTE: if it reconstitutes the packet, what = happens when you get an option you don't understand? E.g., = EDO?

There are still plenty of more concerns with this system. = Overall, you *still* appear to be doing one of two = things:

    a) acting like a conventional = application-layer proxy, which would be fine but would not require any = new RFCs
    b) tunneling - or acting exactly like = you're tunneling, by reconstituting packets on the other end - a TCP = connection over TCP, which is a bad idea

So which is it? Or is it = something else?

Joe

------=_NextPart_001_0027_01D2B91D.849CE2B0-- ------=_NextPart_000_0026_01D2B91D.849CE2B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR0zCCA3Iw ggJaoAMCAQICEEXP0AXpGX+6QUxIIut7VSMwDQYJKoZIhvcNAQEFBQAwQTETMBEGCgmSJomT8ixk ARkWA2FkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxFDASBgNVBAMTC0NTTy1yb290LUNBMB4XDTEx MDUyNzIwNDUyM1oXDTMxMDUyNzIwNTUyMVowQTETMBEGCgmSJomT8ixkARkWA2FkczEUMBIGCgmS JomT8ixkARkWBGNvcnAxFDASBgNVBAMTC0NTTy1yb290LUNBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyGO/eGuOZXuAF0hDAnpb+F7wrba5bK1jAbAr0Lw4YzpxP1Fgq+SspsurJ57N 01c1aXE32fZcInKr13KKjMwudfEHFtx5SI9Ca1hBYQoQHFOjStO12GJ/ptnF8eWzuR0GNtjHsznR docLIc8eYpGKg26/MwfW5tVXJPQQLmfrjqWZeCc9waHft8GS4B9n66NM0jX7Ln0F6pZTiM7xSn5G bqYDbKmURx0+2T0EZdB2LHk5etQkko1osEkWJMGRxGdhJoDq0z/hjsb+D4ueMY0vUWs8YzlEpQcS SKjrXzuOso7ZiQ/K0jQs1CeeXtbuJsdCr2v4jCB7lQirJp/vZc/HYQIDAQABo2YwZDATBgkrBgEE AYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUwFEy g4eKV1dY/we7og2DLW6zKpswEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEFBQADggEBADpk kwkpX7GBNxdwns7811j6jgHMTPtbYknqICkhYRcbSprxnab8bea8MKoPAlCIv0UTc2Y/dRuZ09YW 6nt0He0G8/3lH2FA8yk2BJoOXqtbzhkjhiTR/KwAVLQM1PlTmbhV9907Xw+2eqtyuMe2HeqcWfrw AqgxC0vuKEVn7TnWdNRWBkj8RxNkxFGbn75oYeRP6V07vXOgAz/bwZPbLWhh/b3PmTHr9/az9ZFR TIDFrU17WW1Bw/qoIPb9MT05Cu0/oaRYsiCrMSGq28uAmLKq3zHftb65IoKKiYZ0yN3EKed5Zd60 STRjYSAEoe8d3/ld88FkmmWub533wZmoVaQwggRaMIIDQqADAgECAgofuGLrAAEAAAAHMA0GCSqG SIb3DQEBBQUAMEcxEzARBgoJkiaJk/IsZAEZFgNhZHMxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRow GAYDVQQDExFDU08tRnVuY3Rpb25hbC1DQTAeFw0xMTA2MjAyMjE1MzFaFw0yMTA2MjAyMjI1MzFa MEQxEzARBgoJkiaJk/IsZAEZFgNhZHMxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRcwFQYDVQQDEw5D U08tSXNzdWluZy1DQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBkD5WUjfIR9gg4 CZbctcU4h/XdcEXlG0R83i7xtpMwXqeD18VJbaW7um6v5QB1VmdkfJvqa1GZLBWQSgE9UsX2aC5R 3Ia4/SCAzI9lhstKrwqOq/rA3fMt608OBhGSC/gBFGToJS5ermQqjitspFrcqPHvJ21Hj5Ysj69g PSQxvvFeD7fDJ0HpzcN0+OMCJczNJ90DrWvzePCAbwD4FffeEcs2rKnTSyxSylXGIITCDrfIqklX CMgbYEz/yuUSc0PW7sxAJHNJCV7q5zDpDZ2SIPkTt+O3EsXpjtCrqpW4o2IKNXa9ZscBAPUpR/Rj voGY50FgNZs/b1jS2VvyBL0CAwEAAaOCAUkwggFFMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQW BBSxQeetQATG+5j9MezN1WCKsBx8STAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBQQYS0Q8N1L4AuYfcfvEneEuLRp1zBN BgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vY2RwLnRzbC50ZWx1cy5jb20vQ2VydEVucm9sbC9DU08t RnVuY3Rpb25hbC1DQSgxKS5jcmwwaQYIKwYBBQUHAQEEXTBbMFkGCCsGAQUFBzAChk1odHRwOi8v Y2RwLnRzbC50ZWx1cy5jb20vQ2VydEVucm9sbC93cDQwNjM2LmNvcnAuYWRzX0NTTy1GdW5jdGlv bmFsLUNBKDEpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAcNxHTgCiCygcyNDnwS2G2FH0OhtEddKe /XCmAZbul7JrUYe2l09Y38XTY9MbwVTEbpcKb/qJgZHdggM0TCzOW5ww9rDv43HYW+CuFkWiEWH9 V3udPXwpaNCWDMaC7FB/24e/NGEsSLjZb30uA6p1Bo46ZL/MfL7d/0s+ON1liFGuooCUMzrxsNjX 8QXCsyxeyryNsy6q9/BI7D8Wntyv3fY39Bd6dS8LO62D28m5GX6AqypIeTph8GiKyeRm5Tet/5WG xnfoD7h8vaznuPRXsOrA8cJO6CElhIiajYp7uVF0kOITkCXb6yFm+V5YjAIv8bgEkEMDAq1IozmP JucluzCCBGwwggNUoAMCAQICCnzMt9MAAAAAAAcwDQYJKoZIhvcNAQEFBQAwQTETMBEGCgmSJomT 8ixkARkWA2FkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxFDASBgNVBAMTC0NTTy1yb290LUNBMB4X DTExMDYyMDIxMzAzMFoXDTI2MDYyMDIxNDAzMFowRzETMBEGCgmSJomT8ixkARkWA2FkczEUMBIG CgmSJomT8ixkARkWBGNvcnAxGjAYBgNVBAMTEUNTTy1GdW5jdGlvbmFsLUNBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtvS/xNy7ezJU+t5GQNgMbDsfTM/2SUxVi4b8bYDZEdnAoci3 Ka8OEfExDyMZjgYS7qLZr0GhohQw41mtBsIp+BqTsy8vV6jdnb7b8kFNaw5csEvRP72iyMT+/09r bZitEpbiQ67skmlUtVpm7dfeKtGO8nrw2qLK3mZoBUqJCY1oQdYHUdC8+6+igHGIs03laLaDehQi zv8w+yQJgFdnpClAXccm83bMcTEwLMGyxlkZJ39DVS+t785AJbmWufx075CiZ5mcL9pWtXhk1CsT bsaqcSMLppo78MkmbEL4ikYx3sQx8MuT3qhSbizuxzZEx7oKLSixhPEksjiapTbh3QIDAQABo4IB XjCCAVowEgYJKwYBBAGCNxUBBAUCAwEAATAjBgkrBgEEAYI3FQIEFgQUkM/SHaqV2nOF3hzPiDuP VdzFu7kwHQYDVR0OBBYEFBBhLRDw3UvgC5h9x+8Sd4S4tGnXMBkGCSsGAQQBgjcUAgQMHgoAUwB1 AGIAQwBBMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFMBRMoOHildX WP8Hu6INgy1usyqbMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jZHAudHNsLnRlbHVzLmNvbS9D ZXJ0RW5yb2xsL0NTTy1yb290LUNBLmNybDBgBggrBgEFBQcBAQRUMFIwUAYIKwYBBQUHMAKGRGh0 dHA6Ly9jZHAudHNsLnRlbHVzLmNvbS9DZXJ0RW5yb2xsL3dwNDA2MzUuY29ycC5hZHNfQ1NPLXJv b3QtQ0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQAiBl7YLaVbXYC5PwH/NehOX4sqwLtjqPmz+Uxh xsqaETgoGoHC4kUq96SVy4CSqxKNMWHnr82+IyvgI/WWoktp/nLNarYQuMnm8xrOIMaKHG0Q/ImL d5CKcy801232RAUYdOErw5wFFHh6ildKASdh7NFt2pVinSUs+gtbmpCXFoA//77tzrjhbvzPPEin to3ylJMFFSbl9Y6myABsFDj6e76PHp7RD30MFCPN6eS96ux0ZA33GdAxnU03KO7WlbXbwZuWGL0i fr2cuaBvQnqhO2YEXhHR5j28MK6st+4laKmV9D/ZAI1GRS4eVtWCN2aG4+bb48AvGeTsn9mdURXL MIIFizCCBHOgAwIBAgIKIdc0eQAAAD42vjANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQB GRYDYWRzMRQwEgYKCZImiZPyLGQBGRYEY29ycDEXMBUGA1UEAxMOQ1NPLUlzc3VpbmctQ0EwHhcN MTcwMzMwMjExNjEzWhcNMTkwMzMwMjExNjEzWjAYMRYwFAYDVQQDEw1Kb3JkYW4gTWVsemVyMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsOrirwDOuKJboDkKdk11hj8gcp2rb9vt3si8 BsdVWpCAqXpokjmRHQVZXm1UJNV+YG7ch0D7PfbGnbVeJ/wtA1lmf+XhvvqNPyqQh4Ua9E4M2ywR smheOc2L51FTVA6a6EccFGdrMfFeJeugZE2SBFEkvKLwlt61Kf0fM9Y60LT6Mt3jz7aFlaMh8PFD ediaaC/kiSCk/xPngCrhoGcWIO2f4NqlEnsuRJ5lMD4eYGu/+PdnfvsoOMsdw2hyKNi3uqL7K+e4 XWiwqvmt9UQLZgmV1NqN1BUyr9GAww4zU4mpChcMIrvzHZ9EDYmHbAOdx+z55nKBfrZUGMoGhXM3 iQIDAQABo4ICqTCCAqUwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIgbS7T4HW332HzYc1gYr8 UoXC+isigaLbQIG0xDECAWQCAQwwEwYDVR0lBAwwCgYIKwYBBQUHAwQwCwYDVR0PBAQDAgXgMBsG CSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgIC AIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBQEfMSoDVtp NFGh7WjX7MKM3qfLYTAfBgNVHSMEGDAWgBSxQeetQATG+5j9MezN1WCKsBx8STB3BgNVHR8EcDBu MGygaqBohjZodHRwOi8vY2RwLnRzbC50ZWx1cy5jb20vQ2VydEVucm9sbC9DU08tSXNzdWluZy1D QS5jcmyGLmh0dHA6Ly93cDQwNjQwLmNvcnAuYWRzL2NkcC9DU08tSXNzdWluZy1DQS5jcmwwgd8G CCsGAQUFBwEBBIHSMIHPMFMGCCsGAQUFBzAChkdodHRwOi8vY2RwLnRzbC50ZWx1cy5jb20vQ2Vy dEVucm9sbC93cDQwNjM3LmNvcnAuYWRzX0NTTy1Jc3N1aW5nLUNBLmNydDArBggrBgEFBQcwAYYf aHR0cDovL29jc3AudHNsLnRlbHVzLmNvbS9vY3NwLzBLBggrBgEFBQcwAoY/aHR0cDovL3dwNDA2 NDAuY29ycC5hZHMvY2RwL3dwNDA2MzcuY29ycC5hZHNfQ1NPLUlzc3VpbmctQ0EuY3J0MEQGA1Ud EQQ9MDugIAYKKwYBBAGCNxQCA6ASDBB0ODQ0MzIzQGNvcnAuYWRzgRdqb3JkYW4ubWVsemVyQHRl bHVzLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAKQFG9uiNQtVcTrgYwv/z8Zq5sz+tfcAlLqfWYrYR Cr4T0XOsJzo0SaehyMrGf0lax7OrsPcxOQkutAJhjpwjuWb2puGFW/waZ/2lt+0wP2JF+wb8RTJt syWVysll9OmCJy3v6e0qILx2M+VrEjuOvxaWowrkuU7+1woFSeGTGWXb8rJ7SsqDoOyzR9qg9rWI EVGnkY1DkbHAUBcplnFV6qI4cgNNVqn3th2GByG8aJ3zfeFMaH6pFtU0PWRrp9ktOwno5kbiQsmS NQqfLHYdGPp2skjZa1KQWmJD0WhBzstDEenVtxVrqDHNenyYNWcV/7Aw8DQ6xV++buhDILaX9jGC A1AwggNMAgEBMFIwRDETMBEGCgmSJomT8ixkARkWA2FkczEUMBIGCgmSJomT8ixkARkWBGNvcnAx FzAVBgNVBAMTDkNTTy1Jc3N1aW5nLUNBAgoh1zR5AAAAPja+MAkGBSsOAwIaBQCgggHTMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDQxOTE4NTkxN1owIwYJKoZI hvcNAQkEMRYEFGwnjt25EBXzlWR9fO44wZgY7R2PMGEGCSsGAQQBgjcQBDFUMFIwRDETMBEGCgmS JomT8ixkARkWA2FkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxFzAVBgNVBAMTDkNTTy1Jc3N1aW5n LUNBAgoh1zR5AAAAPja+MGMGCyqGSIb3DQEJEAILMVSgUjBEMRMwEQYKCZImiZPyLGQBGRYDYWRz MRQwEgYKCZImiZPyLGQBGRYEY29ycDEXMBUGA1UEAxMOQ1NPLUlzc3VpbmctQ0ECCiHXNHkAAAA+ Nr4wgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3 DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgB ZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZh2Go8is/u5pbe2K28PNk4sbylhitZ82MKosM9G8sLU2 MRllysjsy0VJpRk2jHX4021neAih8wtzcupQ9y4ANqThquLYBHcK2gkvIdEedtLzV6Y3pAkQZCWw 2dTtBdzjvyej1jEdS+vPhdBNKh3osOvb6WqmqbcoWb8Kg3lcDkc9Jv/jaE8e33ptRdFWdj/7utt/ cBgo76lUdVUvrIDjGva9Y1+aaYxM9guwr4AvfNwVpQ0vhxeNilVKMolwkkaYvpcSNffxIilrbn3Q bWypFrOclAbpDo+OjeO+M80OwoOiefPgoI6Ha3Qscq+Ok0LPaqSlkNkGPv2FyQYQbN2UDgAAAAAA AA== ------=_NextPart_000_0026_01D2B91D.849CE2B0-- From nobody Wed Apr 19 13:04:10 2017 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 2EE8B1293E9 for ; Wed, 19 Apr 2017 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oszdc3aguWfh for ; Wed, 19 Apr 2017 13:04:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E123C12956A for ; Wed, 19 Apr 2017 13:04:05 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3JK3SJA012703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 13:03:29 -0700 (PDT) To: Jordan Melzer , "mohamed.boucadair@orange.com" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> From: Joe Touch Message-ID: <7163c17c-6396-b046-efea-4376404e852b@isi.edu> Date: Wed, 19 Apr 2017 13:03:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> Content-Type: multipart/alternative; boundary="------------BA7D23F5178E015C89B931A4" X-MailScanner-ID: v3JK3SJA012703 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:04:08 -0000 This is a multi-part message in MIME format. --------------BA7D23F5178E015C89B931A4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 4/19/2017 11:59 AM, Jordan Melzer wrote: > > It’s a conventional proxy. There are different sockets on each side > of the proxy, different RTTs, different congestion control. The > proposal is to find a near-zero overhead way to do this when the proxy > is off-path (ie, when it’s not a simple connection hijack). This may > be totally possible without a new RFC – Christoph Paasch suggested > that SOCKS + TFO could basically become this, but I am not sure anyone > who cared either caught it or agreed. > > > > Re b), it’s off-topic, but what would you think of a multipath tunnel > that was basically MPTCP with the retransmissions gutted out? I had > thought this would be what BANANA is doing, but I am not clear there > are any two people in BANANA who agree on what it is. > Why would that not be SCTP? Joe > > > > > *From:*multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf > Of *Joe Touch > *Sent:* April 19, 2017 02:17 PM > *To:* mohamed.boucadair@orange.com; philip.eardley@bt.com; > multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] Consensus call on potential MPTCP proxy work > > > > > > > > On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com > wrote: > > As explained in my previous message, there is no layered > congestion control. All packets are transported over plain TCP: no > encap, no tunnel. > > I did say "if"; I now understand better what you're trying to do, but > there are plenty of parts still not addressed: > > > I really reiterate my comment to read > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf > > Here's what those slides do not explain: > > - is this system 1:1 per client TCP connection, or are you expecting a > single MPTCP between proxies to support multiples? > - what is the congestion control interaction? I.e., does the client > think the RTT is to the proxy (which will work), or to the TCP > receiver past the end of the MPTCP connection? > NOTE: if the latter, then you still end up with layered congestion > control > - what is the proxy relaying? > is it TCP data, or is it somehow trying to tunnel and reconstitute > the entire packet? > > NOTE: if it reconstitutes the packet, what happens when you get an > option you don't understand? E.g., EDO? > > There are still plenty of more concerns with this system. Overall, you > *still* appear to be doing one of two things: > > a) acting like a conventional application-layer proxy, which would > be fine but would not require any new RFCs > b) tunneling - or acting exactly like you're tunneling, by > reconstituting packets on the other end - a TCP connection over TCP, > which is a bad idea > > So which is it? Or is it something else? > > Joe > --------------BA7D23F5178E015C89B931A4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 4/19/2017 11:59 AM, Jordan Melzer wrote:

It’s a conventional proxy.  There are different sockets on each side of the proxy, different RTTs, different congestion control.  The proposal is to find a near-zero overhead way to do this when the proxy is off-path (ie, when it’s not a simple connection hijack).  This may be totally possible without a new RFC – Christoph Paasch suggested that SOCKS + TFO could basically become this, but I am not sure anyone who cared either caught it or agreed.

 

Re b), it’s off-topic, but what would you think of a multipath tunnel that was basically MPTCP with the retransmissions gutted out?  I had thought this would be what BANANA is doing, but I am not clear there are any two people in BANANA who agree on what it is.


Why would that not be SCTP?
Joe

 

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch
Sent: April 19, 2017 02:17 PM
To: mohamed.boucadair@orange.com; philip.eardley@bt.com; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work

 

 

 

On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:


 I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?
   
    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?

Joe


--------------BA7D23F5178E015C89B931A4-- From nobody Wed Apr 19 15:07:58 2017 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 1A947128B90 for ; Wed, 19 Apr 2017 15:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGvEttzQk1VO for ; Wed, 19 Apr 2017 15:07:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 11783127010 for ; Wed, 19 Apr 2017 15:07:55 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3JM7qnM011383; Thu, 20 Apr 2017 00:07:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3C40BD7891; Thu, 20 Apr 2017 00:07:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZMx-L366-23C; Thu, 20 Apr 2017 00:07:50 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 15398D7885; Thu, 20 Apr 2017 00:07:49 +0200 (CEST) Date: Thu, 20 Apr 2017 00:07:58 +0200 Message-ID: <87k26gaw5d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Jordan Melzer Cc: Joe Touch , "mohamed.boucadair@orange.com" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" In-Reply-To: <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 20 Apr 2017 00:07:52 +0200 (CEST) X-Miltered: at korolev with ID 58F7DFB8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F7DFB8.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58F7DFB8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:07:57 -0000 > It’s a conventional proxy. There are different sockets on each side of the > proxy Can you please explain what's going on in Figure 5 on page 11 of draft-boucadair-mptcp-plain-mode-10? I read this as delaying a SYN-ACK on the client side until a SYN-ACK on the server side is received. How do you implement that with different sockets? -- Juliusz From nobody Wed Apr 19 15:17:48 2017 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 A229E128B90 for ; Wed, 19 Apr 2017 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hobjPJEcPUZv for ; Wed, 19 Apr 2017 15:17:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49CC128D8B for ; Wed, 19 Apr 2017 15:17:46 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3JMHALB014054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 15:17:11 -0700 (PDT) To: Juliusz Chroboczek , Jordan Melzer References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0e49cefbf1d64b38b62492c260bf2baf@BTWP000357.corp.ads> <87k26gaw5d.wl-jch@irif.fr> Cc: "mohamed.boucadair@orange.com" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" From: Joe Touch Message-ID: Date: Wed, 19 Apr 2017 15:17:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87k26gaw5d.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:17:48 -0000 On 4/19/2017 3:07 PM, Juliusz Chroboczek wrote: >> It’s a conventional proxy. There are different sockets on each side of the >> proxy > Can you please explain what's going on in Figure 5 on page 11 of > draft-boucadair-mptcp-plain-mode-10? I read this as delaying a SYN-ACK on > the client side until a SYN-ACK on the server side is received. How do > you implement that with different sockets? Excellent point. That would more clearly confirm that this is not application-layer (I'm excluding application access to raw Unix sockets, which would end up running TCP in the user layer). Joe From nobody Wed Apr 19 22:32:41 2017 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 2199612EACB for ; Wed, 19 Apr 2017 22:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 0Z57BrenJFXU for ; Wed, 19 Apr 2017 22:32:38 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B450E126DED for ; Wed, 19 Apr 2017 22:32:38 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 0CA63C06A6; Thu, 20 Apr 2017 07:32:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id D25271A005F; Thu, 20 Apr 2017 07:32:36 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 07:32:36 +0200 From: To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQAZ8zuAAB4TboAAD/kHAAAWfiXA Date: Thu, 20 Apr 2017 05:32:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> In-Reply-To: <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 05:32:40 -0000 Hi Matt,=20 What I meant by "native MPTCP connections" is that the CPE won't proxy a SY= N that contains MP_CPABALE received from an MPTCP-capable client. That is, = the CPE won't modify the destination IP address to the one of the network-l= ocated proxy. That SYN+MP_CPABALE will be received and handled directly by = the remote server. =20 Cheers, Med > -----Message d'origine----- > De=A0: Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies] > [mailto:matthew.t.sargent@nasa.gov] > Envoy=E9=A0: mercredi 19 avril 2017 15:38 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: philip.eardley@bt.com; multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > Hi Med, >=20 > > On Apr 19, 2017, at 2:00 AM, mohamed.boucadair@orange.com wrote: > > > > Hi Matt, > > > > Yes, I confirm. > > > > * Native MPTCP connections can be established directly without involvin= g > a proxy. > > * If the client is not MPTCP-capable but the server is MPTCP-capable, > the communication leg between the proxy and that server will be placed > using MPTCP. > > >=20 > I am not sure I understand how you maintain native MPTCP connections in > the dual proxy case. >=20 > I am assuming a network that is set up like you have on slide 10. 1 > address on the client, 1 address on the server, multiple paths are > "hidden" by the MCP's. >=20 > Do you mean to claim that installing MPTCP on the client and server will > result in an MPTCP connection that "works" in the sense that it will > contain multiple subflows to use the available paths in the network? How > would this work without additional signaling? >=20 > Sorry if I am missing something obvious here. >=20 > Thanks, > Matt From nobody Wed Apr 19 22:50:39 2017 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 3335F129B44 for ; Wed, 19 Apr 2017 22:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 jnZ1ol1Blibw for ; Wed, 19 Apr 2017 22:50:36 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.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 A74C5128AB0 for ; Wed, 19 Apr 2017 22:50:35 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id F0EAA180631; Thu, 20 Apr 2017 07:50:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id BBB211C0067; Thu, 20 Apr 2017 07:50:33 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 07:50:33 +0200 From: To: Joe Touch , Yoshifumi Nishida CC: multipathtcp Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuThvFYN3Pf6Ey0Kw29UUSw2QvaHNvQhA Date: Thu, 20 Apr 2017 05:50:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> In-Reply-To: <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50F66OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 05:50:37 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E50F66OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnRzIGhlcmU6DQoNCsK3 ICAgICAgICAgVGhlIHVzZSBvZiBhIDMyLWJpdCBtYWdpYyBudW1iZXIgaXMgbWVhbnQgdG8gZGlz dGluZ3Vpc2ggYXBwbGljYXRpb24tc3VwcGxpZWQgZGF0YSBmcm9tIHRoZSBvbmUgaW5zZXJ0ZWQg YnkgdGhlIHByb3h5LiBUaGVyZSBhcmUgb3RoZXIgZmllbGRzIGluIHRoZSBNUF9DT05WRVJUIGlu Zm9ybWF0aW9uIGVsZW1lbnQgdGhhdCBoZWxwIGluIHRoYXQgYWltIHRvbyAodmFsaWRhdGlvbiBv ZiB0aGUgVExWLCBNLWJpdCwgZm9yIGV4YW1wbGUpLg0KDQrCtyAgICAgICAgIEJvdGggZW50aXRp ZXMgdGhhdCBzdXBwbHkgYW5kIHByb2Nlc3MgdGhlIGRhdGEgYXJlIHVuZGVyIHRoZSBjb250cm9s IG9mIHRoZSBzYW1lIG9wZXJhdG9yLg0KDQrCtyAgICAgICAgIFRoZSBuZXR3b3JrLWxvY2F0ZWQg cHJveHkgaXMgZXhwbGljaXRseSBjb25maWd1cmVkIG9uIHRoZSBDUEUuIFRoZSBkZXN0aW5hdGlv biBJUCBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMgYW4gYWRkcmVzcyBvZiB0aGF0IHByb3h5LCBu b3QgdGhlIGFkZHJlc3Mgb2YgYSBsZWdhY3kgbm9kZS4NCg0KwrcgICAgICAgICBUaGUgcHJveHkg bXVzdCBlY2hvIHN1cHBsaWVkIGRhdGEgaW4gYSBTWU4vQUNLLiBJZiBhIG1pc21hdGNoIGlzIGRl dGVjdGVkIGJ5IHRoZSBDUEUsIHRoYXQgcHJveHkgV09O4oCZdCBiZSB1c2VkIGZvciBzdWJzZXF1 ZW50IGNvbm5lY3Rpb25zIHRpbGwgYSBuZXcgcHJveHkgaXMgY29uZmlndXJlZCwgVFRMIGV4cGly ZXMsIGV0Yy4NCg0KVG8gc3VtOg0KDQrCtyAgICAgICAgIFdlIGFyZSBhY3Rpbmcgb24gb25lIHNp bmdsZSBTWU4gb2YgYW4gTVBUQ1AgY29ubmVjdGlvbi4NCg0KwrcgICAgICAgICBJZiBhIG1pc21h dGNoIGlzIGRldGVjdGVkIGZvciBvbmUgc2luZ2xlIFNZTiBvZiBhIGdpdmVuIGNvbm5lY3Rpb24s IGFsbCBzdWJzZXF1ZW50IGNvbm5lY3Rpb25zICh3aXRoIGFueSByZW1vdGUgc2VydmVyKSB3b27i gJl0IGJlIHJlbGF5ZWQgdG8gdGhhdCBwcm94eS4NCg0KSG93IGlzIHRoaXMg4oCcaGF6YXJkb3Vz 4oCdPw0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEpvZSBUb3VjaCBbbWFp bHRvOnRvdWNoQGlzaS5lZHVdDQpFbnZvecOpIDogbWVyY3JlZGkgMTkgYXZyaWwgMjAxNyAyMDox Mg0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBZb3NoaWZ1bWkgTmlzaGlkYQ0KQ2Mg OiBtdWx0aXBhdGh0Y3ANCk9iamV0IDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxs IG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCg0KDQoNCk9uIDQvMTgvMjAxNyAxMDo0 NiBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQouLi4NClVzaW5nIHRoZSBTWU4gZGF0YSBhcyBjb250cm9s IGluZm9ybWF0aW9uIGlzIHRoZSBoYXphcmRvdXMgcGFydC4NCltNZWRdIEl0IGlzbuKAmXQgZm9y IHRoZSBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCBsZWdhY3kgSW50ZXJuZXQgbm9kZXMgd2ls bCBuZXZlciByZWNlaXZlIGEgU1lOIHdpdGggQ1BFLXN1cHBsaWVkIGRhdGEgYW5kIHRoYXQgdGhl IFRDUCBwZWVyIGlzIGtub3duIHRvIHByb2Nlc3MgdGhlIHN1cHBsaWVkIGRhdGEuIEEgR3VhcmQg YWdhaW5zdCBtaXNjb25maWd1cmF0aW9ucyBpcyBzdXBwb3J0ZWQ6IGVjaG8gaW4gYSBTWU4vQUNL Lg0KDQpUaGUgaWRlYSBvZiB1c2luZyBhIG1hZ2ljIG51bWJlciB0byBwcm90ZWN0IGFnYWluc3Qg bWlzY29tbXVuaWNhdGlvbiB2aXJ0dWFsbHkgZW5zdXJlcyB0aGF0IHRoZXJlIHdpbGwgYmUgcmVs aWFibGUgY29ubmVjdGlvbnMgd2l0aCBlcnJvcnMuIFRoYXQgY2hhbmdlcyBUQ1BzIHNlbWFudGlj cy4NCg0KUHV0dGluZyBkYXRhIGluIHRoZSBTWU4gb2YgVEZPIGlzIHBlcm1pdHRlZCBvbmx5IGJl Y2F1c2Ugb2YgcHJldmlvdXMgc3RhdGUuDQoNCk1QVENQIGRvZXNuJ3QgaGF2ZSB0aGF0IHN0YXRl IGFuZCBzbyBpdCBpcyBoYXphcmRvdXMgdG8gcHV0IGRhdGEgaW4gdGhlIFNZTi4NCg0KSS5lLiwg aWYgeW91IHdhbnQgVEZPLWxpa2UgcGVyZm9ybWFuY2UsIGZpZ3VyZSBvdXQgaG93IHRvIHVzZSBU Rk8uIFBlcmlvZC4NCg0KSm9lDQo= --_000_787AE7BB302AE849A7480A190F8B933009E50F66OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291 cmllciBOZXcgXDtjb2xvclw6YmxhY2siO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMzI3NjA3NDsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjA5Nzg4MjEy IDY4MDc5MTY0NCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2 Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEzMTM2Nzc0Njc7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM3MjgyNzIgNjgwNzkx NjQ0IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3 IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSm9lLA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBjb21t ZW50cyBoZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+VGhlIHVzZSBvZiBhIDMyLWJpdCBtYWdpYyBudW1iZXIgaXMgbWVhbnQgdG8g ZGlzdGluZ3Vpc2ggYXBwbGljYXRpb24tc3VwcGxpZWQgZGF0YSBmcm9tIHRoZSBvbmUgaW5zZXJ0 ZWQgYnkgdGhlIHByb3h5LiBUaGVyZSBhcmUgb3RoZXIgZmllbGRzIGluDQogdGhlIE1QX0NPTlZF UlQgaW5mb3JtYXRpb24gZWxlbWVudCB0aGF0IGhlbHAgaW4gdGhhdCBhaW0gdG9vICh2YWxpZGF0 aW9uIG9mIHRoZSBUTFYsIE0tYml0LCBmb3IgZXhhbXBsZSkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Cb3RoIGVudGl0aWVzIHRoYXQg c3VwcGx5IGFuZCBwcm9jZXNzIHRoZSBkYXRhIGFyZSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUg c2FtZSBvcGVyYXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoZSBuZXR3b3JrLWxvY2F0ZWQgcHJveHkgaXMgZXhwbGljaXRseSBj b25maWd1cmVkIG9uIHRoZSBDUEUuIFRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIG9mIHRoZSBw YWNrZXQgaXMgYW4gYWRkcmVzcyBvZiB0aGF0IHByb3h5LCBub3QgdGhlIGFkZHJlc3MNCiBvZiBh IGxlZ2FjeSBub2RlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoZSBwcm94eSBtdXN0IGVjaG8gc3VwcGxpZWQgZGF0YSBpbiBhIFNZ Ti9BQ0suIElmIGEgbWlzbWF0Y2ggaXMgZGV0ZWN0ZWQgYnkgdGhlIENQRSwgdGhhdCBwcm94eSBX T07igJl0IGJlIHVzZWQgZm9yIHN1YnNlcXVlbnQgY29ubmVjdGlvbnMgdGlsbCBhDQogbmV3IHBy b3h5IGlzIGNvbmZpZ3VyZWQsIFRUTCBleHBpcmVzLCBldGMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UbyBzdW06PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBhcmUgYWN0aW5nIG9u IG9uZSBzaW5nbGUgU1lOIG9mIGFuIE1QVENQIGNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBhIG1pc21hdGNoIGlz IGRldGVjdGVkIGZvciBvbmUgc2luZ2xlIFNZTiBvZiBhIGdpdmVuIGNvbm5lY3Rpb24sIGFsbCBz dWJzZXF1ZW50IGNvbm5lY3Rpb25zICh3aXRoIGFueSByZW1vdGUgc2VydmVyKSB3b27igJl0IGJl IHJlbGF5ZWQgdG8gdGhhdA0KIHByb3h5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5Ib3cgaXMgdGhpcyDigJxoYXphcmRvdXPigJ0/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDE5IGF2cmls IDIwMTcgMjA6MTI8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE47IFlvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBtdWx0aXBhdGh0Y3A8 YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBDb25zZW5zdXMgY2Fs bCBvbiBwb3RlbnRpYWwgTVBUQ1AgcHJveHkgd29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8xOC8yMDE3IDEw OjQ2IFBNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5Vc2luZyB0aGUgU1lOIGRhdGEgYXMgY29udHJvbCBpbmZvcm1hdGlv biBpcyB0aGUgaGF6YXJkb3VzIHBhcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij5bTWVkXSBJ dCBpc27igJl0IGZvciB0aGUgZm9yIHRoZSBzaW1wbGUgcmVhc29uIHRoYXQgbGVnYWN5IEludGVy bmV0IG5vZGVzIHdpbGwgbmV2ZXIgcmVjZWl2ZSBhIFNZTiB3aXRoIENQRS1zdXBwbGllZCBkYXRh IGFuZCB0aGF0IHRoZSBUQ1AgcGVlciBpcyBrbm93bg0KIHRvIHByb2Nlc3MgdGhlIHN1cHBsaWVk IGRhdGEuIEEgR3VhcmQgYWdhaW5zdCBtaXNjb25maWd1cmF0aW9ucyBpcyBzdXBwb3J0ZWQ6IGVj aG8gaW4gYSBTWU4vQUNLLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhlIGlkZWEgb2YgdXNpbmcgYSBtYWdp YyBudW1iZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IG1pc2NvbW11bmljYXRpb24gdmlydHVhbGx5IGVu c3VyZXMgdGhhdCB0aGVyZSB3aWxsIGJlIHJlbGlhYmxlIGNvbm5lY3Rpb25zIHdpdGggZXJyb3Jz LiBUaGF0IGNoYW5nZXMgVENQcyBzZW1hbnRpY3MuPGJyPg0KPGJyPg0KUHV0dGluZyBkYXRhIGlu IHRoZSBTWU4gb2YgVEZPIGlzIHBlcm1pdHRlZCBvbmx5IGJlY2F1c2Ugb2YgcHJldmlvdXMgc3Rh dGUuPGJyPg0KPGJyPg0KTVBUQ1AgZG9lc24ndCBoYXZlIHRoYXQgc3RhdGUgYW5kIHNvIGl0IGlz IGhhemFyZG91cyB0byBwdXQgZGF0YSBpbiB0aGUgU1lOLiA8YnI+DQo8YnI+DQpJLmUuLCBpZiB5 b3Ugd2FudCBURk8tbGlrZSBwZXJmb3JtYW5jZSwgZmlndXJlIG91dCBob3cgdG8gdXNlIFRGTy4g UGVyaW9kLjxicj4NCjxicj4NCkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009E50F66OPEXCLILMA3corp_-- From nobody Wed Apr 19 23:16:21 2017 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 E2CD0128BB7 for ; Wed, 19 Apr 2017 23:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 BlKuNSvC4xGW for ; Wed, 19 Apr 2017 23:16:16 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B293112EB04 for ; Wed, 19 Apr 2017 23:16:14 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 3B1A8C024C; Thu, 20 Apr 2017 08:16:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 00E76120065; Thu, 20 Apr 2017 08:16:13 +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.0319.002; Thu, 20 Apr 2017 08:16:12 +0200 From: To: Joe Touch , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuTkeFYN3Pf6Ey0Kw29UUSw2QvaHNwcPg Date: Thu, 20 Apr 2017 06:16:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50F91OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 06:16:20 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E50F91OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoy=E9 : mercredi 19 avril 2017 20:17 =C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.o= rg Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote: As explained in my previous message, there is no layered congestion control= . All packets are transported over plain TCP: no encap, no tunnel. I did say "if"; I now understand better what you're trying to do, but there= are plenty of parts still not addressed: I really reiterate my comment to read https://www.ietf.org/proceedings/98/= slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf Here's what those slides do not explain: - is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples? [Med] We are not multiplexing connections. This is explained in https://too= ls.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2: The upstream MCP maps an upstream TCP connection onto a downstream MPTCP connection (and its associated subflows) . On the upstream MCP, an established MPTCP connection can be identified by the local Token that was assigned upon reception of the SYN segment from the Client. - what is the congestion control interaction? I.e., does the client think t= he RTT is to the proxy (which will work), or to the TCP receiver past the e= nd of the MPTCP connection? NOTE: if the latter, then you still end up with layered congestion cont= rol [Med] The one to the proxy. This is important for subflows management and t= raffic distribution. - what is the proxy relaying? is it TCP data, or is it somehow trying to tunnel and reconstitute the = entire packet? [Med] The proxy will need to strop any supplied-data in the initial SYN, an= d then create a state to be used for handling subsequent packets of that co= nnection. Once a state is created, we are doing something similar to SOCKS = for the data plane. There are some new features compared to SOCKS that I wo= n't detail here. The reader may refer to https://tools.ietf.org/html/draft-= nam-mptcp-deployment-considerations-01. NOTE: if it reconstitutes the packet, what happens when you get an opti= on you don't understand? E.g., EDO? [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touc= h options that are inserted by a TCP endpoint. The proxy is not required to= understand those options. The only modification we are doing at this level= is to insert MPTCP options. And even for this case, as shown in slide 30, = when there is an exhausted TCP option space in the original SYN, ** no ** M= PTCP options are inserted. So, all is safe. There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things: a) acting like a conventional application-layer proxy, which would be f= ine but would not require any new RFCs b) tunneling - or acting exactly like you're tunneling, by reconstituti= ng packets on the other end - a TCP connection over TCP, which is a bad ide= a So which is it? Or is it something else? [Med] Interoperability is needed here because the CPE and the network-locat= ed proxy are provided by distinct vendors. For example, the format, locatio= n, and processing of the supplied proxy data is to be standardized. Other m= atters like those you mentioned are key to keep in mind. Joe --_000_787AE7BB302AE849A7480A190F8B933009E50F91OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De := Joe Touch [mailto:touch@isi.edu]
Envoy=E9 : mercredi 19 avril 2017 20:17
=C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipa= thtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

 

 

On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previous message, there= is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I did say "if"; I now understand better wh= at you're trying to do, but there are plenty of parts still not addressed:<= br>

 I really reiterate my comment to rea= d https://www.ietf.org/procee= dings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

= Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples?

= [Med] We are not multiplexing connections. This is explained in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2= .2:

   The upstream = MCP maps an upstream TCP connection onto a downstream

   MPTCP connect= ion (and its associated subflows) . On the upstream MCP,<= /p>

   an establishe= d MPTCP connection can be identified by the local Token

   that was assi= gned upon reception of the SYN segment from the Client.

=
- what is the congestion control interaction? I.e., does the client = think the RTT is to the proxy (which will work), or to the TCP receiver pas= t the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered = congestion control

= [Med] The one to the proxy. This is important for subflows management and t= raffic distribution.

=
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel= and reconstitute the entire packet?=

= [Med] The proxy will need to strop any supplied-data in the initial SYN, an= d then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doing somethin= g similar to SOCKS for the data plane. There are some new features compared= to SOCKS that I won’t detail here. The reader may refer to https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.
   
    NOTE: if it reconstitutes the packet, what happens when = you get an option you don't understand? E.g., EDO?

= [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touc= h options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification w= e are doing at this level is to insert MPTCP options. And even for this cas= e, as shown in slide 30, when there is an exhausted TCP option space in the= original SYN, ** no ** MPTCP options are inserted. So, all is safe.

There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, w= hich would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, = by reconstituting packets on the other end - a TCP connection over TCP, whi= ch is a bad idea

So which is it? Or is it something else?

= [Med] Interoperability is needed here because the CPE and the network-locat= ed proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be s= tandardized. Other matters like those you mentioned are key to keep in mind= .

Joe

--_000_787AE7BB302AE849A7480A190F8B933009E50F91OPEXCLILMA3corp_-- From nobody Wed Apr 19 23:34:52 2017 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 AF28212EB04 for ; Wed, 19 Apr 2017 23:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 5lbGdVu-I3yA for ; Wed, 19 Apr 2017 23:34:48 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8F6120724 for ; Wed, 19 Apr 2017 23:34:48 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 6EBFCC0346; Thu, 20 Apr 2017 08:34:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 5282240069; Thu, 20 Apr 2017 08:34:46 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 08:34:46 +0200 From: To: Jordan Melzer CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK5n8HwPVdmWlqIT+qt6bBQdKeelg== Date: Thu, 20 Apr 2017 06:34:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E50FB1@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50FB1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 06:34:51 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E50FB1OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jordan, SOCKS + TFO was discussed in the mailing list and also during the meeting i= n Chicago. Modifying SOCKS to provide 0-RTT will need to be yet specified..= .and therefore will need a new RFCed. There was clear consensus during the = Chicago meeting to not work on SOCKS. Modifying SOCKS will at best provide what we are doing in the plain mode, b= ut still it does not provide address preservation feature that we want to e= nsure for IPv6. Cheers, Med De : Jordan Melzer [mailto:Jordan.Melzer@telus.com] Envoy=E9 : mercredi 19 avril 2017 20:59 =C0 : Joe Touch; BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipat= htcp@ietf.org Objet : RE: [multipathtcp] Consensus call on potential MPTCP proxy work It's a conventional proxy. There are different sockets on each side of the= proxy, different RTTs, different congestion control. The proposal is to f= ind a near-zero overhead way to do this when the proxy is off-path (ie, whe= n it's not a simple connection hijack). This may be totally possible witho= ut a new RFC - Christoph Paasch suggested that SOCKS + TFO could basically = become this, but I am not sure anyone who cared either caught it or agreed. Re b), it's off-topic, but what would you think of a multipath tunnel that = was basically MPTCP with the retransmissions gutted out? I had thought thi= s would be what BANANA is doing, but I am not clear there are any two peopl= e in BANANA who agree on what it is. From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe = Touch Sent: April 19, 2017 02:17 PM To: mohamed.boucadair@orange.com; phil= ip.eardley@bt.com; multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote: As explained in my previous message, there is no layered congestion control= . All packets are transported over plain TCP: no encap, no tunnel. I did say "if"; I now understand better what you're trying to do, but there= are plenty of parts still not addressed: I really reiterate my comment to read https://www.ietf.org/proceedings/98/= slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf Here's what those slides do not explain: - is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples? - what is the congestion control interaction? I.e., does the client think t= he RTT is to the proxy (which will work), or to the TCP receiver past the e= nd of the MPTCP connection? NOTE: if the latter, then you still end up with layered congestion cont= rol - what is the proxy relaying? is it TCP data, or is it somehow trying to tunnel and reconstitute the = entire packet? NOTE: if it reconstitutes the packet, what happens when you get an opti= on you don't understand? E.g., EDO? There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things: a) acting like a conventional application-layer proxy, which would be f= ine but would not require any new RFCs b) tunneling - or acting exactly like you're tunneling, by reconstituti= ng packets on the other end - a TCP connection over TCP, which is a bad ide= a So which is it? Or is it something else? Joe --_000_787AE7BB302AE849A7480A190F8B933009E50FB1OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jordan,

 

SOCKS + TFO was discussed i= n the mailing list and also during the meeting in Chicago. Modifying SOCKS = to provide 0-RTT will need to be yet specified…and therefore will need a new RFCed. There was clear consensus during the Chicago meetin= g to not work on SOCKS.

 

Modifying SOCKS will at best pr= ovide what we are doing in the plain mode, but still it does not provide ad= dress preservation feature that we want to ensure for IPv6.

 

Cheers,

Med

 

De := Jordan Melzer [mailto:Jordan.Melzer@telus.com= ]
Envoy=E9 : mercredi 19 avril 2017 20:59
=C0 : Joe Touch; BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.c= om; multipathtcp@ietf.org
Objet : RE: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

It’s= a conventional proxy.  There are different sockets on each side of th= e proxy, different RTTs, different congestion control.  The proposal is to find a near-zero overhead way to do this when the proxy is off-path = (ie, when it’s not a simple connection hijack).  This may be tot= ally possible without a new RFC – Christoph Paasch suggested that SOC= KS + TFO could basically become this, but I am not sure anyone who cared either caught it or agreed.

 = ;

Re b), it&= #8217;s off-topic, but what would you think of a multipath tunnel that was = basically MPTCP with the retransmissions gutted out?  I had thought this would be what BANANA is doing, but I am not clear there are any two p= eople in BANANA who agree on what it is.

 = ;

 = ;

From:= multipathtcp [mailto:multipathtcp-bounces@iet= f.org] On Behalf Of Joe Touch
Sent: April 19, 2017 02:17 PM
To: mohamed.boucadai= r@orange.com; philip.eardley@bt.com; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy = work

 

 

 

On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previous message, there= is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

= I did say "if"; I now understand better what you're trying to do,= but there are plenty of parts still not addressed:

 I really reiterate my comment to rea= d https://www.ietf.org/procee= dings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

= Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client think t= he RTT is to the proxy (which will work), or to the TCP receiver past the e= nd of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered = congestion control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and re= constitute the entire packet?
   
    NOTE: if it reconstitutes the packet, what happens when = you get an option you don't understand? E.g., EDO?

There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, w= hich would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, = by reconstituting packets on the other end - a TCP connection over TCP, whi= ch is a bad idea

So which is it? Or is it something else?

Joe

--_000_787AE7BB302AE849A7480A190F8B933009E50FB1OPEXCLILMA3corp_-- From nobody Thu Apr 20 07:05:53 2017 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 ECF06129571 for ; Thu, 20 Apr 2017 07:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgSrAJnCxJOe for ; Thu, 20 Apr 2017 07:05:49 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C7CFA129573 for ; Thu, 20 Apr 2017 07:05:48 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3KE5lLe029347; Thu, 20 Apr 2017 16:05:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 20D62D7891; Thu, 20 Apr 2017 16:05:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9muQ-GnBRbtZ; Thu, 20 Apr 2017 16:05:46 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 35727D7885; Thu, 20 Apr 2017 16:05:46 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d1CiP-0004lV-Sr; Thu, 20 Apr 2017 16:05:46 +0200 Date: Thu, 20 Apr 2017 16:05:45 +0200 Message-ID: <7iefwnb2di.wl-jch@irif.fr> From: Juliusz Chroboczek To: Cc: "multipathtcp@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 20 Apr 2017 16:05:47 +0200 (CEST) X-Miltered: at korolev with ID 58F8C03B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F8C03B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58F8C03B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:05:51 -0000 > What I meant by "native MPTCP connections" is that the CPE won't proxy > a SYN that contains MP_CPABALE received from an MPTCP-capable > client. That is, the CPE won't modify the destination IP address to the > one of the network-located proxy. That SYN+MP_CPABALE will be received > and handled directly by the remote server. It will still act as a middlebox, though, with no way for the client to avoid it. -- Juliusz From nobody Thu Apr 20 07:15:10 2017 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 EEB03129A91 for ; Thu, 20 Apr 2017 07:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 rTsolNIU8br4 for ; Thu, 20 Apr 2017 07:15:06 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659D1129520 for ; Thu, 20 Apr 2017 07:15:06 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id E7617A0344; Thu, 20 Apr 2017 16:15:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id BAF231C006C; Thu, 20 Apr 2017 16:15:04 +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.0319.002; Thu, 20 Apr 2017 16:15:04 +0200 From: To: Juliusz Chroboczek CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSud80FYN3Pf6Ey0Kw29UUSw2QvaHOS58Q Date: Thu, 20 Apr 2017 14:15:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E515E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7iefwnb2di.wl-jch@irif.fr> In-Reply-To: <7iefwnb2di.wl-jch@irif.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:15:08 -0000 Juliusz, No. This is not true.=20 Connections that are not eligible to network-assisted MPTCP service WON'T i= nvolve a proxy.=20 Cheers, Med > -----Message d'origine----- > De=A0: Juliusz Chroboczek [mailto:jch@irif.fr] > Envoy=E9=A0: jeudi 20 avril 2017 16:06 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > > What I meant by "native MPTCP connections" is that the CPE won't proxy > > a SYN that contains MP_CPABALE received from an MPTCP-capable > > client. That is, the CPE won't modify the destination IP address to the > > one of the network-located proxy. That SYN+MP_CPABALE will be received > > and handled directly by the remote server. >=20 > It will still act as a middlebox, though, with no way for the client to > avoid it. >=20 > -- Juliusz From nobody Thu Apr 20 07:36:34 2017 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 64DDB13147A for ; Thu, 20 Apr 2017 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYLBM0sBTv4P for ; Thu, 20 Apr 2017 07:36:32 -0700 (PDT) Received: from ndmsvnpf101.ndc.nasa.gov (NDMSVNPF101.ndc.nasa.gov [198.117.0.151]) (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 C59F0129A91 for ; Thu, 20 Apr 2017 07:36:31 -0700 (PDT) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndmsvnpf101.ndc.nasa.gov 9E0AA40050C6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492698990; bh=Q68j7Zs5SltsEHG/cDvh6rDIFn5EwMnqKb/gzwlqOOA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AeJJDKGcvOjl9tA020lJgmLKzuzE10hp26OtMHZ8vZ8ZGKTV7pvwughu+1esy/79Z pVYi5ZddtNWlS+/hSP3sTnzMXiktBGVIC6rE4xpFXH/3U/cnKblZ2LpPMqvU+nqoHJ k/mg9QbA0YxK2ejByLzFp8cueXJjA3rDsFSS0UYTkNkDYoMSKooWipXaP2V/LriaCx 0YfU20wW9Tle881Kvq/ZWsrSs7BmEl4cpG9hQ5r5LYYgz3a2kgCL4nxdB3cUgvUSc+ BS3lOkIGzrVVd51JisEKbzkKeLNAE662wBop2gJxKXaALeUglv6yJpi9uQSLBoDkz8 x/c0su13svNjw== Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id 9E0AA40050C6; Thu, 20 Apr 2017 09:36:30 -0500 (CDT) Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3KEaSXC015891; Thu, 20 Apr 2017 09:36:30 -0500 Received: from ndjscht111.ndc.nasa.gov (ndjscht111-pub.ndc.nasa.gov [198.117.1.211]) by ndjsppt103.ndc.nasa.gov with ESMTP id 29xxpvg1h4-4; Thu, 20 Apr 2017 09:36:30 -0500 Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.9]) by NDJSCHT111.ndc.nasa.gov ([198.117.1.181]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 09:32:44 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: "mohamed.boucadair@orange.com" CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAAB4TboAAD/kHAAAhVsoAABLdBYA= Date: Thu, 20 Apr 2017 14:32:44 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <651373719410144C9DDE8D1F4A3497D7@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-20_13:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:36:33 -0000 Hi Med, Thanks for the response. > On Apr 20, 2017, at 1:32 AM, mohamed.boucadair@orange.com wrote: >=20 > What I meant by "native MPTCP connections" is that the CPE won't proxy a = SYN that contains MP_CPABALE received from an MPTCP-capable client. That is= , the CPE won't modify the destination IP address to the one of the network= -located proxy. That SYN+MP_CPABALE will be received and handled directly b= y the remote server. =20 I thought this was the case.=20 Part of this proposal that I do not support is that network assistance requ= ires connection hijacking. There is no plan to have the network assist 2 MP= TCP hosts that want end-to-end connectivity. Here is a network diagram I drew up: https://docs.google.com/drawings/d/1VQyZgcg3aHoB0VVeCBYlc6cTVD6a0ZrwXFtw6Ev= Nw6s/edit?usp=3Dsharing What I would like to see is a solution that supports the following: The cell phone and server have on ongoing connection over Path 3. Now this = phone wants to add a subflow using the WiFi interface. How could the networ= k assist this connection to enable the use of both Path 1 and Path 2 rather= than (Path 1 xor Path 2) in an end-to-end manner? In other words, how coul= d the cell phone discover it should start a second subflow over WiFi? Maybe there is an MPTCP-based solution. Maybe there is an out of band solut= ion. I have not fleshed anything out at the moment, but I think network ass= istance in a more general sense is a useful topic to dwell on. Thanks, Matt= From nobody Thu Apr 20 08:16:30 2017 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 58446129A90 for ; Thu, 20 Apr 2017 08:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 MVcrGbToFl1x for ; Thu, 20 Apr 2017 08:16:27 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.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 43E13128D19 for ; Thu, 20 Apr 2017 08:16:27 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id B3A22C01AA; Thu, 20 Apr 2017 17:16:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 7F4BA1A0062; Thu, 20 Apr 2017 17:16:25 +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.0319.002; Thu, 20 Apr 2017 17:16:25 +0200 From: To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQAZ8zuAAB4TboAAD/kHAAAhVsoAABLdBYAAChGW0A== Date: Thu, 20 Apr 2017 15:16:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E516D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 15:16:29 -0000 Matt,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies] > [mailto:matthew.t.sargent@nasa.gov] > Envoy=E9=A0: jeudi 20 avril 2017 16:33 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: philip.eardley@bt.com; multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > Hi Med, >=20 > Thanks for the response. >=20 > > On Apr 20, 2017, at 1:32 AM, mohamed.boucadair@orange.com wrote: > > > > What I meant by "native MPTCP connections" is that the CPE won't proxy = a > SYN that contains MP_CPABALE received from an MPTCP-capable client. That > is, the CPE won't modify the destination IP address to the one of the > network-located proxy. That SYN+MP_CPABALE will be received and handled > directly by the remote server. >=20 > I thought this was the case. >=20 > Part of this proposal that I do not support is that network assistance > requires connection hijacking. There is no plan to have the network assis= t > 2 MPTCP hosts that want end-to-end connectivity. >=20 > Here is a network diagram I drew up: > https://docs.google.com/drawings/d/1VQyZgcg3aHoB0VVeCBYlc6cTVD6a0ZrwXFtw6= E > vNw6s/edit?usp=3Dsharing >=20 > What I would like to see is a solution that supports the following: >=20 > The cell phone and server have on ongoing connection over Path 3. Now thi= s > phone wants to add a subflow using the WiFi interface. How could the > network assist this connection to enable the use of both Path 1 and Path = 2 > rather than (Path 1 xor Path 2) in an end-to-end manner? [Med] A proposal we have to make use of path diversity corresponds to Case = 6 of slide 16 (https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-s= essa-network-assisted-mptcp-03.pdf). To do so, the CPE needs to be provided= with a policy so that this connection is eligible to network-assisted MPTC= P. These policies are discussed in https://tools.ietf.org/html/draft-boucad= air-mptcp-plain-mode-10#section-7.2.1.=20 In addition to that policy, we have a configurable parameter to instruct th= e proxy to be removed from the path (see Section 5.6.1 of that draft) =3D=3D Whether an MCP must be maintained in the processing of an MPTCP connection that involve MPTCP-capable clients and server is a configurable parameter. =3D=3D Note that blindly withdrawing a proxy when both the client and server are M= PTCP-capable may lead to some issues:=20 =3D=3D 1. The use of private IPv4 addresses in some access networks. Typically, additional subflows can not be added to the MPTCP connection without the help of an MCP. 2. The assignment of IPv6 prefix only by some networks. If the server is IPv4-only, subflows that are placed over IPv6 cannot be added to an MPTCP connection towards that server. 3. Some of the access networks are subject to subscription with volume quota. =3D=3D In other words, > how could the cell phone discover it should start a second subflow over > WiFi? [Med] This is a general MPTCP problem: triggers to add new subflows to an M= PTCP connection. We don't require a modification to that behavior. If appro= priate policies are configured on the CPE (LAN), subflows will be created o= ver existing multiple paths. Doing so allows for rich path diversity. =20 >=20 > Maybe there is an MPTCP-based solution. [Med] Another proposal would be to use a means to create state for incoming= connections for each CPE WAN interfaces (PCP (RFC6887)) + discover the ext= ernal IP addresses allocated to the CPE, and then advertise these addresses= /ports to the remote MPTCP endpoint. The remote MPTCP will create subflow u= sing these addresses. The extension in https://tools.ietf.org/html/draft-bo= ucadair-mptcp-symmetric-02 can be used to encourage the remote endpoint to = create incoming subflows. Maybe there is an out of band > solution. I have not fleshed anything out at the moment, but I think > network assistance in a more general sense is a useful topic to dwell on. [Med] I agree.=20 >=20 >=20 > Thanks, > Matt From nobody Thu Apr 20 10:25:05 2017 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 3A3E4129B39 for ; Thu, 20 Apr 2017 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bNjPVx0E4MH for ; Thu, 20 Apr 2017 10:25:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87984129B31 for ; Thu, 20 Apr 2017 10:25:01 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3KHOWip006732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Apr 2017 10:24:32 -0700 (PDT) To: mohamed.boucadair@orange.com, Yoshifumi Nishida References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: multipathtcp From: Joe Touch Message-ID: Date: Thu, 20 Apr 2017 10:24:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------F79FF6160DF9B5089637E01E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:25:03 -0000 This is a multi-part message in MIME format. --------------F79FF6160DF9B5089637E01E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Med, On 4/19/2017 10:50 PM, mohamed.boucadair@orange.com wrote: > > Hi Joe, > > > > I don’t understand your comments here: > > · The use of a 32-bit magic number is meant to distinguish > application-supplied data from the one inserted by the proxy. There > are other fields in the MP_CONVERT information element that help in > that aim too (validation of the TLV, M-bit, for example). > > · Both entities that supply and process the data are under the > control of the same operator. > > · The network-located proxy is explicitly configured on the > CPE. The destination IP address of the packet is an address of that > proxy, not the address of a legacy node. > > · The proxy must echo supplied data in a SYN/ACK. If a > mismatch is detected by the CPE, that proxy WON’t be used for > subsequent connections till a new proxy is configured, TTL expires, etc. > > > > To sum: > > · We are acting on one single SYN of an MPTCP connection. > > · If a mismatch is detected for one single SYN of a given > connection, all subsequent connections (with any remote server) won’t > be relayed to that proxy. > > > > How is this “hazardous� > TCPM archives are full of discussions on why TFO only works for subsequent connections to the same endpoint, due to cached cookies that allow the SYN data to be safely interpreted *before* the end of the 3WHS. MPTCP archives are full of discussions on why the data plane is not a good place to put option information. It's not practical to repeat those arguments in one email. The point is that you're reinventing the wheel in ways that this group and other groups already know are hazardous. Joe > > > Thank you. > > > > Cheers, > > Med > > > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* mercredi 19 avril 2017 20:12 > *À :* BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida > *Cc :* multipathtcp > *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work > > > > > > > > On 4/18/2017 10:46 PM, mohamed.boucadair@orange.com > wrote: > > ... > > Using the SYN data as control information is the hazardous part. > > [Med] It isn’t for the for the simple reason that legacy Internet > nodes will never receive a SYN with CPE-supplied data and that the > TCP peer is known to process the supplied data. A Guard against > misconfigurations is supported: echo in a SYN/ACK. > > > The idea of using a magic number to protect against miscommunication > virtually ensures that there will be reliable connections with errors. > That changes TCPs semantics. > > Putting data in the SYN of TFO is permitted only because of previous > state. > > MPTCP doesn't have that state and so it is hazardous to put data in > the SYN. > > I.e., if you want TFO-like performance, figure out how to use TFO. Period. > > Joe > --------------F79FF6160DF9B5089637E01E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Med,


On 4/19/2017 10:50 PM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

I don’t understand your comments here:

·         The use of a 32-bit magic number is meant to distinguish application-supplied data from the one inserted by the proxy. There are other fields in the MP_CONVERT information element that help in that aim too (validation of the TLV, M-bit, for example).

·         Both entities that supply and process the data are under the control of the same operator.

·         The network-located proxy is explicitly configured on the CPE. The destination IP address of the packet is an address of that proxy, not the address of a legacy node.

·         The proxy must echo supplied data in a SYN/ACK. If a mismatch is detected by the CPE, that proxy WON’t be used for subsequent connections till a new proxy is configured, TTL expires, etc.

 

To sum:

·         We are acting on one single SYN of an MPTCP connection.

·         If a mismatch is detected for one single SYN of a given connection, all subsequent connections (with any remote server) won’t be relayed to that proxy.

 

How is this “hazardous�


TCPM archives are full of discussions on why TFO only works for subsequent connections to the same endpoint, due to cached cookies that allow the SYN data to be safely interpreted *before* the end of the 3WHS.

MPTCP archives are full of discussions on why the data plane is not a good place to put option information.

It's not practical to repeat those arguments in one email. The point is that you're reinventing the wheel in ways that this group and other groups already know are hazardous.

Joe

 

Thank you.

 

Cheers,

Med

 

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 19 avril 2017 20:12
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

 

 

 

On 4/18/2017 10:46 PM, mohamed.boucadair@orange.com wrote:

...

Using the SYN data as control information is the hazardous part.

[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.


The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics.

Putting data in the SYN of TFO is permitted only because of previous state.

MPTCP doesn't have that state and so it is hazardous to put data in the SYN.

I.e., if you want TFO-like performance, figure out how to use TFO. Period.

Joe


--------------F79FF6160DF9B5089637E01E-- From nobody Thu Apr 20 10:31:57 2017 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 B61831201FA for ; Thu, 20 Apr 2017 10:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaAO4LzWVSLc for ; Thu, 20 Apr 2017 10:31:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AEF13149F for ; Thu, 20 Apr 2017 10:31:50 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3KHUVhF007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Apr 2017 10:30:32 -0700 (PDT) To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> Date: Thu, 20 Apr 2017 10:30:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------DA20779EA38FC7FA2D4D28B9" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:31:56 -0000 This is a multi-part message in MIME format. --------------DA20779EA38FC7FA2D4D28B9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Med, On 4/19/2017 11:16 PM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* mercredi 19 avril 2017 20:17 > *À :* BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work > > > > > > > > On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com > wrote: > > As explained in my previous message, there is no layered > congestion control. All packets are transported over plain TCP: no > encap, no tunnel. > > I did say "if"; I now understand better what you're trying to do, but > there are plenty of parts still not addressed: > > > I really reiterate my comment to read > https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf > > Here's what those slides do not explain: > > - is this system 1:1 per client TCP connection, or are you expecting a > single MPTCP between proxies to support multiples? > > [Med] We are not multiplexing connections. This is explained in > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2: > > The upstream MCP maps an upstream TCP connection onto a downstream > > MPTCP connection (and its associated subflows) . On the upstream MCP, > > an established MPTCP connection can be identified by the local Token > > that was assigned upon reception of the SYN segment from the Client. > > Great. It would be useful to explain this a lot earlier and at a higher level. > - what is the congestion control interaction? I.e., does the client > think the RTT is to the proxy (which will work), or to the TCP > receiver past the end of the MPTCP connection? > NOTE: if the latter, then you still end up with layered congestion > control > > [Med] The one to the proxy. This is important for subflows management > and traffic distribution. > > So you have three congestion controls running in series? Have you considered the impact on bufferbloat (of the buffers in the proxy) and reactivity? > - what is the proxy relaying? > is it TCP data, or is it somehow trying to tunnel and reconstitute > the entire packet? > > [Med] The proxy will need to strop any supplied-data in the initial > SYN, and then create a state to be used for handling subsequent > packets of that connection. Once a state is created, we are doing > something similar to SOCKS for the data plane. There are some new > features compared to SOCKS that I won’t detail here. The reader may > refer to > https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01. > > If you strip user-supplied data in the SYN, you're *changing TCP semantics* - esp. for a TFO connection. So you really can't be doing that... > NOTE: if it reconstitutes the packet, what happens when you get an > option you don't understand? E.g., EDO? > > [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not > touch options that are inserted by a TCP endpoint. The proxy is not > required to understand those options. The only modification we are > doing at this level is to insert MPTCP options. And even for this > case, as shown in slide 30, when there is an exhausted TCP option > space in the original SYN, ** no ** MPTCP options are inserted. So, > all is safe. > What happens if you create a segment that's larger than the PMTU? what do you drop or split? (there's no way to do that safely for unknown options) > There are still plenty of more concerns with this system. Overall, you > *still* appear to be doing one of two things: > > a) acting like a conventional application-layer proxy, which would > be fine but would not require any new RFCs > b) tunneling - or acting exactly like you're tunneling, by > reconstituting packets on the other end - a TCP connection over TCP, > which is a bad idea > > So which is it? Or is it something else? > > [Med] Interoperability is needed here because the CPE and the > network-located proxy are provided by distinct vendors. For example, > the format, location, and processing of the supplied proxy data is to > be standardized. Other matters like those you mentioned are key to > keep in mind. > If that were the case, you'd simply be defining a new application service and asking for a TCP port number. And you wouldn't be able to do zero-RTT opens. Joe --------------DA20779EA38FC7FA2D4D28B9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Med,

On 4/19/2017 11:16 PM, mohamed.boucadair@orange.com wrote:

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 19 avril 2017 20:17
À : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

 

 

 

On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:


 I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?

[Med] We are not multiplexing connections. This is explained in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2:

   The upstream MCP maps an upstream TCP connection onto a downstream

   MPTCP connection (and its associated subflows) . On the upstream MCP,

   an established MPTCP connection can be identified by the local Token

   that was assigned upon reception of the SYN segment from the Client.



Great. It would be useful to explain this a lot earlier and at a higher level.

- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control

[Med] The one to the proxy. This is important for subflows management and traffic distribution.


So you have three congestion controls running in series? Have you considered the impact on bufferbloat (of the buffers in the proxy) and reactivity?

- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?

[Med] The proxy will need to strop any supplied-data in the initial SYN, and then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doing something similar to SOCKS for the data plane. There are some new features compared to SOCKS that I won’t detail here. The reader may refer to https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.
   

If you strip user-supplied data in the SYN, you're *changing TCP semantics* - esp. for a TFO connection.

So you really can't be doing that...

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?

[Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification we are doing at this level is to insert MPTCP options. And even for this case, as shown in slide 30, when there is an exhausted TCP option space in the original SYN, ** no ** MPTCP options are inserted. So, all is safe.

What happens if you create a segment that's larger than the PMTU? what do you drop or split? (there's no way to do that safely for unknown options)

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?

[Med] Interoperability is needed here because the CPE and the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be standardized. Other matters like those you mentioned are key to keep in mind.

If that were the case, you'd simply be defining a new application service and asking for a TCP port number.

And you wouldn't be able to do zero-RTT opens.

Joe


--------------DA20779EA38FC7FA2D4D28B9-- From nobody Thu Apr 20 13:02:41 2017 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 58000131652 for ; Thu, 20 Apr 2017 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ7lJlkCStUT for ; Thu, 20 Apr 2017 13:02:37 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 64C1B13162B for ; Thu, 20 Apr 2017 13:02:37 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3KK2Zej026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Apr 2017 22:02:35 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3KK2ZRf001593; Thu, 20 Apr 2017 22:02:35 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3043AD7952; Thu, 20 Apr 2017 22:02:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id JZmnGmaJ9PM4; Thu, 20 Apr 2017 22:02:34 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7B990D7936; Thu, 20 Apr 2017 22:02:32 +0200 (CEST) Date: Thu, 20 Apr 2017 22:02:41 +0200 Message-ID: <87fuh2kftq.wl-jch@irif.fr> From: Juliusz Chroboczek To: Cc: "multipathtcp@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E515E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7iefwnb2di.wl-jch@irif.fr> <787AE7BB302AE849A7480A190F8B933009E515E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 20 Apr 2017 22:02:35 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 20 Apr 2017 22:02:35 +0200 (CEST) X-Miltered: at korolev with ID 58F913DB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F913DB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F913DB.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F913DB.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58F913DB.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F913DB.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:02:40 -0000 >>> What I meant by "native MPTCP connections" is that the CPE won't proxy >>> a SYN that contains MP_CPABALE received from an MPTCP-capable >>> client. That is, the CPE won't modify the destination IP address to the >>> one of the network-located proxy. That SYN+MP_CPABALE will be received >>> and handled directly by the remote server. >> It will still act as a middlebox, though, with no way for the client to >> avoid it. > No. This is not true. > Connections that are not eligible to network-assisted MPTCP service > WON'T involve a proxy. I've probably missed something, then. I don't see anything in -10 that says that non-eligible packets are forwarded statelessly without any modification, including forwarding unknown IP and TCP options. All I see on the subject is Section 4.3 paragraph 2, which I find hardly reassuring. My gut feeling is that either the proxy is implemented at the upper layers, in which case it terminates all connections and hence discards any unknown options, or it is implemented at a lower layer, allowing it to bypass selected packets, in which case it is no longer a mere upper layer proxy. I just don't see how you can have it both ways. Could you please explain what I'm missing? -- Juliusz From nobody Thu Apr 20 22:31:14 2017 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 92DCB12773A for ; Thu, 20 Apr 2017 22:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoYZ981ftwt3 for ; Thu, 20 Apr 2017 22:31:08 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C82128CDC for ; Thu, 20 Apr 2017 22:31:07 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 169B6C06CE; Fri, 21 Apr 2017 07:31:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id BF1AC20057; Fri, 21 Apr 2017 07:31:05 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 07:31:05 +0200 From: To: Joe Touch , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSufvNFYN3Pf6Ey0Kw29UUSw2QvaHPSNdw Date: Fri, 21 Apr 2017 05:31:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> In-Reply-To: <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E51CDFOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:31:12 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E51CDFOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, Please see inline. Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoy=E9 : jeudi 20 avril 2017 19:30 =C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.o= rg Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work Med, On 4/19/2017 11:16 PM, mohamed.boucadair@orange.com wrote: Re-, Please see inline. Cheers, Med De : Joe Touch [mailto:touch@isi.edu] Envoy=E9 : mercredi 19 avril 2017 20:17 =C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.org Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote: As explained in my previous message, there is no layered congestion control= . All packets are transported over plain TCP: no encap, no tunnel. I did say "if"; I now understand better what you're trying to do, but there= are plenty of parts still not addressed: I really reiterate my comment to read https://www.ietf.org/proceedings/98/= slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf Here's what those slides do not explain: - is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples? [Med] We are not multiplexing connections. This is explained in https://too= ls.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2: The upstream MCP maps an upstream TCP connection onto a downstream MPTCP connection (and its associated subflows) . On the upstream MCP, an established MPTCP connection can be identified by the local Token that was assigned upon reception of the SYN segment from the Client. Great. It would be useful to explain this a lot earlier and at a higher lev= el. - what is the congestion control interaction? I.e., does the client think t= he RTT is to the proxy (which will work), or to the TCP receiver past the e= nd of the MPTCP connection? NOTE: if the latter, then you still end up with layered congestion cont= rol [Med] The one to the proxy. This is important for subflows management and t= raffic distribution. So you have three congestion controls running in series? Have you considere= d the impact on bufferbloat (of the buffers in the proxy) and reactivity? [Med] A detailed specification will need to discuss these details once we h= ave a WG document. - what is the proxy relaying? is it TCP data, or is it somehow trying to tunnel and reconstitute the = entire packet? [Med] The proxy will need to strop any supplied-data in the initial SYN, an= d then create a state to be used for handling subsequent packets of that co= nnection. Once a state is created, we are doing something similar to SOCKS = for the data plane. There are some new features compared to SOCKS that I wo= n't detail here. The reader may refer to https://tools.ietf.org/html/draft-= nam-mptcp-deployment-considerations-01. If you strip user-supplied data in the SYN, you're *changing TCP semantics*= - esp. for a TFO connection. [Med] There is a misunderstand here : the user supplied data is NOT striped= /altered. What is striped is MP_CONVERT IEs (proxy supplied data). So you really can't be doing that... [Med] We are not doing it. NOTE: if it reconstitutes the packet, what happens when you get an opti= on you don't understand? E.g., EDO? [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touc= h options that are inserted by a TCP endpoint. The proxy is not required to= understand those options. The only modification we are doing at this level= is to insert MPTCP options. And even for this case, as shown in slide 30, = when there is an exhausted TCP option space in the original SYN, ** no ** M= PTCP options are inserted. So, all is safe. What happens if you create a segment that's larger than the PMTU? what do y= ou drop or split? (there's no way to do that safely for unknown options) [Med] This is not specific to this proposal. As a reminder, we have this pr= oblem only of the initial SYN. My take on this is to augment the MTU on the= CPE and the network side to absorb MP_CONVERT. These details will be worke= d out in the WG endorsed document. It is likely that we inspire from the re= commendations in draft-ietf-rtgwg-dt-encap-02#section-9: "assume well-manag= ed MTU hence no need for fragmentation and reassembly". There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things: a) acting like a conventional application-layer proxy, which would be f= ine but would not require any new RFCs b) tunneling - or acting exactly like you're tunneling, by reconstituti= ng packets on the other end - a TCP connection over TCP, which is a bad ide= a So which is it? Or is it something else? [Med] Interoperability is needed here because the CPE and the network-locat= ed proxy are provided by distinct vendors. For example, the format, locatio= n, and processing of the supplied proxy data is to be standardized. Other m= atters like those you mentioned are key to keep in mind. If that were the case, you'd simply be defining a new application service a= nd asking for a TCP port number. And you wouldn't be able to do zero-RTT opens. [Med] 0-RTT is a key requirement for the WG. Joe --_000_787AE7BB302AE849A7480A190F8B933009E51CDFOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Please see inline.

 

Cheers,

Med

 

De := Joe Touch [mailto:touch@isi.edu]
Envoy=E9 : jeudi 20 avril 2017 19:30
=C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipa= thtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

Med,

On 4/19/2017 11:16 PM, mohamed.boucadair@orange.com wrote:

Re-,

 

Please see inline.

 

Cheers,

Med

 

De := Joe Touch [m= ailto:touch@isi.edu]
Envoy=E9 : mercredi 19 avril 2017 20:17
=C0 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP pr= oxy work

 

 

 

On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com wrote:

As explained in my previou= s message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I did say "if"; I now understand better wh= at you're trying to do, but there are plenty of parts still not addressed:<= br>


 I really reiterate m= y comment to read https://w= ww.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mp= tcp-03.pdf

= Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a sing= le MPTCP between proxies to support multiples?

[Med] We are not multiplexing connections. This is expla= ined in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2= .2:

 &= nbsp; The upstream MCP maps an upstream TCP connection onto a downstream

 &= nbsp; MPTCP connection (and its associated subflows) . On the upstream MCP,=

 &= nbsp; an established MPTCP connection can be identified by the local Token<= /span>

 &= nbsp; that was assigned upon reception of the SYN segment from the Client.<= /span>

 


Great. It would be useful to explain this a lot earlier and at a higher lev= el.


= - what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work= ), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered = congestion control

[Med] The one to the proxy. This is important for subflo= ws management and traffic distribution.

 

So you have three congestion controls running in ser= ies? Have you considered the impact on bufferbloat (of the buffers in the p= roxy) and reactivity?

[Med] A detai= led specification will need to discuss these details once we have a WG docu= ment.


= - what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and re= constitute the entire packet?

[Med] The proxy will need to strop any supplied-data in = the initial SYN, and then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doi= ng something similar to SOCKS for the data plane. There are some new featur= es compared to SOCKS that I won’t detail here. The reader may refer t= o https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.
   

If you strip user-supplied data in the SYN, you're *= changing TCP semantics* - esp. for a TFO connection.

[Med] There i= s a misunderstand here : the user supplied data is NOT striped/altered= . What is striped is MP_CONVERT IEs (proxy supplied data).


So you really can't be doing that...

[Med] We are = not doing it.




=     NOTE: if it reconstitutes the packet, what happens when = you get an option you don't understand? E.g., EDO?

[Med] EDO can be passed via the MPTCP proxy safely. The = proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modificati= on we are doing at this level is to insert MPTCP options. And even for this= case, as shown in slide 30, when there is an exhausted TCP option space in= the original SYN, ** no ** MPTCP options are inserted. So, all is safe.

What happens if you create a segment that's larger t= han the PMTU? what do you drop or split? (there's no way to do that safely = for unknown options)

[Med] This is= not specific to this proposal. As a reminder, we have this problem only of= the initial SYN. My take on this is to augment the MTU on the CPE and the network side to absorb MP_CONVERT. These details will be w= orked out in the WG endorsed document. It is likely that we inspire from th= e recommendations in draft-ietf-rtgwg-dt-encap-02#section-9: “assume well-managed MTU hence no need for fragmentation a= nd reassembly”.



= There are still plenty of more concerns with this system. Overall, you *sti= ll* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, w= hich would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, = by reconstituting packets on the other end - a TCP connection over TCP, whi= ch is a bad idea

So which is it? Or is it something else?

[Med] Interoperability is needed here because the CPE an= d the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy da= ta is to be standardized. Other matters like those you mentioned are key to= keep in mind.

If that were the case= , you'd simply be defining a new application service and asking for a TCP p= ort number.

And you wouldn't be able to do zero-RTT opens.<= o:p>

[Med] 0-RTT is a key requirement for the WG.

Joe

--_000_787AE7BB302AE849A7480A190F8B933009E51CDFOPEXCLILMA3corp_-- From nobody Thu Apr 20 23:03:09 2017 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 C96A012773A for ; Thu, 20 Apr 2017 23:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyxTZ01R3uU for ; Thu, 20 Apr 2017 23:03:07 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64370127599 for ; Thu, 20 Apr 2017 23:03:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,228,1488873600"; d="asc'?scan'208";a="188746297" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 20 Apr 2017 22:48:37 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 23:02:03 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 20 Apr 2017 23:02:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Wsy9RaDHy01r7c4mGuP1/nU+AIV3AR+bG/knrGUqpY=; b=owcckr/SVLNCrtDj8zsnz3HwFvw6a7JjPm0pl/kfpsOByKLPCoPujX3VsZvv6tdeKEEJqAEhhuDvMsGWHhEFL3GKQvo9/9wTabnAs8npaKsosxqgJ5NwodKOAbrUg3oru2hGq2ie7Is7M+Xs6QLnxE5Q4Eb4+G3KkEHIiOC/3so= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Fri, 21 Apr 2017 06:02:02 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.1047.013; Fri, 21 Apr 2017 06:02:01 +0000 From: "Eggert, Lars" To: Philip Eardley CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgCSLSEA Date: Fri, 21 Apr 2017 06:02:01 +0000 Message-ID: <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: bt.com; dkim=none (message not signed) header.d=none;bt.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:zTBjJhkd5ObUkifZulOFYfW0y8j9hU6ccx2pWeuTFgPStlUu9x1Ge2amo6UbM1bkqTKbkK9td8aphnqtyXww87ZR82ddvaCf0uS8qw7ytDG1D4o90dR4BXnA0imqC66x8ciMxVDXO22CMY3WbltmMwHRdtqOXICj9azLH8koF9a1aXrmY33ZcNOkrrXgDzU3wOD+K4zzIIHZ6gPtE0A1jbCtfoW9QGBl5c+s8koK260wAz7JvnNV7TJADfGQZ8tRHP7BvWTy57axXatUvFYyl10b89Und4bqWS2pmRR/byiK5RhahzDIvonnHNqioBr3D10XXF2jevhI9C1DXUFzUg== x-ms-office365-filtering-correlation-id: 15215e65-47dc-42fd-a33c-08d4887bedd2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(146908506813832)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39400400002)(39840400002)(39850400002)(39450400003)(39410400002)(377424004)(24454002)(33656002)(99936001)(76176999)(36756003)(50986999)(3280700002)(57306001)(2906002)(106356001)(3660700001)(81166006)(8676002)(7736002)(50226002)(8936002)(6116002)(3846002)(305945005)(5660300001)(6436002)(102836003)(6486002)(77096006)(99286003)(82746002)(6506006)(229853002)(4326008)(25786009)(53546009)(53936002)(66066001)(6512007)(6246003)(110136004)(189998001)(83716003)(122556002)(4001150100001)(38730400002)(6916009)(86362001)(2950100002)(2900100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_E66CE165-3AE0-45E6-A114-E4B2E9C1448B"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 06:02:01.7504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:03:09 -0000 --Apple-Mail=_E66CE165-3AE0-45E6-A114-E4B2E9C1448B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2017-4-18, at 10:17, philip.eardley@bt.com wrote: > Please say whether you support, or don=E2=80=99t support, such work = =E2=80=93 so we can see if there=E2=80=99s consensus for it. I don't support doing proxy work in MPTCP. Sure, you can probably take a sledgehammer to MPTCP and make it roughly = conform to what operators believe they need here (cf. RFC1925 clause 3). = But I believe that MPTCP is fundamentally the wrong starting point for = solutions to this problem space. Lars --Apple-Mail=_E66CE165-3AE0-45E6-A114-E4B2E9C1448B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlj5oFQACgkQVLXDCb9w wVcEiRAAh3WZ3SF9e2tu0lKlqoDgW7DJXSYK8KqZlYcVxx90yMB4+HOeQ3lex8eH o2HAaSS8zEsUTLuYqNgR2g3MxG03fLkWhoXMx9BwQ3QdRUnUJLciOPG3JEJU8jz+ fTBdBDo7NypyROkM7NXSVPshFZa0PGQVVDKTLkGTkbd9OCT2pAIUrktn9P+J20ZT Uo3WLP5hTdrOXg3DrOwQMNvWOXG+jx+V/7JdkcftPg23+J5TmJ4kmxVoEHqx65fg 3NdKqGddq5ZfenbeRfn1k9XVseKGiIR+xKJbtCFYRjyY0CUDa5HkayBfdzYYjnrD 9AIwOnhdjATHGsmDHIq/o5amCPNfFxh34x3ta0LdJQgg886IxNiqxgW7i3rnCKZk 43oGOZGJZt1HfQcgKaRyCnNalixsecjyogIRhZPzLEyep9MK/66TiET0yKERU6zI OwJ5x3KJ0lVChx7pM+Wmxktsrl7hsHwnmakSUhmc8MZcawKNyUasx0Vf0xHhM16K fCu5y8p3K9kq+PhuwuA6VkKfI4xxLhDl7IVnIko0q0LLq3LR9oQ+j9ZGBP6IiqMO B/O9vCt3PgsdRDSS8WMBmAMft8S1UI/wGfrk6k01AZzYF3isjyKvu6euT2ySDIhT Ttm7Eo/oLd39C+FC43/vHhR+4j/2iEkHLkkNN9B0Tunbr+MhPxM= =vjGK -----END PGP SIGNATURE----- --Apple-Mail=_E66CE165-3AE0-45E6-A114-E4B2E9C1448B-- From nobody Thu Apr 20 23:07:36 2017 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 2841612773A for ; Thu, 20 Apr 2017 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI730fYc6dn1 for ; Thu, 20 Apr 2017 23:07:34 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 00684127599 for ; Thu, 20 Apr 2017 23:07:33 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 57800C0355; Fri, 21 Apr 2017 08:07:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id DD2DA208E1; Fri, 21 Apr 2017 08:07:31 +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.0319.002; Fri, 21 Apr 2017 08:07:31 +0200 From: To: Juliusz Chroboczek CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSuhERFYN3Pf6Ey0Kw29UUSw2QvaHPTV8w Date: Fri, 21 Apr 2017 06:07:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E51D1E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <02572A11-A7D5-49D2-A31A-61B575613DF3@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <90A6EE89-D089-46C1-980F-9DE5DE2B07B7@nasa.gov> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7iefwnb2di.wl-jch@irif.fr> <787AE7BB302AE849A7480A190F8B933009E515E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <87fuh2kftq.wl-jch@irif.fr> In-Reply-To: <87fuh2kftq.wl-jch@irif.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:07:35 -0000 Hi Jaliusz, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Juliusz Chroboczek [mailto:jch@irif.fr] > Envoy=E9=A0: jeudi 20 avril 2017 22:03 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > >>> What I meant by "native MPTCP connections" is that the CPE won't prox= y > >>> a SYN that contains MP_CPABALE received from an MPTCP-capable > >>> client. That is, the CPE won't modify the destination IP address to > the > >>> one of the network-located proxy. That SYN+MP_CPABALE will be receive= d > >>> and handled directly by the remote server. >=20 > >> It will still act as a middlebox, though, with no way for the client t= o > >> avoid it. >=20 > > No. This is not true. >=20 > > Connections that are not eligible to network-assisted MPTCP service > > WON'T involve a proxy. >=20 > I've probably missed something, then. I don't see anything in -10 that > says that non-eligible packets are forwarded statelessly without any > modification, including forwarding unknown IP and TCP options. [Med] Two comments here:=20 * We don't touch/alter existing IP/TCP options/EHs for ** both ** eligible = and non-eligible flows. This is something we will call out explicitly in th= e document to avoid misinterpretation. We are adding MPTCP options at the T= CP option level and MP_CONVERT IE in the first SYN. That's all.=20 * The document is focusing more on "what we are doing" not "what we are not= doing". It says for instance:=20 Any data that is eligible to be transported over the MPTCP connection ^^^^^^^^^^^^^^^^^^^^^^^^ is sent by the Client towards the MCP over the MPTCP connection. The MCP then forwards these data over the regular TCP connection until they reach the server. The same forwarding principle applies for the data sent by the Server over the TCP connection with the MCP.=20 and Any data received by the upstream MCP over the upstream TCP connection will be forwarded by the MCP over the bound downstream MPTCP connection, assuming such data are eligible to MPTCP transport. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The same applies for data received over the downstream MPTCP connection which will be forwarded by the upstream MCP over the upstream TCP connection. So, other flows will be processed following any default forwarding behavior= in place: that default may be NAT44, IPv4-in-IPv6 encap without NAT (DS-Li= te), IPv4-in-IPv6 encap with port-restricted NAT (MAP-E, lw4o6), CLAT (464x= lat), IPv4/IPv6 translation (MAP-E), .... The text will be updated to call this out. =20 All I see > on the subject is Section 4.3 paragraph 2, which I find hardly reassuring= . >=20 > My gut feeling is that either the proxy is implemented at the upper > layers, in which case it terminates all connections and hence discards an= y > unknown options, or it is implemented at a lower layer, allowing it to > bypass selected packets, in which case it is no longer a mere upper layer > proxy. I just don't see how you can have it both ways. >=20 > Could you please explain what I'm missing? [Med]=20 * This is an MPTCP proxy that does not need to understand IP/TCP options th= at are carried in the original SYN.=20 * The proxy located at the network side does only process packets that are = destined explicitly to it (i.e., DST@ of the packet=3D=3Dproxy@).=20 * Packets that are not eligible to MPTCP-assisted service, will be forwarde= d without involving a proxy.=20 * Even if that proxy is embedded in a device that is on a default forwardin= g path, the proxy won't intercept those packets because the destination add= ress !=3D proxy@.=20 >=20 > -- Juliusz From nobody Thu Apr 20 23:15:21 2017 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 154FA12869B for ; Thu, 20 Apr 2017 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI9VIp_7I1Xo for ; Thu, 20 Apr 2017 23:15:19 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 D8FA1127599 for ; Thu, 20 Apr 2017 23:15:18 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 9C3C5C0650; Fri, 21 Apr 2017 08:15:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 57788400A9; Fri, 21 Apr 2017 08:15:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 08:15:17 +0200 From: To: "Eggert, Lars" , Philip Eardley CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQCSLSEAAABdPSA= Date: Fri, 21 Apr 2017 06:15:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> In-Reply-To: <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.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.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:15:20 -0000 TGFycywgDQoNCkkgZG9uJ3Qgc2VlIGFueSB0ZWNobmljYWwgYXJndW1lbnQgaW4geW91ciBtZXNz YWdlLiANCg0KSXMgaXQgcmVzcGVjdGZ1bCBmb3IgcGVvcGxlIHRvIGNpdGUgQXByaWwgMSBpbiBh IHNlcm91cyB0ZWNobmljYWwgZGlzY3Vzc2lvbj8NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRp cGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlDQo+IEVnZ2VydCwgTGFycw0K PiBFbnZvecOpwqA6IHZlbmRyZWRpIDIxIGF2cmlsIDIwMTcgMDg6MDINCj4gw4DCoDogUGhpbGlw IEVhcmRsZXkNCj4gQ2PCoDogbXVsdGlwYXRodGNwQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBb bXVsdGlwYXRodGNwXSBDb25zZW5zdXMgY2FsbCBvbiBwb3RlbnRpYWwgTVBUQ1AgcHJveHkgd29y aw0KPiANCj4gT24gMjAxNy00LTE4LCBhdCAxMDoxNywgcGhpbGlwLmVhcmRsZXlAYnQuY29tIHdy b3RlOg0KPiA+IFBsZWFzZSBzYXkgd2hldGhlciB5b3Ugc3VwcG9ydCwgb3IgZG9u4oCZdCBzdXBw b3J0LCBzdWNoIHdvcmsg4oCTIHNvIHdlIGNhbg0KPiBzZWUgaWYgdGhlcmXigJlzIGNvbnNlbnN1 cyBmb3IgaXQuDQo+IA0KPiBJIGRvbid0IHN1cHBvcnQgZG9pbmcgcHJveHkgd29yayBpbiBNUFRD UC4NCj4gDQo+IFN1cmUsIHlvdSBjYW4gcHJvYmFibHkgdGFrZSBhIHNsZWRnZWhhbW1lciB0byBN UFRDUCBhbmQgbWFrZSBpdCByb3VnaGx5DQo+IGNvbmZvcm0gdG8gd2hhdCBvcGVyYXRvcnMgYmVs aWV2ZSB0aGV5IG5lZWQgaGVyZSAoY2YuIFJGQzE5MjUgY2xhdXNlIDMpLg0KPiBCdXQgSSBiZWxp ZXZlIHRoYXQgTVBUQ1AgaXMgZnVuZGFtZW50YWxseSB0aGUgd3Jvbmcgc3RhcnRpbmcgcG9pbnQg Zm9yDQo+IHNvbHV0aW9ucyB0byB0aGlzIHByb2JsZW0gc3BhY2UuDQo+IA0KPiBMYXJzDQo= From nobody Thu Apr 20 23:27:46 2017 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 0140912869B for ; Thu, 20 Apr 2017 23:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeZn70uumyjM for ; Thu, 20 Apr 2017 23:27:43 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C28127599 for ; Thu, 20 Apr 2017 23:27:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,229,1488873600"; d="asc'?scan'208";a="183940184" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx142-out.netapp.com with ESMTP; 20 Apr 2017 23:13:22 -0700 Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 23:26:41 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 20 Apr 2017 23:26:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qR5OobyBMULK1Eq/cAim8e9omMEOhs/z45Qb3dPJSAQ=; b=MGM5RtYzwFvVqD2WT62CIUMc3UjvwTGzr8y6Lg8bLmJdnE2HR1Sy5j61R9AQTRuG11EjJO3Z8Nd5kaf/1v+c8f0tQqWGc3S1EUgA8ulxNitflXZuO/FvFHo3BV98r88L4t81U5uBkDiwnhdL6s6QN8aHSmJZZ5HcipFd6iAzjc8= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Fri, 21 Apr 2017 06:26:41 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.1047.013; Fri, 21 Apr 2017 06:26:41 +0000 From: "Eggert, Lars" To: "mohamed.boucadair@orange.com" CC: Philip Eardley , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgCSLSEAAAB3NgAAAGWgAA== Date: Fri, 21 Apr 2017 06:26:41 +0000 Message-ID: <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:9KjC+b7R6+6M25CPRdIvsLNhgNEM0WBcZhvm5W5pXrUpxtS7QiuthGoMLVVZwAfapEBJQYI1AXOIWmRYjWJylKVVt/kSKg2lwIXVW3NYIVAN9tPgNFC2StV6Pl/SQHvop6KscVKADGMo1U2yLG8geOgokq7Sq9d/2Y7w2ZQg4ZiJPbyNL/uP8KPJYBqllSC5W0oNXlS4H1+G4bAVZJsPtqOBnE75CwR1JJGrIalTE6RKXM+k7ejLVgBRu8YsX5ZupqJEjQTx0+cnMedeqc07SGYEPusM9FlRzcBfFSkwVymoEFBSGAeHzA7cF+rIHhCg85DVLlmFcJ/0WJqZ9I0kEQ== x-ms-office365-filtering-correlation-id: ad99c8de-dc43-46df-fc04-08d4887f5fa1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39840400002)(39450400003)(39410400002)(377424004)(24454002)(33656002)(2351001)(99936001)(76176999)(36756003)(50986999)(3280700002)(2501003)(2906002)(3660700001)(8676002)(50226002)(8936002)(7736002)(6116002)(3846002)(305945005)(5660300001)(6436002)(5640700003)(102836003)(77096006)(6486002)(99286003)(82746002)(54906002)(6506006)(229853002)(4326008)(25786009)(53546009)(53936002)(66066001)(6512007)(6246003)(110136004)(189998001)(83716003)(122556002)(38730400002)(6916009)(86362001)(2950100002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_CFE28894-30E7-4530-A27D-34E9270C3625"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 06:26:41.1820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:27:45 -0000 --Apple-Mail=_CFE28894-30E7-4530-A27D-34E9270C3625 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-4-21, at 8:15, mohamed.boucadair@orange.com wrote: > I don't see any technical argument in your message. we're not asked to have a technical discussion. We're asked whether we = support this work in MPTCP, and I don't, for the reasons stated. I think = MPTCP is architecturally the wrong starting point for solutions to this = operator problem space. > Is it respectful for people to cite April 1 in a serous technical = discussion? I provided the reference, because it summarizes my standpoint in a - = what I consider - humorous way. I do apologize if this caused offense. = As I said, I do believe that you can bang MPTCP out of shape to make it = do what's needed here - but that is true for other existing starting = points, some of which might be a more natural fit. Or not - that's not = the question we're asked to answer here. Lars --Apple-Mail=_CFE28894-30E7-4530-A27D-34E9270C3625 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlj5ph4ACgkQVLXDCb9w wVfunxAAyg2xpOJac4yoBjmfOhPYVlQEaFSi62P0PvgbFERqxH6Mc8iuOkn+t6ce WP59F+IdQed1iyy4DwKN8WvkPcN94t01cGTy9J8ueg5zNhMp+BRISQQT6OYIvpHB 9nBXIUlralcyJnAQteMly83A+OD2bQlyW/VcNmfv6cDN+7zxOVvsUZqkqLxQVLg6 16UBUDIZC619NghNDbVyRwnuLRKWkyy4er9jdzSw4U3okZVjZpNpsFwhlvf+dLN1 i/qbaChzL7GoankSUe8g0yOcaKzfBjGUS3/hrxZP2XBMW+Q1y4mGXE52nt4CE0Wv VxXZxCio9WxjaEWA/o+tcpibHF3plQoM5cBbo8dR0OBTWLYj3RjvkD+UtX+Mr2i1 xg8c34Sb4iGZOrqgW/ugsD6oLfkSvp1Y0ouAW1NPJUWUgbAe3/nPGY7OdrPVbBs9 Mx8oBz74DrHC9jxIVFNCVZk3v7IbiNlhixmK6zCqFxToxaccWDoPEM1venZKSnr+ 1TbubEfKrJPWtfODjEnk9omeoTboegeizF6NxxL4/M3OgGi2fT4DWVCj2vSWduV9 Rp52ZuiJ8pIeg7vixzOVrsbZX9DTF8a67Un5VKHuYHW0VMB7fqH8U9lQ+ZYUGcIo MjBYqiFSuFxAXBqdhxotg8VnZB82qiFRnkFJy27DlM9Wx/5b9X4= =Xkbn -----END PGP SIGNATURE----- --Apple-Mail=_CFE28894-30E7-4530-A27D-34E9270C3625-- From nobody Thu Apr 20 23:55:33 2017 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 03580128DF3 for ; Thu, 20 Apr 2017 23:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqFl198lIPgQ for ; Thu, 20 Apr 2017 23:55:28 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7050B126C83 for ; Thu, 20 Apr 2017 23:55:28 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id CE52B20525; Fri, 21 Apr 2017 08:55:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 9D8784005D; Fri, 21 Apr 2017 08:55:26 +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.0319.002; Fri, 21 Apr 2017 08:55:26 +0200 From: To: "Eggert, Lars" CC: Philip Eardley , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQCSLSEAAAB3NgAAAGWgAAAAJCvQ Date: Fri, 21 Apr 2017 06:55:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> In-Reply-To: <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:55:30 -0000 Re-, The initial message form Phil includes the following: "We believe the work = does not require an update to the MPTCP WG charter". So, the proposal is no= t to modify the MPTCP WG charter to cover the proxy work (the WG charter al= ready covers "MPTCP-aware middlebox" work), but to decide which technical a= pproach to follow for that item in the charter. I hopped you can explicit why "MPTCP is architecturally the wrong starting = point". This is not obvious to me. Sorry but I'm a fun of https://tools.iet= f.org/html/rfc7282#section-4 (Humming should be the start of a conversation= , not the end).=20 Lacking that information, I don't see a new element here that could lead to= change the consensus reached at the Chicago meeting (of course I'm not ent= itled to do that call anyway).=20 Cheers, Med > -----Message d'origine----- > De=A0: Eggert, Lars [mailto:lars@netapp.com] > Envoy=E9=A0: vendredi 21 avril 2017 08:27 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Philip Eardley; multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > Hi, >=20 > On 2017-4-21, at 8:15, mohamed.boucadair@orange.com wrote: > > I don't see any technical argument in your message. >=20 > we're not asked to have a technical discussion. We're asked whether we > support this work in MPTCP, and I don't, for the reasons stated. I think > MPTCP is architecturally the wrong starting point for solutions to this > operator problem space. >=20 > > Is it respectful for people to cite April 1 in a serous technical > discussion? >=20 > I provided the reference, because it summarizes my standpoint in a - what > I consider - humorous way. I do apologize if this caused offense. As I > said, I do believe that you can bang MPTCP out of shape to make it do > what's needed here - but that is true for other existing starting points, > some of which might be a more natural fit. Or not - that's not the > question we're asked to answer here. >=20 > Lars From nobody Fri Apr 21 02:01:05 2017 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 CAA6E129B29 for ; Fri, 21 Apr 2017 02:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjQ1TF6Fl_Dj for ; Fri, 21 Apr 2017 02:01:02 -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 BBEAD129A9F for ; Fri, 21 Apr 2017 02:01:01 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BE116279EAD for ; Fri, 21 Apr 2017 18:00:59 +0900 (JST) Received: by mail-oi0-f48.google.com with SMTP id y11so53581893oie.0 for ; Fri, 21 Apr 2017 02:00:59 -0700 (PDT) X-Gm-Message-State: AN3rC/7iOsLqMPSEZPT7alPUkw2gAvvEE9rVC4cnEusCAtZLKs4OGe1P sC0T20nLCsEuUGGhckQmBNgBHVjljQ== X-Received: by 10.202.102.206 with SMTP id m75mr6264195oik.206.1492765258072; Fri, 21 Apr 2017 02:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 02:00:57 -0700 (PDT) In-Reply-To: <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> From: Yoshifumi Nishida Date: Fri, 21 Apr 2017 02:00:57 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Yoshifumi Nishida , multipathtcp Content-Type: multipart/alternative; boundary=001a1140f77ef0ceea054da97e5b Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 09:01:04 -0000 --001a1140f77ef0ceea054da97e5b Content-Type: text/plain; charset=UTF-8 Hi Joe, On Tue, Apr 18, 2017 at 6:18 PM, Joe Touch wrote: > > On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote: > > Hi Joe, > > On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch wrote: > >> >> >> On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote: >> > Hi Joe, >> > >> > It's not tunneling. The proxy converts a tcp connection into a mptcp >> > connection and converts it back to a tcp connection (if necessary) >> > So, it won't be tcp over tcp. >> OK, but that's not proxying either. >> >> That's (at best) connection hijacking. >> > > I won't deny it as I'm not 100% sure whether proxy is a good name or not. > But, I am thinking you might want to call NAT hijacking as well. > > Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 > translation of only addresses and ports. > > Doing more than that has never been part of an IETF standard, AFAICT - for > many reasons. > I am not very sure how 1 TCP: 1 MPTCP translations is complicated yet. So, I don't have a reason to stop people exploring. > > MPTCP will convey control data for application (proxy) in payload. >> > But, MPTCP of course doesn't care the contents of payload. >> > It just carries data and app will parse the data. Putting data in SYN >> > is trying to reduce the latency and no other meaning as far as I >> > understand. >> >> MPTCP is TCP. Putting the data in the SYN of a TCP connection is >> hazardous. The goal is irrelevant. > > > In TCP, we already have a precedence such as TFO. > > > Sorry, to be more clear: > Data in the SYN has been part of TCP since it was standardized. > > Using the SYN data as control information is the hazardous part. > > I think what the solution does won't exceed what TFO does. > > TFO changes when the SYN data is delivered, based on the fact that past > cookie information "accelerates" the 3WHS. > > It does not put control plane information in the data area of the SYN. > In my view, TFO relies on the info from past connections and we somehow believe it's valid and not staled. But, it's still external info because it is from the outside of the current connection. This case relies on other type of external info and when we believe the info, we will send data in SYN. I personally don't see big differences. -- Yoshi --001a1140f77ef0ceea054da97e5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Tue, Apr 18, 2017 at 6:18 PM, Joe Touch <touch@isi.e= du> wrote:
On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote:
Hi Joe,

On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <touch@isi.edu> wrote:


On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> It's not tunneling. The proxy converts a tcp connection into a mptcp
> connection and converts it back to a tcp connection (if necessary)
> So, it won't be tcp over tcp.
OK, but that's not proxying either.

That's (at best) connection hijacking.

I won't deny it as I'm not 100% sure whether proxy= is a good name or not.=C2=A0
But, I am thinking you might want to call NAT hijacking as well.
 Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 translation of only addresses and ports.

Doing more than that has never been part of an IETF standard, AFAICT - for many reasons.

I am not very= sure how 1 TCP: 1 MPTCP translations is complicated yet.=C2=A0
S= o, I don't have a reason to stop people exploring.
=C2=A0=C2= =A0
&g= t; MPTCP will convey control data for application (proxy) in payload.
> But, MPTCP of course doesn't care the contents of payload.
> It just carries data and app will parse the data. Putting data in SYN
> is trying to reduce the latency and no other meaning as far as I
> understand.

MPTCP is TCP. Putting the data in the SYN of a TCP connection is
hazardous. The goal is irrelevant.
=C2=A0
In TCP, we already have a precedence such as TFO.

Sorry, to be more clear:
=C2=A0=C2=A0=C2=A0 Data in the SYN has been part of TCP since it was st= andardized.

Using the SYN data as control information is the hazardous part.<= br>
I think what the solution does won't exceed what TFO does.
 TFO changes when the SYN data is delivered, based on the fact that past cookie information "accelerates" the 3WHS.

It does not put control plane information in the data area of the SYN.

In my view, TFO relies on th= e info from past connections and we somehow believe it's valid and not = staled. But, it's still external info because it is from the outside of= the current connection.
This case relies on other type of extern= al info and when we believe the info, we will send data in SYN. I personall= y don't see big differences.
=C2=A0
--
Yo= shi
--001a1140f77ef0ceea054da97e5b-- From nobody Fri Apr 21 05:27:57 2017 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 0C8341294A3 for ; Fri, 21 Apr 2017 05:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_kpl6NWDpUi for ; Fri, 21 Apr 2017 05:27:54 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 E044112949D for ; Fri, 21 Apr 2017 05:27:53 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 589DA2043D; Fri, 21 Apr 2017 14:27:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 2277C1A0064; Fri, 21 Apr 2017 14:27:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 14:27:51 +0200 From: To: Joe Touch , Yoshifumi Nishida CC: multipathtcp Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSufr4FYN3Pf6Ey0Kw29UUSw2QvaHPsxBg Date: Fri, 21 Apr 2017 12:27:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5204E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F66@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5204EOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:27:56 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E5204EOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9lIFRv dWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCkVudm95w6kgOiBqZXVkaSAyMCBhdnJpbCAyMDE3 IDE5OjI1DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFlvc2hpZnVtaSBOaXNoaWRh DQpDYyA6IG11bHRpcGF0aHRjcA0KT2JqZXQgOiBSZTogW211bHRpcGF0aHRjcF0gQ29uc2Vuc3Vz IGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsNCg0KDQpNZWQsDQoNCk9uIDQvMTkv MjAxNyAxMDo1MCBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpIaSBKb2UsDQoNCkkgZG9u4oCZdCB1bmRl cnN0YW5kIHlvdXIgY29tbWVudHMgaGVyZToNCg0KwrcgICAgICAgICBUaGUgdXNlIG9mIGEgMzIt Yml0IG1hZ2ljIG51bWJlciBpcyBtZWFudCB0byBkaXN0aW5ndWlzaCBhcHBsaWNhdGlvbi1zdXBw bGllZCBkYXRhIGZyb20gdGhlIG9uZSBpbnNlcnRlZCBieSB0aGUgcHJveHkuIFRoZXJlIGFyZSBv dGhlciBmaWVsZHMgaW4gdGhlIE1QX0NPTlZFUlQgaW5mb3JtYXRpb24gZWxlbWVudCB0aGF0IGhl bHAgaW4gdGhhdCBhaW0gdG9vICh2YWxpZGF0aW9uIG9mIHRoZSBUTFYsIE0tYml0LCBmb3IgZXhh bXBsZSkuDQoNCsK3ICAgICAgICAgQm90aCBlbnRpdGllcyB0aGF0IHN1cHBseSBhbmQgcHJvY2Vz cyB0aGUgZGF0YSBhcmUgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIHNhbWUgb3BlcmF0b3IuDQoN CsK3ICAgICAgICAgVGhlIG5ldHdvcmstbG9jYXRlZCBwcm94eSBpcyBleHBsaWNpdGx5IGNvbmZp Z3VyZWQgb24gdGhlIENQRS4gVGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhlIHBhY2tl dCBpcyBhbiBhZGRyZXNzIG9mIHRoYXQgcHJveHksIG5vdCB0aGUgYWRkcmVzcyBvZiBhIGxlZ2Fj eSBub2RlLg0KDQrCtyAgICAgICAgIFRoZSBwcm94eSBtdXN0IGVjaG8gc3VwcGxpZWQgZGF0YSBp biBhIFNZTi9BQ0suIElmIGEgbWlzbWF0Y2ggaXMgZGV0ZWN0ZWQgYnkgdGhlIENQRSwgdGhhdCBw cm94eSBXT07igJl0IGJlIHVzZWQgZm9yIHN1YnNlcXVlbnQgY29ubmVjdGlvbnMgdGlsbCBhIG5l dyBwcm94eSBpcyBjb25maWd1cmVkLCBUVEwgZXhwaXJlcywgZXRjLg0KDQpUbyBzdW06DQoNCsK3 ICAgICAgICAgV2UgYXJlIGFjdGluZyBvbiBvbmUgc2luZ2xlIFNZTiBvZiBhbiBNUFRDUCBjb25u ZWN0aW9uLg0KDQrCtyAgICAgICAgIElmIGEgbWlzbWF0Y2ggaXMgZGV0ZWN0ZWQgZm9yIG9uZSBz aW5nbGUgU1lOIG9mIGEgZ2l2ZW4gY29ubmVjdGlvbiwgYWxsIHN1YnNlcXVlbnQgY29ubmVjdGlv bnMgKHdpdGggYW55IHJlbW90ZSBzZXJ2ZXIpIHdvbuKAmXQgYmUgcmVsYXllZCB0byB0aGF0IHBy b3h5Lg0KDQpIb3cgaXMgdGhpcyDigJxoYXphcmRvdXPigJ0/DQoNClRDUE0gYXJjaGl2ZXMgYXJl IGZ1bGwgb2YgZGlzY3Vzc2lvbnMgb24gd2h5IFRGTyBvbmx5IHdvcmtzIGZvciBzdWJzZXF1ZW50 IGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1lIGVuZHBvaW50LCBkdWUgdG8gY2FjaGVkIGNvb2tpZXMg dGhhdCBhbGxvdyB0aGUgU1lOIGRhdGEgdG8gYmUgc2FmZWx5IGludGVycHJldGVkICpiZWZvcmUq IHRoZSBlbmQgb2YgdGhlIDNXSFMuDQpbTWVkXSBpZiBoYXZpbmcgYSDigJxjb29raWXigJ0gaXMg dGhlIGd1YXJhbnRlZSB0byDigJxhbGxvdyB0aGUgU1lOIGRhdGEgdG8gYmUgc2FmZWx5IGludGVy cHJldGVkICpiZWZvcmUqIHRoZSBlbmQgb2YgdGhlIDNXSFPigJ0sIEnigJlkIGxpa2UgdG8gY29u ZmlybSB0aGF0IGFyZSBjb25mb3JtaW5nIHRvIHRoYXQgcmF0aW9uYWxlOg0KDQrCtyAgICAgICAg IFRGTyBjb29raWUgaXMg4oCcdXNlZCBieSB0aGUgc2VydmVyIHNpZGUgdG8gYXV0aGVudGljYXRl IGEgY2xpZW50IGluaXRpYXRpbmcgYSBURk8gY29ubmVjdGlvbuKAnS4gSW4gb3VyIGNhc2UsIGFs bCBNUFRDUCBjb25uZWN0aW9ucyB0aGF0IGluY2x1ZGUgTVBfQ09OVkVSVCBhcmUgYWx3YXlzIGJl dHdlZW4gdGhlIHNhbWUgbm9kZXMuIFRoZSBwcm94eSByZWxpZXMgdXBvbiBvdGhlciBtZWFucyB0 byBhdXRoZW50aWNhdGUvYXV0aG9yaXplIGEgQ1BFLiBQbGVhc2UgcmVmZXIgdG8gc2xpZGUgMjkg b2YgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC1t cHRjcC1zZXNzYS1uZXR3b3JrLWFzc2lzdGVkLW1wdGNwLTAzLnBkZi4NCg0KwrcgICAgICAgICBU Rk8gc2VydmVyLXN1cHBsaWVkIGNvb2tpZXMgYXJlIHVzZWQgdG8gcHJldmVudCBTWU5zIHdpdGgg c3Bvb2ZlZCBJUCBhZGRyZXNzZXMgYXR0YWNrczogU3Bvb2ZlZCBJUCBhZGRyZXNzZXMgaXMgbm90 IGEgcHJvYmxlbSBpbiBhIHByb3ZpZGVyIG5ldHdvcmsgYmVjYXVzZSBhbnRpLXNwb29maW5nIGZp bHRlcnMgYXJlIGluIHBsYWNlIChhdCBhY2Nlc3Mgbm9kZXMsIHR5cGljYWxseSkuDQoNCsK3ICAg ICAgICAgVEZPIHNwZWNpZmljYXRpb24gYWNrbm93bGVkZ2VzIHRoZSBmb2xsb3dpbmc6IOKAnGNv b2tpZXMgYXJlIG5vdCBuZWNlc3NhcnkgaWYgdGhlIHNlcnZlciBoYXMgYXBwbGljYXRpb24tbGV2 ZWwgcHJvdGVjdGlvbiBvciBpcyBpbW11bmUgdG8gdGhlc2UgYXR0YWNrc+KAnSAoY29va2llLWxl c3MgRmFzdCBPcGVuKSBhbmQg4oCcdGhlIHNlcnZlciBtYXkgY2hvb3NlIHRvIGdlbmVyYXRlIGEg dHJpdmlhbCBvciAgICBldmVuIGEgemVyby1sZW5ndGggY29va2llIHRvIGltcHJvdmUgcGVyZm9y bWFuY2UgYnkgYXZvaWRpbmcgdGhlIGNvb2tpZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb27i gJ0uIENhY2hlZCBjb29raWVzIGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcGx5IGRhdGEgaW4gM1dI UyBpZiB0aGUgc2VydmVyIGlmIHByb3RlY3Rpb24gaXMgaW4gcGxhY2UuIFRoaXMgaXMgdGhlIGNh c2UgZm9yIHRoZSBNUFRDUCBwcm94eSB0YXJnZXQgY2FzZS4NCg0KwrcgICAgICAgICBMYXN0LCB0 aGUgdXNlIG9mIFRGTyBjb29raWVzIGlzIG5vdCAxMDAlIHNhZmUuIFNZTiBmbG9vZGluZyB3aXRo IHZhbGlkIGNvb2tpZXMgaXMgc3RpbGwgYSB2YWxpZCB0aHJlYXQuDQoNCk1QVENQIGFyY2hpdmVz IGFyZSBmdWxsIG9mIGRpc2N1c3Npb25zIG9uIHdoeSB0aGUgZGF0YSBwbGFuZSBpcyBub3QgYSBn b29kIHBsYWNlIHRvIHB1dCBvcHRpb24gaW5mb3JtYXRpb24uDQpbTWVkXSBIbW0sIEVETyBkb2Vz IGFscmVhZHkgdGhhdC4gQnV04oCmbW9yZSBpbXBvcnRhbnQ6DQoNCsK3ICAgICAgICAgd2UgYXJl IG5vdCBwdXR0aW5nIG9wdGlvbiBpbmZvcm1hdGlvbiBpbiB0aGUgcGF5bG9hZC4NCg0KwrcgICAg ICAgICBJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBv ZiB0aGUgZXh0ZW5kZWQgb3B0aW9uIHNwYWNlIGluIGEgU1lOLiBUaGlzIHdvdWxkIGJlIGEgdmFs aWQgcG9pbnQgaWYgd2UgYXJlIHNlbmRpbmcgZGF0YSB0byBBTlkgaG9zdCBvbiB0aGUgSW50ZXJu ZXQgYnV0IHdlIGFyZSBub3QgZG9pbmcgdGhhdC4gV2UgYXJlIHN1cHBseWluZyBkYXRhIHRvIE9O RSBzaW5nbGUgbm9kZSB0aGF0IGlzIGNvbmZpZ3VyZWQgZXhwbGljaXRseSB0byBhIGhvc3QvQ1BF LiBUaGUgcHJvdmlkZXIsIHdobyBjb25maWd1cmVzIHRoYXQgcHJveHkgdG8gYSBob3N0L0NQRSBi eSBtZWFucyBvZiBESENQLCBlbnN1cmVzIHRoYXQgcHJveHkgY29tcGxpZXMgd2l0aCB0aGUgc3Bl Y2lmaWNhdGlvbi4gQXMgYSBndWFyZCwgdGhlIHNvbHV0aW9uIHN1cHBvcnRzIGEgbWVjaGFuaXNt IHRvIGRldGVjdCBtaXNiZWhhdmluZyBwcm94aWVzLg0KDQpJdCdzIG5vdCBwcmFjdGljYWwgdG8g cmVwZWF0IHRob3NlIGFyZ3VtZW50cyBpbiBvbmUgZW1haWwuIFRoZSBwb2ludCBpcyB0aGF0IHlv dSdyZSByZWludmVudGluZyB0aGUgd2hlZWwgaW4gd2F5cyB0aGF0IHRoaXMgZ3JvdXAgYW5kIG90 aGVyIGdyb3VwcyBhbHJlYWR5IGtub3cgYXJlIGhhemFyZG91cy4NCltNZWRdIEkgZG9u4oCZdCB0 aGluayB0aGVyZSBpcyBhIHByZWNlZGVudCBvZiB0aGUgMC1SVFQgcHJveHlpbmcgd29yay4gSSBk b27igJl0IHNlZSB3aGF0IHdlIGFyZSByZWludmVudGluZyBoZXJlLiAgSSBzdGlsbCBkb27igJl0 IHNlZSB3aGF0IGlzIOKAnGhhemFyZG91c+KAnSBoZXJlLg0KDQoNCkpvZQ0KDQoNCg0KVGhhbmsg eW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2ku ZWR1XQ0KRW52b3nDqSA6IG1lcmNyZWRpIDE5IGF2cmlsIDIwMTcgMjA6MTINCsOAIDogQk9VQ0FE QUlSIE1vaGFtZWQgSU1UL09MTjsgWW9zaGlmdW1pIE5pc2hpZGENCkNjIDogbXVsdGlwYXRodGNw DQpPYmpldCA6IFJlOiBbbXVsdGlwYXRodGNwXSBDb25zZW5zdXMgY2FsbCBvbiBwb3RlbnRpYWwg TVBUQ1AgcHJveHkgd29yaw0KDQoNCg0KDQpPbiA0LzE4LzIwMTcgMTA6NDYgUE0sIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ IHdyb3RlOg0KLi4uDQpVc2luZyB0aGUgU1lOIGRhdGEgYXMgY29udHJvbCBpbmZvcm1hdGlvbiBp cyB0aGUgaGF6YXJkb3VzIHBhcnQuDQpbTWVkXSBJdCBpc27igJl0IGZvciB0aGUgZm9yIHRoZSBz aW1wbGUgcmVhc29uIHRoYXQgbGVnYWN5IEludGVybmV0IG5vZGVzIHdpbGwgbmV2ZXIgcmVjZWl2 ZSBhIFNZTiB3aXRoIENQRS1zdXBwbGllZCBkYXRhIGFuZCB0aGF0IHRoZSBUQ1AgcGVlciBpcyBr bm93biB0byBwcm9jZXNzIHRoZSBzdXBwbGllZCBkYXRhLiBBIEd1YXJkIGFnYWluc3QgbWlzY29u ZmlndXJhdGlvbnMgaXMgc3VwcG9ydGVkOiBlY2hvIGluIGEgU1lOL0FDSy4NCg0KVGhlIGlkZWEg b2YgdXNpbmcgYSBtYWdpYyBudW1iZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IG1pc2NvbW11bmljYXRp b24gdmlydHVhbGx5IGVuc3VyZXMgdGhhdCB0aGVyZSB3aWxsIGJlIHJlbGlhYmxlIGNvbm5lY3Rp b25zIHdpdGggZXJyb3JzLiBUaGF0IGNoYW5nZXMgVENQcyBzZW1hbnRpY3MuDQoNClB1dHRpbmcg ZGF0YSBpbiB0aGUgU1lOIG9mIFRGTyBpcyBwZXJtaXR0ZWQgb25seSBiZWNhdXNlIG9mIHByZXZp b3VzIHN0YXRlLg0KDQpNUFRDUCBkb2Vzbid0IGhhdmUgdGhhdCBzdGF0ZSBhbmQgc28gaXQgaXMg aGF6YXJkb3VzIHRvIHB1dCBkYXRhIGluIHRoZSBTWU4uDQoNCkkuZS4sIGlmIHlvdSB3YW50IFRG Ty1saWtlIHBlcmZvcm1hbmNlLCBmaWd1cmUgb3V0IGhvdyB0byB1c2UgVEZPLiBQZXJpb2QuDQoN CkpvZQ0KDQo= --_000_787AE7BB302AE849A7480A190F8B933009E5204EOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291 cmllciBOZXcgXDtjb2xvclw6YmxhY2siO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsN CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJ e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjMyNzYwNzQ7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjYwOTc4ODIxMiA2ODA3OTE2NDQg Njc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4 OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iiwic2VyaWYiO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzEz Njc3NDY3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoz NzI4MjcyIDY4MDc5MTY0NCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5 NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5s aW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo8YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMjAgYXZyaWwgMjAxNyAxOToyNTxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgWW9zaGlmdW1pIE5pc2hpZGE8 YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IG11bHRpcGF0aHRjcDxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBw cm94eSB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+TWVkLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gNC8xOS8yMDE3IDEwOjUwIFBNLCA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEpvZSwNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFj ayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+SSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBjb21tZW50cyBoZXJl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7 Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSB1c2Ugb2YgYSAzMi1iaXQg bWFnaWMgbnVtYmVyIGlzIG1lYW50IHRvIGRpc3Rpbmd1aXNoIGFwcGxpY2F0aW9uLXN1cHBsaWVk IGRhdGEgZnJvbSB0aGUgb25lIGluc2VydGVkIGJ5IHRoZSBwcm94eS4gVGhlcmUgYXJlIG90aGVy DQogZmllbGRzIGluIHRoZSBNUF9DT05WRVJUIGluZm9ybWF0aW9uIGVsZW1lbnQgdGhhdCBoZWxw IGluIHRoYXQgYWltIHRvbyAodmFsaWRhdGlvbiBvZiB0aGUgVExWLCBNLWJpdCwgZm9yIGV4YW1w bGUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJvdGggZW50aXRpZXMgdGhh dCBzdXBwbHkgYW5kIHByb2Nlc3MgdGhlIGRhdGEgYXJlIHVuZGVyIHRoZSBjb250cm9sIG9mIHRo ZSBzYW1lIG9wZXJhdG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBu ZXR3b3JrLWxvY2F0ZWQgcHJveHkgaXMgZXhwbGljaXRseSBjb25maWd1cmVkIG9uIHRoZSBDUEUu IFRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMgYW4gYWRkcmVzcyBv ZiB0aGF0IHByb3h5LCBub3QNCiB0aGUgYWRkcmVzcyBvZiBhIGxlZ2FjeSBub2RlLiA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJs YWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUgcHJveHkgbXVzdCBlY2hvIHN1cHBsaWVk IGRhdGEgaW4gYSBTWU4vQUNLLiBJZiBhIG1pc21hdGNoIGlzIGRldGVjdGVkIGJ5IHRoZSBDUEUs IHRoYXQgcHJveHkgV09O4oCZdCBiZSB1c2VkIGZvciBzdWJzZXF1ZW50IGNvbm5lY3Rpb25zDQog dGlsbCBhIG5ldyBwcm94eSBpcyBjb25maWd1cmVkLCBUVEwgZXhwaXJlcywgZXRjLiA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2Nv bG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNr JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UbyBzdW06PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+V2UgYXJlIGFjdGluZyBvbiBvbmUgc2luZ2xlIFNZTiBvZiBhbiBNUFRDUCBj b25uZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPklmIGEgbWlzbWF0 Y2ggaXMgZGV0ZWN0ZWQgZm9yIG9uZSBzaW5nbGUgU1lOIG9mIGEgZ2l2ZW4gY29ubmVjdGlvbiwg YWxsIHN1YnNlcXVlbnQgY29ubmVjdGlvbnMgKHdpdGggYW55IHJlbW90ZSBzZXJ2ZXIpIHdvbuKA mXQgYmUgcmVsYXllZA0KIHRvIHRoYXQgcHJveHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+SG93IGlzIHRoaXMg4oCcaGF6YXJkb3Vz4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRDUE0gYXJjaGl2ZXMg YXJlIGZ1bGwgb2YgZGlzY3Vzc2lvbnMgb24gd2h5IFRGTyBvbmx5IHdvcmtzIGZvciBzdWJzZXF1 ZW50IGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1lIGVuZHBvaW50LCBkdWUgdG8gY2FjaGVkIGNvb2tp ZXMgdGhhdCBhbGxvdyB0aGUgU1lOIGRhdGEgdG8gYmUgc2FmZWx5IGludGVycHJldGVkICpiZWZv cmUqIHRoZSBlbmQgb2YgdGhlIDNXSFMuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIGlmIGhhdmluZyBhIOKAnGNv b2tpZeKAnSBpcyB0aGUgZ3VhcmFudGVlIHRvIOKAnGFsbG93IHRoZSBTWU4gZGF0YSB0byBiZSBz YWZlbHkgaW50ZXJwcmV0ZWQgKmJlZm9yZSogdGhlIGVuZCBvZiB0aGUgM1dIU+KAnSwgSeKAmWQg bGlrZSB0byBjb25maXJtIHRoYXQNCiBhcmUgY29uZm9ybWluZyB0byB0aGF0IHJhdGlvbmFsZTog PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5URk8gY29va2llIGlzIOKAnHVzZWQgYnkgdGhlIHNlcnZlciBz aWRlIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVudCBpbml0aWF0aW5nIGEgVEZPIGNvbm5lY3Rpb27i gJ0uIEluIG91ciBjYXNlLCBhbGwgTVBUQ1AgY29ubmVjdGlvbnMgdGhhdCBpbmNsdWRlDQogTVBf Q09OVkVSVCBhcmUgYWx3YXlzIGJldHdlZW4gdGhlIHNhbWUgbm9kZXMuIFRoZSBwcm94eSByZWxp ZXMgdXBvbiBvdGhlciBtZWFucyB0byBhdXRoZW50aWNhdGUvYXV0aG9yaXplIGEgQ1BFLiBQbGVh c2UgcmVmZXIgdG8gc2xpZGUgMjkgb2YNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtbXB0Y3Atc2Vzc2EtbmV0d29yay1hc3Npc3Rl ZC1tcHRjcC0wMy5wZGYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xp ZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1uZXR3b3JrLWFzc2lzdGVkLW1wdGNwLTAzLnBkZjwv YT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5URk8gc2VydmVyLXN1cHBsaWVkIGNvb2tpZXMgYXJlIHVz ZWQgdG8gcHJldmVudCBTWU5zIHdpdGggc3Bvb2ZlZCBJUCBhZGRyZXNzZXMgYXR0YWNrczogU3Bv b2ZlZCBJUCBhZGRyZXNzZXMgaXMgbm90IGEgcHJvYmxlbSBpbiBhIHByb3ZpZGVyDQogbmV0d29y ayBiZWNhdXNlIGFudGktc3Bvb2ZpbmcgZmlsdGVycyBhcmUgaW4gcGxhY2UgKGF0IGFjY2VzcyBu b2RlcywgdHlwaWNhbGx5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRGTyBzcGVjaWZpY2F0aW9uIGFj a25vd2xlZGdlcyB0aGUgZm9sbG93aW5nOiDigJxjb29raWVzIGFyZSBub3QgbmVjZXNzYXJ5IGlm IHRoZSBzZXJ2ZXIgaGFzIGFwcGxpY2F0aW9uLWxldmVsIHByb3RlY3Rpb24gb3IgaXMgaW1tdW5l IHRvDQogdGhlc2UgYXR0YWNrc+KAnSAoY29va2llLWxlc3MgRmFzdCBPcGVuKSBhbmQg4oCcdGhl IHNlcnZlciBtYXkgY2hvb3NlIHRvIGdlbmVyYXRlIGEgdHJpdmlhbCBvciAmbmJzcDsmbmJzcDsm bmJzcDtldmVuIGEgemVyby1sZW5ndGggY29va2llIHRvIGltcHJvdmUgcGVyZm9ybWFuY2UgYnkg YXZvaWRpbmcgdGhlIGNvb2tpZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb27igJ0uIENhY2hl ZCBjb29raWVzIGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcGx5IGRhdGEgaW4gM1dIUyBpZiB0aGUN CiBzZXJ2ZXIgaWYgcHJvdGVjdGlvbiBpcyBpbiBwbGFjZS4gVGhpcyBpcyB0aGUgY2FzZSBmb3Ig dGhlIE1QVENQIHByb3h5IHRhcmdldCBjYXNlLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6 YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkxh c3QsIHRoZSB1c2Ugb2YgVEZPIGNvb2tpZXMgaXMgbm90IDEwMCUgc2FmZS4gU1lOIGZsb29kaW5n IHdpdGggdmFsaWQgY29va2llcyBpcyBzdGlsbCBhIHZhbGlkIHRocmVhdC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpNUFRDUCBhcmNoaXZlcyBhcmUgZnVsbCBvZiBkaXNjdXNzaW9ucyBvbiB3aHkgdGhlIGRhdGEg cGxhbmUgaXMgbm90IGEgZ29vZCBwbGFjZSB0byBwdXQgb3B0aW9uIGluZm9ybWF0aW9uLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEhtbSwgRURPIGRvZXMgYWxyZWFkeSB0aGF0 LiBCdXTigKZtb3JlIGltcG9ydGFudDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPndlIGFyZSBub3QgcHV0dGluZyBvcHRpb24gaW5m b3JtYXRpb24gaW4gdGhlIHBheWxvYWQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBs Zm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBv ZiB0aGUgZXh0ZW5kZWQgb3B0aW9uIHNwYWNlIGluIGEgU1lOLiBUaGlzIHdvdWxkIGJlIGEgdmFs aWQgcG9pbnQgaWYgd2UgYXJlIHNlbmRpbmcNCiBkYXRhIHRvIEFOWSBob3N0IG9uIHRoZSBJbnRl cm5ldCBidXQgd2UgYXJlIG5vdCBkb2luZyB0aGF0LiBXZSBhcmUgc3VwcGx5aW5nIGRhdGEgdG8g T05FIHNpbmdsZSBub2RlIHRoYXQgaXMgY29uZmlndXJlZCBleHBsaWNpdGx5IHRvIGEgaG9zdC9D UEUuIFRoZSBwcm92aWRlciwgd2hvIGNvbmZpZ3VyZXMgdGhhdCBwcm94eSB0byBhIGhvc3QvQ1BF IGJ5IG1lYW5zIG9mIERIQ1AsIGVuc3VyZXMgdGhhdCBwcm94eSBjb21wbGllcyB3aXRoIHRoZSBz cGVjaWZpY2F0aW9uLg0KIEFzIGEgZ3VhcmQsIHRoZSBzb2x1dGlvbiBzdXBwb3J0cyBhIG1lY2hh bmlzbSB0byBkZXRlY3QgbWlzYmVoYXZpbmcgcHJveGllcy4gJm5ic3A7Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpJdCdzIG5vdCBwcmFjdGljYWwgdG8gcmVwZWF0 IHRob3NlIGFyZ3VtZW50cyBpbiBvbmUgZW1haWwuIDwvc3Bhbj5UaGUgcG9pbnQgaXMgdGhhdCB5 b3UncmUgcmVpbnZlbnRpbmcgdGhlIHdoZWVsIGluIHdheXMgdGhhdCB0aGlzIGdyb3VwIGFuZCBv dGhlciBncm91cHMgYWxyZWFkeSBrbm93IGFyZSBoYXphcmRvdXMuPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkg ZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIHByZWNlZGVudCBvZiB0aGUgMC1SVFQgcHJveHlpbmcg d29yay4gSSBkb27igJl0IHNlZSB3aGF0IHdlIGFyZSByZWludmVudGluZyBoZXJlLiAmbmJzcDtJ IHN0aWxsIGRvbuKAmXQgc2VlIHdoYXQgaXMg4oCcaGF6YXJkb3Vz4oCdDQogaGVyZS4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxicj4NCkpvZTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtj b2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmsgeW91Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2Nv bG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5NZWQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEpvZSBUb3VjaCBbPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPjxhIGhyZWY9Im1h aWx0bzp0b3VjaEBpc2kuZWR1Ij48c3BhbiBsYW5nPSJFTi1VUyI+bWFpbHRvOnRvdWNoQGlzaS5l ZHU8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNy ZWRpIDE5IGF2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPnJpbCAyMDE3IDIwOjEyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1l ZCBJTVQvT0xOOyBZb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gbXVsdGlw YXRodGNwPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW211bHRpcGF0aHRjcF0gQ29uc2Vu c3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcms8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvMTgv MjAxNyAxMDo0NiBQTSwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li4uPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VXNpbmcgdGhlIFNZTiBkYXRhIGFzIGNvbnRyb2wgaW5m b3JtYXRpb24gaXMgdGhlIGhhemFyZG91cyBwYXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPltNZWRdIEl0IGlzbuKAmXQgZm9yIHRoZSBmb3IgdGhlIHNpbXBsZSBy ZWFzb24gdGhhdCBsZWdhY3kgSW50ZXJuZXQgbm9kZXMgd2lsbCBuZXZlciByZWNlaXZlIGEgU1lO IHdpdGggQ1BFLXN1cHBsaWVkIGRhdGEgYW5kIHRoYXQgdGhlIFRDUCBwZWVyIGlzDQoga25vd24g dG8gcHJvY2VzcyB0aGUgc3VwcGxpZWQgZGF0YS4gQSBHdWFyZCBhZ2FpbnN0IG1pc2NvbmZpZ3Vy YXRpb25zIGlzIHN1cHBvcnRlZDogZWNobyBpbiBhIFNZTi9BQ0suPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpU aGUgaWRlYSBvZiB1c2luZyBhIG1hZ2ljIG51bWJlciB0byBwcm90ZWN0IGFnYWluc3QgbWlzY29t bXVuaWNhdGlvbiB2aXJ0dWFsbHkgZW5zdXJlcyB0aGF0IHRoZXJlIHdpbGwgYmUgcmVsaWFibGUg Y29ubmVjdGlvbnMgd2l0aCBlcnJvcnMuIFRoYXQgY2hhbmdlcyBUQ1BzIHNlbWFudGljcy48YnI+ DQo8YnI+DQpQdXR0aW5nIGRhdGEgaW4gdGhlIFNZTiBvZiBURk8gaXMgcGVybWl0dGVkIG9ubHkg YmVjYXVzZSBvZiBwcmV2aW91cyBzdGF0ZS48YnI+DQo8YnI+DQpNUFRDUCBkb2Vzbid0IGhhdmUg dGhhdCBzdGF0ZSBhbmQgc28gaXQgaXMgaGF6YXJkb3VzIHRvIHB1dCBkYXRhIGluIHRoZSBTWU4u IDxicj4NCjxicj4NCkkuZS4sIGlmIHlvdSB3YW50IFRGTy1saWtlIHBlcmZvcm1hbmNlLCBmaWd1 cmUgb3V0IGhvdyB0byB1c2UgVEZPLiBQZXJpb2QuPGJyPg0KPGJyPg0KSm9lPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009E5204EOPEXCLILMA3corp_-- From nobody Fri Apr 21 09:05:00 2017 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 023E2129646 for ; Fri, 21 Apr 2017 09:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W03-zjAO0j5 for ; Fri, 21 Apr 2017 09:04:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223AC129A99 for ; Fri, 21 Apr 2017 09:04:57 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3LG4BXZ015604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 09:04:12 -0700 (PDT) To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> Date: Fri, 21 Apr 2017 09:04:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:04:58 -0000 Med, I've made my position clear too. I do not support this doc as MPTCP work. I also call into question whether this is in-scope for MPTCP. MPTCP is chartered to work within MPTCP - but this solution requires access to raw incoming SYNs inside a different TCP connection, which is no longer in-scope IMO. Joe From nobody Fri Apr 21 09:06:13 2017 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 3A03E128B8F for ; Fri, 21 Apr 2017 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2opnzn7aByN for ; Fri, 21 Apr 2017 09:06:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413FD126E3A for ; Fri, 21 Apr 2017 09:06:11 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3LG60x2016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 09:06:01 -0700 (PDT) To: Yoshifumi Nishida Cc: multipathtcp References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> From: Joe Touch Message-ID: Date: Fri, 21 Apr 2017 09:05:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:06:12 -0000 On 4/21/2017 2:00 AM, Yoshifumi Nishida wrote: > In my view, TFO relies on the info from past connections and we > somehow believe it's valid and not staled. But, it's still external > info because it is from the outside of the current connection. > This case relies on other type of external info and when we believe > the info, we will send data in SYN. I personally don't see big > differences. Again, TFO semantics were vetted by TCPM over a fairly long set of discussions. If you want TFO behavior, use TFO. If you want to argue that this is a different way to achieve the same results, that's a very long road of discussions to begin. That discussion is IMO outside the scope of MPTCP (there's no zero-delay open in its charter). Joe From nobody Fri Apr 21 09:07:47 2017 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 117A0128B8F for ; Fri, 21 Apr 2017 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U28eQn7S2uZ5 for ; Fri, 21 Apr 2017 09:07:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3560112778D for ; Fri, 21 Apr 2017 09:07:44 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3LG7LBj016809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 09:07:22 -0700 (PDT) To: mohamed.boucadair@orange.com, Yoshifumi Nishida Cc: multipathtcp References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5204E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <35c6bd09-c29f-2eb3-6c70-cb02163090aa@isi.edu> Date: Fri, 21 Apr 2017 09:07:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5204E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------28C678AE7A6B007A3675E4E5" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:07:45 -0000 This is a multi-part message in MIME format. --------------28C678AE7A6B007A3675E4E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit One final point: On 4/21/2017 5:27 AM, mohamed.boucadair@orange.com wrote: > > MPTCP archives are full of discussions on why the data plane is not a > good place to put option information. > > [Med] Hmm, EDO does already that. But…more important: > It also explains at length why this is not possible inside the SYN. Again, MPTCP isn't the place to develop solutions that have been rejected within TCPM. Joe --------------28C678AE7A6B007A3675E4E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

One final point:


On 4/21/2017 5:27 AM, mohamed.boucadair@orange.com wrote:

MPTCP archives are full of discussions on why the data plane is not a good place to put option information.

[Med] Hmm, EDO does already that. But…more important:

It also explains at length why this is not possible inside the SYN.

Again, MPTCP isn't the place to develop solutions that have been rejected within TCPM.

Joe
--------------28C678AE7A6B007A3675E4E5-- From nobody Mon Apr 24 01:23:11 2017 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 0C4E2129AC7 for ; Mon, 24 Apr 2017 01:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 IV5_fsaCeuCe for ; Mon, 24 Apr 2017 01:23:07 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7989A129AB8 for ; Mon, 24 Apr 2017 01:23:06 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1D19D1C02EE; Mon, 24 Apr 2017 10:23:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id E9ADE4007E; Mon, 24 Apr 2017 10:23:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Mon, 24 Apr 2017 10:23:04 +0200 From: To: Joe Touch , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSurjoFYN3Pf6Ey0Kw29UUSw2QvaHUMW4g Date: Mon, 24 Apr 2017 08:23:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> In-Reply-To: <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> 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: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 08:23:09 -0000 Joe,=20 Transforming a TCP connection into MPTCP connection will obviously need to = access to SYNs to insert MPTCP options.=20 This is the basic behavior of ** any ** MPTCP proxy. =20 Cheers, Med > -----Message d'origine----- > De=A0: Joe Touch [mailto:touch@isi.edu] > Envoy=E9=A0: vendredi 21 avril 2017 18:04 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > Med, >=20 > I've made my position clear too. >=20 > I do not support this doc as MPTCP work. >=20 > I also call into question whether this is in-scope for MPTCP. MPTCP is > chartered to work within MPTCP - but this solution requires access to > raw incoming SYNs inside a different TCP connection, which is no longer > in-scope IMO. >=20 > Joe >=20 From nobody Mon Apr 24 07:50:33 2017 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 0C02A131644 for ; Mon, 24 Apr 2017 07:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-nXgHD2Doz7 for ; Mon, 24 Apr 2017 07:50:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11458131577 for ; Mon, 24 Apr 2017 07:49:21 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3OEmift002033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 07:48:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14E304) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 24 Apr 2017 07:48:44 -0700 Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 14:50:32 -0000 Med, A proxy can operate at the conventional socket layer and would not have or n= eed direct access to SYN segments. Any information needed to reconstitute th= e SYN at the upstream proxy could be retrieved in other ways. You're pushing a split-TCP solution, one that (again, I repeat) the IETF has= never sanctioned and I do not agree with. Joe > On Apr 24, 2017, at 1:23 AM, wrote: >=20 > Joe,=20 >=20 > Transforming a TCP connection into MPTCP connection will obviously need to= access to SYNs to insert MPTCP options.=20 >=20 > This is the basic behavior of ** any ** MPTCP proxy. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Joe Touch [mailto:touch@isi.edu] >> Envoy=C3=A9 : vendredi 21 avril 2017 18:04 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; >> multipathtcp@ietf.org >> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work >>=20 >> Med, >>=20 >> I've made my position clear too. >>=20 >> I do not support this doc as MPTCP work. >>=20 >> I also call into question whether this is in-scope for MPTCP. MPTCP is >> chartered to work within MPTCP - but this solution requires access to >> raw incoming SYNs inside a different TCP connection, which is no longer >> in-scope IMO. >>=20 >> Joe >>=20 >=20 From nobody Mon Apr 24 08:04:58 2017 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 0157E131586 for ; Mon, 24 Apr 2017 08:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 l7JcnzO8GiEl for ; Mon, 24 Apr 2017 08:04:54 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD272131626 for ; Mon, 24 Apr 2017 08:03:25 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 577D540369; Mon, 24 Apr 2017 17:03:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 238E74006B; Mon, 24 Apr 2017 17:03:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Mon, 24 Apr 2017 17:03:23 +0200 From: To: Joe Touch CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSvQneFYN3Pf6Ey0Kw29UUSw2QvaHUm0kQ Date: Mon, 24 Apr 2017 15:03:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> In-Reply-To: <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:04:57 -0000 UmUtLA0KDQpEbyB5b3UgY29uc2lkZXIgYSBOQVQgaW1wbGVtZW50YXRpb24gYXMgcGFydCBvZiB5 b3VyIGZpcnN0IGNhdGVnb3J5IG9yIHRoZSBzZWNvbmQgb25lPw0KDQpCVFcsIHRoZSBtcHRjcCBw cm94eSBkb2N1bWVudHMgZG8gb25seSBkZXNjcmliZSB0aGUgZXh0ZXJuYWwgYmVoYXZpb3IuIE5v IGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGFzc3VtcHRpb25zL2RldGFpbHMgYXJlIGluY2x1ZGVk LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERl wqA6IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IEVudm95w6nCoDogbHVuZGkg MjQgYXZyaWwgMjAxNyAxNjo0OQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+ IENjwqA6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTsgbXVsdGlwYXRodGNwQGlldGYub3JnDQo+IE9i amV0wqA6IFJlOiBbbXVsdGlwYXRodGNwXSBDb25zZW5zdXMgY2FsbCBvbiBwb3RlbnRpYWwgTVBU Q1AgcHJveHkgd29yaw0KPiANCj4gTWVkLA0KPiANCj4gQSBwcm94eSBjYW4gb3BlcmF0ZSBhdCB0 aGUgY29udmVudGlvbmFsIHNvY2tldCBsYXllciBhbmQgd291bGQgbm90IGhhdmUgb3INCj4gbmVl ZCBkaXJlY3QgYWNjZXNzIHRvIFNZTiBzZWdtZW50cy4gQW55IGluZm9ybWF0aW9uIG5lZWRlZCB0 byByZWNvbnN0aXR1dGUNCj4gdGhlIFNZTiBhdCB0aGUgdXBzdHJlYW0gcHJveHkgY291bGQgYmUg cmV0cmlldmVkIGluIG90aGVyIHdheXMuDQo+IA0KPiBZb3UncmUgcHVzaGluZyBhIHNwbGl0LVRD UCBzb2x1dGlvbiwgb25lIHRoYXQgKGFnYWluLCBJIHJlcGVhdCkgdGhlIElFVEYNCj4gaGFzIG5l dmVyIHNhbmN0aW9uZWQgYW5kIEkgZG8gbm90IGFncmVlIHdpdGguDQo+IA0KPiBKb2UNCj4gDQo+ ID4gT24gQXByIDI0LCAyMDE3LCBhdCAxOjIzIEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4g Sm9lLA0KPiA+DQo+ID4gVHJhbnNmb3JtaW5nIGEgVENQIGNvbm5lY3Rpb24gaW50byBNUFRDUCBj b25uZWN0aW9uIHdpbGwgb2J2aW91c2x5IG5lZWQNCj4gdG8gYWNjZXNzIHRvIFNZTnMgdG8gaW5z ZXJ0IE1QVENQIG9wdGlvbnMuDQo+ID4NCj4gPiBUaGlzIGlzIHRoZSBiYXNpYyBiZWhhdmlvciBv ZiAqKiBhbnkgKiogTVBUQ1AgcHJveHkuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4N Cj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDogSm9lIFRvdWNoIFtt YWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPj4gRW52b3nDqSA6IHZlbmRyZWRpIDIxIGF2cmlsIDIw MTcgMTg6MDQNCj4gPj4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBwaGlsaXAuZWFy ZGxleUBidC5jb207DQo+ID4+IG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KPiA+PiBPYmpldCA6IFJl OiBbbXVsdGlwYXRodGNwXSBDb25zZW5zdXMgY2FsbCBvbiBwb3RlbnRpYWwgTVBUQ1AgcHJveHkg d29yaw0KPiA+Pg0KPiA+PiBNZWQsDQo+ID4+DQo+ID4+IEkndmUgbWFkZSBteSBwb3NpdGlvbiBj bGVhciB0b28uDQo+ID4+DQo+ID4+IEkgZG8gbm90IHN1cHBvcnQgdGhpcyBkb2MgYXMgTVBUQ1Ag d29yay4NCj4gPj4NCj4gPj4gSSBhbHNvIGNhbGwgaW50byBxdWVzdGlvbiB3aGV0aGVyIHRoaXMg aXMgaW4tc2NvcGUgZm9yIE1QVENQLiBNUFRDUCBpcw0KPiA+PiBjaGFydGVyZWQgdG8gd29yayB3 aXRoaW4gTVBUQ1AgLSBidXQgdGhpcyBzb2x1dGlvbiByZXF1aXJlcyBhY2Nlc3MgdG8NCj4gPj4g cmF3IGluY29taW5nIFNZTnMgaW5zaWRlIGEgZGlmZmVyZW50IFRDUCBjb25uZWN0aW9uLCB3aGlj aCBpcyBubyBsb25nZXINCj4gPj4gaW4tc2NvcGUgSU1PLg0KPiA+Pg0KPiA+PiBKb2UNCj4gPj4N Cj4gPg0KDQo= From nobody Mon Apr 24 08:24:27 2017 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 D0A62131692 for ; Mon, 24 Apr 2017 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI-wURWSZnvV for ; Mon, 24 Apr 2017 08:24:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F6A131674 for ; Mon, 24 Apr 2017 08:24:19 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3OFNVBD007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Apr 2017 08:23:41 -0700 (PDT) To: mohamed.boucadair@orange.com Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Mon, 24 Apr 2017 08:23:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:24:27 -0000 On 4/24/2017 8:03 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Do you consider a NAT implementation as part of your first category or the second one? A NAT is part of the second one. You'll notice that there are no IETF-endorsed NAT solutions - only protocols to talk directly to NATs or methods to overcome what NATs do. > BTW, the mptcp proxy documents do only describe the external behavior. No implementation-specific assumptions/details are included. When you require the MPTCP SYN to be issued before the SYN-ACK is sent to the originating client, that is specifying split-TCP behavior that the IETF has never endorsed. The same is true when you try to reinvent ways to interpret SYN data before the MPTCP 3WHS completes - reinventing TFO without TFO's protections. Joe > > Cheers, > Med > >> -----Message d'origine----- >> De : Joe Touch [mailto:touch@isi.edu] >> Envoyé : lundi 24 avril 2017 16:49 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : philip.eardley@bt.com; multipathtcp@ietf.org >> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work >> >> Med, >> >> A proxy can operate at the conventional socket layer and would not have or >> need direct access to SYN segments. Any information needed to reconstitute >> the SYN at the upstream proxy could be retrieved in other ways. >> >> You're pushing a split-TCP solution, one that (again, I repeat) the IETF >> has never sanctioned and I do not agree with. >> >> Joe >> >>> On Apr 24, 2017, at 1:23 AM, >> wrote: >>> Joe, >>> >>> Transforming a TCP connection into MPTCP connection will obviously need >> to access to SYNs to insert MPTCP options. >>> This is the basic behavior of ** any ** MPTCP proxy. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joe Touch [mailto:touch@isi.edu] >>>> Envoyé : vendredi 21 avril 2017 18:04 >>>> À : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; >>>> multipathtcp@ietf.org >>>> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work >>>> >>>> Med, >>>> >>>> I've made my position clear too. >>>> >>>> I do not support this doc as MPTCP work. >>>> >>>> I also call into question whether this is in-scope for MPTCP. MPTCP is >>>> chartered to work within MPTCP - but this solution requires access to >>>> raw incoming SYNs inside a different TCP connection, which is no longer >>>> in-scope IMO. >>>> >>>> Joe >>>> From nobody Mon Apr 24 08:26:19 2017 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 60395131647 for ; Mon, 24 Apr 2017 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIEkX88yohqT for ; Mon, 24 Apr 2017 08:26:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D58291316BE for ; Mon, 24 Apr 2017 08:26:05 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3OFQ3DL027141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Apr 2017 17:26:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3OFQ38x013780; Mon, 24 Apr 2017 17:26:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A2B27D7935; Mon, 24 Apr 2017 17:26:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OUYb0CEa9H_r; Mon, 24 Apr 2017 17:26:02 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AC5E2D7924; Mon, 24 Apr 2017 17:26:02 +0200 (CEST) Date: Mon, 24 Apr 2017 17:26:15 +0200 Message-ID: <87tw5dq12g.wl-jch@irif.fr> From: Juliusz Chroboczek To: mohamed.boucadair@orange.com Cc: "multipathtcp@ietf.org" In-Reply-To: <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 24 Apr 2017 17:26:03 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 24 Apr 2017 17:26:03 +0200 (CEST) X-Miltered: at korolev with ID 58FE190B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58FE190B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58FE190B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58FE190B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58FE190B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58FE190B.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:26:18 -0000 > I also call into question whether this is in-scope for MPTCP. MPTCP is > chartered to work within MPTCP - but this solution requires access to > raw incoming SYNs inside a different TCP connection, which is no longer > in-scope IMO. On a related note -- is there a publicly available implementation of the plain mode proxy, so we can see how deep it needs to delve into the network stack's internals? -- Juliusz From nobody Tue Apr 25 00:11:44 2017 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 2D84B128768 for ; Tue, 25 Apr 2017 00:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld-tgkoVsQGQ for ; Tue, 25 Apr 2017 00:11:39 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310D112025C for ; Tue, 25 Apr 2017 00:11:38 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 25 Apr 2017 08:11:36 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 25 Apr 2017 08:11:36 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 08:11:35 +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.1210.000; Tue, 25 Apr 2017 08:11:35 +0100 From: To: , CC: Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgCSLSEA///y9gCAAAMwgIAACAeA//mir4A= Date: Tue, 25 Apr 2017 07:11:34 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:11:42 -0000 Just to clarify our interpretation of the various hums during the meeting. We interpreted them as indicating there was one topic that it was worthwhil= e doing a consensus call on. We did not interpret the hums as indicating cl= ear consensus that we merely needed to confirm on the list.=20 So far we see: In favour:=20 christian.jacquenet@orange.com mohamed.boucadair@orange.com William Ivancic =20 Stefano Secci =20 Henderickx, Wim (Nokia - BE/Antwerp) =20 David Allan I =20 Markus.Brunner3@swisscom.com=20 Robert Skog =20 Olivier Bonaventure =20 Costin Raiciu =20 Against: =20 Joe Touch Juliusz Chroboczek =20 Eggert, Lars It is therefore important to hear views from other people. Of course it is = also welcome for the technical discussion to continue (indeed, some people = may want more of the technical discussion before giving their view on the c= onsensus call). Thanks Phil & Yoshi -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 21 April 2017 07:55 [cut] Lacking that information, I don't see a new element here that could lead to= change the consensus reached at the Chicago meeting (of course I'm not ent= itled to do that call anyway).=20 From nobody Tue Apr 25 04:31:12 2017 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 E253612EC01 for ; Tue, 25 Apr 2017 04:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxMOBvGFeyLI for ; Tue, 25 Apr 2017 04:31:07 -0700 (PDT) Received: from smfilter2.kt.com (smfilter2.kt.com [14.63.245.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7A24612EC13 for ; Tue, 25 Apr 2017 04:31:05 -0700 (PDT) Received: from external ([147.6.42.87]) by smfilter2.kt.com (1.0) id v3PBUEN0069A; Tue, 25 Apr 2017 20:30:14 +0900 Received: by KTEX2.localdomain (Postfix, from userid 600) id 3wC1GZ0Gjlz4KwV5; Tue, 25 Apr 2017 20:30:07 +0900 (KST) Received: from MAIL-FRT-03.corp.ktad.kt.com (unknown [147.6.42.85]) by KTEX2.localdomain (Postfix) with ESMTP id 3wC1GR3Gxlz4KwV7; Tue, 25 Apr 2017 20:30:07 +0900 (KST) Received: from MAIL-MBX-02.corp.ktad.kt.com ([10.215.33.72]) by MAIL-FRT-03.corp.ktad.kt.com ([10.215.33.53]) with mapi id 14.03.0210.002; Tue, 25 Apr 2017 20:30:07 +0900 From: SungHoon Seo To: "philip.eardley@bt.com" , "mohamed.boucadair@orange.com" , "lars@netapp.com" CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgCSLSEA//9s2QCAAAMxgIAACAeAgAZN1wD//yIysA== Date: Tue, 25 Apr 2017 11:30:05 +0000 Message-ID: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dispnameaddress: sh.seo@kt.com x-originating-ip: [10.214.73.222] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:31:11 -0000 SGVsbG9+IFBoaWwgYW5kIFdHLA0KDQpJIGZ1bGx5IHN1cHBvcnQgdGhpcyBwcm94eSB3b3JrIGlu IHRoZSBXRy4NCg0KVXNlIGNhc2Ugd2l0aCB0aGlzIHByb3h5IHdvcmsgbWF5IGluY3JlYXNlIHRo ZSB1c2FnZSBvZiB0aGUgTVBUQ1AsIHNpbmNlIG1vc3Qgb2YgdGhlIGV4aXN0aW5nIHNlcnZlcnMg ZG8gbm90IGhhdmUgTVBUQ1AgY2FwYWJpbGl0eS4NCg0KUmVnYXJkcywNClN1bmdIb29uDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXVsdGlwYXRodGNwIFttYWlsdG86 bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBwaGlsaXAuZWFy ZGxleUBidC5jb20NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMjUsIDIwMTcgNDoxMiBQTQ0KPiBU bzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+IENjOiBt dWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNl bnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQo+DQo+IEp1c3QgdG8gY2xh cmlmeSBvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHZhcmlvdXMgaHVtcyBkdXJpbmcgdGhlIG1l ZXRpbmcuDQo+DQo+IFdlIGludGVycHJldGVkIHRoZW0gYXMgaW5kaWNhdGluZyB0aGVyZSB3YXMg b25lIHRvcGljIHRoYXQgaXQgd2FzDQo+IHdvcnRod2hpbGUgZG9pbmcgYSBjb25zZW5zdXMgY2Fs bCBvbi4gV2UgZGlkIG5vdCBpbnRlcnByZXQgdGhlIGh1bXMgYXMNCj4gaW5kaWNhdGluZyBjbGVh ciBjb25zZW5zdXMgdGhhdCB3ZSBtZXJlbHkgbmVlZGVkIHRvIGNvbmZpcm0gb24gdGhlIGxpc3Qu DQo+DQo+IFNvIGZhciB3ZSBzZWU6DQo+IEluIGZhdm91cjoNCj4gY2hyaXN0aWFuLmphY3F1ZW5l dEBvcmFuZ2UuY29tDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gV2lsbGlhbSBJ dmFuY2ljIDxpdmFuY2ljQHN5enlneWVuZ2luZWVyaW5nLmNvbT4NCj4gU3RlZmFubyBTZWNjaSA8 c3RlZmFuby5zZWNjaUBsaXA2LmZyPg0KPiBIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUvQW50 d2VycCkgPHdpbS5oZW5kZXJpY2t4QG5va2lhLmNvbT4gRGF2aWQNCj4gQWxsYW4gSSA8ZGF2aWQu aS5hbGxhbkBlcmljc3Nvbi5jb20+IE1hcmt1cy5CcnVubmVyM0Bzd2lzc2NvbS5jb20gUm9iZXJ0 DQo+IFNrb2cgPHJvYmVydC5za29nQGVyaWNzc29uLmNvbT4gT2xpdmllciBCb25hdmVudHVyZQ0K PiA8T2xpdmllci5Cb25hdmVudHVyZUB1Y2xvdXZhaW4uYmU+DQo+IENvc3RpbiBSYWljaXUgPGNv c3Rpbi5yYWljaXVAY3MucHViLnJvPg0KPg0KPiBBZ2FpbnN0Og0KPiBKb2UgVG91Y2ggPHRvdWNo QGlzaS5lZHU+DQo+IEp1bGl1c3ogQ2hyb2JvY3playA8amNoQHBwcy51bml2LXBhcmlzLWRpZGVy b3QuZnI+IEVnZ2VydCwgTGFycw0KPiA8bGFyc0BuZXRhcHAuY29tPg0KPg0KPg0KPiBJdCBpcyB0 aGVyZWZvcmUgaW1wb3J0YW50IHRvIGhlYXIgdmlld3MgZnJvbSBvdGhlciBwZW9wbGUuIE9mIGNv dXJzZSBpdCBpcw0KPiBhbHNvIHdlbGNvbWUgZm9yIHRoZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiB0 byBjb250aW51ZSAoaW5kZWVkLCBzb21lIHBlb3BsZQ0KPiBtYXkgd2FudCBtb3JlIG9mIHRoZSB0 ZWNobmljYWwgZGlzY3Vzc2lvbiBiZWZvcmUgZ2l2aW5nIHRoZWlyIHZpZXcgb24gdGhlDQo+IGNv bnNlbnN1cyBjYWxsKS4NCj4NCj4gVGhhbmtzDQo+IFBoaWwgJiBZb3NoaQ0KPg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gU2VudDogMjEgQXByaWwg MjAxNyAwNzo1NQ0KPg0KPiBbY3V0XQ0KPg0KPiBMYWNraW5nIHRoYXQgaW5mb3JtYXRpb24sIEkg ZG9uJ3Qgc2VlIGEgbmV3IGVsZW1lbnQgaGVyZSB0aGF0IGNvdWxkIGxlYWQNCj4gdG8gY2hhbmdl IHRoZSBjb25zZW5zdXMgcmVhY2hlZCBhdCB0aGUgQ2hpY2FnbyBtZWV0aW5nIChvZiBjb3Vyc2Ug SSdtIG5vdA0KPiBlbnRpdGxlZCB0byBkbyB0aGF0IGNhbGwgYW55d2F5KS4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXVsdGlwYXRodGNw IG1haWxpbmcgbGlzdA0KPiBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3ANCg0KDQrAzCC43sDPwLogwfbBpLXI ILz2w+vAzri4wLsgwKfH2CDA27y6tce++sC4uOcsIMHfv+TH0SDBpLq4s6ogwPrA27HHwLsgxvfH 1MfPsO0gwNbAuyC89iDA1r3AtM+02S4gvu62sMfRILHHx9EgvvjAzCwgursgua68rb+hIMb3x9S1 yCDBpLq4wMcgwPy6ziC2x7TCIMDPus64piC5q7TcwLi3ziDBpjPA2r+hsNQgsPiwsywguejG9ywg urm75yC2x7TCILvnv+vHz7TCILDNwLsgvvaw3cj3ILHdwfbH1bTPtNkuILi4vuAsILq7ILjewM/A zCDA37j4IMD8vNu1yCCw5r/sLCC5373FwM4gtse0wiC057vnv6Egvsu3wcHWvcOw7SwgursguN7A z8C7IMHvvcMgu+jBpsfPv6kgwda9w7HiILnZtvi0z7TZLg0KVGhpcyBFLW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZC9vciBjb3B5cmlnaHQgbWF0ZXJpYWwuIFRo aXMgZW1haWwgaXMgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5LiBJ ZiB5b3UgcmVjZWl2ZSB0aGlzIGVtYWlsIGJ5IG1pc3Rha2UsIHBsZWFzZSBlaXRoZXIgZGVsZXRl IGl0IHdpdGhvdXQgcmVwcm9kdWNpbmcsIGRpc3RyaWJ1dGluZyBvciByZXRhaW5pbmcgY29waWVz IHRoZXJlb2Ygb3Igbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQo= From nobody Tue Apr 25 04:40:04 2017 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 5B75C12EC28 for ; Tue, 25 Apr 2017 04:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhdRS6a6P0rn for ; Tue, 25 Apr 2017 04:40:00 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 2F5CA12EC22 for ; Tue, 25 Apr 2017 04:39:59 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3PBdwtq001913; Tue, 25 Apr 2017 13:39:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 569A2D7936; Tue, 25 Apr 2017 13:39:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id n58OpKBfU4Bp; Tue, 25 Apr 2017 13:39:57 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4D74AD7924; Tue, 25 Apr 2017 13:39:57 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d2yp2-0008WB-NL; Tue, 25 Apr 2017 13:39:56 +0200 Date: Tue, 25 Apr 2017 13:39:56 +0200 Message-ID: <7ishkwu35f.wl-jch@irif.fr> From: Juliusz Chroboczek To: SungHoon Seo Cc: "multipathtcp@ietf.org" In-Reply-To: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 25 Apr 2017 13:39:58 +0200 (CEST) X-Miltered: at korolev with ID 58FF358E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58FF358E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58FF358E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:40:02 -0000 > Use case with this proxy work may increase the usage of the MPTCP, since > most of the existing servers do not have MPTCP capability. It may also have the opposite effect -- to lock up MPTCP in the ghetto of proxy-to-proxy protocols, and destroy the (positive) perception of MPTCP as a suitable end-to-end protocol. (IMHO, upstreaming MPTCP into the Linux kernel would do more for MPTCP deployment than anything that the IETF may do, but I guess that's somewhat off-topic for this discussion.) -- Juliusz From nobody Tue Apr 25 04:55:44 2017 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 679E912EC44 for ; Tue, 25 Apr 2017 04:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-FphLBN7hgg for ; Tue, 25 Apr 2017 04:55:40 -0700 (PDT) Received: from vrout30.yaziba.net (vrout30-bl.yaziba.net [185.56.204.35]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2E512EC3E for ; Tue, 25 Apr 2017 04:55:39 -0700 (PDT) Received: from mtaout20.int.yaziba.net (mtaout20.int.yaziba.net [10.4.20.37]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vrout30.yaziba.net (mx10.yaziba.net) with ESMTPS id F0BDB5228A for ; Tue, 25 Apr 2017 13:55:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mtaout20.int.yaziba.net (Postfix) with ESMTP id EFE55160488 for ; Tue, 25 Apr 2017 13:55:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at mtaout20.int.yaziba.net Received: from mtaout20.int.yaziba.net ([127.0.0.1]) by localhost (mtaout20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 16PEzaDqOJIz for ; Tue, 25 Apr 2017 13:55:37 +0200 (CEST) Received: from [192.168.18.122] (d515308a2.static.telenet.be [81.83.8.162]) by mtaout20.int.yaziba.net (Postfix) with ESMTPSA id BAE2016025C for ; Tue, 25 Apr 2017 13:55:37 +0200 (CEST) To: multipathtcp@ietf.org References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Wouter Cloetens Message-ID: <5cf19f64-6aec-1e86-ab4c-fe88100c6ce6@softathome.com> Date: Tue, 25 Apr 2017 13:55:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-DRWEB-SCAN: ok X-VRSPAM-SCORE: 0 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrgedvgdeglecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtqhertddtfeejnecuhfhrohhmpeghohhuthgvrhcuvehlohgvthgvnhhsuceofihouhhtvghrrdgtlhhovghtvghnshesshhofhhtrghthhhomhgvrdgtohhmqeenucfkphepkedurdekfedrkedrudeivdenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:55:43 -0000 As a hummer during the meeting, I fully support the work on MPTCP proxy=20 solutions in the WG. If I'd pressed to provide a reason, I'd start by admitting that, indeed,=20 this is not perfect. It won't solve every use case and every problem.=20 The plain mode draft makes no effort to fix the world in one day, which=20 is, IMO, exactly why it is a good starting point for a realistic solution= . If there were a silver bullet solution, that would solve everything in a=20 simple way, we'd have found it by now, and there would be no debate. If we could practically redesign IP from the ground up for multipathing,=20 channel bonding and congestion control, solved for all higher level=20 protocols, then we'd be doing that. If there were a better alternative available, we'd go for that. I've=20 studied some. All have weaknesses. MPTCP, as a proxy mechanism, has a=20 leg up on the competition because it defers congestion control to TCP=20 and MPTCP, rather than attempting to reinvent TCP. As such, it is the=20 best choice for a network topology in which at least one of the links is=20 not point-to-point with a fixed upstream and downstream bandwidth budget. A someone with an engineering mentality, I'd like to see solutions for=20 real problems within my lifetime. And I'd rather build those solutions=20 in a standard, interoperable way. bfn, Wouter On 25/04/17 09:11, philip.eardley@bt.com wrote: > Just to clarify our interpretation of the various hums during the meeti= ng. > > We interpreted them as indicating there was one topic that it was worth= while doing a consensus call on. We did not interpret the hums as indicat= ing clear consensus that we merely needed to confirm on the list. > > So far we see: > In favour: > christian.jacquenet@orange.com > mohamed.boucadair@orange.com > William Ivancic > Stefano Secci > Henderickx, Wim (Nokia - BE/Antwerp) > David Allan I > Markus.Brunner3@swisscom.com > Robert Skog > Olivier Bonaventure > Costin Raiciu > > Against: > Joe Touch > Juliusz Chroboczek > Eggert, Lars > > > It is therefore important to hear views from other people. Of course it= is also welcome for the technical discussion to continue (indeed, some p= eople may want more of the technical discussion before giving their view = on the consensus call). > > Thanks > Phil & Yoshi > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ] > Sent: 21 April 2017 07:55 > > [cut] > > Lacking that information, I don't see a new element here that could lea= d to change the consensus reached at the Chicago meeting (of course I'm n= ot entitled to do that call anyway). > --=20 Chief Home Gateway Architect SoftAtHome http://www.softathome.com/ https://www.linkedin.com/in/wcloetens Vaartdijk 3/B701, B-3018 Wijgmaal Tel: +32-16-852010 Mobile: +32-492-277790 Conf. phone: +32-16-852097 This message and any attachments are confidential, intended solely for the addressees and are SoftAtHome=E2=80=99s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. From nobody Tue Apr 25 04:57:18 2017 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 C69C012EC45 for ; Tue, 25 Apr 2017 04:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MsZVWrrKD-EP for ; Tue, 25 Apr 2017 04:57:13 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B06212EC46 for ; Tue, 25 Apr 2017 04:57:13 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r190so93954394wme.1 for ; Tue, 25 Apr 2017 04:57:13 -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=19TlH5OnhPg+ZOHBySLUQUzP0ZcykXYMuxb2kIic9UY=; b=gIizD8TqtOsYis02zG8hqbFj6Zuw8nhZrLNFdg02OT7XD72Rod0JBS29Qo+gD3M598 S4TJukPGpr1tIdyYsCX6yMQBeYslbuqHejK5l7ngmjTzuID6HKwzi7ANCp/UXrWmj/Up eFgsHFWVXkAFfk9Wun07AcIHizaZQ10dsvMb2BpQGK5gVyZQt1r7W/gOq0rnEqA4EX3U b/lGvvM1SPSbrWvgCgMttJFv4Uc3A5hBljPoyySfcDjvip4/My2tmhqWPBNhy0WVv0DJ 19s/7ebFltwKkABNxQpE59WHpHSAqtQ92F0GVfQMoC6wkW0e3kkamFMOSBNH0HZURZwk F/lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=19TlH5OnhPg+ZOHBySLUQUzP0ZcykXYMuxb2kIic9UY=; b=ZusQdxhfrTx3xPG6TYCJmtkOmE6IJz4K3zPJ1OZk0Sf1uB82BjyNhPGcGlpyl4KJ30 FbsIAZ0ICh5JhttRY1q5Al8+nzEITehF5WafO+cxYOtR/KuQDeSMG7GJblhEDHyCQ8hH 2XVqJ5uXNua3fZTUovgUCaSZMornic+9hVWtY7eee4f39LQexLcH8ntWBpdnQa1FZb3x Oqk6H7WZNKL7SxuvfYuzXRSjWwCTWlWp97DXyyOt0rPh5XMUHDi7npw61mN19Kmkhm+y rW2ThMLG0g7fbm9cCTuQ8dWdty0D/5C9jvI1X4K8V7LU4PB0xU3J0lq37IvHzObLgQEQ 4NQg== X-Gm-Message-State: AN3rC/4llgfdyKTCKe0q+NFSMIIpVgkUfGWUbSFyzLtyNy9d1MmVQ9HY gi+aqpcOqxuF3lmtcOwxooIg2d+FF6a900cBSMmQ3yGa5K2XGLipfLbSrwLZg39LUWqQzgBfgTd nvF/q X-Received: by 10.80.135.87 with SMTP id 23mr4849195edv.148.1493121431178; Tue, 25 Apr 2017 04:57:11 -0700 (PDT) Received: from [192.168.1.20] ([87.66.241.239]) by smtp.gmail.com with ESMTPSA id l4sm4966767edb.35.2017.04.25.04.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 04:57:10 -0700 (PDT) To: philip.eardley@bt.com, mohamed.boucadair@orange.com, lars@netapp.com References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: multipathtcp@ietf.org From: =?UTF-8?B?U8OpYmFzdGllbiBCYXJyw6k=?= Message-ID: <70244e39-1bf8-87ae-9718-8ddcd8a6ba69@tessares.net> Date: Tue, 25 Apr 2017 13:57:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/related; boundary="------------DA97BE46482808FC075997BE" Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:57:17 -0000 --------------DA97BE46482808FC075997BE Content-Type: multipart/alternative; boundary="------------FC1A5F43CA805374F8E840C7" This is a multi-part message in MIME format. --------------FC1A5F43CA805374F8E840C7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, Op 25-04-17 om 09:11 schreef philip.eardley@bt.com: > Just to clarify our interpretation of the various hums during the meeting= . > > We interpreted them as indicating there was one topic that it was worthwh= ile doing a consensus call on. We did not interpret the hums as indicating = clear consensus that we merely needed to confirm on the list. > > So far we see: > In favour: > christian.jacquenet@orange.com > mohamed.boucadair@orange.com > William Ivancic > Stefano Secci > Henderickx, Wim (Nokia - BE/Antwerp) > David Allan I > Markus.Brunner3@swisscom.com > Robert Skog > Olivier Bonaventure > Costin Raiciu I am also in favour. thanks, S=E9bastien. > > Against: > Joe Touch > Juliusz Chroboczek > Eggert, Lars > > > It is therefore important to hear views from other people. Of course it i= s also welcome for the technical discussion to continue (indeed, some peopl= e may want more of the technical discussion before giving their view on the= consensus call). > > Thanks > Phil & Yoshi > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 21 April 2017 07:55 > > [cut] > > Lacking that information, I don't see a new element here that could lead = to change the consensus reached at the Chicago meeting (of course I'm not e= ntitled to do that call anyway). > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --=20 Tessares SA S=E9bastien Barr=E9=BA | Co-Founder = & COO sebastien.barre@tessares.net | +32 10 39 22 55 | +32 472 24 67 40=20 Tessares SA | Hybrid Access Solutions www.tessares.net 6 Rue Louis de Geer, 1348 Louvain-la-Neuve, Belgium=20 =20 =BAPraos Consulting SPRL --=20 ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. --------------FC1A5F43CA805374F8E840C7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi all,


Op 25-04-17 om 09:11 schreef philip.eardley@bt.com:
Just to clarify our interpretation of the various hums=
 during the meeting.

We interpreted them as indicating there was one topic that it was worthwhil=
e doing a consensus call on. We did not interpret the hums as indicating cl=
ear consensus that we merely needed to confirm on the list.=20

So far we see:
In favour:=20
christian.jacquenet@orange.com
mohamed.boucadair@orange.com
William Ivancic <ivancic@syzygyengineering.com>=20
Stefano Secci <stefano.secci@lip6.fr>  =20
Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>=
=20
David Allan I <david.i.allan@ericsson.com>=20
Markus.Brunner3@swisscom.com=20
Robert Skog <robert.skog@ericsson.com>=20
Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>=
=20
Costin Raiciu <costin.raiciu@cs.pub.ro>
I am also in favour.
thanks,
S=E9bastien.

Against: =20
Joe Touch =
<touch@isi.edu>
Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>=20
Eggert, Lars <lars@netapp.com>


It is therefore important to hear views from other people. Of course it is =
also welcome for the technical discussion to continue (indeed, some people =
may want more of the technical discussion before giving their view on the c=
onsensus call).

Thanks
Phil & Yoshi

-----Original Message-----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucada=
ir@orange.com]=20
Sent: 21 April 2017 07:55

[cut]

Lacking that information, I don't see a new element here that could lead to=
 change the consensus reached at the Chicago meeting (of course I'm not ent=
itled to do that call anyway).=20

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

--
3D"Tessares <= span style=3D"font-weight: bold; color: rgba(37, 83, 155, 1); display: inline;"> S=E9bastien Barr=E9=BA | Co-Founder &= ; COO
<= a href=3D"mailto:sebastien.barre%40tessares.net" style=3D"color: rgb(0, 0, 0); text-decoration: none; display: inline;"> sebastien.barre@tessares.net | +32 10 39 22 55 | +32 472 24 67 40
Tessares SA | Hybrid Access Solutions
 www.= tessares.net
6 Rue Louis de Geer, 1348 Louvain-la-Neuve, Belgium

=BAPraos Consulting SPRL


DISCLAIMER.
This email and any files transmitted with it are confidential an= d 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 syste= m manager. This message contains confidential information and is intended o= nly 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 delet= e this e-mail from your system. If you are not the intended recipient you a= re notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited.= --------------FC1A5F43CA805374F8E840C7-- --------------DA97BE46482808FC075997BE Content-Type: image/png; name="siglogo.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="siglogo.png" iVBORw0KGgoAAAANSUhEUgAAAJAAAACQCAYAAADnRuK4AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAABmJLR0QA/wD/AP+g vaeTAAAACXBIWXMAAA3XAAAN1wFCKJt4AAAAB3RJTUUH3wMRDzUvggX2ogAAH/1JREFUeNrt nXl8lOXV97/numeSALIjEMENcAFcu1lQq6iUKlESEPv0QalaNisEbau2fWvt8z5v375W2woi SnADrEtVCJtaH2Wpiq1L1SqLCqgsCfu+JDNzX+f945ogYEgyyczcd2i+nw98+ITMzLnv+d3X cs65zoEmmmgAErQBRzuj5peDZyBuIwge7p5b8UjE/Tz7aEHboE1sEE0CygCjXigHEKx0BP0W 8A3gNKATEAF2AZ8DHwJvoSxHZD9WKbkqP2jzU6JJQGlk1PwN+Hm5ePsqjke4BvgB0BNofoSX WGATsBiYJrAQqJhS0HhE1CSgNDD85Y2cXr6Xz9vndQL5AfBD4AzcaFNXdgBPC/w/Rb8QDFMK Ogd9abXSJKAGMGreeqzkYDTRDigERgFfA6L1fEsF/gaMR+QD4nFKCo8P+jJrJJUnpIkko1TR OWUgppXRxADgJqAPkNfAtxbgIuAhVG8kElke9LXWxeAm6siw51fTMq8F1tpmCJfghHMx0CID HzcTGAlsKwnxmqhJQHVk5LwNCJqj0FdgDPA9oHUGPzIO3Kbx+ATJyaFkYDjXQ01TWC2Mml8O EEH1G8BogQKgQxY+OgqMkGh0NqqfB30fjkTTCHQERs3fCGI8bOIM4AbgGiDbc4kPjAN5ULBM KTgu6NvyFZpGoMP48exyjEVianugdjhwHXACwTxsHjAA5TFVUxH0vamOJgElGTWvHEUlAV3x GIYbdU4h+FG6N6LHAauDvkfV8W8voOtnbiW/0ya2btfOgnwfJ5wzcE9/GOgEdESaBBQqbpq/ kZj6eMTbb93eZhDwI+Cb1N8JmClyBNpp0FYcgX87AY16ZTuybx/W2paeyADQMcCFQE7Qth0B 0fCMhl/h30ZAY+ZsJB710crK5hhzMS7s0J8jBzrDgo+L3oeSfwsBjZpXhq821/Pl28kR53Iy 6wRMJ9uBzUEbcSSOagGNnLsON/zL10S4CRgEtAvarhRZjUhZ0EYciaNSQMmELoPlDHGL46uB 8Hnh6sbfiNkdsTOPDdqOajmqBDRy3kasGMEmugPDgWuBk4O2qwFsAuYQFZot3Rq0LdVyVAho xPwy2vlRtkuiq6f2P4HrcSmkJmjbGsgsq/pPAR4cFM6IfNBe1gYzat5GwLbDTVOjgHMI8bY3 BZYDQwWWThnYGSScX1WjHYFGzitDQMBeAPwSuITw+nJSZYvAXQnPLI0k/NCKBxqhgAZMXsBJ J/RC1TZH5EbgdiDceZ+psRn4pVg7M6KWKVd2CdqeGml0Ajrp+J6g2gGR3wA3As2CtilNKPCh wl14Mtcazy+5IpxJZAcT3rGxGkbNKwe3Hb8H+D5Hx1oH3G7raZBJ+9fv+zQvvxlTG8n5sEYj oNFOPB0UJuDOWzUa22tgGzAXKFHkHRGNlQxsHMKpolFMYSPnbsAqzUX0TtzI09jFsxv4H+Ah kNesUHHiDuXOYY1LPNAIBDRm3gY840ncJq7HnVJozNPWPtzp04dQFqjRfVMb2YhzOKEXkEWx NnEecAeNd8FcCbwNTBblBRvVnblbo0waFs7wRCqEWkCj5pUj0FLhp7i85MZGAngPmAqUevFW myuar+GxAT2DtitthFZAI+ZvxFgfK3IlMDBoe1LEAiuAR0CebrXFlu1pJzxYlInzh8ESWgEZ FGtMO1RH0HimLgusAqYBT0Ui/mfWR++9vmvQdmWMUApo5PwNiCoKlwHfDtqeOrIO+DPwuIFP FOzk7x29wqkilAISqyjkIgwh/KPPJuB54BFB3lfwHzqsLMusZcmCU6p5Ai0RWoom43aCr7BH hN2+yr4E1vcQhvRqHOlLoRRQ0stzKtA3aFNqYDswD3hIkbdB4iUFnQCYuawMEBG0jcDpoOcC ZyCcCrQHWqocCPz6wB5Vdhl0TQ6yFPhX6bLy90UoT8QknpNnufK0cAoqlA65ZMhiDPAA4cvp 2QW8DDyMqyxWUVKQzwvLPmc/eXj4eSDn4M7QX4J7ENqR2r3eD6wB3gTmISzSmG6ViFDYO1xC Cp2ARrs0Dc8ij+AqfYWF/cAi4CHgVSvsfTjpBCxdXgZKHq62zw+BS4GOafrcfcC7wAyEmday NeLBVaeHQ0ihE1By9OkIvIir9hU0MeAtoASYg9idaISSgk6ULisDN0KeCYwDhgBtMmRHJfAG 8CeQl1WIFfUM3osdVgH1AhbgjvUGRQJ4H5iqyEzB36KtPaZe2JnSZRsgtxNUlufjjkKPBE7K kl3bgenAH0DXgqGwV3BCSmkR3e9nC9m+S2jRjBaq2gWXyNUJdxx4P7AeWCNiN6glPmyi4Wbp Vx+7jiczVb/qggLLgMeAZzzi6ywRphR04c9bv6BgaTkqthmV5QXALcC3Ur2PDaQtUAycjZjb V69a+/bcFRu48vRgcofqNAL1Gfs3VD2MiZ2AUIDzDJ+J21FEk+9jccPsOtycPRtYYGCbBZZM rJuQkiPQMNwXmM1z6opzAk4HnrSW1UbQkivd0z1rWTkIRlTPBcbjimq2zKJ91bECGC/N9GUq hEE9s78uqlFA5xUvIiIK0FKV/wDGAr2pW0S8ggNztn0ZJL5k4iW1vigpoNHAg7XZl0bWAU8B j6qVTxC1U5PCSa5zwBWXujFpW5hSaFcDN0ejOS/FYpUU9c5uCmyNW2RPFVU9UZVJwETgLOqe TpGH241MA3MHmJZ9ixfV1a5csiOezcAUkCLU/ALMiqlXdT4gntnLyxGkBa462XPAbwiXeAC6 ARPj8dj5ApQuL8/qhx9x7u5TvDBpnEzCFZSs7xfaHrgTtJ0Kd/UtXri7DtNZHDelZEpE+4D5 wGTULlGITT0oeX3OR2WgGKt6DnArbro6JkO2pINTgHtU5DpRXZXND652BOpbvBBxhSR/jytE 0NAvMge4WZRbxLeR88ctqO339+M8tJlgKXATwo2ILkKiB8RTuqKMu/RtrEe+9fgFrtTutYRb PFX0EbgTaHHQtJtxviKgPsWLSKgnOE9wYRo/KwcYr565XIE+4xfV9LubcQvydBIHnkEZWlLQ ebr1ZU/JwOMoKejIvFVrKF1WjijNz13e5RqU53HT1YlptiHTDAW+b32P2cvXZ+UDDxHQt8cu RFAi4n8Nd8oz3emj7YE7MNJF1B75t5T1uEV4utgH/AFkDJ4sH1G6gYevctveWUvLiVVEDarf VOVh4FFc1flwxglrpjkw3nh+d9Xs7D8OuUlRBeIiflSHkbnFYl+UMaj8pu+4hf6S+w9fDykI m0A24ATXUHYDv1XViQL7S65IbsuXr2c7FYjSVdDrcAtlgL8Cn+J8Wjtx02kElxVwLNAVt3Dt nrxHzQiXQ/YsYIzF+8WsZRsSRb0y6x86REC+B3jaFRiQwc8UYASir4JZ1Peml1ny4HcP+U9g i7q1Su8GftZ+4HcKf0KIlRTkM33pDtrqbnwrzdtJs2+A9sF5d29SZJUV2RYl17eaoLDXoTnL M5dtpLlfSaUXzVW0M27xehGu3cHZBO8XqmK4wZ+vLnaXUaobpnvjnrBM0hnkdrAfEo0cUrek 0z86seHbm2Io7/DlqFAffOBBNToBJTZ14HHMXFqOpVJ8MW2ALqhsVtHJOa067K7cuIbBX+9R 4xsO7nUgslIJfPHC0s1feMZ7Zb9WtMMlvv0HbtORjUr2NdERuEVU3itdVrazMIO5RdXtws6g 4V1n6sJlIMP9nc3oO37hgR/+7//23AbePT0NKe32EnC3WNk3deCXN1CwIkhM1K4wnlke37Bh 98CuObWKpzqu6H0sA3q2o7DXcdus6AsII3FVQp4G9mbhHtbEAESHIlC6NHO7supGoGw5yqLA WK91xWKUf/YpXsibSf+QOO/3clV5F+eDSpUvgP8CNn2dL9cAg3vngwu5pP3LHdyzC8+891ll brO8xaq8I6pFwM9p+DRcX/KAcaqySERXZupDqhuBsunz6Ab8TFSPOcQQFazKHlw8LVV/UAJ4 wOC/IyijC7K3vv3+uSdTeHo+VqN7O1S8/wTuFO3MpE1BcJago41IZHaGPNTVCSjd/pfaGKQi Q3wLFySnsikF+VWL6RdwjWlT4e8K03w8Dao5yZBeHSjPOQdgqSqjgUmk1y2RCsMVvUBVmf1x +kVUnYA2ZvkCmwM/9Qyn2oPLsQtIQtfgouN1fYJjwGMYNhlbx1dkiKFnHEdhr+MQI1vUyK+A PxCMiDqqciuirdWm/6ZUJ6DlZH/IPVOh2OLn9Cl+FYCSgfloRED5C+50Z114V5T54sOUkJRH KeyZj/HZC/J/gftxHvFs811Uro5Iguc+2pTWN65OQP8CgqhLPMzgXS7q0Xd8MlZmPFB/Pe5o cKwO7zEXL+sjaK0M6p0P6D7gd8BfAjAhDyhO2GiPiEnv2HCYgARFVgOvBXCRbYDbMNpFkyug kis6JkXELNwJhZrYCLysFqqSwMJE0hezHbgLV2gh25wFjPIRb1Yag62HCkhA0BjwJMH0Z+iD Mlp99fokI/YlBfkgbMGdhthfw2s/FOHTENejJFIBalgF/BbXJz7bDPfQCwWhdPm6tLzhIQJa MuFiF0sQFgKzArhAA4w0Ri5ADBeP/StQ5VfkRVxtnSPxD7XsCt0psoMo+NpxSELAyovAjABM 6ATcItBaND1x8q/c7kQ8F5T9wJ+AjDmgaqAzcLtA+5hxhzeNWBTZiTtas7ua18SBfyIw5fLw TV+9hk2n17Dp0mvYdJ6a9QEYjeG29h8FYM4ARYcYEjy3rOE9XL4ioLcm90VVKd+w4QPcrqEu i9d00x/0uko9hr7FC5gysAvixqFXcCGKw9kJfBaAnXViz44EFZW03L9fc996byOIIr75BCei bN/fPGB8Aq+7l4YNYbUD/pv3X0J+587ghtm/ZvkCwYU5xuXKnnOrTNy3bycishc3Ch3eOGIT 6JYDk13IiORGwCKCOT43J8btv34J9Sy4HdnLAZh0lsBoD7zZDVxQH3HFsGRiP9TtGu4hmG19 N+BnYFv0LV7AE9ecDqqI2yHOPex3d6GyhywlUaVK0qpdgh4fj+Xm+36UTSt3IsJ23FIhiH5g wy1coEBDRFTjktOqpdJPvIF76oPw7RaCXG2s0mf8IqYU5KMu1DKVQz3me62y3w/Y+3wkVs0c jrjhcS/Q3/NUfj/tLdQqqL4GPBGAWZ2AW1Fp3ZDsxRoF9I/7LyXXi1jcF/ZGABfZHPiJNeYU UTc9iYIob3GoQ856BhsJfxLqp0Af35fTVYXC3l3ASBx3Bi6QBTWig43Ak5/Wb79U66bXGFAo Q7gHN6Vlm7OAYlHN6Vu8AAOoIQE8giuB4q5DMOGcwByi0HVl7nZcfvZIi3jdBs9w47rIp7gF dbYD2XnAeCvarXm8fq1jaxXQ6/f1Izn+/pVgfBcA16rI91Dhg1dWuDbGIv/COTwBmqmSa8O5 hgZg5azhrOtRCS674GqDfktQV+9HtSrm90oApp2NMloNXuny1NdCdXK7vTmhH6LEQO8HPgjg ItsAt2Fc28opBfn4qoorZrkSaCtKSwmxgA7ik+T1jEVp3r1oOmr2A7Id+CMBLajFcj5Wmb16 S0ovrLPfVkUR9Vbi0hL2BXCRfVFGq8XrO24hKNiKxApcukdrFdqEdBN2KMpGXJjoKoT+CNz+ yzdxF8RruEKd2aYzcIsaaW0rUnNL1VlAb064BBUFZCYuyy7bGGCkCOcjwvuvfojJi4AwA3cE p3sANqWGGyH34vxYxwBjQdrbqqnMEAedjDuRkm0uF2UwKLOX1T3xLKXI0RtcBOhe3CiU1TPY SfKB2wRtF7FRYvEIntjPcU9tT0G56tkQz2Muzpjgy8Sy74AONWrpNngGBh8wn+IiAEEsqIsF OVlTcMimJCCZ6JpMyjHe+wQX5higcJ3ktuGTBR/iWwOuzK6nKi07520IwKSUsHyZVJYDjLYi JwmWMTd8kPxvDWpBfQ4wGjWR0qV1G4VSjl0vmdAP3eODMh3XsijbRIFxWrnjHBG3PfTbR9cB 7yB0CtUZ0epQPA7t7Xo2cIMVI3ldtyGAugV1UB7qHyK2j4ry6vrad2X1Sn4Q99d2XPWO7Bak cXQHfqpoi4/+ZwXelgSovA3kqcmVUfPSm7aZVoQoh5bvE+B6Dz1XFAb1qgoc698IxkPdGbhF kFa7d9b+y/US0BsT+6HWoonY6wQX5igCGYznse7DdfjGbgc2ezaWI4GYU0eUFny1kusJqtyk aG63wdMo7NUFkDguiS6IBfUVoENEYVYtvqF6p1+9OelSJJJTFeZYEsBFtgB+iu/32LFhN7kx TyNxtpi4JLx4iOcxoQvVn6EfLMjFgtB96BOQUPDkE4JbUI9T4SRTy3q6Qfl7ViyorIfAwhxn A+MM5HywcBmTi/L9yUWd/MlFQVYHrp62l08gOfn3wMX4DqcdcLOKtsb6FJ7VBXwFF/N7NQCT zwFGxw3e8zWMQg0S0N8nXOr+oeYlvgwrZJvrLHwXXHGssNIury0krMF9MUfKJ+0vSqG1wilD ppF8+oPyUAtwfcTSx6thFGpwBvGS+y8G8WOgE3BHgrJNW+DnVvR4CWlC2QE80wb4eg2/kQfy YxGO81W4KtkXQ0UXE5yH+lYr0upIa6E0paAbDPIp7kkJJMwhKj9DbW7f2usvZp0eg/+cdCLq WcDptfz6NwSG76rowslFT7rTrSoJ3IJ6WQDmX25UrxRfKP34qyJKi4CWTLwYFRCR54HSAC5S gOsR85/EfcInIp817kTS96i9l4YBftQ6b31vkUTy1RYj3scEk0PdDBghxrYT/6sjfNoOwbwx oR+quge4F1f8Otu0Av6bnMgVCRW+c+vCBr9hulDgBJqdiGsBVRd6ACOMSqR70XSG9OqKVR9c 3aEgFtTfVOR8izBnxaHFO9N6isqKZV9kz/u4JyWIM+BdgD9GDJfGY0IKhc0zxolXP04yzaQQ SKVd8zUqei4CZw+YjhGtylH/I5BazkXDaQH0zzMJ1B7qIkmrgP4+4VKaJ1pU5ekEEeYAOA14 SDy9XHe1kL5jFwdkhiNiDSqcBFxPavf7OGC4r+Ltai5c1bNLVZRmEcEsqM+ptJGWh09iGTjH KQDbcL6hoCKbPYASabVnlBo/r0/xAvoWZ39K6z5kBuIZA/wI57NKlSuN6KlSNYS58/UJXA51 tj3UnRQ6ZFxASyb2S2YtyGu4tpBBxRW6AvcK8ntBegBZFVGPoscBUN/2wwmoPu7xEwT6iwrd h0xzP3F9kT7GtQPN5oL6GIEWh19Exnz+yS+rK/AMwTbPVZx/6g8izLOW7Z6XzPVOx3XeshAQ wdpcqzZRudNPtDwxQtnSdSjSFTfdfKcBH/Giig4F9q5+3nUALXUJX21BnwCuyNJ9LMOVf/7o 4KqvGStFIB6gug43ldUhrpsxBDd9lKjyFxEZapUO59wxh2/9pP7LtG/fvJjzbl5s8OmMam+g nYi1uS2FsqXrUaQ1rl3CBQ20/0xROVEOztcVBbQq5WNrPd83VfZRjY8vo1HHZLWxXMHch+u9 EQb240akucBiRVeIyI4dO0nkd4JX7z7yyHTB2EWoSARsO4Qz1DXd26LowoT45QajW9auB+c7 +RVwGw1vmhcHhgNPr5o5/MAPZy9fj0DUqtyDa4CXaZaIG+12Dup1cNnkDHN+8ULU7Yyew9Wg DguKq9GzCnfSZBnuhMem5M8TyfuTgwuXdMQtznvhSveuBaYiugBLpdfMUL5yLcAxit4B/ITq g6b14begvyK3NaueKjzww2RXntNwGZmZLif8kIf/YzFowelfVoLO+FlOBVT1YxH5AzAZ93SG AcEJ4xvJP4rLVa7Eiadqw2GS9ykXl+ZQBkwS4ZG4MZuivuWN+/vRvWg6QHuEXwA3k95i7Scj XoTK3YfUpxMV4tHEx5GENxk3neXU7+1rpQJ4NYGnkcO2RBkvx7RkYj/ElQ17jmDCHHVFcOJu g2tVcGzyT3ugdfL/ZwKDja93k2DTW3+6iPI1a+g5/BkQeiM8jJtO0l3pv7OqbXF4svug3vlE Eh64dp2Z9FC/h+rfRJUrD2ubkJV6XskOhVVhjiCKVjWEqi7O40FvAP3H6w9cYt94oB89iqYh RlrG9lSOwOXtFJKZUb2VQE516w23IzqwoM6Eh7oSeNTAJpWvyiVr5QjEwJ7N5p8t2uvvQCcS XFvvVNgFPC3wp9yE+Thu0NcmXZScriRHRfvgpqsCMjs1N6eG70qsAWWheloC3EF6+7zNAXnW ChRV058+axUF37ivH807WFT0KVxTt0y1tEwHFngHGCnKeFVWLJh8kZatW033QY8ZhDMRvQ83 LQ8l8+u6Gp2xg87IRz1NCNyHaw+RLt4G7lL0iB1/sloQpfOObWxs3X4/qv+F0AH4QTY/v45s xlX+mJzTIrZ294ZW7Nz5KS0LHgbjHQ/cgItrnZxFm2LU8sDZ+DZMTvvNoD9NHh26koYNEP8A bgZdXlRDP/qs1jSdNW0I3Y5XFLaK8HPcojosaYRx3GG+a43Kr0Vl7aLfDWDnjo9RaNsxJ+dG 3Hb512RXPOAKi9YYthh89hkU9sxHVD4HfowLddTHgVuBix7cYEXfFQzUUDs5sOMLLulLuiDc i5sG0t2fNRXWAZNQHvGVLW3yYNXqtYDmKdIPKMZ1JcxGH7XqeAbV6xCJH+xMrI5nP91MNBFH kVxR7Q/chAul1NaFqQJ4FyhBpRR0V2Hv2pvVBHr+pc/YhYihA87pdjMuKSybVABzQe41wjuK 2i1ryrCqnjX2HNzNvxq3jQ+SewW5zdcEn826oU4vmPthGZURg2e1tYh+E7gU+BouPlklpgpc xsS/gAWIvD6oZ/7m0uWbKOrZsU6fE/gBqvOLF4KSq8LVfNmgLdN2Ka5Oz32CPKnoro3r1roY k0o3XPR8OO5mB00CuBGYUdvocyRmfbgRjUeRvMoWgrbDOUVRJS7CDj/q7ULRIaemfhwqcAEB nD9+EcaI+L49BRiHa9R2bAPf9khswqWGTvF9lqOiO7auxI/ldlDRq3Hrh95keX1YA1sEvqvw Xn0FlElCISCA/r9YyJ49ggg5oF/HjQAFuMy8hn6ZFrfOmaPwpKDvKBrfsK4cI7YFyvdwwu1D 5sIB9WWRqBYCO1fO+mHQtnyF0AjoYPqMW4BBoyrmNNyhwf64yPex1P0LjuFyiN8HXkF4SZEV oIkNa9cBJmLwz8MJZyDZbfWZCneq8H+MdXUWw0YoBVTF+eMWYazB9/xjgBNweT2n4aLinXGL 22bJ6/BxuTHluLYHS0E/QmT1uvWJPb/9SYS77l2DomIwpwEjgGHJ9wkrG3Gj8Dsay2P1vIZ0 Qc8MoRbQ4VxY/Aqi4ItEFZODc4RWTW+KW3DGQOMgmozB0X3wnzHxOBr1Oit6LTASOKURXP8M VEcAsVUhnL4gy57ohvLaxMuq/hmnDseGThn8OAmNgvqtbNQMBL0ZOK+RXPd24AkRicVDrPPG cCPrxclFM/CRXCP+hbh1zmWkL8ErG8xCWawCX8y8LmhbjshRJ6BTBj+OYI2P9gYdg3MJtA/a rhT5HJiMUBnGrfvBHDUCOmXwdDpYZRNyPJjrcc63k4K2qx5UAPd4Jvqutdlunp06jV5A3Ypm EIkk8H3abTIyCOcIPJdgY2v1RYGnEZ2R0BirZ4Zz4XwwjVpA3YumoWLz/IR3GcI4XNAwqIBn OnhZ4U7U7JZEEKUFUie8y/sa6H71NBA8fDkXF/AcQvABz4byOsIY1B1ZDvvap4pGJaDug6cD Kqg5EdFRuHBHl6DtaiCK60Y9Vjx/eeX29qx95aqgbaozjWYK61Y0A1VyRRiC6B24M2ZhCXjW lxguLfZOVFar7zUq8UAjGYG6DZ4OoseIym3ALWQ/bygTbAQeELhf0R1RmrNi5tCgbUqZ0I9A 3YtmgJIH/C9c4lnYouWpUgksAO5G5XWr+KtLG8d6pzpCLaAeg6fT3FP2+gwHxtK4xWNxmX+T FZ4zYrbHbZwvSuuWYRhWQjuF3fr4TGbP2Y0IZ6PyHC4C31j5HJim8LiJRT/XaIJVs8IbnkiF 0I5Ac+fuwRjjqdURNF7xbMOd5JgM8i8Bu3JeGE8y1Z/QCkhdVYbTcOebGhv7cGfV70dksUJs 9fNHx4hzOKEUULLSBcCFuESyxkIC+CeuQcocK+yK+sonjXiRXBuhFJCX8LCC0YjfhxCv0w5C cUUjpoA+ZT2/zKjhs+euD9qujBNKAfkRH1yOcregbakDG3F1EB8WwwpU9LNnbwzapqwRSgEl ywG2lNrbAgTJbuBFlEm+8qYRSax67uhc59REKAWUxBDOlIwY8CZunfMSontzJMInM4cFbVcg hFJAyUVPJa4gZliwwHLgAUSfbbVDt+xqZ1j1bPhzdjJJKAVkRQDdZTSQrsXVsR7XvuHRaJRV iYTw3qv/3sKpIpQCEqtEolT4CT7EtUgKih24uogPCrwH+CueOXq35PUhlAJCDDZhARbjUlSz XQ6vAucInKzCApSKxpLglW1C62NxyWN0AGbR8GrvdSWBOwr9kMBzVti5+vkm4dREaBOyFBBX dfRxMt/2WnFN8n4DUvStsv6PWNEm8dSB0I5AkByFlDYIjwJFGfqYzcCzwGRxuyy7smm6qjOh FhDR6XR3odSzgCdwFTrSxT7gJWACVt5EiB8tKRbZJNwCAk4qfJzmzZpRWVl5Ma5VQiptI6sj DrwFTBJ0vrXsXl3atCWvL6EXEED3a57Aq6jAj+ScB9yNi9Knun6rKmv3EMJT2yoSG9vmRljd NF01iEYhIEhW2iCKwe8KjAauBU6swzUozhH4DDDVh08E9LMm4aSFRiOgKroVTUPAQ+Q0XPGl y4DTcYHXKE4wPq5G8ifAYoXZin4kSKJpxEkvjU5AVfQY8hie8Un4OS1xDWG7otJWRC2wE6FM VTbuz6nYZazR9X/5UdAmN9FEE0000UQT4eH/A2rxKDFq1cE9AAAAJXRFWHRkYXRlOmNyZWF0 ZQAyMDE1LTAzLTE3VDE1OjUzOjQ3KzAxOjAwC+gPpQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAx NS0wMy0xN1QxNTo1Mzo0NyswMTowMHq1txkAAAAASUVORK5CYII= --------------DA97BE46482808FC075997BE-- From nobody Tue Apr 25 09:13:11 2017 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 5B49C13166F for ; Tue, 25 Apr 2017 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Oxfl_cF-TT for ; Tue, 25 Apr 2017 09:13:07 -0700 (PDT) Received: from cal1-mh779.smtproutes.com (cal1-mh779.smtproutes.com [208.70.91.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB413167B for ; Tue, 25 Apr 2017 09:13:01 -0700 (PDT) X-Katharion-ID: 1493136761.38176.cal1-mh779 Received: from mail.epeerless.com ([74.203.78.194]) by cal1-mh779.smtproutes.com [(192.69.16.145)] with ESMTP via TCP (TLSv1.2/TLS_RSA_WITH_AES_256_CBC_SHA); 25 Apr 2017 16:12:41 +0000 Received: from exchange03.peerlesstech.local (192.168.1.7) by exchange03.peerlesstech.local (192.168.1.7) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 25 Apr 2017 12:12:37 -0400 Received: from exchange03.peerlesstech.local ([::1]) by exchange03.peerlesstech.local ([::1]) with mapi id 15.00.1236.000; Tue, 25 Apr 2017 12:12:37 -0400 From: Matt Sargent To: "philip.eardley@bt.com" CC: "mohamed.boucadair@orange.com" , "lars@netapp.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSvd7A7vsWLDzMLE69PvbsKDlgyQ== Date: Tue, 25 Apr 2017 16:12:36 +0000 Message-ID: <08E2585C-258B-4004-9C47-79F080C099FC@epeerless.com> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <244B4D06AEB2F9498D39FD976CB94FC1@epeerless.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:13:10 -0000 Hi all, > On Apr 25, 2017, at 3:11 AM, philip.eardley@bt.com wrote: >=20 > Just to clarify our interpretation of the various hums during the meeting= . >=20 > We interpreted them as indicating there was one topic that it was worthwh= ile doing a consensus call on. We did not interpret the hums as indicating = clear consensus that we merely needed to confirm on the list.=20 >=20 > So far we see: > In favour:=20 > christian.jacquenet@orange.com > mohamed.boucadair@orange.com > William Ivancic =20 > Stefano Secci =20 > Henderickx, Wim (Nokia - BE/Antwerp) =20 > David Allan I =20 > Markus.Brunner3@swisscom.com=20 > Robert Skog =20 > Olivier Bonaventure =20 > Costin Raiciu =20 >=20 > Against: =20 > Joe Touch > Juliusz Chroboczek =20 > Eggert, Lars >=20 You can add me to the against list. I am largely in line with Lars and Juli= usz. Thanks, Matt= From nobody Tue Apr 25 09:20:25 2017 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 39A4912F280 for ; Tue, 25 Apr 2017 09:20:24 -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 HkL24vXSuPKK for ; Tue, 25 Apr 2017 09:20:22 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C51131639 for ; Tue, 25 Apr 2017 09:20:22 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A88FF67D9FB; Tue, 25 Apr 2017 18:20:13 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be A88FF67D9FB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1493137213; bh=5bIqNC6vch4IvbDH8wWotCs3RLo0a++zcZdkTdcKGR4=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=w0HYH1WbuLn9P30MTdS5dGN+kv15gmUeNs1qvhZal72DOH0L+XXRi66Yww7f4mwJq 0xRdpOlFIlq6B7igQxw6jVHZW67Hr33P//xpdp17//YGRrRse6/40XtVneqpCE0HC3 QrDLZAD7saKZAU3/bj/cvTu9GN8HaLeajMb/vGSg= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5 Reply-To: Olivier.Bonaventure@uclouvain.be References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7ishkwu35f.wl-jch@irif.fr> To: Juliusz Chroboczek , SungHoon Seo Cc: "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <4ec233dd-af7d-9570-6149-60c4f08375b3@uclouvain.be> Date: Tue, 25 Apr 2017 18:20:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7ishkwu35f.wl-jch@irif.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: A88FF67D9FB.A610A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:20:24 -0000 Juliusz, >> Use case with this proxy work may increase the usage of the MPTCP, since >> most of the existing servers do not have MPTCP capability. > > It may also have the opposite effect -- to lock up MPTCP in the ghetto of > proxy-to-proxy protocols, and destroy the (positive) perception of MPTCP > as a suitable end-to-end protocol. I disagree. Having MPTCP proxies provides incentives to deploy MPTCP on endhosts. This is clearly what we observe today with the wide deployment of MPTCP on Android smartphones in Korea. Without proxies (in this case SOCKS proxies, but they have drawbacks as discussed earlier) nobody would have considered this deployment. > (IMHO, upstreaming MPTCP into the Linux kernel would do more for MPTCP > deployment than anything that the IETF may do, but I guess that's somewhat > off-topic for this discussion.) I agree but there are already two major smartphone vendors that use the open-source Linux MPTCP code and have included in the Linux kernel version that they ship to their customers. This is an indication of the maturity of the solution and the benefits that users can obtain with MPTCP today. Olivier From nobody Tue Apr 25 10:27:12 2017 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 749DA1316F9 for ; Tue, 25 Apr 2017 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9mcbY8LromM for ; Tue, 25 Apr 2017 10:26:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442661316EB for ; Tue, 25 Apr 2017 10:26:52 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PHQJoL016476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 10:26:20 -0700 (PDT) To: philip.eardley@bt.com, mohamed.boucadair@orange.com, lars@netapp.com Cc: multipathtcp@ietf.org References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <259f03b9-7b06-4d82-872f-cd8a24073c56@isi.edu> Date: Tue, 25 Apr 2017 10:26:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:26:54 -0000 Philip, Your note below isn't a hum; it's a vote tally. I encourage you to avoid doing that in the future. Joe On 4/25/2017 12:11 AM, philip.eardley@bt.com wrote: > Just to clarify our interpretation of the various hums during the meeting. > > We interpreted them as indicating there was one topic that it was worthwhile doing a consensus call on. We did not interpret the hums as indicating clear consensus that we merely needed to confirm on the list. > > So far we see: > In favour: > christian.jacquenet@orange.com > mohamed.boucadair@orange.com > William Ivancic > Stefano Secci > Henderickx, Wim (Nokia - BE/Antwerp) > David Allan I > Markus.Brunner3@swisscom.com > Robert Skog > Olivier Bonaventure > Costin Raiciu > > Against: > Joe Touch > Juliusz Chroboczek > Eggert, Lars > > > It is therefore important to hear views from other people. Of course it is also welcome for the technical discussion to continue (indeed, some people may want more of the technical discussion before giving their view on the consensus call). > > Thanks > Phil & Yoshi > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 21 April 2017 07:55 > > [cut] > > Lacking that information, I don't see a new element here that could lead to change the consensus reached at the Chicago meeting (of course I'm not entitled to do that call anyway). > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Apr 25 23:11:43 2017 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 223F2129416 for ; Tue, 25 Apr 2017 23:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 Hr6ZGvlibhD5 for ; Tue, 25 Apr 2017 23:11:40 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 0D11D126C25 for ; Tue, 25 Apr 2017 23:11:40 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 7C1D84019F; Wed, 26 Apr 2017 08:11:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4C1891C005D; Wed, 26 Apr 2017 08:11:38 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 08:11:37 +0200 From: To: Joe Touch CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSvQneFYN3Pf6Ey0Kw29UUSw2QvaHUm0kQ///mkACAAqPNgA== Date: Wed, 26 Apr 2017 06:11:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@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.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:11:42 -0000 SGkgVG91Y2gsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XQ0KPiBFbnZvecOpwqA6IGx1bmRpIDI0IGF2cmlsIDIwMTcgMTc6MjMNCj4gw4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8KgOiBwaGlsaXAuZWFyZGxleUBidC5j b207IG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW211bHRpcGF0aHRjcF0g Q29uc2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsNCj4gDQo+IA0KPiAN Cj4gT24gNC8yNC8yMDE3IDg6MDMgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3Jv dGU6DQo+ID4gUmUtLA0KPiA+DQo+ID4gRG8geW91IGNvbnNpZGVyIGEgTkFUIGltcGxlbWVudGF0 aW9uIGFzIHBhcnQgb2YgeW91ciBmaXJzdCBjYXRlZ29yeSBvcg0KPiB0aGUgc2Vjb25kIG9uZT8N Cj4gQSBOQVQgaXMgcGFydCBvZiB0aGUgc2Vjb25kIG9uZS4gWW91J2xsIG5vdGljZSB0aGF0IHRo ZXJlIGFyZSBubw0KPiBJRVRGLWVuZG9yc2VkIE5BVCBzb2x1dGlvbnMNCg0KW01lZF0gSSBkaXNh Z3JlZSwgSm9lLiBUaGUgSUVURiBwdWJsaXNoZWQgIlN0YW5kYXJkcyBUcmFjayIgZG9jdW1lbnRz IGFib3V0IE5BVCBUQ1Agc3RhdGUgbWFjaGluZXM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3ODU3I3NlY3Rpb24tMiwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDYj c2VjdGlvbi0zLjUuMi4yLCBhbmQgbWFueSBvdGhlciBSRkNzIGFib3V0IE5BVCBUQ1AgYmVoYXZp b3IgaXRzZWxmIChSRkM1MzgyKSBvciBSRkM2ODg4LiBBbGwgdGhlc2UgUkZDcyBhcmUgaW1wbGVt ZW50ZWQgYW5kIGRlcGxveWVkIGluIHJlYWwgbmV0d29ya3MuDQoNClRoZSBJRVRGIGhhcyBhbHNv IGEgIlN0YW5kYXJkcyBUcmFjayIgZG9jdW1lbnQgY2FsbGVkIFNPQ0tTdjUgKFJGQzE5MjgpIHRo YXQgaXMgc3BsaXR0aW5nIHRoZSBUQ1AgY29ubmVjdGlvbi4gV2UgYXJlIGFkaGVyaW5nIHRvIHRo ZSBsb2dpYyBvZiB0aGF0IFJGQyBidXQgd2l0aG91dCB0aGUgZHJhd2JhY2tzIG9mIFNPQ0tTLg0K DQpZb3VyIGluaXRpYWwgYXJndW1lbnQsIHRoYXQgaXMgYWJvdXQgInRoZSBJRVRGIGhhcyBuZXZl ciBzYW5jdGlvbmVkLi4iLCBpcyBub3QgYWNjZXB0YWJsZS4NCg0KDQogLSBvbmx5IHByb3RvY29s cyB0byB0YWxrIGRpcmVjdGx5IHRvIE5BVHMgb3INCj4gbWV0aG9kcyB0byBvdmVyY29tZSB3aGF0 IE5BVHMgZG8uDQoNCltNZWRdIEkgZGlzYWdyZWUuIFNlZSBhYm92ZS4gV2UgYXJlIGxldmVyYWdp bmcgb24gZXhpc3RpbmcgSUVURiBzdGFuZGFyZCB0cmFjayBkb2N1bWVudHMuIA0KDQo+IA0KPiA+ IEJUVywgdGhlIG1wdGNwIHByb3h5IGRvY3VtZW50cyBkbyBvbmx5IGRlc2NyaWJlIHRoZSBleHRl cm5hbCBiZWhhdmlvci4NCj4gTm8gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgYXNzdW1wdGlvbnMv ZGV0YWlscyBhcmUgaW5jbHVkZWQuDQo+IFdoZW4geW91IHJlcXVpcmUgdGhlIE1QVENQIFNZTiB0 byBiZSBpc3N1ZWQgYmVmb3JlIHRoZSBTWU4tQUNLIGlzIHNlbnQNCj4gdG8gdGhlIG9yaWdpbmF0 aW5nIGNsaWVudCwgdGhhdCBpcyBzcGVjaWZ5aW5nIHNwbGl0LVRDUCBiZWhhdmlvciB0aGF0DQo+ IHRoZSBJRVRGIGhhcyBuZXZlciBlbmRvcnNlZC4NCj4gDQo+IFRoZSBzYW1lIGlzIHRydWUgd2hl biB5b3UgdHJ5IHRvIHJlaW52ZW50IHdheXMgdG8gaW50ZXJwcmV0IFNZTiBkYXRhDQo+IGJlZm9y ZSB0aGUgTVBUQ1AgM1dIUyBjb21wbGV0ZXMgLSByZWludmVudGluZyBURk8gd2l0aG91dCBURk8n cw0KPiBwcm90ZWN0aW9ucy4NCg0KW01lZF0gSSBkb24ndCBhY2NlcHQgdGhpcyBhcmd1bWVudC4g VGhlIG9ubHkgcHJvdGVjdGlvbiBpbiBURk8gaXMgYSBzZXJ2ZXItc3VwcGxpZWQgImNvb2tpZSIu IFRoZSBwcm94eSB3b3JrIGhhcyBzdWZmaWNpZW50IHByb3RlY3Rpb25zIHRvIGludGVycHJldCBk YXRhIGluc2VydGVkIGluIGEgU1lOIGluIGEgc2FmZSBtYW5uZXIuIA0KDQotIFRGTyBjb29raWUg aXMg4oCcdXNlZCBieSB0aGUgc2VydmVyIHNpZGUgdG8gYXV0aGVudGljYXRlIGEgY2xpZW50IGlu aXRpYXRpbmcgYSBURk8gY29ubmVjdGlvbuKAnS4gV2Ugc3VwcG9ydCBhIHZhcmlldHkgb2YgYXV0 aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBtZXRob2RzOyBQbGVhc2UgcmVmZXIgdG8gc2xpZGUg Mjkgb2YgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05 OC1tcHRjcC1zZXNzYS1uZXR3b3JrLWFzc2lzdGVkLW1wdGNwLTAzLnBkZi4NCg0KLSBURk8gc3Bl Y2lmaWNhdGlvbiBhY2tub3dsZWRnZXMgdGhlIGZvbGxvd2luZzog4oCcQ09PS0lFUyBBUkUgTk9U IE5FQ0VTU0FSWSBpZiB0aGUgc2VydmVyIGhhcyBhcHBsaWNhdGlvbi1sZXZlbCBwcm90ZWN0aW9u IG9yIGlzIGltbXVuZSB0byB0aGVzZSBhdHRhY2tz4oCdIChjb29raWUtbGVzcyBGYXN0IE9wZW4p IGFuZCDigJx0aGUgc2VydmVyIG1heSBjaG9vc2UgdG8gZ2VuZXJhdGUgYSBUUklWSUFMIG9yIGV2 ZW4gYSBaRVJPLUxFTkdUSCBDT09LSUUgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZSBieSBhdm9pZGlu ZyB0aGUgY29va2llIGdlbmVyYXRpb24gYW5kIHZlcmlmaWNhdGlvbuKAnS4gQ2FjaGVkIGNvb2tp ZXMgYXJlIG5vdCByZXF1aXJlZCB0byBzdXBwbHkgZGF0YSBpbiAzV0hTIGlmIHRoZSBzZXJ2ZXIg aWYgcHJvdGVjdGlvbiBpcyBpbiBwbGFjZS4gVGhpcyBpcyB0aGUgY2FzZSBmb3IgdGhlIE1QVENQ IHByb3h5IHRhcmdldCBjYXNlLiAgDQoNCi0gVEZPIHNlcnZlci1zdXBwbGllZCBjb29raWVzIGFy ZSB1c2VkIHRvIHByZXZlbnQgU1lOcyB3aXRoIHNwb29mZWQgSVAgYWRkcmVzc2VzIGF0dGFja3M6 IFByb3ZpZGVycycgbmV0d29ya3MgYXJlIGVuYWJsZWQgd2l0aCBhbnRpLXNwb29maW5nIGZpbHRl cnMuICANCg0KSW4gb3JkZXIgdG8gYXZvaWQgYW55IGNvbmZ1c2lvbjogdGhlIGRhdGEgd2UgYXJl IHRhbGtpbmcgYWJvdXQgaXMgbm90IHVzZXIvYXBwbGljYXRpb24gc3VwcGxpZWQgZGF0YSBidXQg YSBwcm94eS1zdXBwbGllZCBkYXRhIHRoYXQgd29uJ3QgbmV2ZXIgcmVhY2ggdGhlIHVsdGltYXRl IGRlc3RpbmF0aW9uLiBXZSBhcmUgbm90IGNsb25pbmcgVEZPIGZ1bmN0aW9uYWxpdHkuIA0KDQo+ IA0KPiBKb2UNCj4gDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hA aXNpLmVkdV0NCj4gPj4gRW52b3nDqSA6IGx1bmRpIDI0IGF2cmlsIDIwMTcgMTY6NDkNCj4gPj4g w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+ID4+IENjIDogcGhpbGlwLmVhcmRsZXlA YnQuY29tOyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj4gPj4gT2JqZXQgOiBSZTogW211bHRpcGF0 aHRjcF0gQ29uc2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcmsNCj4gPj4N Cj4gPj4gTWVkLA0KPiA+Pg0KPiA+PiBBIHByb3h5IGNhbiBvcGVyYXRlIGF0IHRoZSBjb252ZW50 aW9uYWwgc29ja2V0IGxheWVyIGFuZCB3b3VsZCBub3QgaGF2ZQ0KPiBvcg0KPiA+PiBuZWVkIGRp cmVjdCBhY2Nlc3MgdG8gU1lOIHNlZ21lbnRzLiBBbnkgaW5mb3JtYXRpb24gbmVlZGVkIHRvDQo+ IHJlY29uc3RpdHV0ZQ0KPiA+PiB0aGUgU1lOIGF0IHRoZSB1cHN0cmVhbSBwcm94eSBjb3VsZCBi ZSByZXRyaWV2ZWQgaW4gb3RoZXIgd2F5cy4NCj4gPj4NCj4gPj4gWW91J3JlIHB1c2hpbmcgYSBz cGxpdC1UQ1Agc29sdXRpb24sIG9uZSB0aGF0IChhZ2FpbiwgSSByZXBlYXQpIHRoZQ0KPiBJRVRG DQo+ID4+IGhhcyBuZXZlciBzYW5jdGlvbmVkIGFuZCBJIGRvIG5vdCBhZ3JlZSB3aXRoLg0KPiA+ Pg0KPiA+PiBKb2UNCj4gPj4NCj4gPj4+IE9uIEFwciAyNCwgMjAxNywgYXQgMToyMyBBTSwgPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPiB3cm90ZToNCj4gPj4+IEpvZSwNCj4gPj4+DQo+ID4+PiBUcmFuc2Zvcm1pbmcgYSBU Q1AgY29ubmVjdGlvbiBpbnRvIE1QVENQIGNvbm5lY3Rpb24gd2lsbCBvYnZpb3VzbHkNCj4gbmVl ZA0KPiA+PiB0byBhY2Nlc3MgdG8gU1lOcyB0byBpbnNlcnQgTVBUQ1Agb3B0aW9ucy4NCj4gPj4+ IFRoaXMgaXMgdGhlIGJhc2ljIGJlaGF2aW9yIG9mICoqIGFueSAqKiBNUFRDUCBwcm94eS4NCj4g Pj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+PiBNZWQNCj4gPj4+DQo+ID4+Pj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4gRGUgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2ku ZWR1XQ0KPiA+Pj4+IEVudm95w6kgOiB2ZW5kcmVkaSAyMSBhdnJpbCAyMDE3IDE4OjA0DQo+ID4+ Pj4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBwaGlsaXAuZWFyZGxleUBidC5jb207 DQo+ID4+Pj4gbXVsdGlwYXRodGNwQGlldGYub3JnDQo+ID4+Pj4gT2JqZXQgOiBSZTogW211bHRp cGF0aHRjcF0gQ29uc2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5DQo+IHdvcmsN Cj4gPj4+Pg0KPiA+Pj4+IE1lZCwNCj4gPj4+Pg0KPiA+Pj4+IEkndmUgbWFkZSBteSBwb3NpdGlv biBjbGVhciB0b28uDQo+ID4+Pj4NCj4gPj4+PiBJIGRvIG5vdCBzdXBwb3J0IHRoaXMgZG9jIGFz IE1QVENQIHdvcmsuDQo+ID4+Pj4NCj4gPj4+PiBJIGFsc28gY2FsbCBpbnRvIHF1ZXN0aW9uIHdo ZXRoZXIgdGhpcyBpcyBpbi1zY29wZSBmb3IgTVBUQ1AuIE1QVENQDQo+IGlzDQo+ID4+Pj4gY2hh cnRlcmVkIHRvIHdvcmsgd2l0aGluIE1QVENQIC0gYnV0IHRoaXMgc29sdXRpb24gcmVxdWlyZXMg YWNjZXNzIHRvDQo+ID4+Pj4gcmF3IGluY29taW5nIFNZTnMgaW5zaWRlIGEgZGlmZmVyZW50IFRD UCBjb25uZWN0aW9uLCB3aGljaCBpcyBubw0KPiBsb25nZXINCj4gPj4+PiBpbi1zY29wZSBJTU8u DQo+ID4+Pj4NCj4gPj4+PiBKb2UNCj4gPj4+Pg0KDQo= From nobody Tue Apr 25 23:38:46 2017 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 48072131853 for ; Tue, 25 Apr 2017 23:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 UZKgjK51NFwk for ; Tue, 25 Apr 2017 23:38:42 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626A3131855 for ; Tue, 25 Apr 2017 23:38:42 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 2077D60550; Wed, 26 Apr 2017 08:38:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 054CA180055; Wed, 26 Apr 2017 08:38:41 +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.0319.002; Wed, 26 Apr 2017 08:38:40 +0200 From: To: Juliusz Chroboczek , SungHoon Seo CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...] Thread-Index: AQHSvbixRQbMuzi5EkWLuCvpR3koVqHXLPRA Date: Wed, 26 Apr 2017 06:38:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5395D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7ishkwu35f.wl-jch@irif.fr> In-Reply-To: <7ishkwu35f.wl-jch@irif.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:38:44 -0000 Hi Juliusz,=20 I echo Olivier here. That's said, you are making a valid point: how to avoid the risk that proxi= es may prevent end-to-end MPTCP connections (if it happens that servers sup= port MPTCP).=20 This is exactly why we need a standard solution and why we have this design= objective: "Avoid interference with native MPTCP connections".=20 The solution we have on the table allows for this.=20 Better, it allows to make use of path diversity whenever available and with= out requiring changes to hosts: - That path diversity may not even be visible to an MPTCP-aware client, e.g= ., a host connected in LAN network that is multi-homed. - That path diversity may not even be usable by a host, e.g., multi-path se= rver and MPTCP-unaware client. - That path diversity may not even be usable for MPTCP-aware endpoints, e.g= ., a host provided with an IPv4 address from network1 and IPv6-only prefix = from network2 while the server is IPv4-only. As a bonus, the proposal allows to withdraw a proxy from the path based on = policies. We are proposing a design that avoids to include locks out there.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Juliusz Chroboczek > Envoy=E9=A0: mardi 25 avril 2017 13:40 > =C0=A0: SungHoon Seo > Cc=A0: multipathtcp@ietf.org > Objet=A0: [multipathtcp] Increasing usage of MPTCP [was: Consensus call..= .] >=20 > > Use case with this proxy work may increase the usage of the MPTCP, sinc= e > > most of the existing servers do not have MPTCP capability. >=20 > It may also have the opposite effect -- to lock up MPTCP in the ghetto of > proxy-to-proxy protocols, and destroy the (positive) perception of MPTCP > as a suitable end-to-end protocol. >=20 > (IMHO, upstreaming MPTCP into the Linux kernel would do more for MPTCP > deployment than anything that the IETF may do, but I guess that's somewha= t > off-topic for this discussion.) >=20 > -- Juliusz >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Apr 25 23:39:01 2017 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 466DE13185B for ; Tue, 25 Apr 2017 23:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5zJuRoY29kZ for ; Tue, 25 Apr 2017 23:38:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0968013185D for ; Tue, 25 Apr 2017 23:38:49 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3Q6bfdJ001787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 23:37:51 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CBACD639-45A1-4252-9CDE-1E78D1279E35 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14E304) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 25 Apr 2017 23:37:40 -0700 Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:38:51 -0000 --Apple-Mail-CBACD639-45A1-4252-9CDE-1E78D1279E35 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I > On Apr 25, 2017, at 11:11 PM, wrote: >=20 > Hi Touch,=20 >=20 > Please see inline.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Joe Touch [mailto:touch@isi.edu] >> Envoy=C3=A9 : lundi 24 avril 2017 17:23 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN >> Cc : philip.eardley@bt.com; multipathtcp@ietf.org >> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work >>=20 >>=20 >>=20 >>> On 4/24/2017 8:03 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>>=20 >>> Do you consider a NAT implementation as part of your first category or >> the second one? >> A NAT is part of the second one. You'll notice that there are no >> IETF-endorsed NAT solutions >=20 > [Med] I disagree, Joe. The IETF published "Standards Track" documents abou= t NAT TCP state machines: https://tools.ietf.org/html/rfc7857#section-2, htt= ps://tools.ietf.org/html/rfc6146#section-3.5.2.2, and many other RFCs about N= AT TCP behavior itself (RFC5382) or RFC6888. All these RFCs are implemented a= nd deployed in real networks. >=20 Trying to create standards to patch the broken idea of a NAT and make it les= s interfering with existing protocols is not the same thing as standardizing= the NAT itself. > The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) th= at is splitting the TCP connection. We are adhering to the logic of that RFC= but without the drawbacks of SOCKS. Can you clarify where you see split TCP in RFC1928, or are you confusing it w= ith this, which adds split TCP to a SOCKS proxy: http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.34.9915&rep=3Drep= 1&type=3Dpdf ... >> The same is true when you try to reinvent ways to interpret SYN data >> before the MPTCP 3WHS completes - reinventing TFO without TFO's >> protections. >=20 > [Med] I don't accept this argument. The only protection in TFO is a server= -supplied "cookie". The proxy work has sufficient protections to interpret d= ata inserted in a SYN in a safe manner.=20 >=20 > - TFO cookie is =E2=80=9Cused by the server side to authenticate a client i= nitiating a TFO connection=E2=80=9D. We support a variety of authentication/= authorization methods; Please refer to slide 29 of https://www.ietf.org/proc= eedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf. Can you confirm that your approach has the same level of protection as TFO c= ookies?=20 >=20 > - TFO specification acknowledges the following: =E2=80=9CCOOKIES ARE NOT N= ECESSARY if the server has application-level protection or is immune to thes= e attacks=E2=80=9D (cookie-less Fast Open) and =E2=80=9Cthe server may choos= e to generate a TRIVIAL or even a ZERO-LENGTH COOKIE to improve performance b= y avoiding the cookie generation and verification=E2=80=9D. Cached cookies a= re not required to supply data in 3WHS if the server if protection is in pla= ce. This is the case for the MPTCP proxy target case. =20 >=20 Please explain your application level protection or why you think this appro= ach is immune to cookieless attacks. Or are you just embracing the result of= those attacks as valid? > - TFO server-supplied cookies are used to prevent SYNs with spoofed IP add= resses attacks: Providers' networks are enabled with anti-spoofing filters. = =20 >=20 > In order to avoid any confusion: the data we are talking about is not user= /application supplied data but a proxy-supplied data that won't never reach t= he ultimate destination. We are not cloning TFO functionality.=20 Agreed. That might actually be OK. Joe= --Apple-Mail-CBACD639-45A1-4252-9CDE-1E78D1279E35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I
On Apr 2= 5, 2017, at 11:11 PM, <mo= hamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

Hi Touch,

Ple= ase see inline.

Cheers,
Me= d

-----Message d'= origine-----
De = : Joe Touch [mailto:touch@isi.edu]
Envoy=C3=A9 : lundi 2= 4 avril 2017 17:23
=C3= =80 : BOUCADAIR Mohamed IMT/OLN
Cc : philip.ea= rdley@bt.com; multipathtcp@ietf= .org
Objet := Re: [multipathtcp] Consensus call on potential MPTCP proxy work
<= /blockquote>



On 4/24/2017 8:0= 3 AM, mohamed.boucadair@oran= ge.com wrote:
Re-,

Do you consi= der a NAT implementation as part of your first category or
the second one?
A NAT is part of the second on= e. You'll notice that there are no
IETF-endorsed NAT solutions

[Med] I disagree, Joe. The IETF published "Standards Track" docum= ents about NAT TCP state machines: https://tools.ietf.org/html/rfc7857#section-2, https://tools.ietf.org= /html/rfc6146#section-3.5.2.2, and many other RFCs about NAT TCP behavio= r itself (RFC5382) or RFC6888. All these RFCs are implemented and deployed i= n real networks.

Trying t= o create standards to patch the broken idea of a NAT and make it less interf= ering with existing protocols is not the same thing as standardizing the NAT= itself.

The IETF has also a "= Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP= connection. We are adhering to the logic of that RFC but without the drawba= cks of SOCKS.

Can you clari= fy where you see split TCP in RFC1928, or are you confusing it with this, wh= ich adds split TCP to a SOCKS proxy:

...
The same is true when you try to= reinvent ways to interpret SYN data
<= span>before the MPTCP 3WHS completes - reinventing TFO without TFO's<= br>
protections.

[Med] I don't accept this argument. The only p= rotection in TFO is a server-supplied "cookie". The proxy work has sufficien= t protections to interpret data inserted in a SYN in a safe manner. <= br>
- TFO cookie is =E2=80=9Cused by the server side t= o authenticate a client initiating a TFO connection=E2=80=9D. We support a v= ariety of authentication/authorization methods; Please refer to slide 29 of <= a href=3D"https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-n= etwork-assisted-mptcp-03.pdf">https://www.ietf.org/proceedings/98/slides/sli= des-98-mptcp-sessa-network-assisted-mptcp-03.pdf.

Can you confirm that your approach has the same level o= f protection as TFO cookies? 


- TFO specification acknowledges the following: =E2=80=9C= COOKIES ARE NOT NECESSARY if the server has application-level protection or i= s immune to these attacks=E2=80=9D (cookie-less Fast Open) and =E2=80=9Cthe s= erver may choose to generate a TRIVIAL or even a ZERO-LENGTH COOKIE to impro= ve performance by avoiding the cookie generation and verification=E2=80=9D. C= ached cookies are not required to supply data in 3WHS if the server if prote= ction is in place. This is the case for the MPTCP proxy target case.  <= /span>

Please explain your appli= cation level protection or why you think this approach is immune to cookiele= ss attacks. Or are you just embracing the result of those attacks as valid?<= /div>

- TFO server-suppli= ed cookies are used to prevent SYNs with spoofed IP addresses attacks: Provi= ders' networks are enabled with anti-spoofing filters.  

In order to avoid any confusion: the data we are talking a= bout is not user/application supplied data but a proxy-supplied data that wo= n't never reach the ultimate destination. We are not cloning TFO functionali= ty. 

Agreed.
That might= actually be OK.

Joe
= --Apple-Mail-CBACD639-45A1-4252-9CDE-1E78D1279E35-- From nobody Wed Apr 26 00:11:39 2017 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 8A2AB126BF6 for ; Wed, 26 Apr 2017 00:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 H5myISHbk3cU for ; Wed, 26 Apr 2017 00:11:35 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.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 58FDA131948 for ; Wed, 26 Apr 2017 00:11:32 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id E509A20255; Wed, 26 Apr 2017 09:11:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 89B254006B; Wed, 26 Apr 2017 09:11:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 09:11:30 +0200 From: To: Joe Touch CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSvleZFYN3Pf6Ey0Kw29UUSw2QvaHXM+ww Date: Wed, 26 Apr 2017 07:11:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> In-Reply-To: <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E539A3OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 07:11:38 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E539A3OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9l IFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCkVudm95w6kgOiBtZXJjcmVkaSAyNiBhdnJp bCAyMDE3IDA4OjM4DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogcGhpbGlw LmVhcmRsZXlAYnQuY29tOyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFttdWx0 aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoN Cg0KSQ0KT24gQXByIDI1LCAyMDE3LCBhdCAxMToxMSBQTSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiA8bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+ IHdyb3RlOg0KSGkgVG91Y2gsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQN Cg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogSm9lIFRvdWNoIFttYWlsdG86 dG91Y2hAaXNpLmVkdV0NCkVudm95w6kgOiBsdW5kaSAyNCBhdnJpbCAyMDE3IDE3OjIzDQrDgCA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1h aWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+OyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmc8bWFpbHRv Om11bHRpcGF0aHRjcEBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNl bnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCg0KDQpPbiA0LzI0LzIw MTcgODowMyBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpSZS0sDQoNCkRvIHlvdSBjb25zaWRlciBhIE5B VCBpbXBsZW1lbnRhdGlvbiBhcyBwYXJ0IG9mIHlvdXIgZmlyc3QgY2F0ZWdvcnkgb3INCnRoZSBz ZWNvbmQgb25lPw0KQSBOQVQgaXMgcGFydCBvZiB0aGUgc2Vjb25kIG9uZS4gWW91J2xsIG5vdGlj ZSB0aGF0IHRoZXJlIGFyZSBubw0KSUVURi1lbmRvcnNlZCBOQVQgc29sdXRpb25zDQoNCltNZWRd IEkgZGlzYWdyZWUsIEpvZS4gVGhlIElFVEYgcHVibGlzaGVkICJTdGFuZGFyZHMgVHJhY2siIGRv Y3VtZW50cyBhYm91dCBOQVQgVENQIHN0YXRlIG1hY2hpbmVzOiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzg1NyNzZWN0aW9uLTIsIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2MTQ2I3NlY3Rpb24tMy41LjIuMiwgYW5kIG1hbnkgb3RoZXIgUkZDcyBhYm91dCBOQVQgVENQ IGJlaGF2aW9yIGl0c2VsZiAoUkZDNTM4Mikgb3IgUkZDNjg4OC4gQWxsIHRoZXNlIFJGQ3MgYXJl IGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBpbiByZWFsIG5ldHdvcmtzLg0KVHJ5aW5nIHRvIGNy ZWF0ZSBzdGFuZGFyZHMgdG8gcGF0Y2ggdGhlIGJyb2tlbiBpZGVhIG9mIGEgTkFUIGFuZCBtYWtl IGl0IGxlc3MgaW50ZXJmZXJpbmcgd2l0aCBleGlzdGluZyBwcm90b2NvbHMgaXMgbm90IHRoZSBz YW1lIHRoaW5nIGFzIHN0YW5kYXJkaXppbmcgdGhlIE5BVCBpdHNlbGYuDQpbTWVkXSBOQVQ2NCAo UkZDNjE0NikgaXMgbm90IGEgcGF0Y2ggQUZBSUsuDQoNClRoZSBJRVRGIGhhcyBhbHNvIGEgIlN0 YW5kYXJkcyBUcmFjayIgZG9jdW1lbnQgY2FsbGVkIFNPQ0tTdjUgKFJGQzE5MjgpIHRoYXQgaXMg c3BsaXR0aW5nIHRoZSBUQ1AgY29ubmVjdGlvbi4gV2UgYXJlIGFkaGVyaW5nIHRvIHRoZSBsb2dp YyBvZiB0aGF0IFJGQyBidXQgd2l0aG91dCB0aGUgZHJhd2JhY2tzIG9mIFNPQ0tTLg0KDQpDYW4g eW91IGNsYXJpZnkgd2hlcmUgeW91IHNlZSBzcGxpdCBUQ1AgaW4gUkZDMTkyOCwNCltNZWRdIEkg ZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIFJGQzE5MjggaW4gdGhlIHNhbWUgd2F5IEkg ZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIHRoZSBwbGFpbi1tb2RlIGRyYWZ0Lg0KDQpJ IHRob3VnaCB5b3UgYXJlIG1ha2luZyB0aGUgc2FtZSBhbmFseXNpcywgeW91IGhhdmUgZG9uZSBm b3IgdGhlIE1QVENQIHByb3h5LCBmb3IgU09DS1MgdG9vOiBpLmUuLCBtaXggaW1wbGVtZW50YXRp b25zLXNwZWNpZmljIGRlc2lnbiBjaG9pY2VzIHdpdGggdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiBp dHNlbGYuIEZXSVcsIHRoZSB0eXBpY2FsIGV4Y2hhbmdlcyB0aGF0IGFyZSBvYnNlcnZlZCB3aGVu IE1QVENQIGlzIHVzZWQgd2l0aCBhIFNPQ0tTIGltcGxlbWVudGF0aW9uIGlzIGFzIGZvbGxvd3M6 DQoNCj09PT09DQooTVAgQ2xpZW50KSAtPiAgICBUQ1AgU1lOICAgIC0+ICAoTUNQKQ0KICAgICAg ICAgICAgICAgICAgIDwtIFRDUCBTWU4vQUNLIDwtDQogICAgICAgICAgICAgICAgICAgLT4gICAg VENQIEFDSyAgICAtPg0KICAgICAgICAgICAgICAgICAgIC0+IFNPQ0tTIE1ldGhvZCBSZXF1ZXN0 IC0+DQogICAgICAgICAgICAgICAgICAgPC0gICAgVENQIEFDSyAgIDwtDQogICAgICAgICAgICAg ICAgICAgIDwtIFNPQ0tTIE1ldGhvZCBSZXNwb25zZSAgPC0NCiAgICAgICAgICAgICAgICAgICAg LT4gICBUQ1AgQUNLICAgLT4NCiAgICAgICAgICAgICAgICAgICAgLT4gU09DS1MgQXV0aGVudGlj YXRpb24gUmVxdWVzdCAtPg0KICAgICAgICAgICAgICAgICAgICA8LSAgICBUQ1AgQUNLICAgICA8 LQ0KICAgICAgICAgICAgICAgICAgICA8LSBTT0NLUyBBdXRoLiBSZXNwb25zZSA8LQ0KICAgICAg ICAgICAgICAgICAgICAtPiAgIFRDUCBBQ0sgICAtPg0KICAgICAgICAgICAgICAgICAgICAtPiBT T0NLUyBDb25uZWN0aW9uIFJlcXVlc3QgIC0+IChNQ1ApDQogICAgICAgICAgICAgICAgICAgIDwt ICAgVENQIEFDSyAgICAgICAgICAgICAgICAgICA8LSAoTUNQKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE1DUCkgIC0+IFRDUCBTWU4gIC0+ IChTZXJ2ZXIpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoTUNQKSAgPC0gU1lOL0FDSyAgPC0gKFNlcnZlcikNCiAgICAgICAgICAgICAgICAg ICAgPC0gU09DS1MgQ29ubmVjdGlvbiBSZXNwb25zZSAgIDwtKE1DUCkgLT4gVENQIEFDSyAtPiAo U2VydmVyKQ0KICAgICAgICAgICAgICAgICAgICAtPiAgIFRDUCBBQ0sgIC0+DQo9PT09PT0NCg0K b3IgYXJlIHlvdSBjb25mdXNpbmcgaXQgd2l0aCB0aGlzLCB3aGljaCBhZGRzIHNwbGl0IFRDUCB0 byBhIFNPQ0tTIHByb3h5Og0KaHR0cDovL2NpdGVzZWVyeC5pc3QucHN1LmVkdS92aWV3ZG9jL2Rv d25sb2FkP2RvaT0xMC4xLjEuMzQuOTkxNSZyZXA9cmVwMSZ0eXBlPXBkZg0KDQpbTWVkXSBCaW5n by4gVGhhdCBpcyBleGFjdGx5IG15IHBvaW50LiBXZSBuZWVkIHRvIGF2b2lkIG1peGluZyBpbXBs ZW1lbnRhdGlvbiBkZXRhaWxzIHdpdGggYmFzZSBzcGVjaWZpY2F0aW9ucy4gVGhhdCBpcyBleGFj dGx5IHRoZSByZWFzb24gd2h5IEkgc2FpZCBlYXJsaWVyIHRoYXQgbXB0Y3AgcHJveHkgZG9jdW1l bnRzIG9ubHkgZGVzY3JpYmUgdGhlIGV4dGVybmFsIGJlaGF2aW9yLg0KDQouLi4NClRoZSBzYW1l IGlzIHRydWUgd2hlbiB5b3UgdHJ5IHRvIHJlaW52ZW50IHdheXMgdG8gaW50ZXJwcmV0IFNZTiBk YXRhDQpiZWZvcmUgdGhlIE1QVENQIDNXSFMgY29tcGxldGVzIC0gcmVpbnZlbnRpbmcgVEZPIHdp dGhvdXQgVEZPJ3MNCnByb3RlY3Rpb25zLg0KDQpbTWVkXSBJIGRvbid0IGFjY2VwdCB0aGlzIGFy Z3VtZW50LiBUaGUgb25seSBwcm90ZWN0aW9uIGluIFRGTyBpcyBhIHNlcnZlci1zdXBwbGllZCAi Y29va2llIi4gVGhlIHByb3h5IHdvcmsgaGFzIHN1ZmZpY2llbnQgcHJvdGVjdGlvbnMgdG8gaW50 ZXJwcmV0IGRhdGEgaW5zZXJ0ZWQgaW4gYSBTWU4gaW4gYSBzYWZlIG1hbm5lci4NCg0KLSBURk8g Y29va2llIGlzIOKAnHVzZWQgYnkgdGhlIHNlcnZlciBzaWRlIHRvIGF1dGhlbnRpY2F0ZSBhIGNs aWVudCBpbml0aWF0aW5nIGEgVEZPIGNvbm5lY3Rpb27igJ0uIFdlIHN1cHBvcnQgYSB2YXJpZXR5 IG9mIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gbWV0aG9kczsgUGxlYXNlIHJlZmVyIHRv IHNsaWRlIDI5IG9mIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9z bGlkZXMtOTgtbXB0Y3Atc2Vzc2EtbmV0d29yay1hc3Npc3RlZC1tcHRjcC0wMy5wZGYuDQoNCkNh biB5b3UgY29uZmlybSB0aGF0IHlvdXIgYXBwcm9hY2ggaGFzIHRoZSBzYW1lIGxldmVsIG9mIHBy b3RlY3Rpb24gYXMgVEZPIGNvb2tpZXM/DQpbTWVkXSBZZXMsIEkgY29uZmlybS4NCg0KDQoNCi0g VEZPIHNwZWNpZmljYXRpb24gYWNrbm93bGVkZ2VzIHRoZSBmb2xsb3dpbmc6IOKAnENPT0tJRVMg QVJFIE5PVCBORUNFU1NBUlkgaWYgdGhlIHNlcnZlciBoYXMgYXBwbGljYXRpb24tbGV2ZWwgcHJv dGVjdGlvbiBvciBpcyBpbW11bmUgdG8gdGhlc2UgYXR0YWNrc+KAnSAoY29va2llLWxlc3MgRmFz dCBPcGVuKSBhbmQg4oCcdGhlIHNlcnZlciBtYXkgY2hvb3NlIHRvIGdlbmVyYXRlIGEgVFJJVklB TCBvciBldmVuIGEgWkVSTy1MRU5HVEggQ09PS0lFIHRvIGltcHJvdmUgcGVyZm9ybWFuY2UgYnkg YXZvaWRpbmcgdGhlIGNvb2tpZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb27igJ0uIENhY2hl ZCBjb29raWVzIGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcGx5IGRhdGEgaW4gM1dIUyBpZiB0aGUg c2VydmVyIGlmIHByb3RlY3Rpb24gaXMgaW4gcGxhY2UuIFRoaXMgaXMgdGhlIGNhc2UgZm9yIHRo ZSBNUFRDUCBwcm94eSB0YXJnZXQgY2FzZS4NClBsZWFzZSBleHBsYWluIHlvdXIgYXBwbGljYXRp b24gbGV2ZWwgcHJvdGVjdGlvbiBvciB3aHkgeW91IHRoaW5rIHRoaXMgYXBwcm9hY2ggaXMgaW1t dW5lIHRvIGNvb2tpZWxlc3MgYXR0YWNrcy4gT3IgYXJlIHlvdSBqdXN0IGVtYnJhY2luZyB0aGUg cmVzdWx0IG9mIHRob3NlIGF0dGFja3MgYXMgdmFsaWQ/DQoNCi0gVEZPIHNlcnZlci1zdXBwbGll ZCBjb29raWVzIGFyZSB1c2VkIHRvIHByZXZlbnQgU1lOcyB3aXRoIHNwb29mZWQgSVAgYWRkcmVz c2VzIGF0dGFja3M6IFByb3ZpZGVycycgbmV0d29ya3MgYXJlIGVuYWJsZWQgd2l0aCBhbnRpLXNw b29maW5nIGZpbHRlcnMuDQoNCkluIG9yZGVyIHRvIGF2b2lkIGFueSBjb25mdXNpb246IHRoZSBk YXRhIHdlIGFyZSB0YWxraW5nIGFib3V0IGlzIG5vdCB1c2VyL2FwcGxpY2F0aW9uIHN1cHBsaWVk IGRhdGEgYnV0IGEgcHJveHktc3VwcGxpZWQgZGF0YSB0aGF0IHdvbid0IG5ldmVyIHJlYWNoIHRo ZSB1bHRpbWF0ZSBkZXN0aW5hdGlvbi4gV2UgYXJlIG5vdCBjbG9uaW5nIFRGTyBmdW5jdGlvbmFs aXR5Lg0KDQpBZ3JlZWQuDQpUaGF0IG1pZ2h0IGFjdHVhbGx5IGJlIE9LLg0KDQpKb2UNCg== --_000_787AE7BB302AE849A7480A190F8B933009E539A3OPEXCLILMA3corp_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAu ODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5IaSBKb2UsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBz ZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5l ZHVdDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMjYgYXZyaWwgMjAxNyAw ODozODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4N CjxiPkNjJm5ic3A7OjwvYj4gcGhpbGlwLmVhcmRsZXlAYnQuY29tOyBtdWx0aXBhdGh0Y3BAaWV0 Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBDb25zZW5z dXMgY2FsbCBvbiBwb3RlbnRpYWwgTVBUQ1AgcHJveHkgd29yazxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+STxicj4NCk9uIEFwciAyNSwgMjAxNywgYXQgMTE6MTEgUE0sICZsdDs8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBU b3VjaCwgPGJyPg0KPGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUuIDxicj4NCjxicj4NCkNoZWVycyw8 YnI+DQpNZWQ8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EZSZuYnNwOzogSm9lIFRvdWNoIFs8YSBocmVmPSJtYWlsdG86dG91 Y2hAaXNpLmVkdSI+bWFpbHRvOnRvdWNoQGlzaS5lZHU8L2E+XTxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbnZvecOpJm5ic3A7OiBsdW5kaSAy NCBhdnJpbCAyMDE3IDE3OjIzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPsOAJm5ic3A7OiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNjJm5ic3A7 OiA8YSBocmVmPSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxleUBi dC5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcEBpZXRmLm9yZyI+bXVsdGlw YXRodGNwQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PYmpldCZuYnNwOzogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1 cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvMjQvMjAx NyA4OjAzIEFNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+ DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZS0sPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IGNvbnNpZGVyIGEgTkFUIGltcGxlbWVudGF0 aW9uIGFzIHBhcnQgb2YgeW91ciBmaXJzdCBjYXRlZ29yeSBvcjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgc2Vj b25kIG9uZT88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QSBOQVQgaXMgcGFydCBvZiB0aGUgc2Vjb25kIG9uZS4gWW91J2xsIG5vdGljZSB0aGF0 IHRoZXJlIGFyZSBubzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JRVRGLWVuZG9yc2VkIE5BVCBzb2x1dGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KW01lZF0gSSBkaXNhZ3JlZSwgSm9lLiBUaGUgSUVURiBwdWJsaXNoZWQgJnF1 b3Q7U3RhbmRhcmRzIFRyYWNrJnF1b3Q7IGRvY3VtZW50cyBhYm91dCBOQVQgVENQIHN0YXRlIG1h Y2hpbmVzOg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4NTcjc2Vj dGlvbi0yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg1NyNzZWN0aW9uLTI8L2E+ LA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDYjc2VjdGlvbi0z LjUuMi4yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NiNzZWN0aW9uLTMuNS4y LjI8L2E+LCBhbmQgbWFueSBvdGhlciBSRkNzIGFib3V0IE5BVCBUQ1AgYmVoYXZpb3IgaXRzZWxm IChSRkM1MzgyKSBvciBSRkM2ODg4LiBBbGwgdGhlc2UgUkZDcyBhcmUgaW1wbGVtZW50ZWQgYW5k IGRlcGxveWVkIGluIHJlYWwgbmV0d29ya3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcnlpbmcgdG8gY3JlYXRlIHN0 YW5kYXJkcyB0byBwYXRjaCB0aGUgYnJva2VuIGlkZWEgb2YgYSBOQVQgYW5kIG1ha2UgaXQgbGVz cyBpbnRlcmZlcmluZyB3aXRoIGV4aXN0aW5nIHByb3RvY29scyBpcyBub3QgdGhlIHNhbWUgdGhp bmcgYXMgc3RhbmRhcmRpemluZyB0aGUgTkFUIGl0c2VsZi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5bTWVkXSBOQVQ2NCAoUkZDNjE0NikgaXMgbm90IGEgcGF0Y2ggQUZBSUsuDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElFVEYgaGFzIGFs c28gYSAmcXVvdDtTdGFuZGFyZHMgVHJhY2smcXVvdDsgZG9jdW1lbnQgY2FsbGVkIFNPQ0tTdjUg KFJGQzE5MjgpIHRoYXQgaXMgc3BsaXR0aW5nIHRoZSBUQ1AgY288L3NwYW4+bm5lY3Rpb24uIFdl IGFyZSBhZGhlcmluZyB0byB0aGUgbG9naWMgb2YgdGhhdCBSRkMgYnV0IHdpdGhvdXQgdGhlIGRy YXdiYWNrcyBvZiBTT0NLUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBjbGFyaWZ5IHdoZXJlIHlvdSBzZWUgc3BsaXQgVENQIGlu IFJGQzE5MjgsPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PltNZWRdIEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIFJGQzE5MjggaW4gdGhlIHNh bWUgd2F5IEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIHRoZSBwbGFpbi1tb2RlIGRy YWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkkgdGhvdWdoIHlvdSBhcmUgbWFraW5nIHRoZSBzYW1lIGFuYWx5c2lzLCB5b3UgaGF2ZSBkb25l IGZvciB0aGUgTVBUQ1AgcHJveHksIGZvciBTT0NLUyB0b286IGkuZS4sIG1peCBpbXBsZW1lbnRh dGlvbnMtc3BlY2lmaWMgZGVzaWduIGNob2ljZXMgd2l0aCB0aGUgYmFzZQ0KIHNwZWNpZmljYXRp b24gaXRzZWxmLiBGV0lXLCB0aGUgdHlwaWNhbCBleGNoYW5nZXMgdGhhdCBhcmUgb2JzZXJ2ZWQg d2hlbiBNUFRDUCBpcyB1c2VkIHdpdGggYSBTT0NLUyBpbXBsZW1lbnRhdGlvbiBpcyBhcyBmb2xs b3dzOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPihNUCBDbGllbnQpIC0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRDUCBTWU4m bmJzcDsmbmJzcDsmbmJzcDsgLSZndDsmbmJzcDsgKE1DUCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7 LSBUQ1AgU1lOL0FDSyAmbHQ7LQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUQ1AgQUNLJm5ic3A7Jm5ic3A7 Jm5ic3A7IC0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LSZndDsgU09DS1MgTWV0aG9kIFJlcXVlc3QgLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LSZuYnNwOyZuYnNwOyZuYnNwOyBUQ1AgQUNLICZuYnNw OyZuYnNwOyZsdDstPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0Oy0gU09DS1MgTWV0aG9kIFJlc3BvbnNlICZuYnNwOyZsdDstPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsmbmJzcDsmbmJzcDsg VENQIEFDSyZuYnNwOyZuYnNwOyAtJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mZ3Q7IFNPQ0tTIEF1dGhlbnRpY2F0aW9uIFJlcXVlc3QgLSZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 LSZuYnNwOyZuYnNwOyZuYnNwOyBUQ1AgQUNLICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDst PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0g U09DS1MgQXV0aC4gUmVzcG9uc2UgJmx0Oy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtJmd0OyZuYnNwOyZuYnNwOyBUQ1AgQUNLJm5ic3A7Jm5ic3A7 IC0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LSZndDsgU09DS1MgQ29ubmVjdGlvbiBSZXF1ZXN0ICZuYnNwOy0mZ3Q7IChNQ1ApPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUu MjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0mbmJzcDsmbmJz cDsgVENQIEFDSyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7LSAoTUNQKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhNQ1ApJm5ic3A7IC0m Z3Q7IFRDUCBTWU4gJm5ic3A7LSZndDsgKFNlcnZlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsoTUNQKSZuYnNwOyAmbHQ7LSBTWU4vQUNLICZuYnNwOyZsdDstIChTZXJ2ZXIpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUu MjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0gU09DS1MgQ29u bmVjdGlvbiBSZXNwb25zZSAmbmJzcDsmbmJzcDsmbHQ7LShNQ1ApIC0mZ3Q7IFRDUCBBQ0sgLSZn dDsgKFNlcnZlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtJmd0OyZuYnNwOyZuYnNwOyBUQ1AgQUNLJm5ic3A7IC0mZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj49PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciBhcmUg eW91IGNvbmZ1c2luZyBpdCB3aXRoIHRoaXMsIHdoaWNoIGFkZHMgc3BsaXQgVENQIHRvIGEgU09D S1MgcHJveHk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2NpdGVzZWVyeC5pc3QucHN1LmVkdS92aWV3ZG9j L2Rvd25sb2FkP2RvaT0xMC4xLjEuMzQuOTkxNSZhbXA7cmVwPXJlcDEmYW1wO3R5cGU9cGRmIj5o dHRwOi8vY2l0ZXNlZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2MvZG93bmxvYWQ/ZG9pPTEwLjEuMS4z NC45OTE1JmFtcDtyZXA9cmVwMSZhbXA7dHlwZT1wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gQmluZ28uIFRoYXQgaXMgZXhhY3Rs eSBteSBwb2ludC4gV2UgbmVlZCB0byBhdm9pZCBtaXhpbmcgaW1wbGVtZW50YXRpb24gZGV0YWls cyB3aXRoIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFRoYXQgaXMgZXhhY3RseSB0aGUgcmVhc29uIHdo eSBJIHNhaWQgZWFybGllcg0KIHRoYXQgbXB0Y3AgcHJveHkgZG9jdW1lbnRzIG9ubHkgZGVzY3Jp YmUgdGhlIGV4dGVybmFsIGJlaGF2aW9yLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBzYW1lIGlzIHRydWUgd2hlbiB5b3UgdHJ5IHRvIHJlaW52ZW50IHdheXMgdG8gaW50 ZXJwcmV0IFNZTiBkYXRhPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmJlZm9yZSB0aGUgTVBUQ1AgM1dIUyBjb21wbGV0ZXMgLSByZWludmVudGlu ZyBURk8gd2l0aG91dCBURk8nczxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5wcm90ZWN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCltNZWRdIEkgZG9uJ3QgYWNjZXB0IHRoaXMg YXJndW1lbnQuIFRoZSBvbmx5IHByb3RlY3Rpb24gaW4gVEZPIGlzIGEgc2VydmVyLXN1cHBsaWVk ICZxdW90O2Nvb2tpZSZxdW90Oy4gVGhlIHByb3h5IHdvcmsgaGFzIHN1ZmZpY2llbnQgcHJvdGVj dGlvbnMgdG8gaW50ZXJwcmV0IGRhdGEgaW5zZXJ0ZWQgaW4gYSBTWU4gaW4gYSBzYWZlIG1hbm5l ci4NCjxicj4NCjxicj4NCi0gVEZPIGNvb2tpZSBpcyDigJx1c2VkIGJ5IHRoZSBzZXJ2ZXIgc2lk ZSB0byBhdXRoZW50aWNhdGUgYSBjbGllbnQgaW5pdGlhdGluZyBhIFRGTyBjb25uZWN0aW9u4oCd LiBXZSBzdXBwb3J0IGEgdmFyaWV0eSBvZiBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIG1l dGhvZHM7IFBsZWFzZSByZWZlciB0byBzbGlkZSAyOSBvZg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC1tcHRjcC1zZXNzYS1uZXR3 b3JrLWFzc2lzdGVkLW1wdGNwLTAzLnBkZiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LW1wdGNwLXNlc3NhLW5ldHdvcmstYXNzaXN0ZWQtbXB0 Y3AtMDMucGRmPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IGNvbmZpcm0gdGhhdCB5b3VyIGFwcHJvYWNoIGhh cyB0aGUgc2FtZSBsZXZlbCBvZiBwcm90ZWN0aW9uIGFzIFRGTyBjb29raWVzPyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN ZWRdIFllcywgSSBjb25maXJtLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KLSBURk8g c3BlY2lmaWNhdGlvbiBhY2tub3dsZWRnZXMgdGhlIGZvbGxvd2luZzog4oCcQ09PS0lFUyBBUkUg Tk9UIE5FQ0VTU0FSWSBpZiB0aGUgc2VydmVyIGhhcyBhcHBsaWNhdGlvbi1sZXZlbCBwcm90ZWN0 aW9uIG9yIGlzIGltbXVuZSB0byB0aGVzZSBhdHRhY2tz4oCdIChjb29raWUtbGVzcyBGYXN0IE9w ZW4pIGFuZCDigJx0aGUgc2VydmVyIG1heSBjaG9vc2UgdG8gZ2VuZXJhdGUgYSBUUklWSUFMIG9y IGV2ZW4gYSBaRVJPLUxFTkdUSCBDT09LSUUgdG8NCiBpbXByb3ZlIHBlcmZvcm1hbmNlIGJ5IGF2 b2lkaW5nIHRoZSBjb29raWUgZ2VuZXJhdGlvbiBhbmQgdmVyaWZpY2F0aW9u4oCdLiBDYWNoZWQg Y29va2llcyBhcmUgbm90IHJlcXVpcmVkIHRvIHN1cHBseSBkYXRhIGluIDNXSFMgaWYgdGhlIHNl cnZlciBpZiBwcm90ZWN0aW9uIGlzIGluIHBsYWNlLiBUaGlzIGlzIHRoZSBjYXNlIGZvciB0aGUg TVBUQ1AgcHJveHkgdGFyZ2V0IGNhc2UuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGV4cGxhaW4geW91ciBhcHBsaWNhdGlv biBsZXZlbCBwcm90ZWN0aW9uIG9yIHdoeSB5b3UgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBpbW11 bmUgdG8gY29va2llbGVzcyBhdHRhY2tzLiBPciBhcmUgeW91IGp1c3QgZW1icmFjaW5nIHRoZSBy ZXN1bHQgb2YgdGhvc2UgYXR0YWNrcyBhcyB2YWxpZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRGTyBzZXJ2ZXItc3VwcGxpZWQgY29v a2llcyBhcmUgdXNlZCB0byBwcmV2ZW50IFNZTnMgd2l0aCBzcG9vZmVkIElQIGFkZHJlc3NlcyBh dHRhY2tzOiBQcm92aWRlcnMnIG5ldHdvcmtzIGFyZSBlbmFibGVkIHdpdGggYW50aS1zcG9vZmlu ZyBmaWx0ZXJzLiAmbmJzcDs8YnI+DQo8YnI+DQpJbiBvcmRlciB0byBhdm9pZCBhbnkgY29uZnVz aW9uOiB0aGUgZGF0YSB3ZSBhcmUgdGFsa2luZyBhYm91dCBpcyBub3QgdXNlci9hcHBsaWNhdGlv biBzdXBwbGllZCBkYXRhIGJ1dCBhIHByb3h5LXN1cHBsaWVkIGRhdGEgdGhhdCB3b24ndCBuZXZl ciByZWFjaCB0aGUgdWx0aW1hdGUgZGVzdGluYXRpb24uIFdlIGFyZSBub3QgY2xvbmluZyBURk8g ZnVuY3Rpb25hbGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBtaWdodCBhY3R1YWxseSBiZSBPSy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9lPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_787AE7BB302AE849A7480A190F8B933009E539A3OPEXCLILMA3corp_-- From nobody Wed Apr 26 10:35:15 2017 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 DFDA81294F9 for ; Wed, 26 Apr 2017 10:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tlu6tlELE6s for ; Wed, 26 Apr 2017 10:34:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E683D131513 for ; Wed, 26 Apr 2017 10:34:40 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3QHY9tf025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 10:34:10 -0700 (PDT) To: mohamed.boucadair@orange.com Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 26 Apr 2017 10:34:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------320F7C8F6A65801719233CC0" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:35:00 -0000 This is a multi-part message in MIME format. --------------320F7C8F6A65801719233CC0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Med, On 4/26/2017 12:11 AM, mohamed.boucadair@orange.com wrote: > ... > > Trying to create standards to patch the broken idea of a NAT and make > it less interfering with existing protocols is not the same thing as > standardizing the NAT itself. > > [Med] NAT64 (RFC6146) is not a patch AFAIK. > IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy. > > The IETF has also a "Standards Track" document called SOCKSv5 > (RFC1928) that is splitting the TCP connection. We are adhering to the > logic of that RFC but without the drawbacks of SOCKS. > > > > Can you clarify where you see split TCP in RFC1928, > > [Med] I don’t see “split TCP†in RFC1928 in the same way I don’t see > “split TCP†in the plain-mode draft. > Nothing in RFC1929 talks about translating SYNs - it doesn't even mention specific TCP segments at all, but refers only to the standard TCP API, where user data would be available only after the 3WHS between the client and the SOCKS proxy. Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN generating an outgoing SYN before the client SYN/ACK is returned. You don't mention split-TCP (and it has taken more than too long to figure out that's what's going on here), but that is what you show. > > or are you confusing it with this, which adds split TCP to a SOCKS proxy: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf > > > > [Med] Bingo. That is exactly my point. We need to avoid mixing > implementation details with base specifications. That is exactly the > reason why I said earlier that mptcp proxy documents only describe the > external behavior. > OK, so keep ALL discussions of SYN (or any segment translation) out of this document - including the figures. If you can explain this using the existing TCP API, e.g., OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure. But nowhere in that API does TCP tell you when a SYN arrives *before* sending a SYN-ACK. ----- As to your TFO argument, the problem is this: - what happens to the first MPTCP connection from proxy to proxy? why do you treat this differently than a typical MPTCP, and what information lets you do so? I don't see anything in this doc that qualifies as what TFO calls either a cookie between sessions or any substitute based on authentication or authorization. I agree that you're not strictly cloning TFO - IMO, you're trying to reinvent TFO without leveraging the experience the community has developed in that process, and IMO you're repeating some of the mistakes on that journey. Joe --------------320F7C8F6A65801719233CC0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Med,


On 4/26/2017 12:11 AM, mohamed.boucadair@orange.com wrote:
...

Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.

[Med] NAT64 (RFC6146) is not a patch AFAIK.

IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy.


The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

 

Can you clarify where you see split TCP in RFC1928,

[Med] I don’t see “split TCP†in RFC1928 in the same way I don’t see “split TCP†in the plain-mode draft.

Nothing in RFC1929 talks about translating SYNs - it doesn't even mention specific TCP segments at all, but refers only to the standard TCP API, where user data would be available only after the 3WHS between the client and the SOCKS proxy.

Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN generating an outgoing SYN before the client SYN/ACK is returned. You don't mention split-TCP (and it has taken more than too long to figure out that's what's going on here), but that is what you show.

or are you confusing it with this, which adds split TCP to a SOCKS proxy:

 

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.

OK, so keep ALL discussions of SYN (or any segment translation) out of this document - including the figures.

If you can explain this using the existing TCP API, e.g., OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.

But nowhere in that API does TCP tell you when a SYN arrives *before* sending a SYN-ACK.

-----
As to your TFO argument, the problem is this:

    - what happens to the first MPTCP connection from proxy to proxy?
            why do you treat this differently than a typical MPTCP, and what information lets you do so?

I don't see anything in this doc that qualifies as what TFO calls either a cookie between sessions or any substitute based on authentication or authorization.

I agree that you're not strictly cloning TFO - IMO, you're trying to reinvent TFO without leveraging the experience the community has developed in that process, and IMO you're repeating some of the mistakes on that journey.

Joe

--------------320F7C8F6A65801719233CC0-- From nobody Wed Apr 26 23:54:04 2017 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 A41D9126C25 for ; Wed, 26 Apr 2017 23:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhexvnWBYWOQ for ; Wed, 26 Apr 2017 23:53:59 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6A01294CF for ; Wed, 26 Apr 2017 23:53:59 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id B431A1204E9; Thu, 27 Apr 2017 08:53:57 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.63]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 8BCD0180065; Thu, 27 Apr 2017 08:53:57 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM3F.corporate.adroot.infra.ftgroup ([fe80::e857:81f3:3859:a5de%21]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 08:53:57 +0200 From: To: Joe Touch CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSvrNkxyRUG64+RkCrxHrjpOgwSKHYr/4w Date: Thu, 27 Apr 2017 06:53:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5B470OPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 06:54:03 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E5B470OPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9l IFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCkVudm95w6kgOiBtZXJjcmVkaSAyNiBhdnJp bCAyMDE3IDE5OjM0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogcGhpbGlw LmVhcmRsZXlAYnQuY29tOyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFttdWx0 aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoN Cg0KTWVkLA0KDQpPbiA0LzI2LzIwMTcgMTI6MTEgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KLi4uDQpU cnlpbmcgdG8gY3JlYXRlIHN0YW5kYXJkcyB0byBwYXRjaCB0aGUgYnJva2VuIGlkZWEgb2YgYSBO QVQgYW5kIG1ha2UgaXQgbGVzcyBpbnRlcmZlcmluZyB3aXRoIGV4aXN0aW5nIHByb3RvY29scyBp cyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgc3RhbmRhcmRpemluZyB0aGUgTkFUIGl0c2VsZi4NCltN ZWRdIE5BVDY0IChSRkM2MTQ2KSBpcyBub3QgYSBwYXRjaCBBRkFJSy4NCklNTywgaXQgaXMgLSBp dCdzIGEgcGF0Y2ggdG8gaGVscCBzdXBwb3J0IHRoZSBkZXByZWNhdGlvbiBvZiBJUHY0IGluIHRo ZSBnbG9iYWwgSW50ZXJuZXQuIEkgZG9uJ3Qgc2VlIHRoYXQgYXMgdGhlIHJvbGUgZm9yIGFuIE1Q VENQIHByb3h5Lg0KW01lZF0gVGhlIG1haW4gcG9pbnQgSm9lIGlzIHRoYXQgdGhlIElFVEYgaGFz IHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50cyB0aGF0IHNwZWNpZnkgYSBUQ1Agc3RhdGUgbWFjaGlu ZSB3aGVuIE5BVCBpcyB1c2VkLiBXZSBhcmUgbGV2ZXJhZ2luZyB0aGF0IHN0YXRlIG1hY2hpbmUg Zm9yIHRoZSBNUFRDUCBwcm94eSB3b3JrLg0KDQoNCg0KVGhlIElFVEYgaGFzIGFsc28gYSAiU3Rh bmRhcmRzIFRyYWNrIiBkb2N1bWVudCBjYWxsZWQgU09DS1N2NSAoUkZDMTkyOCkgdGhhdCBpcyBz cGxpdHRpbmcgdGhlIFRDUCBjb25uZWN0aW9uLiBXZSBhcmUgYWRoZXJpbmcgdG8gdGhlIGxvZ2lj IG9mIHRoYXQgUkZDIGJ1dCB3aXRob3V0IHRoZSBkcmF3YmFja3Mgb2YgU09DS1MuDQoNCkNhbiB5 b3UgY2xhcmlmeSB3aGVyZSB5b3Ugc2VlIHNwbGl0IFRDUCBpbiBSRkMxOTI4LA0KW01lZF0gSSBk b27igJl0IHNlZSDigJxzcGxpdCBUQ1DigJ0gaW4gUkZDMTkyOCBpbiB0aGUgc2FtZSB3YXkgSSBk b27igJl0IHNlZSDigJxzcGxpdCBUQ1DigJ0gaW4gdGhlIHBsYWluLW1vZGUgZHJhZnQuDQpOb3Ro aW5nIGluIFJGQzE5MjkgdGFsa3MgYWJvdXQgdHJhbnNsYXRpbmcgU1lOcw0KW01lZF0gSSBndWVz cyB5b3UgbWVhbnQgUkZDMTkyOC4gVHJhbnNsYXRpbmcgcGFja2V0cyBpcyBub3QgZXhwbGljaXRl ZCBpbiB0aGUgdGV4dCwgYnV0IGl0IGlzIGhpbnRlZC4gRm9yIGV4YW1wbGUsIHRoZSB0ZXh0IHNh eXMgdGhlIGZvbGxvd2luZzoNCg0KICAgV2hlbiBhIFRDUC1iYXNlZCBjbGllbnQgd2lzaGVzIHRv IGVzdGFibGlzaCBhIGNvbm5lY3Rpb24gdG8gYW4gb2JqZWN0DQogICB0aGF0IGlzIHJlYWNoYWJs ZSBvbmx5IHZpYSBhIGZpcmV3YWxsIChzdWNoIGRldGVybWluYXRpb24gaXMgbGVmdCB1cA0KICAg dG8gdGhlIGltcGxlbWVudGF0aW9uKSwgaXQgbXVzdCBvcGVuIGEgVENQIGNvbm5lY3Rpb24gdG8g dGhlDQogICBhcHByb3ByaWF0ZSBTT0NLUyBwb3J0IG9uIHRoZSBTT0NLUyBzZXJ2ZXIgc3lzdGVt Lg0KDQpIb3cgYSBjb25uZWN0aW9uIGZyb20gYSBjbGllbnQgdG8gYSBzZXJ2ZXIgd2l0aCBEU1RA PVNPQ0tTX1Byb3h5IHdpbGwgYmUgcmVsYXllZCB0byB0aGF0IHJlbW90ZSBzZXJ2ZXIgd2l0aG91 dCBnbHVpbmcgY29ubmVjdGlvbnMgaW4gYm90aCBzaWRlcz8gVGhhdCDigJxnbHVl4oCdIGNhbiBi ZSBzZWVuIGFzIHRyYW5zbGF0aW5nIHBhY2tldHMgYnkgbWVhbnMgb2YgU05BVC9ETkFULg0KDQoo c2lkZSBub3RlOiBJ4oCZbSBzdXJlIHRoYXQgUkZDMTkyOCB3aWxsIG5ldmVyIGJlIHB1Ymxpc2hl ZCBhcyBpdCBpcyBpbiAyMDE3LiBJIGhlYXIgZnJvbSBoZXJlIHBlb3BsZSB0aGF0IHdpbGwgYXJn dWUgdGhhdCBSRkMxOTI4IGlzIHVuZGVyc3BlY2lmaWVkKQ0KDQotIGl0IGRvZXNuJ3QgZXZlbiBt ZW50aW9uIHNwZWNpZmljIFRDUCBzZWdtZW50cyBhdCBhbGwsIGJ1dCByZWZlcnMgb25seSB0byB0 aGUgc3RhbmRhcmQgVENQIEFQSSwgd2hlcmUgdXNlciBkYXRhIHdvdWxkIGJlIGF2YWlsYWJsZSBv bmx5IGFmdGVyIHRoZSAzV0hTIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIFNPQ0tTIHByb3h5 Lg0KW01lZF0gVGhhdOKAmXMgYWxzbyB0aGUgY2FzZSBmb3IgdGhlIE1QVENQIHByb3h5LiBUaGUg dXNlciBkYXRhIHdpbGwgYmUgYXZhaWxhYmxlIE9OTFkgb25jZSB0aGUgM1dIUyBpcyBjb21wbGV0 ZWQuDQoNCkZpZ3VyZSA1IG9mIFNlYyA1LjIgb2YgeW91ciBkb2N1bWVudCBjbGVhcmx5IHNob3dz IGFuIGluY29taW5nIFNZTiBnZW5lcmF0aW5nIGFuIG91dGdvaW5nIFNZTiBiZWZvcmUgdGhlIGNs aWVudCBTWU4vQUNLIGlzIHJldHVybmVkLiBZb3UgZG9uJ3QgbWVudGlvbiBzcGxpdC1UQ1AgKGFu ZCBpdCBoYXMgdGFrZW4gbW9yZSB0aGFuIHRvbyBsb25nIHRvIGZpZ3VyZSBvdXQgdGhhdCdzIHdo YXQncyBnb2luZyBvbiBoZXJlKSwgYnV0IHRoYXQgaXMgd2hhdCB5b3Ugc2hvdy4NCm9yIGFyZSB5 b3UgY29uZnVzaW5nIGl0IHdpdGggdGhpcywgd2hpY2ggYWRkcyBzcGxpdCBUQ1AgdG8gYSBTT0NL UyBwcm94eToNCmh0dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3dubG9hZD9k b2k9MTAuMS4xLjM0Ljk5MTUmcmVwPXJlcDEmdHlwZT1wZGYNCg0KW01lZF0gQmluZ28uIFRoYXQg aXMgZXhhY3RseSBteSBwb2ludC4gV2UgbmVlZCB0byBhdm9pZCBtaXhpbmcgaW1wbGVtZW50YXRp b24gZGV0YWlscyB3aXRoIGJhc2Ugc3BlY2lmaWNhdGlvbnMuIFRoYXQgaXMgZXhhY3RseSB0aGUg cmVhc29uIHdoeSBJIHNhaWQgZWFybGllciB0aGF0IG1wdGNwIHByb3h5IGRvY3VtZW50cyBvbmx5 IGRlc2NyaWJlIHRoZSBleHRlcm5hbCBiZWhhdmlvci4NCk9LLCBzbyBrZWVwIEFMTCBkaXNjdXNz aW9ucyBvZiBTWU4gKG9yIGFueSBzZWdtZW50IHRyYW5zbGF0aW9uKSBvdXQgb2YgdGhpcyBkb2N1 bWVudCAtIGluY2x1ZGluZyB0aGUgZmlndXJlcy4NCltNZWRdIEnigJltIHBlcnNvbmFsbHkgZmlu ZSB3aXRoIHlvdXIgcHJvcG9zYWwsIGJ1dCBJ4oCZbSBzdXJlIHdlIHdpbGwgaGF2ZSBhIGxvdCBv ZiBjb21tZW50cyBhc2tpbmcgZm9yIG1vcmUgZGV0YWlscy4gRmlndXJlcyBhcmUgbm90IG5vcm1h dGl2ZTsgdGhleSBhcmUgcHJvdmlkZWQgZm9yIGlsbHVzdHJhdGlvbiBwdXJwb3Nlcy4NCg0KSWYg eW91IGNhbiBleHBsYWluIHRoaXMgdXNpbmcgdGhlIGV4aXN0aW5nIFRDUCBBUEksIGUuZy4sIE9Q RU4vQ0xPU0UvQUJPUlQvU1RBVFVTIGFuZCBTRU5EL1JFQ0VJVkUgKFJGQzc5MyBTZWMgMy45KSwg dGhlbiBzdXJlLg0KDQpCdXQgbm93aGVyZSBpbiB0aGF0IEFQSSBkb2VzIFRDUCB0ZWxsIHlvdSB3 aGVuIGEgU1lOIGFycml2ZXMgKmJlZm9yZSogc2VuZGluZyBhIFNZTi1BQ0suDQoNCi0tLS0tDQpB cyB0byB5b3VyIFRGTyBhcmd1bWVudCwgdGhlIHByb2JsZW0gaXMgdGhpczoNCg0KICAgIC0gd2hh dCBoYXBwZW5zIHRvIHRoZSBmaXJzdCBNUFRDUCBjb25uZWN0aW9uIGZyb20gcHJveHkgdG8gcHJv eHk/DQpbTWVkXSBEbyB5b3UgbWVhbiB0aGUgZmlyc3QgTVBUQ1AgY29ubmVjdGlvbiB0aGF0IGlz IHByb3hpZWQ/IE9yIHRoZSBmaXJzdCBzdWJmbG93IG9mIGEgcHJveGllZCBNUFRDUCBjb25uZWN0 aW9uPw0KDQogICAgICAgICAgICB3aHkgZG8geW91IHRyZWF0IHRoaXMgZGlmZmVyZW50bHkgdGhh biBhIHR5cGljYWwgTVBUQ1AsIGFuZCB3aGF0IGluZm9ybWF0aW9uIGxldHMgeW91IGRvIHNvPw0K W01lZF0gQ2FuIHlvdSBwbGVhc2UgZXhwbGljaXQgeW91ciBxdWVzdGlvbj8gQXJlIHlvdSByZWZl cnJpbmcgdG8gYSBtdWx0aXBhdGggY2xpZW50LCBtdWx0aXBhdGggc2VydmVyLCBvciBwcm94eT8N Cg0KLSAgICBObyBjaGFuZ2UgaXMgcmVxdWlyZWQgZm9yIE1QVENQLXVuYXdhcmUgY2xpZW50cyBh bmQgc2VydmVycy4NCg0KLSAgICBNUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBz ZXJ2ZXIgZm9sbG93cyB0aGUgYmFzZSBNUFRDUCBzcGVjaWZpY2F0aW9uLg0KDQotICAgIE1QVENQ IHByb2Nlc3NpbmcgYXQgdGhlIE1QVENQLWF3YXJlIGNsaWVudCBpbiB0aGUgZHVhbC1wcm94eSBj YXNlIGZvbGxvd3MgdGhlIGJhc2UgTVBUQ1Agc3BlY2lmaWNhdGlvbi4NCg0KLSAgICBNUFRDUCBw cm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBjbGllbnQgaW4gdGhlIHNpbmdsZS1wcm94eSBj YXNlIHdpbGwgcmVxdWlyZSB0byBzdXBwbHkgdGhlIE1QX0NPTlZFUlQgaW4gdGhlIGluaXRpYWwg c3ViZmxvdy4gQSBwYXJ0IGZyb20gdGhhdCwgaXQgZm9sbG93cyB0aGUgYmFzZSBNUFRDUCBzcGVj aWZpY2F0aW9uLg0KDQotICAgTVBUQ1AgcHJvY2Vzc2luZyBhdCB0aGUgcHJveHkgd2lsbCByZXF1 aXJlIHRvIHByb2Nlc3MgdGhlIE1QX0NPTlZFUlQgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gY3Jl YXRlIGEgZm9yd2FyZGluZyBzdGF0ZSBmb3IgdGhhdCBNUFRDUCBjb25uZWN0aW9uLiBBIHBhcnQg ZnJvbSB0aGF0LCBpdCBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNpZmljYXRpb24uDQoNCkkg ZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoaXMgZG9jIHRoYXQgcXVhbGlmaWVzIGFzIHdoYXQgVEZP IGNhbGxzIGVpdGhlciBhIGNvb2tpZSBiZXR3ZWVuIHNlc3Npb25zIG9yIGFueSBzdWJzdGl0dXRl IGJhc2VkIG9uIGF1dGhlbnRpY2F0aW9uIG9yIGF1dGhvcml6YXRpb24uDQpbTWVkXSBJIGFscmVh ZHkgcHJvdmlkZWQgYSBwb2ludGVyIHRvIHRoZSBzbGlkZXMgd2hlcmUgdGhpcyBpcyBkaXNjdXNz ZWQuIFlvdSBjYW4gYWxzbyByZWZlciB0byBkcmFmdC1uYW0tbXB0Y3AtZGVwbG95bWVudC1jb25z aWRlcmF0aW9ucy0wMSNzZWN0aW9uLTUuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbmFtLW1wdGNwLWRlcGxveW1lbnQtY29uc2lkZXJhdGlvbnMtMDEjc2VjdGlvbi01LjM+Og0K DQogICBUaGUgTmV0d29yayBQcm92aWRlciB0aGF0IG1hbmFnZXMgdGhlIHZhcmlvdXMgbmV0d29y ayBhdHRhY2htZW50cw0KICAgKGluY2x1ZGluZyB0aGUgTUNQcykgbWF5IGVuZm9yY2UgYXV0aGVu dGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24NCiAgIHBvbGljaWVzIHVzaW5nIGFwcHJvcHJpYXRl IG1lY2hhbmlzbXMuICBGb3IgZXhhbXBsZSwgYSBub24tZXhoYXVzdGl2ZQ0KICAgbGlzdCBvZiBt ZXRob2RzIHRvIGFjaGlldmUgYXV0aG9yaXphdGlvbiBpcyBwcm92aWRlZCBoZXJlYWZ0ZXI6DQoN CiAgIG8gIFRoZSBuZXR3b3JrIHByb3ZpZGVyIG1heSBlbmZvcmNlIGEgcG9saWN5IGJhc2VkIG9u IHRoZQ0KICAgICAgSW50ZXJuYXRpb25hbCBNb2JpbGUgU3Vic2NyaWJlciBJZGVudGl0eSAoSU1T SSkgdG8gdmVyaWZ5IHRoYXQgYQ0KICAgICAgdXNlciBpcyBhbGxvd2VkIHRvIGJlbmVmaXQgZnJv bSB0aGUgYWdncmVnYXRpb24gc2VydmljZS4gIElmIHRoYXQNCiAgICAgIGF1dGhvcml6YXRpb24g ZmFpbHMsIHRoZSBQYWNrZXQgRGF0YSBQcm90b2NvbCAoUERQKSBjb250ZXh0DQogICAgICAvYmVh cmVyIHdpbGwgbm90IGJlIG1vdW50ZWQuICBUaGlzIG1ldGhvZCBkb2VzIG5vdCByZXF1aXJlIGFu eQ0KICAgICAgaW50ZXJhY3Rpb24gd2l0aCB0aGUgTUNQLg0KDQogICBvICBUaGUgbmV0d29yayBw cm92aWRlciBtYXkgZW5mb3JjZSBhIHBvbGljeSBiYXNlZCB1cG9uIEFjY2Vzcw0KICAgICAgQ29u dHJvbCBMaXN0cyAoQUNMcyksIGUuZy4sIGF0IGEgQnJvYWRiYW5kIE5ldHdvcmsgR2F0ZXdheSAo Qk5HKQ0KICAgICAgdG8gY29udHJvbCB0aGUgQ1BFcyB0aGF0IGFyZSBhdXRob3JpemVkIHRvIGNv bW11bmljYXRlIHdpdGggYW4NCiAgICAgIE1DUC4gIFRoZXNlIEFDTHMgbWF5IGJlIGluc3RhbGxl ZCBhcyBhIHJlc3VsdCBvZiBSQURJVVMgZXhjaGFuZ2VzLA0KICAgICAgZm9yIGluc3RhbmNlIChb SS1ELmJvdWNhZGFpci1tcHRjcC1yYWRpdXM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW5hbS1tcHRjcC1kZXBsb3ltZW50LWNvbnNpZGVyYXRpb25zLTAxI3JlZi1JLUQuYm91Y2Fk YWlyLW1wdGNwLXJhZGl1cz5dKS4gIFRoaXMgbWV0aG9kIGRvZXMgbm90DQogICAgICByZXF1aXJl IGFueSBpbnRlcmFjdGlvbiB3aXRoIHRoZSBNQ1AuDQoNCiAgIG8gIFRoZSBNQ1AgbWF5IGltcGxl bWVudCBhbiBJZGVudCBpbnRlcmZhY2UgW1JGQzE0MTM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzE0MTM+XSB0byByZXRyaWV2ZSBhbg0KICAgICAgaWRlbnRpZmllciB0aGF0IHdpbGwg YmUgdXNlZCB0byBhc3Nlc3Mgd2hldGhlciB0aGF0IGNsaWVudCBpcw0KICAgICAgZW50aXRsZWQg dG8gbWFrZSB1c2Ugb2YgdGhlIGFnZ3JlZ2F0aW9uIHNlcnZpY2UuICBJZGVudCBleGNoYW5nZXMN CiAgICAgIHdpbGwgdGFrZSBwbGFjZSBvbmx5IHdoZW4gcmVjZWl2aW5nIHRoZSBmaXJzdCBzdWJm bG93IGZyb20gYSBnaXZlbg0KICAgICAgc291cmNlIElQIGFkZHJlc3MuDQoNCiAgIG8gIFRoZSBk ZXZpY2UgdGhhdCBlbWJlZHMgdGhlIE1DUCBtYXkgYWxzbyBob3N0IGEgUkFESVVTIGNsaWVudCB0 aGF0DQogICAgICB3aWxsIHNvbGljaXQgYW4gQUFBIHNlcnZlciB0byBjaGVjayB3aGV0aGVyIGNv bm5lY3Rpb25zIHJlY2VpdmVkDQogICAgICBmcm9tIGEgZ2l2ZW4gc291cmNlIElQIGFkZHJlc3Mg YXJlIGF1dGhvcml6ZWQgb3Igbm90DQogICAgICAoW0ktRC5ib3VjYWRhaXItbXB0Y3AtcmFkaXVz PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uYW0tbXB0Y3AtZGVwbG95bWVudC1j b25zaWRlcmF0aW9ucy0wMSNyZWYtSS1ELmJvdWNhZGFpci1tcHRjcC1yYWRpdXM+XSkuDQoNCg0K SSBhZ3JlZSB0aGF0IHlvdSdyZSBub3Qgc3RyaWN0bHkgY2xvbmluZyBURk8gLSBJTU8sIHlvdSdy ZSB0cnlpbmcgdG8gcmVpbnZlbnQgVEZPIHdpdGhvdXQgbGV2ZXJhZ2luZyB0aGUgZXhwZXJpZW5j ZSB0aGUgY29tbXVuaXR5IGhhcyBkZXZlbG9wZWQgaW4gdGhhdCBwcm9jZXNzLCBhbmQgSU1PIHlv dSdyZSByZXBlYXRpbmcgc29tZSBvZiB0aGUgbWlzdGFrZXMgb24gdGhhdCBqb3VybmV5Lg0KW01l ZF0gSSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRoaXMuIFdlIGFyZSBsZXZlcmFnaW5nIG9uIHRo ZSBndWFyZHMgYXMgZGlzY3Vzc2VkIGluIFRGTyBzcGVjaWZpY2F0aW9uOg0KDQotICAgIEFudGkt c3Bvb2ZpbmcgZmlsdGVycyBhcmUgaW4gcGxhY2UgaW4gdGhlIGFjY2VzcyBzZWdtZW50Lg0KDQot ICAgVEZPIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGEgY29va2llLWxlc3Mgc2NoZW1lIGlmIHRo ZSBzZXJ2ZXIgaXMgaW1tdW5lLg0KDQpKb2UNCg0K --_000_787AE7BB302AE849A7480A190F8B933009E5B470OPEXCNORMADcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291 cmllciBOZXcgXDtjb2xvclw6YmxhY2siOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N CnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRN TCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZv cm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5ncmV5DQoJ e21zby1zdHlsZS1uYW1lOmdyZXk7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjA0NDYwMDQwOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg3OTc3MTU2NCAt MTIzNDUyMTQxMCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2 Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA 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 eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjE2NDg5Nzc0OTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjc4NDYyNDM0MCAyMDMzMTczNDYgNjc4OTUyOTkgNjc4OTUzMDEgNjc4 OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBKb2UsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBp c2kuZWR1XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI2IGF2cmlsIDIw MTcgMTk6MzQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48 YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTsgbXVsdGlwYXRodGNw QGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW211bHRpcGF0aHRjcF0gQ29u c2Vuc3VzIGNhbGwgb24gcG90ZW50aWFsIE1QVENQIHByb3h5IHdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD5NZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA0LzI2 LzIwMTcgMTI6MTEgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLiA8bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJ5 aW5nIHRvIGNyZWF0ZSBzdGFuZGFyZHMgdG8gcGF0Y2ggdGhlIGJyb2tlbiBpZGVhIG9mIGEgTkFU IGFuZCBtYWtlIGl0IGxlc3MgaW50ZXJmZXJpbmcgd2l0aCBleGlzdGluZyBwcm90b2NvbHMgaXMg bm90IHRoZSBzYW1lIHRoaW5nIGFzIHN0YW5kYXJkaXppbmcgdGhlIE5BVCBpdHNlbGYuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7 Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPltNZWRdIE5BVDY0IChSRkM2MTQ2 KSBpcyBub3QgYSBwYXRjaCBBRkFJSy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PLCBpdCBpcyAtIGl0J3MgYSBw YXRjaCB0byBoZWxwIHN1cHBvcnQgdGhlIGRlcHJlY2F0aW9uIG9mIElQdjQgaW4gdGhlIGdsb2Jh bCBJbnRlcm5ldC4gSSBkb24ndCBzZWUgdGhhdCBhcyB0aGUgcm9sZSBmb3IgYW4gTVBUQ1AgcHJv eHkuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRd IFRoZSBtYWluIHBvaW50IEpvZSBpcyB0aGF0IHRoZSBJRVRGIGhhcyBzdGFuZGFyZCB0cmFjayBk b2N1bWVudHMgdGhhdCBzcGVjaWZ5IGEgVENQIHN0YXRlIG1hY2hpbmUgd2hlbiBOQVQgaXMgdXNl ZC4gV2UgYXJlIGxldmVyYWdpbmcgdGhhdCBzdGF0ZSBtYWNoaW5lDQogZm9yIHRoZSBNUFRDUCBw cm94eSB3b3JrLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRG IGhhcyBhbHNvIGEgJnF1b3Q7U3RhbmRhcmRzIFRyYWNrJnF1b3Q7IGRvY3VtZW50IGNhbGxlZCBT T0NLU3Y1IChSRkMxOTI4KSB0aGF0IGlzIHNwbGl0dGluZyB0aGUgVENQIGNvbm5lY3Rpb24uIFdl IGFyZSBhZGhlcmluZyB0bw0KPC9zcGFuPnRoZSBsb2dpYyBvZiB0aGF0IFJGQyBidXQgd2l0aG91 dCB0aGUgZHJhd2JhY2tzIG9mIFNPQ0tTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IGNsYXJpZnkgd2hlcmUgeW91IHNlZSBzcGxp dCBUQ1AgaW4gUkZDMTkyOCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPltNZWRd IEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIFJGQzE5MjggaW4gdGhlIHNhbWUgd2F5 IEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCdIGluIHRoZSBwbGFpbi1tb2RlIGRyYWZ0Lg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5vdGhpbmcgaW4gUkZDMTkyOSB0YWxrcyBhYm91dCB0cmFuc2xhdGluZyBTWU5zPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkgZ3Vlc3Mg eW91IG1lYW50IFJGQzE5MjguIFRyYW5zbGF0aW5nIHBhY2tldHMgaXMgbm90IGV4cGxpY2l0ZWQg aW4gdGhlIHRleHQsIGJ1dCBpdCBpcyBoaW50ZWQuIEZvciBleGFtcGxlLCB0aGUgdGV4dCBzYXlz IHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7IFdoZW4gYSBUQ1AtYmFzZWQgY2xpZW50IHdpc2hl cyB0byBlc3RhYmxpc2ggYSBjb25uZWN0aW9uIHRvIGFuIG9iamVjdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgdGhhdCBpcyByZWFjaGFibGUgb25seSB2aWEgYSBmaXJl d2FsbCAoc3VjaCBkZXRlcm1pbmF0aW9uIGlzIGxlZnQgdXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+Jm5ic3A7Jm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiksIGl0IG11c3Qgb3BlbiBh IFRDUCBjb25uZWN0aW9uIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsm bmJzcDsgYXBwcm9wcmlhdGUgU09DS1MgcG9ydCBvbiB0aGUgU09DS1Mgc2VydmVyIHN5c3RlbS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkhvdyBhIGNvbm5lY3Rpb24gZnJvbSBhIGNsaWVudCB0byBhIHNlcnZlciB3aXRoIERTVEA9U09D S1NfUHJveHkgd2lsbCBiZSByZWxheWVkIHRvIHRoYXQgcmVtb3RlIHNlcnZlciB3aXRob3V0IGds dWluZyBjb25uZWN0aW9ucyBpbiBib3RoIHNpZGVzPyBUaGF0IOKAnGdsdWXigJ0NCiBjYW4gYmUg c2VlbiBhcyB0cmFuc2xhdGluZyBwYWNrZXRzIGJ5IG1lYW5zIG9mIFNOQVQvRE5BVC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4oc2lkZSBub3RlOiBJ4oCZbSBzdXJl IHRoYXQgUkZDMTkyOCB3aWxsIG5ldmVyIGJlIHB1Ymxpc2hlZCBhcyBpdCBpcyBpbiAyMDE3LiBJ IGhlYXIgZnJvbSBoZXJlIHBlb3BsZSB0aGF0IHdpbGwgYXJndWUgdGhhdCBSRkMxOTI4IGlzIHVu ZGVyc3BlY2lmaWVkKSAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4t IGl0IGRvZXNuJ3QgZXZlbiBtZW50aW9uIHNwZWNpZmljIFRDUCBzZWdtZW50cyBhdCBhbGwsIGJ1 dCByZWZlcnMgb25seSB0byB0aGUgc3RhbmRhcmQgVENQIEFQSSwgd2hlcmUgdXNlciBkYXRhIHdv dWxkIGJlIGF2YWlsYWJsZSBvbmx5IGFmdGVyIHRoZSAzV0hTIGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIFNPQ0tTIHByb3h5Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhhdOKAmXMgYWxzbyB0aGUg Y2FzZSBmb3IgdGhlIE1QVENQIHByb3h5LiBUaGUgdXNlciBkYXRhIHdpbGwgYmUgYXZhaWxhYmxl IE9OTFkgb25jZSB0aGUgM1dIUyBpcyBjb21wbGV0ZWQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxicj4NCjxicj4NCkZpZ3VyZSA1IG9mIFNlYyA1LjIgb2YgeW91ciBkb2N1bWVudCBjbGVh cmx5IHNob3dzIGFuIGluY29taW5nIFNZTiBnZW5lcmF0aW5nIGFuIG91dGdvaW5nIFNZTiBiZWZv cmUgdGhlIGNsaWVudCBTWU4vQUNLIGlzIHJldHVybmVkLg0KPC9zcGFuPllvdSBkb24ndCBtZW50 aW9uIHNwbGl0LVRDUCAoYW5kIGl0IGhhcyB0YWtlbiBtb3JlIHRoYW4gdG9vIGxvbmcgdG8gZmln dXJlIG91dCB0aGF0J3Mgd2hhdCdzIGdvaW5nIG9uIGhlcmUpLCBidXQgdGhhdCBpcyB3aGF0IHlv dSBzaG93Lg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciBhcmUgeW91IGNvbmZ1 c2luZyBpdCB3aXRoIHRoaXMsIHdoaWNoIGFkZHMgc3BsaXQgVENQIHRvIGEgU09DS1MgcHJveHk6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cDovL2NpdGVzZWVyeC5pc3QucHN1LmVkdS92aWV3ZG9jL2Rvd25sb2Fk P2RvaT0xMC4xLjEuMzQuOTkxNSZhbXA7cmVwPXJlcDEmYW1wO3R5cGU9cGRmIj5odHRwOi8vY2l0 ZXNlZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2MvZG93bmxvYWQ/ZG9pPTEwLjEuMS4zNC45OTE1JmFt cDtyZXA9cmVwMSZhbXA7dHlwZT1wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPltNZWRdIEJpbmdvLiBUaGF0IGlzIGV4YWN0bHkgbXkgcG9pbnQuIFdlIG5lZWQgdG8g YXZvaWQgbWl4aW5nIGltcGxlbWVudGF0aW9uIGRldGFpbHMgd2l0aCBiYXNlIHNwZWNpZmljYXRp b25zLiBUaGF0IGlzIGV4YWN0bHkgdGhlIHJlYXNvbiB3aHkgSQ0KIHNhaWQgZWFybGllciB0aGF0 IG1wdGNwIHByb3h5IGRvY3VtZW50cyBvbmx5IGRlc2NyaWJlIHRoZSBleHRlcm5hbCBiZWhhdmlv ci4gPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T0ssIHNvIGtlZXAgQUxMIGRpc2N1c3Npb25zIG9mIFNZTiAob3IgYW55IHNlZ21l bnQgdHJhbnNsYXRpb24pIG91dCBvZiB0aGlzIGRvY3VtZW50IC0gaW5jbHVkaW5nIHRoZSBmaWd1 cmVzLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBJ4oCZbSBwZXJzb25hbGx5IGZpbmUgd2l0aCB5b3VyIHByb3Bvc2FsLCBidXQgSeKAmW0gc3Vy ZSB3ZSB3aWxsIGhhdmUgYSBsb3Qgb2YgY29tbWVudHMgYXNraW5nIGZvciBtb3JlIGRldGFpbHMu IEZpZ3VyZXMgYXJlIG5vdCBub3JtYXRpdmU7IHRoZXkgYXJlIHByb3ZpZGVkDQogZm9yIGlsbHVz dHJhdGlvbiBwdXJwb3Nlcy4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpJ ZiB5b3UgY2FuIGV4cGxhaW4gdGhpcyB1c2luZyB0aGUgZXhpc3RpbmcgVENQIEFQSSwgZS5nLiwg T1BFTi9DTE9TRS9BQk9SVC9TVEFUVVMgYW5kIFNFTkQvUkVDRUlWRSAoUkZDNzkzIFNlYyAzLjkp LCB0aGVuIHN1cmUuPGJyPg0KPGJyPg0KQnV0IG5vd2hlcmUgaW4gdGhhdCBBUEkgZG9lcyBUQ1Ag dGVsbCB5b3Ugd2hlbiBhIFNZTiBhcnJpdmVzICpiZWZvcmUqIHNlbmRpbmcgYSBTWU4tQUNLLjxi cj4NCjxicj4NCjwvc3Bhbj4tLS0tLTxicj4NCkFzIHRvIHlvdXIgVEZPIGFyZ3VtZW50LCB0aGUg cHJvYmxlbSBpcyB0aGlzOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtIHdoYXQgaGFw cGVucyB0byB0aGUgZmlyc3QgTVBUQ1AgY29ubmVjdGlvbiBmcm9tIHByb3h5IHRvIHByb3h5Pzxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBEbyB5 b3UgbWVhbiB0aGUgZmlyc3QgTVBUQ1AgY29ubmVjdGlvbiB0aGF0IGlzIHByb3hpZWQ/IE9yIHRo ZSBmaXJzdCBzdWJmbG93IG9mIGEgcHJveGllZCBNUFRDUCBjb25uZWN0aW9uPw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7IHdoeSBkbyB5b3UgdHJlYXQgdGhpcyBkaWZmZXJlbnRseSB0aGFuIGEgdHlwaWNhbCBNUFRD UCwgYW5kIHdoYXQgaW5mb3JtYXRpb24gbGV0cyB5b3UgZG8gc28/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g Q2FuIHlvdSBwbGVhc2UgZXhwbGljaXQgeW91ciBxdWVzdGlvbj8gQXJlIHlvdSByZWZlcnJpbmcg dG8gYSBtdWx0aXBhdGggY2xpZW50LCBtdWx0aXBhdGggc2VydmVyLCBvciBwcm94eT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5ObyBjaGFuZ2UgaXMgcmVxdWly ZWQgZm9yIE1QVENQLXVuYXdhcmUgY2xpZW50cyBhbmQgc2VydmVycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRD UC1hd2FyZSBzZXJ2ZXIgZm9sbG93cyB0aGUgYmFzZSBNUFRDUCBzcGVjaWZpY2F0aW9uLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TVBUQ1AgcHJvY2Vzc2lu ZyBhdCB0aGUgTVBUQ1AtYXdhcmUgY2xpZW50IGluIHRoZSBkdWFsLXByb3h5IGNhc2UgZm9sbG93 cyB0aGUgYmFzZSBNUFRDUCBzcGVjaWZpY2F0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TVBUQ1AgcHJvY2Vzc2luZyBhdCB0aGUgTVBUQ1AtYXdhcmUg Y2xpZW50IGluIHRoZSBzaW5nbGUtcHJveHkgY2FzZSB3aWxsIHJlcXVpcmUgdG8gc3VwcGx5IHRo ZSBNUF9DT05WRVJUIGluIHRoZSBpbml0aWFsIHN1YmZsb3cuIEEgcGFydCBmcm9tIHRoYXQsDQog aXQgZm9sbG93cyB0aGUgYmFzZSBNUFRDUCBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5NUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBwcm94eSB3aWxsIHJlcXVpcmUgdG8gcHJvY2Vz cyB0aGUgTVBfQ09OVkVSVCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBjcmVhdGUgYSBmb3J3YXJk aW5nIHN0YXRlIGZvciB0aGF0IE1QVENQIGNvbm5lY3Rpb24uDQogQSBwYXJ0IGZyb20gdGhhdCwg aXQgZm9sbG93cyB0aGUgYmFzZSBNUFRDUCBzcGVjaWZpY2F0aW9uLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyPg0KSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhpcyBkb2MgdGhh dCBxdWFsaWZpZXMgYXMgd2hhdCBURk8gY2FsbHMgZWl0aGVyIGEgY29va2llIGJldHdlZW4gc2Vz c2lvbnMgb3IgYW55IHN1YnN0aXR1dGUgYmFzZWQgb24gYXV0aGVudGljYXRpb24gb3IgYXV0aG9y aXphdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJIGFscmVhZHkgcHJvdmlkZWQgYSBwb2ludGVyIHRv IHRoZSBzbGlkZXMgd2hlcmUgdGhpcyBpcyBkaXNjdXNzZWQuIFlvdSBjYW4gYWxzbyByZWZlciB0 bw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5hbS1tcHRjcC1k ZXBsb3ltZW50LWNvbnNpZGVyYXRpb25zLTAxI3NlY3Rpb24tNS4zIj4NCmRyYWZ0LW5hbS1tcHRj cC1kZXBsb3ltZW50LWNvbnNpZGVyYXRpb25zLTAxI3NlY3Rpb24tNS4zPC9hPjogPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNw OyZuYnNwOyBUaGUgTmV0d29yayBQcm92aWRlciB0aGF0IG1hbmFnZXMgdGhlIHZhcmlvdXMgbmV0 d29yayBhdHRhY2htZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsg KGluY2x1ZGluZyB0aGUgTUNQcykgbWF5IGVuZm9yY2UgYXV0aGVudGljYXRpb24gYW5kIGF1dGhv cml6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7IHBvbGljaWVz IHVzaW5nIGFwcHJvcHJpYXRlIG1lY2hhbmlzbXMuJm5ic3A7IEZvciBleGFtcGxlLCBhIG5vbi1l eGhhdXN0aXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBsaXN0IG9m IG1ldGhvZHMgdG8gYWNoaWV2ZSBhdXRob3JpemF0aW9uIGlzIHByb3ZpZGVkIGhlcmVhZnRlcjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBuZXR3b3JrIHByb3ZpZGVyIG1heSBlbmZvcmNl IGEgcG9saWN5IGJhc2VkIG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJuYXRpb25hbCBNb2JpbGUgU3Vic2NyaWJlciBJ ZGVudGl0eSAoSU1TSSkgdG8gdmVyaWZ5IHRoYXQgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlciBpcyBhbGxvd2VkIHRvIGJlbmVm aXQgZnJvbSB0aGUgYWdncmVnYXRpb24gc2VydmljZS4mbmJzcDsgSWYgdGhhdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aG9yaXph dGlvbiBmYWlscywgdGhlIFBhY2tldCBEYXRhIFByb3RvY29sIChQRFApIGNvbnRleHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9iZWFy ZXIgd2lsbCBub3QgYmUgbW91bnRlZC4mbmJzcDsgVGhpcyBtZXRob2QgZG9lcyBub3QgcmVxdWly ZSBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGludGVyYWN0aW9uIHdpdGggdGhlIE1DUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7 IFRoZSBuZXR3b3JrIHByb3ZpZGVyIG1heSBlbmZvcmNlIGEgcG9saWN5IGJhc2VkIHVwb24gQWNj ZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDb250cm9sIExpc3RzIChBQ0xzKSwgZS5nLiwgYXQgYSBCcm9hZGJhbmQgTmV0d29yayBH YXRld2F5IChCTkcpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0byBjb250cm9sIHRoZSBDUEVzIHRoYXQgYXJlIGF1dGhvcml6ZWQgdG8g Y29tbXVuaWNhdGUgd2l0aCBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTUNQLiZuYnNwOyBUaGVzZSBBQ0xzIG1heSBiZSBpbnN0YWxs ZWQgYXMgYSByZXN1bHQgb2YgUkFESVVTIGV4Y2hhbmdlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBpbnN0YW5jZSAoWzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbmFtLW1wdGNwLWRlcGxveW1lbnQtY29uc2lkZXJhdGlvbnMtMDEjcmVm LUktRC5ib3VjYWRhaXItbXB0Y3AtcmFkaXVzIj48c3BhbiBsYW5nPSJFTi1VUyI+SS1ELmJvdWNh ZGFpci1tcHRjcC1yYWRpdXM8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+XSkuJm5ic3A7DQogVGhpcyBtZXRob2QgZG9lcyBub3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVp cmUgYW55IGludGVyYWN0aW9uIHdpdGggdGhlIE1DUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7 IFRoZSBNQ1AgbWF5IGltcGxlbWVudCBhbiBJZGVudCBpbnRlcmZhY2UgWzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMTQxMyIgdGl0bGU9IiZxdW90O0lkZW50aWZpY2F0aW9uIFByb3RvY29sJnF1b3Q7Ij48c3Bh biBsYW5nPSJFTi1VUyI+UkZDMTQxMzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5dDQogdG8gcmV0cmlldmUgYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZpZXIgdGhh dCB3aWxsIGJlIHVzZWQgdG8gYXNzZXNzIHdoZXRoZXIgdGhhdCBjbGllbnQgaXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudGl0bGVk IHRvIG1ha2UgdXNlIG9mIHRoZSBhZ2dyZWdhdGlvbiBzZXJ2aWNlLiZuYnNwOyBJZGVudCBleGNo YW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdpbGwgdGFrZSBwbGFjZSBvbmx5IHdoZW4gcmVjZWl2aW5nIHRoZSBmaXJzdCBzdWJm bG93IGZyb20gYSBnaXZlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgc291cmNlIElQIGFkZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgbyZu YnNwOyBUaGUgZGV2aWNlIHRoYXQgZW1iZWRzIHRoZSBNQ1AgbWF5IGFsc28gaG9zdCBhIFJBRElV UyBjbGllbnQgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7d2lsbCBzb2xpY2l0IGFuIEFBQSBzZXJ2ZXIgdG8gY2hlY2sgd2hldGhl ciBjb25uZWN0aW9ucyByZWNlaXZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnJvbSBhIGdpdmVuIHNvdXJjZSBJUCBhZGRyZXNzIGFy ZSBhdXRob3JpemVkIG9yIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5hbS1tcHRjcC1kZXBs b3ltZW50LWNvbnNpZGVyYXRpb25zLTAxI3JlZi1JLUQuYm91Y2FkYWlyLW1wdGNwLXJhZGl1cyI+ PHNwYW4gbGFuZz0iRU4tVVMiPkktRC5ib3VjYWRhaXItbXB0Y3AtcmFkaXVzPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPl0pLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQo8YnI+DQpJIGFncmVlIHRoYXQgeW91J3JlIG5vdCBzdHJpY3RseSBjbG9uaW5nIFRGTyAt IElNTywgeW91J3JlIHRyeWluZyB0byByZWludmVudCBURk8gd2l0aG91dCBsZXZlcmFnaW5nIHRo ZSBleHBlcmllbmNlIHRoZSBjb21tdW5pdHkgaGFzIGRldmVsb3BlZCBpbiB0aGF0IHByb2Nlc3Ms IGFuZCBJTU8geW91J3JlIHJlcGVhdGluZyBzb21lIG9mIHRoZSBtaXN0YWtlcyBvbiB0aGF0IGpv dXJuZXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRoaXMuIFdl IGFyZSBsZXZlcmFnaW5nIG9uIHRoZSBndWFyZHMgYXMgZGlzY3Vzc2VkIGluIFRGTyBzcGVjaWZp Y2F0aW9uOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QW50 aS1zcG9vZmluZyBmaWx0ZXJzIGFyZSBpbiBwbGFjZSBpbiB0aGUgYWNjZXNzIHNlZ21lbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlRGTyBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBhIGNvb2tpZS1sZXNzIHNjaGVtZSBp ZiB0aGUgc2VydmVyIGlzIGltbXVuZS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGJyPg0KSm9lPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009E5B470OPEXCNORMADcorp_-- From nobody Wed Apr 26 23:58:48 2017 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 BCCA3126CF6 for ; Wed, 26 Apr 2017 23:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdZQllfkacAT for ; Wed, 26 Apr 2017 23:58:45 -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 420BE1242F7 for ; Wed, 26 Apr 2017 23:58:44 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 28D8929C510 for ; Thu, 27 Apr 2017 15:58:43 +0900 (JST) Received: by mail-oi0-f53.google.com with SMTP id w12so27304906oiw.3 for ; Wed, 26 Apr 2017 23:58:43 -0700 (PDT) X-Gm-Message-State: AN3rC/6Ko2Xgabm6PT+PPqk5wrAzpriu+N8LUkPUo0SrazfF+jfOpSt7 SzZMPnRQ88YJY9Nyv9jGj6VUh36q1g== X-Received: by 10.202.206.198 with SMTP id e189mr2001840oig.158.1493276320388; Wed, 26 Apr 2017 23:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Wed, 26 Apr 2017 23:58:40 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 26 Apr 2017 23:58:40 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary=001a113d31a6a0e099054e207c72 Archived-At: Subject: [multipathtcp] Some questions for proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 06:58:47 -0000 --001a113d31a6a0e099054e207c72 Content-Type: text/plain; charset=UTF-8 Hello, We've seen active discussions on doing proxy work in the WG. I just would like to clarify several points from simple cases before discussing detailed mechanisms in proxy. Let's say we have end points E1, E2, middle points M1, M2, and we have a communication path like this. E1 ------- M1 ====== M2 ------ E2 Now, we know E1 and E2 use TCP for communication. Also, we know there are multiple paths between M1 and M2. The bandwidth of E1-M1 and E2-M2 are relatively large compared to any one of paths in M1-M2 or we know there will be heavy congestion in some paths in M1-M2. In this scenario, do we see any advantages for using MPTCP between M1-M2 or not? Or, do we see any problems or concerns to use MPTCP here? Some folks might say we can use routing techniques or bundling IP tunnels here. But, I guess we'll need to handle reorder packets and proper congestion controls across multiple paths. Thanks, -- Yoshi --001a113d31a6a0e099054e207c72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

We've seen active discussions on d= oing proxy work in the WG.=C2=A0
I just would like to clarify sev= eral points from simple cases before discussing detailed mechanisms in prox= y.

Let's say we have end points E1, E2, mi= ddle points M1, M2, and we have a communication path like this.
<= br>
=C2=A0 =C2=A0E1 ------- M1 =3D=3D=3D=3D=3D=3D M2 ------ E2

Now, we know E1 and E2 use TCP for communication. Al= so, we know there are multiple paths between M1 and M2.=C2=A0
The bandwidth of E1-M1 and E2-M2 are relatively large compared = to any one of paths in M1-M2 or we know there will be heavy congestion in s= ome paths in M1-M2.

In this scenario, do we see an= y advantages for using MPTCP between M1-M2 or not? Or, do we see any proble= ms or concerns to use MPTCP here?

Some folks might= say we can use routing techniques or bundling IP tunnels here. But, I gues= s we'll need to handle reorder packets and proper congestion controls a= cross multiple paths.

Thanks,
--
Yoshi
--001a113d31a6a0e099054e207c72-- From nobody Thu Apr 27 01:04:12 2017 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 840E31243FE for ; Thu, 27 Apr 2017 01:04:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 vf6vB_vmg9jf for ; Thu, 27 Apr 2017 01:04:08 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE9012EB29 for ; Thu, 27 Apr 2017 01:04:07 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 00B9510074B; Thu, 27 Apr 2017 10:04:06 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.53]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id D559BC0072; Thu, 27 Apr 2017 10:04:05 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM61.corporate.adroot.infra.ftgroup ([fe80::89e:f34e:3a8e:4519%21]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 10:04:05 +0200 From: To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] Some questions for proxy work Thread-Index: AQHSvyO8ODMkWy8GuEec6w26sRdE7KHY0mPw Date: Thu, 27 Apr 2017 08:04:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5B4DA@OPEXCNORMAD.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5B4DAOPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Some questions for proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 08:04:10 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E5B4DAOPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBt dWx0aXBhdGh0Y3AgW21haWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCBkZSBZb3NoaWZ1bWkgTmlzaGlkYQ0KRW52b3nDqSA6IGpldWRpIDI3IGF2cmlsIDIwMTcg MDg6NTkNCsOAIDogbXVsdGlwYXRodGNwDQpPYmpldCA6IFttdWx0aXBhdGh0Y3BdIFNvbWUgcXVl c3Rpb25zIGZvciBwcm94eSB3b3JrDQoNCkhlbGxvLA0KDQpXZSd2ZSBzZWVuIGFjdGl2ZSBkaXNj dXNzaW9ucyBvbiBkb2luZyBwcm94eSB3b3JrIGluIHRoZSBXRy4NCkkganVzdCB3b3VsZCBsaWtl IHRvIGNsYXJpZnkgc2V2ZXJhbCBwb2ludHMgZnJvbSBzaW1wbGUgY2FzZXMgYmVmb3JlIGRpc2N1 c3NpbmcgZGV0YWlsZWQgbWVjaGFuaXNtcyBpbiBwcm94eS4NCg0KTGV0J3Mgc2F5IHdlIGhhdmUg ZW5kIHBvaW50cyBFMSwgRTIsIG1pZGRsZSBwb2ludHMgTTEsIE0yLCBhbmQgd2UgaGF2ZSBhIGNv bW11bmljYXRpb24gcGF0aCBsaWtlIHRoaXMuDQoNCiAgIEUxIC0tLS0tLS0gTTEgPT09PT09IE0y IC0tLS0tLSBFMg0KDQpOb3csIHdlIGtub3cgRTEgYW5kIEUyIHVzZSBUQ1AgZm9yIGNvbW11bmlj YXRpb24uIEFsc28sIHdlIGtub3cgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGhzIGJldHdlZW4gTTEg YW5kIE0yLg0KDQpUaGUgYmFuZHdpZHRoIG9mIEUxLU0xIGFuZCBFMi1NMiBhcmUgcmVsYXRpdmVs eSBsYXJnZSBjb21wYXJlZCB0byBhbnkgb25lIG9mIHBhdGhzIGluIE0xLU0yIG9yIHdlIGtub3cg dGhlcmUgd2lsbCBiZSBoZWF2eSBjb25nZXN0aW9uIGluIHNvbWUgcGF0aHMgaW4gTTEtTTIuDQoN CkluIHRoaXMgc2NlbmFyaW8sIGRvIHdlIHNlZSBhbnkgYWR2YW50YWdlcyBmb3IgdXNpbmcgTVBU Q1AgYmV0d2VlbiBNMS1NMiBvciBub3Q/DQpbTWVkXSBXaGV0aGVyIE1QVENQIGlzIHRvIGJlIHVz ZWQgZm9yIGEgZ2l2ZW4gZmxvdyBpcyBwb2xpY3ktYmFzZWQuIFB1dHRpbmcgdGhhdCBhc2lkZSwg dGhlIGFkdmFudGFnZXMgb2YgdXNpbmcgTVBUQ1AgaW4gdGhlIGZpcnN0IGNhc2UgKGkuZS4sIHRo ZSBiYW5kd2lkdGggb2YgRTEtTTEgYW5kIEUyLU0yIGFyZSByZWxhdGl2ZWx5IGxhcmdlIGNvbXBh cmVkIHRvIGFueSBvbmUgb2YgcGF0aHMgaW4gTTEtTTIpIGFyZToNCg0KwrcgICAgICAgICBFbnN1 cmUgc2Vzc2lvbiBjb250aW51aXR5IGluIGNhc2UgYW55IG9mIE0xL00yIGxpbmtzIGlzIGJyb2tl bi4NCg0KwrcgICAgICAgICBUaGUgdXNlciBjYW4gY29tcGxhaW4gdGhhdCBoZS9zaGUgY2Fubm90 IHVzZSBFMS9NMSByZXNvdXJjZXMgYXQgbWF4aW11bSBiZWNhdXNlIG9mIHRoZSBjYXBhY2l0eSBj b25zdHJhaW50cyBpbiBhbnkgb2YgdGhlIE0xL00yIGxpbmtzLiBCdW5kbGluZyB0aGUgcmVzb3Vy Y2VzIGluIHRoZSBNMS9NMiBsZWdzIGFsbG93cyB0byBzb2Z0ZW4gdGhhdC4NCg0KSWYgaGVhdnkg Y29uZ2VzdGlvbiBpcyBvYnNlcnZlZCBpbiBzb21lIG9mIHRoZSBNMS9NMiBwYXRoLCBNUFRDUCB3 aWxsIHJlYWN0IGFjY29yZGluZ2x5LiBUaGlzIGlzIG5vdCB0aGUgY2FzZSBmb3IgdHVubmVsLWJh c2VkIHNvbHV0aW9ucy4gRldJVywgbXkgY29sbGVhZ3VlcyBtYWRlIHRlc3RzIGZvciBjb21iaW5n IEFEU0wvTFRFIHdpdGggaW5jcmVhc2luZyB0aGUgTFRFIGRlbGF5IGJ5IDE0MG1zLCB0aGUgY29u Y2x1c2lvbnMgdGhleSBoYWQgaXMgdGhhdCBhIHR1bm5lbC1iYXNlZCBhcHByb2FjaCB0aGF0IGRv ZXMgbm90IHN1cHBvcnQgbWVhbnMgdG8gYWRqdXN0IGJhc2VkIG9uIGNvbmdlc3Rpb24sIHdpbGwg bGVhZCB0byBhIHBlcmZvcm1hbmNlIHdvcnNlIGNvbXBhcmVkIHRvIEFEU0wtb25seSEgT3RoZXIg dGVzdHMgd2VyZSBtYWRlIGJ5IHZhcnlpbmcgdGhlIGRlbGF5IHBlcnR1cmJhdGlvbiBhZGRlZCBv biB0aGUgTFRFIGludGVyZmFjZSBmcm9tIDIwbXMgdG8gNDAwbXMsIHRoZSBkb3dubG9hZGluZyBv ZiBhIGZpbGUgd2hlbiBNUFRDUCBpcyB1c2VkIGlzIGFib3V0IDIgdGltZXMgZmFzdGVyIGNvbXBh cmVkIHRvIHRoZSB0dW5uZWwgc29sdXRpb24uDQoNCk9yLCBkbyB3ZSBzZWUgYW55IHByb2JsZW1z IG9yIGNvbmNlcm5zIHRvIHVzZSBNUFRDUCBoZXJlPw0KDQpTb21lIGZvbGtzIG1pZ2h0IHNheSB3 ZSBjYW4gdXNlIHJvdXRpbmcgdGVjaG5pcXVlcyBvciBidW5kbGluZyBJUCB0dW5uZWxzIGhlcmUu IEJ1dCwgSSBndWVzcyB3ZSdsbCBuZWVkIHRvIGhhbmRsZSByZW9yZGVyIHBhY2tldHMgYW5kIHBy b3BlciBjb25nZXN0aW9uIGNvbnRyb2xzIGFjcm9zcyBtdWx0aXBsZSBwYXRocy4NCltNZWRdIFll cywgTVBUQ1Agd2lsbCBuZWVkIHRvIGJlIHJlaW52ZW50ZWQgYXQgdGhlIGJ1bmRsaW5nIHR1bm5l bCBsZXZlbC4NCg0KVGhhbmtzLA0KLS0NCllvc2hpDQo= --_000_787AE7BB302AE849A7480A190F8B933009E5B4DAOPEXCNORMADcorp_ 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 O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxMTkxNzk1NDQwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTYyOTA2NjM0MiAtMzUxNzkwODk0IDY3ODk1Mjk5IDY3ODk1MzAxIDY3 ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBZ b3NoaSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBtdWx0aXBhdGh0Y3AgW21haWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFlvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDI3IGF2cmlsIDIwMTcgMDg6NTk8YnI+DQo8Yj7DgCZu YnNwOzo8L2I+IG11bHRpcGF0aHRjcDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW211bHRpcGF0 aHRjcF0gU29tZSBxdWVzdGlvbnMgZm9yIHByb3h5IHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UndmUgc2VlbiBhY3RpdmUgZGlzY3Vzc2lvbnMgb24gZG9p bmcgcHJveHkgd29yayBpbiB0aGUgV0cuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNl dmVyYWwgcG9pbnRzIGZyb20gc2ltcGxlIGNhc2VzIGJlZm9yZSBkaXNjdXNzaW5nIGRldGFpbGVk IG1lY2hhbmlzbXMgaW4gcHJveHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxldCdzIHNheSB3ZSBoYXZlIGVuZCBwb2ludHMgRTEsIEUyLCBt aWRkbGUgcG9pbnRzIE0xLCBNMiwgYW5kIHdlIGhhdmUgYSBjb21tdW5pY2F0aW9uIHBhdGggbGlr ZSB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7RTEgLS0tLS0tLSBNMSA9PT09PT0gTTIgLS0tLS0tIEUyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdywgd2Ug a25vdyBFMSBhbmQgRTIgdXNlIFRDUCBmb3IgY29tbXVuaWNhdGlvbi4gQWxzbywgd2Uga25vdyB0 aGVyZSBhcmUgbXVsdGlwbGUgcGF0aHMgYmV0d2VlbiBNMSBhbmQgTTIuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBiYW5kd2lk dGggb2YgRTEtTTEgYW5kIEUyLU0yIGFyZSByZWxhdGl2ZWx5IGxhcmdlIGNvbXBhcmVkIHRvIGFu eSBvbmUgb2YgcGF0aHMgaW4gTTEtTTIgb3Igd2Uga25vdyB0aGVyZSB3aWxsIGJlIGhlYXZ5IGNv bmdlc3Rpb24gaW4gc29tZSBwYXRocyBpbiBNMS1NMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBzY2VuYXJpbywgZG8gd2Ugc2Vl IGFueSBhZHZhbnRhZ2VzIGZvciB1c2luZyBNUFRDUCBiZXR3ZWVuIE0xLU0yIG9yIG5vdD88c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2hldGhl ciBNUFRDUCBpcyB0byBiZSB1c2VkIGZvciBhIGdpdmVuIGZsb3cgaXMgcG9saWN5LWJhc2VkLiBQ dXR0aW5nIHRoYXQgYXNpZGUsIHRoZSBhZHZhbnRhZ2VzIG9mIHVzaW5nIE1QVENQIGluIHRoZSBm aXJzdCBjYXNlIChpLmUuLCB0aGUgYmFuZHdpZHRoDQogb2YgRTEtTTEgYW5kIEUyLU0yIGFyZSBy ZWxhdGl2ZWx5IGxhcmdlIGNvbXBhcmVkIHRvIGFueSBvbmUgb2YgcGF0aHMgaW4gTTEtTTIpIGFy ZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+RW5zdXJlIHNlc3Npb24gY29udGludWl0eSBpbiBjYXNlIGFueSBvZiBNMS9NMiBsaW5r cyBpcyBicm9rZW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoZSB1c2VyIGNhbiBjb21wbGFpbiB0aGF0IGhlL3NoZSBjYW5ub3Qg dXNlIEUxL00xIHJlc291cmNlcyBhdCBtYXhpbXVtIGJlY2F1c2Ugb2YgdGhlIGNhcGFjaXR5IGNv bnN0cmFpbnRzIGluIGFueSBvZiB0aGUgTTEvTTIgbGlua3MuIEJ1bmRsaW5nDQogdGhlIHJlc291 cmNlcyBpbiB0aGUgTTEvTTIgbGVncyBhbGxvd3MgdG8gc29mdGVuIHRoYXQuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBoZWF2eSBjb25nZXN0 aW9uIGlzIG9ic2VydmVkIGluIHNvbWUgb2YgdGhlIE0xL00yIHBhdGgsIE1QVENQIHdpbGwgcmVh Y3QgYWNjb3JkaW5nbHkuIFRoaXMgaXMgbm90IHRoZSBjYXNlIGZvciB0dW5uZWwtYmFzZWQgc29s dXRpb25zLiBGV0lXLCBteSBjb2xsZWFndWVzDQogbWFkZSB0ZXN0cyBmb3IgY29tYmluZyBBRFNM L0xURSB3aXRoIGluY3JlYXNpbmcgdGhlIExURSBkZWxheSBieSAxNDBtcywgdGhlIGNvbmNsdXNp b25zIHRoZXkgaGFkIGlzIHRoYXQgYSB0dW5uZWwtYmFzZWQgYXBwcm9hY2ggdGhhdCBkb2VzIG5v dCBzdXBwb3J0IG1lYW5zIHRvIGFkanVzdCBiYXNlZCBvbiBjb25nZXN0aW9uLCB3aWxsIGxlYWQg dG8gYSBwZXJmb3JtYW5jZSB3b3JzZSBjb21wYXJlZCB0byBBRFNMLW9ubHkhIE90aGVyIHRlc3Rz DQogd2VyZSBtYWRlIGJ5IHZhcnlpbmcgdGhlIGRlbGF5IHBlcnR1cmJhdGlvbiBhZGRlZCBvbiB0 aGUgTFRFIGludGVyZmFjZSBmcm9tIDIwbXMgdG8gNDAwbXMsIHRoZSBkb3dubG9hZGluZyBvZiBh IGZpbGUgd2hlbiBNUFRDUCBpcyB1c2VkIGlzIGFib3V0IDIgdGltZXMgZmFzdGVyIGNvbXBhcmVk IHRvIHRoZSB0dW5uZWwgc29sdXRpb24uICZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9yLCBkbyB3ZSBzZWUgYW55IHByb2JsZW1zIG9yIGNvbmNl cm5zIHRvIHVzZSBNUFRDUCBoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+U29tZSBmb2xrcyBtaWdodCBzYXkgd2UgY2FuIDwvc3Bhbj51c2Ugcm91 dGluZyB0ZWNobmlxdWVzIG9yIGJ1bmRsaW5nIElQIHR1bm5lbHMgaGVyZS4NCjxzcGFuIGxhbmc9 IkVOLVVTIj5CdXQsIEkgZ3Vlc3Mgd2UnbGwgbmVlZCB0byBoYW5kbGUgcmVvcmRlciBwYWNrZXRz IGFuZCBwcm9wZXIgY29uZ2VzdGlvbiBjb250cm9scyBhY3Jvc3MgbXVsdGlwbGUgcGF0aHMuPGI+ PGk+PG86cD48L286cD48L2k+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFllcywgTVBUQ1Agd2lsbCBu ZWVkIHRvIGJlIHJlaW52ZW50ZWQgYXQgdGhlIGJ1bmRsaW5nIHR1bm5lbCBsZXZlbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvc2hpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933009E5B4DAOPEXCNORMADcorp_-- From nobody Thu Apr 27 10:12:15 2017 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 21C0E129B33 for ; Thu, 27 Apr 2017 10:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.889 X-Spam-Level: X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH_WPgojifYy for ; Thu, 27 Apr 2017 10:12:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD13129B5C for ; Thu, 27 Apr 2017 10:09:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RH8ula010415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 10:08:56 -0700 (PDT) To: mohamed.boucadair@orange.com Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> Date: Thu, 27 Apr 2017 10:08:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------C88D73527FF38A84497C3075" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:12:13 -0000 This is a multi-part message in MIME format. --------------C88D73527FF38A84497C3075 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Med, On 4/26/2017 11:53 PM, mohamed.boucadair@orange.com wrote: > ... > > IMO, it is - it's a patch to help support the deprecation of IPv4 in > the global Internet. I don't see that as the role for an MPTCP proxy. > > [Med] The main point Joe is that the IETF has standard track documents > that specify a TCP state machine when NAT is used. We are leveraging > that state machine for the MPTCP proxy work. > A NAT is - at best - a variant of a router. MPTCP is not a router. It is a transport protocol stack. You're not changing the TCP state machine - you're claiming that two TCP connections are somehow tied together inside the TCP stack - that's a fundamental change to the definition of TCP that is far outside the scope of this WG. > > > > The IETF has also a "Standards Track" document called SOCKSv5 > (RFC1928) that is splitting the TCP connection. We are adhering to the > logic of that RFC but without the drawbacks of SOCKS. > > > > Can you clarify where you see split TCP in RFC1928, > > [Med] I don’t see “split TCP†in RFC1928 in the same way I don’t see > “split TCP†in the plain-mode draft. > > Nothing in RFC1929 talks about translating SYNs > > [Med] I guess you meant RFC1928. Translating packets is not explicited > in the text, but it is hinted. For example, the text says the following: > > > > When a TCP-based client wishes to establish a connection to an object > > that is reachable only via a firewall (such determination is left up > > to the implementation), it must open a TCP connection to the > > appropriate SOCKS port on the SOCKS server system. > > > > How a connection from a client to a server with DST@=SOCKS_Proxy will > be relayed to that remote server without gluing connections in both > sides? > It's called a conventional proxy. The 3WHS completes to the SOCKS server, then the SOCKS server opens a new connection. "open a TCP connection" means finishing the 3WHS. > That “glue†can be seen as translating packets by means of SNAT/DNAT. > > > > (side note: I’m sure that RFC1928 will never be published as it is in > 2017. I hear from here people that will argue that RFC1928 is > underspecified) > They can update that RFC if they want. However, that RFC specifies a conventional application layer proxy - see Section 3. > > > - it doesn't even mention specific TCP segments at all, but refers > only to the standard TCP API, where user data would be available only > after the 3WHS between the client and the SOCKS proxy. > > [Med] That’s also the case for the MPTCP proxy. The user data will be > available ONLY once the 3WHS is completed. > So a SYN arrives at the MPTCP proxy from the client. What happens next? If the answer isn't "complete the 3WHS to the client", it's wrong. But that's not what FIg 5 in your doc shows. > > Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN > generating an outgoing SYN before the client SYN/ACK is returned. You > don't mention split-TCP (and it has taken more than too long to figure > out that's what's going on here), but that is what you show. > > or are you confusing it with this, which adds split TCP to a SOCKS proxy: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf > > > > [Med] Bingo. That is exactly my point. We need to avoid mixing > implementation details with base specifications. That is exactly the > reason why I said earlier that mptcp proxy documents only describe the > external behavior. > > OK, so keep ALL discussions of SYN (or any segment translation) out of > this document - including the figures. > > [Med] I’m personally fine with your proposal, but I’m sure we will > have a lot of comments asking for more details. Figures are not > normative; they are provided for illustration purposes. > > If you can explain this using the existing TCP API, e.g., > OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure. > How do you achieve zero-delay E2E otherwise? Or are you assuming zero-delay only within the MPTCP connection? > > But nowhere in that API does TCP tell you when a SYN arrives *before* > sending a SYN-ACK. > > ----- > As to your TFO argument, the problem is this: > > - what happens to the first MPTCP connection from proxy to proxy? > > [Med] Do you mean the first MPTCP connection that is proxied? > Yes. > Or the first subflow of a proxied MPTCP connection? > > > why do you treat this differently than a typical MPTCP, > and what information lets you do so? > > [Med] Can you please explicit your question? Are you referring to a > multipath client, multipath server, or proxy? > I'm asking how the MPTCP connection between the two proxies is different from a typical MPTCP connection as currently specified. > - No change is required for MPTCP-unaware clients and servers. > > - MPTCP processing at the MPTCP-aware server follows the base MPTCP > specification. > > - MPTCP processing at the MPTCP-aware client in the dual-proxy case > follows the base MPTCP specification. > > - MPTCP processing at the MPTCP-aware client in the single-proxy > case will require to supply the MP_CONVERT in the initial subflow. A > part from that, it follows the base MPTCP specification. > > - MPTCP processing at the proxy will require to process the > MP_CONVERT information in order to create a forwarding state for that > MPTCP connection. A part from that, it follows the base MPTCP > specification. > I'm less interested in the details of the MPTCP options than in how the API changes. The current MPTCP API opens initial connections only in response to user calls to OPEN. That doesn't appear to be the case here. > > I don't see anything in this doc that qualifies as what TFO calls > either a cookie between sessions or any substitute based on > authentication or authorization. > > [Med] I already provided a pointer to the slides where this is > discussed. You can also refer to > draft-nam-mptcp-deployment-considerations-01#section-5.3 > : > > > > > The Network Provider that manages the various network attachments > > (including the MCPs) may enforce authentication and authorization > > policies using appropriate mechanisms. For example, a non-exhaustive > > list of methods to achieve authorization is provided hereafter: > You're talking about authorizations of users and access control. TFO is authorizing connections in order to decide if they're new or old. They're different things. > ... > > > > I agree that you're not strictly cloning TFO - IMO, you're trying to > reinvent TFO without leveraging the experience the community has > developed in that process, and IMO you're repeating some of the > mistakes on that journey. > > [Med] I strongly disagree with this. We are leveraging on the guards > as discussed in TFO specification: > > - Anti-spoofing filters are in place in the access segment. > > - TFO specification describes a cookie-less scheme if the server is > immune. > And I disagree that you have proven your server to be immune. Joe --------------C88D73527FF38A84497C3075 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Med,


On 4/26/2017 11:53 PM, mohamed.boucadair@orange.com wrote:
...

IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy.

[Med] The main point Joe is that the IETF has standard track documents that specify a TCP state machine when NAT is used. We are leveraging that state machine for the MPTCP proxy work.


A NAT is - at best - a variant of a router.

MPTCP is not a router. It is a transport protocol stack.

You're not changing the TCP state machine - you're claiming that two TCP connections are somehow tied together inside the TCP stack - that's a fundamental change to the definition of TCP that is far outside the scope of this WG.





The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

 

Can you clarify where you see split TCP in RFC1928,

[Med] I don’t see “split TCP†in RFC1928 in the same way I don’t see “split TCP†in the plain-mode draft.

Nothing in RFC1929 talks about translating SYNs

[Med] I guess you meant RFC1928. Translating packets is not explicited in the text, but it is hinted. For example, the text says the following:

 

   When a TCP-based client wishes to establish a connection to an object

   that is reachable only via a firewall (such determination is left up

   to the implementation), it must open a TCP connection to the

   appropriate SOCKS port on the SOCKS server system.

 

How a connection from a client to a server with DST@=SOCKS_Proxy will be relayed to that remote server without gluing connections in both sides?

It's called a conventional proxy. The 3WHS completes to the SOCKS server, then the SOCKS server opens a new connection.

"open a TCP connection" means finishing the 3WHS.

That “glue†can be seen as translating packets by means of SNAT/DNAT.

 

(side note: I’m sure that RFC1928 will never be published as it is in 2017. I hear from here people that will argue that RFC1928 is underspecified) 


They can update that RFC if they want. However, that RFC specifies a conventional application layer proxy - see Section 3.

 

- it doesn't even mention specific TCP segments at all, but refers only to the standard TCP API, where user data would be available only after the 3WHS between the client and the SOCKS proxy.

[Med] That’s also the case for the MPTCP proxy. The user data will be available ONLY once the 3WHS is completed.


So a SYN arrives at the MPTCP proxy from the client. What happens next?

If the answer isn't "complete the 3WHS to the client", it's wrong. But that's not what FIg 5 in your doc shows.


Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN generating an outgoing SYN before the client SYN/ACK is returned. You don't mention split-TCP (and it has taken more than too long to figure out that's what's going on here), but that is what you show.

or are you confusing it with this, which adds split TCP to a SOCKS proxy:

 

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.

OK, so keep ALL discussions of SYN (or any segment translation) out of this document - including the figures.

[Med] I’m personally fine with your proposal, but I’m sure we will have a lot of comments asking for more details. Figures are not normative; they are provided for illustration purposes.

If you can explain this using the existing TCP API, e.g., OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.


How do you achieve zero-delay E2E otherwise? Or are you assuming zero-delay only within the MPTCP connection?


But nowhere in that API does TCP tell you when a SYN arrives *before* sending a SYN-ACK.

-----
As to your TFO argument, the problem is this:

    - what happens to the first MPTCP connection from proxy to proxy?

[Med] Do you mean the first MPTCP connection that is proxied?

Yes.

Or the first subflow of a proxied MPTCP connection?


            why do you treat this differently than a typical MPTCP, and what information lets you do so?

[Med] Can you please explicit your question? Are you referring to a multipath client, multipath server, or proxy?


I'm asking how the MPTCP connection between the two proxies is different from a typical MPTCP connection as currently specified.

-    No change is required for MPTCP-unaware clients and servers.

-    MPTCP processing at the MPTCP-aware server follows the base MPTCP specification.

-    MPTCP processing at the MPTCP-aware client in the dual-proxy case follows the base MPTCP specification.

-    MPTCP processing at the MPTCP-aware client in the single-proxy case will require to supply the MP_CONVERT in the initial subflow. A part from that, it follows the base MPTCP specification.

-   MPTCP processing at the proxy will require to process the MP_CONVERT information in order to create a forwarding state for that MPTCP connection. A part from that, it follows the base MPTCP specification.

I'm less interested in the details of the MPTCP options than in how the API changes.

The current MPTCP API opens initial connections only in response to user calls to OPEN. That doesn't appear to be the case here.


I don't see anything in this doc that qualifies as what TFO calls either a cookie between sessions or any substitute based on authentication or authorization.

[Med] I already provided a pointer to the slides where this is discussed. You can also refer to draft-nam-mptcp-deployment-considerations-01#section-5.3:

 

   The Network Provider that manages the various network attachments

   (including the MCPs) may enforce authentication and authorization

   policies using appropriate mechanisms.  For example, a non-exhaustive

   list of methods to achieve authorization is provided hereafter:


You're talking about authorizations of users and access control. TFO is authorizing connections in order to decide if they're new or old. They're different things.

 ...



I agree that you're not strictly cloning TFO - IMO, you're trying to reinvent TFO without leveraging the experience the community has developed in that process, and IMO you're repeating some of the mistakes on that journey.

[Med] I strongly disagree with this. We are leveraging on the guards as discussed in TFO specification:

-    Anti-spoofing filters are in place in the access segment.

-   TFO specification describes a cookie-less scheme if the server is immune.


And I disagree that you have proven your server to be immune.

Joe

--------------C88D73527FF38A84497C3075-- From nobody Thu Apr 27 10:21:01 2017 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 1E8A8129492 for ; Thu, 27 Apr 2017 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLuz_Yjae4WH for ; Thu, 27 Apr 2017 10:20:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD00E129471 for ; Thu, 27 Apr 2017 10:18:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RHHf2a011442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 10:17:42 -0700 (PDT) To: mohamed.boucadair@orange.com, Yoshifumi Nishida , multipathtcp References: <787AE7BB302AE849A7480A190F8B933009E5B4DA@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <0eee4a8d-b589-b24a-b026-3de9cc072981@isi.edu> Date: Thu, 27 Apr 2017 10:17:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5B4DA@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------887538696AB8F99037686B31" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Some questions for proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:21:00 -0000 This is a multi-part message in MIME format. --------------887538696AB8F99037686B31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/27/2017 1:04 AM, mohamed.boucadair@orange.com wrote: > > Some folks might say we can use routing techniques or bundling IP > tunnels here. But, I guess we'll need to handle reorder packets and > proper congestion controls across multiple paths.*//* > > [Med] Yes, MPTCP will need to be reinvented at the bundling tunnel level. > You have it backwards. MPTCP reinvents existing channel bonding mechanisms, but with additional constraints. E.g.: - reordering by one MPTCP proxy-proxy connection might be undermined by later reordering over a subsequent multipath sub-path it's more efficient to let the final hop reorder everything, and there's no way that a MPTCP proxy knows it's the last hop - retransmission might be less efficient and incur higher delays than FEC, e.g., which some channel bonding systems implement Joe --------------887538696AB8F99037686B31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/27/2017 1:04 AM, mohamed.boucadair@orange.com wrote:

Some folks might say we can use routing techniques or bundling IP tunnels here. But, I guess we'll need to handle reorder packets and proper congestion controls across multiple paths.

[Med] Yes, MPTCP will need to be reinvented at the bundling tunnel level.

You have it backwards.

MPTCP reinvents existing channel bonding mechanisms, but with additional constraints.

E.g.:
    - reordering by one MPTCP proxy-proxy connection might be undermined by later reordering over a subsequent multipath sub-path
        it's more efficient to let the final hop reorder everything, and there's no way that a MPTCP proxy knows it's the last hop

    - retransmission might be less efficient and incur higher delays than FEC, e.g., which some channel bonding systems implement

Joe
--------------887538696AB8F99037686B31-- From nobody Thu Apr 27 23:45:45 2017 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 E04E6129C21 for ; Thu, 27 Apr 2017 23:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 IkiqiJ_hzUCn for ; Thu, 27 Apr 2017 23:45:40 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5876129B19 for ; Thu, 27 Apr 2017 23:42:58 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 22F161004F9; Fri, 28 Apr 2017 08:42:57 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.86]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id F035BC0079; Fri, 28 Apr 2017 08:42:56 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORMAE.corporate.adroot.infra.ftgroup ([fe80::897f:9a74:3898:db87%21]) with mapi id 14.03.0339.000; Fri, 28 Apr 2017 08:42:56 +0200 From: To: Joe Touch CC: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSv3kQMRevajoXW0S3cZgAqZCH9qHaSu3A Date: Fri, 28 Apr 2017 06:42:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5E00F@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> In-Reply-To: <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> 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_787AE7BB302AE849A7480A190F8B933009E5E00FOPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 06:45:43 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E5E00FOPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9l IFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCkVudm95w6kgOiBqZXVkaSAyNyBhdnJpbCAy MDE3IDE5OjA5DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogcGhpbGlwLmVh cmRsZXlAYnQuY29tOyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFttdWx0aXBh dGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRDUCBwcm94eSB3b3JrDQoNCg0K TWVkLA0KDQpPbiA0LzI2LzIwMTcgMTE6NTMgUE0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KLi4uDQpJTU8s IGl0IGlzIC0gaXQncyBhIHBhdGNoIHRvIGhlbHAgc3VwcG9ydCB0aGUgZGVwcmVjYXRpb24gb2Yg SVB2NCBpbiB0aGUgZ2xvYmFsIEludGVybmV0LiBJIGRvbid0IHNlZSB0aGF0IGFzIHRoZSByb2xl IGZvciBhbiBNUFRDUCBwcm94eS4NCltNZWRdIFRoZSBtYWluIHBvaW50IEpvZSBpcyB0aGF0IHRo ZSBJRVRGIGhhcyBzdGFuZGFyZCB0cmFjayBkb2N1bWVudHMgdGhhdCBzcGVjaWZ5IGEgVENQIHN0 YXRlIG1hY2hpbmUgd2hlbiBOQVQgaXMgdXNlZC4gV2UgYXJlIGxldmVyYWdpbmcgdGhhdCBzdGF0 ZSBtYWNoaW5lIGZvciB0aGUgTVBUQ1AgcHJveHkgd29yay4NCg0KQSBOQVQgaXMgLSBhdCBiZXN0 IC0gYSB2YXJpYW50IG9mIGEgcm91dGVyLg0KW01lZF0gSG1t4oCmYSByb3V0ZXIgZG9lcyBub3Qg YWN0IG9uIHBvcnQgbnVtYmVycy4NCg0KDQpNUFRDUCBpcyBub3QgYSByb3V0ZXIuIEl0IGlzIGEg dHJhbnNwb3J0IHByb3RvY29sIHN0YWNrLg0KW01lZF0gU2FtZSBhcyBhIE5BVCB0aGF0IHJlbGll cyBvbiB0cmFuc3BvcnQgcG9ydHMgdG8gZGVtdXggY29ubmVjdGlvbnMuIFRoaXMgaXMgd2h5IHdl IGhhdmUgVENQL1VEUCBCRUhBVkUgUkZDcy4NCg0KWW91J3JlIG5vdCBjaGFuZ2luZyB0aGUgVENQ IHN0YXRlIG1hY2hpbmUgLSB5b3UncmUgY2xhaW1pbmcgdGhhdCB0d28gVENQIGNvbm5lY3Rpb25z IGFyZSBzb21laG93IHRpZWQgdG9nZXRoZXIgaW5zaWRlIHRoZSBUQ1Agc3RhY2sgLSB0aGF0J3Mg YSBmdW5kYW1lbnRhbCBjaGFuZ2UgdG8gdGhlIGRlZmluaXRpb24gb2YgVENQIHRoYXQgaXMgZmFy IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgV0cuDQpbTWVkXSBXZSBhcmUgbm90IGNoYW5naW5n IHRoZSBUQ1Agc3RhdGUgbWFjaGluZSwgd2UgYXJlIHJlbHlpbmcgb24gdGhlIG9uZSBkZWZpbmVk IGluIHN0YW5kYXJkcyB0cmFjayBJRVRGIGRvY3VtZW50cy4NCg0KDQoNCg0KVGhlIElFVEYgaGFz IGFsc28gYSAiU3RhbmRhcmRzIFRyYWNrIiBkb2N1bWVudCBjYWxsZWQgU09DS1N2NSAoUkZDMTky OCkgdGhhdCBpcyBzcGxpdHRpbmcgdGhlIFRDUCBjb25uZWN0aW9uLiBXZSBhcmUgYWRoZXJpbmcg dG8gdGhlIGxvZ2ljIG9mIHRoYXQgUkZDIGJ1dCB3aXRob3V0IHRoZSBkcmF3YmFja3Mgb2YgU09D S1MuDQoNCkNhbiB5b3UgY2xhcmlmeSB3aGVyZSB5b3Ugc2VlIHNwbGl0IFRDUCBpbiBSRkMxOTI4 LA0KW01lZF0gSSBkb27igJl0IHNlZSDigJxzcGxpdCBUQ1DigJ0gaW4gUkZDMTkyOCBpbiB0aGUg c2FtZSB3YXkgSSBkb27igJl0IHNlZSDigJxzcGxpdCBUQ1DigJ0gaW4gdGhlIHBsYWluLW1vZGUg ZHJhZnQuDQpOb3RoaW5nIGluIFJGQzE5MjkgdGFsa3MgYWJvdXQgdHJhbnNsYXRpbmcgU1lOcw0K W01lZF0gSSBndWVzcyB5b3UgbWVhbnQgUkZDMTkyOC4gVHJhbnNsYXRpbmcgcGFja2V0cyBpcyBu b3QgZXhwbGljaXRlZCBpbiB0aGUgdGV4dCwgYnV0IGl0IGlzIGhpbnRlZC4gRm9yIGV4YW1wbGUs IHRoZSB0ZXh0IHNheXMgdGhlIGZvbGxvd2luZzoNCg0KICAgV2hlbiBhIFRDUC1iYXNlZCBjbGll bnQgd2lzaGVzIHRvIGVzdGFibGlzaCBhIGNvbm5lY3Rpb24gdG8gYW4gb2JqZWN0DQogICB0aGF0 IGlzIHJlYWNoYWJsZSBvbmx5IHZpYSBhIGZpcmV3YWxsIChzdWNoIGRldGVybWluYXRpb24gaXMg bGVmdCB1cA0KICAgdG8gdGhlIGltcGxlbWVudGF0aW9uKSwgaXQgbXVzdCBvcGVuIGEgVENQIGNv bm5lY3Rpb24gdG8gdGhlDQogICBhcHByb3ByaWF0ZSBTT0NLUyBwb3J0IG9uIHRoZSBTT0NLUyBz ZXJ2ZXIgc3lzdGVtLg0KDQpIb3cgYSBjb25uZWN0aW9uIGZyb20gYSBjbGllbnQgdG8gYSBzZXJ2 ZXIgd2l0aCBEU1RAPVNPQ0tTX1Byb3h5IHdpbGwgYmUgcmVsYXllZCB0byB0aGF0IHJlbW90ZSBz ZXJ2ZXIgd2l0aG91dCBnbHVpbmcgY29ubmVjdGlvbnMgaW4gYm90aCBzaWRlcz8NCkl0J3MgY2Fs bGVkIGEgY29udmVudGlvbmFsIHByb3h5LiBUaGUgM1dIUyBjb21wbGV0ZXMgdG8gdGhlIFNPQ0tT IHNlcnZlciwgdGhlbiB0aGUgU09DS1Mgc2VydmVyIG9wZW5zIGEgbmV3IGNvbm5lY3Rpb24uDQpb TWVkXSBUaGUgZXh0ZXJuYWwgYmVoYXZpb3IgaXMgdGhhdCBhIHJlY2VpdmVkIFNZTiB3aWxsIHRy aWdnZXIgYW4gb3V0Z29pbmcgU1lOLiBXaGF0IGhhcHBlbnMgaW5zaWRlIHRoZSBwcm94eSBpdHNl bGYgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuDQoNCiJvcGVuIGEgVENQIGNvbm5lY3Rpb24i IG1lYW5zIGZpbmlzaGluZyB0aGUgM1dIUy4NCg0KDQpUaGF0IOKAnGdsdWXigJ0gY2FuIGJlIHNl ZW4gYXMgdHJhbnNsYXRpbmcgcGFja2V0cyBieSBtZWFucyBvZiBTTkFUL0ROQVQuDQoNCihzaWRl IG5vdGU6IEnigJltIHN1cmUgdGhhdCBSRkMxOTI4IHdpbGwgbmV2ZXIgYmUgcHVibGlzaGVkIGFz IGl0IGlzIGluIDIwMTcuIEkgaGVhciBmcm9tIGhlcmUgcGVvcGxlIHRoYXQgd2lsbCBhcmd1ZSB0 aGF0IFJGQzE5MjggaXMgdW5kZXJzcGVjaWZpZWQpDQoNClRoZXkgY2FuIHVwZGF0ZSB0aGF0IFJG QyBpZiB0aGV5IHdhbnQuIEhvd2V2ZXIsIHRoYXQgUkZDIHNwZWNpZmllcyBhIGNvbnZlbnRpb25h bCBhcHBsaWNhdGlvbiBsYXllciBwcm94eSAtIHNlZSBTZWN0aW9uIDMuDQoNCg0KDQotIGl0IGRv ZXNuJ3QgZXZlbiBtZW50aW9uIHNwZWNpZmljIFRDUCBzZWdtZW50cyBhdCBhbGwsIGJ1dCByZWZl cnMgb25seSB0byB0aGUgc3RhbmRhcmQgVENQIEFQSSwgd2hlcmUgdXNlciBkYXRhIHdvdWxkIGJl IGF2YWlsYWJsZSBvbmx5IGFmdGVyIHRoZSAzV0hTIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhl IFNPQ0tTIHByb3h5Lg0KW01lZF0gVGhhdOKAmXMgYWxzbyB0aGUgY2FzZSBmb3IgdGhlIE1QVENQ IHByb3h5LiBUaGUgdXNlciBkYXRhIHdpbGwgYmUgYXZhaWxhYmxlIE9OTFkgb25jZSB0aGUgM1dI UyBpcyBjb21wbGV0ZWQuDQoNClNvIGEgU1lOIGFycml2ZXMgYXQgdGhlIE1QVENQIHByb3h5IGZy b20gdGhlIGNsaWVudC4gV2hhdCBoYXBwZW5zIG5leHQ/DQpbTWVkXSBJdCBleHRyYWN0cyB0aGUg YWRkcmVzcy9wb3J0IG9mIHRoZSByZW1vdGUgc2VydmVyIGFuZCBzZW5kcyBhIFNZTiB0byB0aGF0 IGFkZHJlc3MvcG9ydC4NCg0KSWYgdGhlIGFuc3dlciBpc24ndCAiY29tcGxldGUgdGhlIDNXSFMg dG8gdGhlIGNsaWVudCIsIGl0J3Mgd3JvbmcuIEJ1dCB0aGF0J3Mgbm90IHdoYXQgRklnIDUgaW4g eW91ciBkb2Mgc2hvd3MuDQpbTWVkXSBUaGUgcHJveHkgY2FuICgxKSBjb21wbGV0ZSB0aGUgM1dI UyB0byB0aGUgY2xpZW50OyB0aGUgZG9jdW1lbnQgc2F5cyB0aGUgZm9sbG93aW5nOg0KDQogICDi gJxDb25jZXB0dWFsbHksIHRoZSBNQ1AgYWN0cyBhcyBhIHJlbGF5IGJldHdlZW4gYW4gdXBzdHJl YW0gTVBUQ1ANCiAgIGNvbm5lY3Rpb24gYW5kIGEgZG93bnN0cmVhbSBUQ1AgY29ubmVjdGlvbi7i gJ0NCg0KDQogICDigJxUaGUgTUNQIG1hcHMgYW4gdXBzdHJlYW0gTVBUQ1AgY29ubmVjdGlvbiAo YW5kIGl0cyBhc3NvY2lhdGVkDQogICBzdWJmbG93cykgb250byBhIGRvd25zdHJlYW0gVENQIGNv bm5lY3Rpb24u4oCdDQoNCg0KICAg4oCcQXQgdGhpcyBwb2ludCwgdGhlcmUgYXJlIHR3byBlc3Rh Ymxpc2hlZCBjb25uZWN0aW9ucy4gIFRoZSBlbmRwb2ludHMNCiAgb2YgdGhlIHVwc3RyZWFtIE11 bHRpcGF0aCBUQ1AgY29ubmVjdGlvbiBhcmUgdGhlIE11bHRpcGF0aCBUQ1AgQ2xpZW50DQogICBh bmQgdGhlIE1DUC4gIFRoZSBlbmRwb2ludHMgb2YgdGhlIGRvd25zdHJlYW0gVENQIGNvbm5lY3Rp b24gYXJlIHRoZQ0KICAgTUNQIGFuZCB0aGUgU2VydmVyLiAgVGhlc2UgdHdvIGNvbm5lY3Rpb25z IGFyZSBib3VuZCBieSB0aGUgTUNQLuKAnQ0KDQpvciAoMikgY2FuIHByb2NlZWQgYSBsYSBOQVQg KGUuZy4sIEZpZyA1KS4NCg0KV2UgaGF2ZSB0cmFkZS1vZmZzOiBpZiB3ZSBjb21wbGV0ZSB0aGUg M1dIUyBiZWZvcmUgYW4gYW5zd2VyIGlzIHJlY2VpdmVkIGZyb20gdGhlIHNlcnZlciwgd2UgbG9z ZSB0aGUgZm9sbG93aW5nIGZlYXR1cmUgdGhhdCB3ZSB3b3VsZCBsaWtlIHRvIG9mZmVyOg0KDQog ICBXaGV0aGVyIGFuIE1DUCBtdXN0IGJlIG1haW50YWluZWQgaW4gdGhlIHByb2Nlc3Npbmcgb2Yg YW4gTVBUQ1ANCiAgIGNvbm5lY3Rpb24gdGhhdCBpbnZvbHZlIE1QVENQLWNhcGFibGUgY2xpZW50 cyBhbmQgc2VydmVyIGlzIGENCiAgIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXIuDQoNCldoZXRoZXIg d2UgbmVlZCB0byBoYXZlIGJvdGggb3IgcmVjb21tZW5kIG9uZSBhcHByb2FjaCBpcyBiZSB3b3Jr ZWQgb3V0IG9uY2Ugd2UgaGF2ZSBhIFdHIGRvY3VtZW50Lg0KVGhlIHNwZWNpZmljYXRpb24gaXMg bm90IGZyb3plbiBhbmQgeW91ciBzdWdnZXN0aW9ucy9jb21tZW50cyB3aWxsIGJlIHRha2VuIGlu dG8gYWNjb3VudC4NCg0KDQpGaWd1cmUgNSBvZiBTZWMgNS4yIG9mIHlvdXIgZG9jdW1lbnQgY2xl YXJseSBzaG93cyBhbiBpbmNvbWluZyBTWU4gZ2VuZXJhdGluZyBhbiBvdXRnb2luZyBTWU4gYmVm b3JlIHRoZSBjbGllbnQgU1lOL0FDSyBpcyByZXR1cm5lZC4gWW91IGRvbid0IG1lbnRpb24gc3Bs aXQtVENQIChhbmQgaXQgaGFzIHRha2VuIG1vcmUgdGhhbiB0b28gbG9uZyB0byBmaWd1cmUgb3V0 IHRoYXQncyB3aGF0J3MgZ29pbmcgb24gaGVyZSksIGJ1dCB0aGF0IGlzIHdoYXQgeW91IHNob3cu DQpvciBhcmUgeW91IGNvbmZ1c2luZyBpdCB3aXRoIHRoaXMsIHdoaWNoIGFkZHMgc3BsaXQgVENQ IHRvIGEgU09DS1MgcHJveHk6DQpodHRwOi8vY2l0ZXNlZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2Mv ZG93bmxvYWQ/ZG9pPTEwLjEuMS4zNC45OTE1JnJlcD1yZXAxJnR5cGU9cGRmDQoNCltNZWRdIEJp bmdvLiBUaGF0IGlzIGV4YWN0bHkgbXkgcG9pbnQuIFdlIG5lZWQgdG8gYXZvaWQgbWl4aW5nIGlt cGxlbWVudGF0aW9uIGRldGFpbHMgd2l0aCBiYXNlIHNwZWNpZmljYXRpb25zLiBUaGF0IGlzIGV4 YWN0bHkgdGhlIHJlYXNvbiB3aHkgSSBzYWlkIGVhcmxpZXIgdGhhdCBtcHRjcCBwcm94eSBkb2N1 bWVudHMgb25seSBkZXNjcmliZSB0aGUgZXh0ZXJuYWwgYmVoYXZpb3IuDQpPSywgc28ga2VlcCBB TEwgZGlzY3Vzc2lvbnMgb2YgU1lOIChvciBhbnkgc2VnbWVudCB0cmFuc2xhdGlvbikgb3V0IG9m IHRoaXMgZG9jdW1lbnQgLSBpbmNsdWRpbmcgdGhlIGZpZ3VyZXMuDQpbTWVkXSBJ4oCZbSBwZXJz b25hbGx5IGZpbmUgd2l0aCB5b3VyIHByb3Bvc2FsLCBidXQgSeKAmW0gc3VyZSB3ZSB3aWxsIGhh dmUgYSBsb3Qgb2YgY29tbWVudHMgYXNraW5nIGZvciBtb3JlIGRldGFpbHMuIEZpZ3VyZXMgYXJl IG5vdCBub3JtYXRpdmU7IHRoZXkgYXJlIHByb3ZpZGVkIGZvciBpbGx1c3RyYXRpb24gcHVycG9z ZXMuDQoNCklmIHlvdSBjYW4gZXhwbGFpbiB0aGlzIHVzaW5nIHRoZSBleGlzdGluZyBUQ1AgQVBJ LCBlLmcuLCBPUEVOL0NMT1NFL0FCT1JUL1NUQVRVUyBhbmQgU0VORC9SRUNFSVZFIChSRkM3OTMg U2VjIDMuOSksIHRoZW4gc3VyZS4NCg0KSG93IGRvIHlvdSBhY2hpZXZlIHplcm8tZGVsYXkgRTJF IG90aGVyd2lzZT8gT3IgYXJlIHlvdSBhc3N1bWluZyB6ZXJvLWRlbGF5IG9ubHkgd2l0aGluIHRo ZSBNUFRDUCBjb25uZWN0aW9uPw0KW01lZF0gV2UgYXJlIGFjaGlldmluZyAwLVJUVCBNUFRDUCBw cm94eWluZyBiZWNhdXNlIDoNCg0KwrcgICAgICAgICBXZSBkb27igJl0IGhhdmUgb3V0IG9mIGJh bmQgc2lnbmFsaW5nIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHByb3h5IChmb3IgdGhlIHJlY29y ZCwgdGhlcmUgYXJlICsxMCBUQ1AgbWVzc2FnZXMgd2hlbiBTT0NLU3Y1IGlzIGluIHVzZSkuDQoN CsK3ICAgICAgICAgVGhlIGluaXRpYWwgU1lOIGluY2x1ZGVzIHRoZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgdWx0aW1hdGUgc2VydmVyOyB0aGF0IHNlcnZlciB3aWxsIGJlIGNvbnRhY3RlZCBpbW1l ZGlhdGVseS4NCg0KRm9yIGV4YW1wbGUsIGJlY2F1c2Ugd2UgYXJlIGxldmVyYWdpbmcgb24gQkVI QVZFIFJGQ3MsIGEgcHJveGllZCBNUFRDUCBjb25uZWN0aW9ucyB3aWxsIGV4cGVyaWVuY2UgdGhl IHNhbWUgZGVsYXkgYXMgYSBUQ1AgY29ubmVjdGlvbiB0aGF0IGdvZXMgdGhyb3VnaCBhIENHTi9O QVQ2NC4NCg0KDQpCdXQgbm93aGVyZSBpbiB0aGF0IEFQSSBkb2VzIFRDUCB0ZWxsIHlvdSB3aGVu IGEgU1lOIGFycml2ZXMgKmJlZm9yZSogc2VuZGluZyBhIFNZTi1BQ0suDQoNCi0tLS0tDQpBcyB0 byB5b3VyIFRGTyBhcmd1bWVudCwgdGhlIHByb2JsZW0gaXMgdGhpczoNCg0KICAgIC0gd2hhdCBo YXBwZW5zIHRvIHRoZSBmaXJzdCBNUFRDUCBjb25uZWN0aW9uIGZyb20gcHJveHkgdG8gcHJveHk/ DQpbTWVkXSBEbyB5b3UgbWVhbiB0aGUgZmlyc3QgTVBUQ1AgY29ubmVjdGlvbiB0aGF0IGlzIHBy b3hpZWQ/DQpZZXMuDQoNCg0KT3IgdGhlIGZpcnN0IHN1YmZsb3cgb2YgYSBwcm94aWVkIE1QVENQ IGNvbm5lY3Rpb24/DQoNCiAgICAgICAgICAgIHdoeSBkbyB5b3UgdHJlYXQgdGhpcyBkaWZmZXJl bnRseSB0aGFuIGEgdHlwaWNhbCBNUFRDUCwgYW5kIHdoYXQgaW5mb3JtYXRpb24gbGV0cyB5b3Ug ZG8gc28/DQpbTWVkXSBDYW4geW91IHBsZWFzZSBleHBsaWNpdCB5b3VyIHF1ZXN0aW9uPyBBcmUg eW91IHJlZmVycmluZyB0byBhIG11bHRpcGF0aCBjbGllbnQsIG11bHRpcGF0aCBzZXJ2ZXIsIG9y IHByb3h5Pw0KDQpJJ20gYXNraW5nIGhvdyB0aGUgTVBUQ1AgY29ubmVjdGlvbiBiZXR3ZWVuIHRo ZSB0d28gcHJveGllcyBpcyBkaWZmZXJlbnQgZnJvbSBhIHR5cGljYWwgTVBUQ1AgY29ubmVjdGlv biBhcyBjdXJyZW50bHkgc3BlY2lmaWVkLg0KW01lZF0gT0ssIHRoYW5rcy4gSXQgaXMgbm90IGRp ZmZlcmVudC4NCg0KDQoNCi0gICBObyBjaGFuZ2UgaXMgcmVxdWlyZWQgZm9yIE1QVENQLXVuYXdh cmUgY2xpZW50cyBhbmQgc2VydmVycy4NCg0KLSAgIE1QVENQIHByb2Nlc3NpbmcgYXQgdGhlIE1Q VENQLWF3YXJlIHNlcnZlciBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNpZmljYXRpb24uDQoN Ci0gICBNUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBjbGllbnQgaW4gdGhlIGR1 YWwtcHJveHkgY2FzZSBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNpZmljYXRpb24uDQoNCi0g ICBNUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBjbGllbnQgaW4gdGhlIHNpbmds ZS1wcm94eSBjYXNlIHdpbGwgcmVxdWlyZSB0byBzdXBwbHkgdGhlIE1QX0NPTlZFUlQgaW4gdGhl IGluaXRpYWwgc3ViZmxvdy4gQSBwYXJ0IGZyb20gdGhhdCwgaXQgZm9sbG93cyB0aGUgYmFzZSBN UFRDUCBzcGVjaWZpY2F0aW9uLg0KDQotICAgTVBUQ1AgcHJvY2Vzc2luZyBhdCB0aGUgcHJveHkg d2lsbCByZXF1aXJlIHRvIHByb2Nlc3MgdGhlIE1QX0NPTlZFUlQgaW5mb3JtYXRpb24gaW4gb3Jk ZXIgdG8gY3JlYXRlIGEgZm9yd2FyZGluZyBzdGF0ZSBmb3IgdGhhdCBNUFRDUCBjb25uZWN0aW9u LiBBIHBhcnQgZnJvbSB0aGF0LCBpdCBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNpZmljYXRp b24uDQpJJ20gbGVzcyBpbnRlcmVzdGVkIGluIHRoZSBkZXRhaWxzIG9mIHRoZSBNUFRDUCBvcHRp b25zIHRoYW4gaW4gaG93IHRoZSBBUEkgY2hhbmdlcy4NCg0KVGhlIGN1cnJlbnQgTVBUQ1AgQVBJ IG9wZW5zIGluaXRpYWwgY29ubmVjdGlvbnMgb25seSBpbiByZXNwb25zZSB0byB1c2VyIGNhbGxz IHRvIE9QRU4uIFRoYXQgZG9lc24ndCBhcHBlYXIgdG8gYmUgdGhlIGNhc2UgaGVyZS4NCg0KDQoN Ci0NCkkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoaXMgZG9jIHRoYXQgcXVhbGlmaWVzIGFzIHdo YXQgVEZPIGNhbGxzIGVpdGhlciBhIGNvb2tpZSBiZXR3ZWVuIHNlc3Npb25zIG9yIGFueSBzdWJz dGl0dXRlIGJhc2VkIG9uIGF1dGhlbnRpY2F0aW9uIG9yIGF1dGhvcml6YXRpb24uDQpbTWVkXSBJ IGFscmVhZHkgcHJvdmlkZWQgYSBwb2ludGVyIHRvIHRoZSBzbGlkZXMgd2hlcmUgdGhpcyBpcyBk aXNjdXNzZWQuIFlvdSBjYW4gYWxzbyByZWZlciB0byBkcmFmdC1uYW0tbXB0Y3AtZGVwbG95bWVu dC1jb25zaWRlcmF0aW9ucy0wMSNzZWN0aW9uLTUuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbmFtLW1wdGNwLWRlcGxveW1lbnQtY29uc2lkZXJhdGlvbnMtMDEjc2VjdGlvbi01 LjM+Og0KDQogICBUaGUgTmV0d29yayBQcm92aWRlciB0aGF0IG1hbmFnZXMgdGhlIHZhcmlvdXMg bmV0d29yayBhdHRhY2htZW50cw0KICAgKGluY2x1ZGluZyB0aGUgTUNQcykgbWF5IGVuZm9yY2Ug YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24NCiAgIHBvbGljaWVzIHVzaW5nIGFwcHJv cHJpYXRlIG1lY2hhbmlzbXMuICBGb3IgZXhhbXBsZSwgYSBub24tZXhoYXVzdGl2ZQ0KICAgbGlz dCBvZiBtZXRob2RzIHRvIGFjaGlldmUgYXV0aG9yaXphdGlvbiBpcyBwcm92aWRlZCBoZXJlYWZ0 ZXI6DQoNCllvdSdyZSB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb25zIG9mIHVzZXJzIGFuZCBh Y2Nlc3MgY29udHJvbC4gVEZPIGlzIGF1dGhvcml6aW5nIGNvbm5lY3Rpb25zIGluIG9yZGVyIHRv IGRlY2lkZSBpZiB0aGV5J3JlIG5ldyBvciBvbGQuIFRoZXkncmUgZGlmZmVyZW50IHRoaW5ncy4N CltNZWRdIFRoZXkgYXJlIGRpZmZlcmVudCB0aGluZ3MgYnV0IGFjaGlldmUgdGhlIHNhbWUgcHVy cG9zZTogcHJlc2VydmUgdGhlIHNlcnZlciBmcm9tIG1pc3VzZS9hYnVzZS9Eb1MuIFdoZXRoZXIg TVBUQ1AgcHJveHkgaGFzIHRvIGNoZWNrIG5ldy9vbGQgY29ubmVjdGlvbnMgaXMgZGVwbG95bWVu dC1zcGVjaWZpYy4NCg0KIC4uLg0KDQoNCkkgYWdyZWUgdGhhdCB5b3UncmUgbm90IHN0cmljdGx5 IGNsb25pbmcgVEZPIC0gSU1PLCB5b3UncmUgdHJ5aW5nIHRvIHJlaW52ZW50IFRGTyB3aXRob3V0 IGxldmVyYWdpbmcgdGhlIGV4cGVyaWVuY2UgdGhlIGNvbW11bml0eSBoYXMgZGV2ZWxvcGVkIGlu IHRoYXQgcHJvY2VzcywgYW5kIElNTyB5b3UncmUgcmVwZWF0aW5nIHNvbWUgb2YgdGhlIG1pc3Rh a2VzIG9uIHRoYXQgam91cm5leS4NCltNZWRdIEkgc3Ryb25nbHkgZGlzYWdyZWUgd2l0aCB0aGlz LiBXZSBhcmUgbGV2ZXJhZ2luZyBvbiB0aGUgZ3VhcmRzIGFzIGRpc2N1c3NlZCBpbiBURk8gc3Bl Y2lmaWNhdGlvbjoNCg0KLSAgIEFudGktc3Bvb2ZpbmcgZmlsdGVycyBhcmUgaW4gcGxhY2UgaW4g dGhlIGFjY2VzcyBzZWdtZW50Lg0KDQotICAgVEZPIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGEg Y29va2llLWxlc3Mgc2NoZW1lIGlmIHRoZSBzZXJ2ZXIgaXMgaW1tdW5lLg0KDQpBbmQgSSBkaXNh Z3JlZSB0aGF0IHlvdSBoYXZlIHByb3ZlbiB5b3VyIHNlcnZlciB0byBiZSBpbW11bmUuDQpbTWVk XSBDYW4geW91IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhdHRhY2sgeW91IGhhdmUgaW4gbWluZCBm b3IgdGhlIE1QVENQIHByb3h5Pw0KDQoNCkpvZQ0K --_000_787AE7BB302AE849A7480A190F8B933009E5E00FOPEXCNORMADcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291 cmllciBOZXcgXDtjb2xvclw6YmxhY2siO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IFw7Y29sb3JcOndpbmRvd3RleHQiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2lu LWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxl LW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5ncmV5DQoJ e21zby1zdHlsZS1uYW1lOmdyZXk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxNjA0NDYwMDQwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTg3OTc3MTU2NCAtMTIzNDUyMTQxMCA2Nzg5NTI5OSA2Nzg5NTMwMSA2 Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE2NDg5Nzc0OTU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc4NDYyNDM0MCAyMDMz MTczNDYgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUy OTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28t bGlzdC1pZDoxNjk4NDU4MjUwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTMyODY0Nzk2NiAtMjIzNzM1NzE4IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkhpIEpvZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxl YXNlIHNlZSBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4gSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCjxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiBqZXVkaSAyNyBhdnJpbCAyMDE3IDE5OjA5PGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBw aGlsaXAuZWFyZGxleUBidC5jb207IG11bHRpcGF0aHRjcEBpZXRmLm9yZzxicj4NCjxiPk9iamV0 Jm5ic3A7OjwvYj4gUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlh bCBNUFRDUCBwcm94eSB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+TWVkLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8yNi8yMDE3IDExOjUzIFBNLCA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4uLi4gPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PLCBpdCBpcyAtIGl0J3MgYSBwYXRjaCB0byBoZWxw IHN1cHBvcnQgdGhlIGRlcHJlY2F0aW9uIG9mIElQdjQgaW4gdGhlIGdsb2JhbCBJbnRlcm5ldC4g SSBkb24ndCBzZWUgdGhhdCBhcyB0aGUgcm9sZSBmb3IgYW4gTVBUQ1AgcHJveHkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6Ymxh Y2smcXVvdDsiPltNZWRdIFRoZSBtYWluIHBvaW50IEpvZSBpcyB0aGF0IHRoZSBJRVRGIGhhcyBz dGFuZGFyZCB0cmFjayBkb2N1bWVudHMgdGhhdCBzcGVjaWZ5IGEgVENQIHN0YXRlIG1hY2hpbmUg d2hlbiBOQVQgaXMgdXNlZC4gV2UgYXJlIGxldmVyYWdpbmcgdGhhdCBzdGF0ZQ0KIG1hY2hpbmUg Zm9yIHRoZSBNUFRDUCBwcm94eSB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQSBOQVQgaXMgLSBhdCBi ZXN0IC0gYSB2YXJpYW50IG9mIGEgcm91dGVyLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBIbW3igKZhIHJvdXRlciBkb2VzIG5vdCBhY3Qgb24g cG9ydCBudW1iZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+TVBUQ1AgaXMgbm90IGEgcm91 dGVyLiBJdCBpcyBhIHRyYW5zcG9ydCBwcm90b2NvbCBzdGFjay4gPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gU2FtZSBhcyBhIE5BVCB0aGF0 IHJlbGllcyBvbiB0cmFuc3BvcnQgcG9ydHMgdG8gZGVtdXggY29ubmVjdGlvbnMuIFRoaXMgaXMg d2h5IHdlIGhhdmUgVENQL1VEUCBCRUhBVkUgUkZDcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxicj4NCllvdSdyZSBub3QgY2hhbmdpbmcgdGhlIFRDUCBzdGF0ZSBtYWNoaW5lIC0g eW91J3JlIGNsYWltaW5nIHRoYXQgdHdvIFRDUCBjb25uZWN0aW9ucyBhcmUgc29tZWhvdyB0aWVk IHRvZ2V0aGVyIGluc2lkZSB0aGUgVENQIHN0YWNrIC0gdGhhdCdzIGEgZnVuZGFtZW50YWwgY2hh bmdlIHRvIHRoZSBkZWZpbml0aW9uIG9mIFRDUCB0aGF0IGlzIGZhciBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIFdHLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIFRD UCBzdGF0ZSBtYWNoaW5lLCB3ZSBhcmUgcmVseWluZyBvbiB0aGUgb25lIGRlZmluZWQgaW4gc3Rh bmRhcmRzIHRyYWNrIElFVEYgZG9jdW1lbnRzLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVU RiBoYXMgYWxzbyBhICZxdW90O1N0YW5kYXJkcyBUcmFjayZxdW90OyBkb2N1bWVudCBjYWxsZWQg U09DS1N2NSAoUkZDMTkyOCkgdGhhdCBpcyBzcGxpdHRpbmcgdGhlIFRDUCBjb25uZWN0aW9uLiBX ZSBhcmUgYWRoZXJpbmcgdG8NCjwvc3Bhbj50aGUgbG9naWMgb2YgdGhhdCBSRkMgYnV0IHdpdGhv dXQgdGhlIGRyYXdiYWNrcyBvZiBTT0NLUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBjbGFyaWZ5IHdoZXJlIHlvdSBzZWUgc3Bs aXQgVENQIGluIFJGQzE5MjgsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCd IGluIFJGQzE5MjggaW4gdGhlIHNhbWUgd2F5IEkgZG9u4oCZdCBzZWUg4oCcc3BsaXQgVENQ4oCd IGluIHRoZSBwbGFpbi1tb2RlIGRyYWZ0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGhpbmcgaW4gUkZDMTkyOSB0YWxrcyBh Ym91dCB0cmFuc2xhdGluZyBTWU5zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPltNZWRdIEkgZ3Vlc3MgeW91 IG1lYW50IFJGQzE5MjguIFRyYW5zbGF0aW5nIHBhY2tldHMgaXMgbm90IGV4cGxpY2l0ZWQgaW4g dGhlIHRleHQsIGJ1dCBpdCBpcyBoaW50ZWQuIEZvciBleGFtcGxlLCB0aGUgdGV4dCBzYXlzIHRo ZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndp bmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGVuIGEgVENQ LWJhc2VkIGNsaWVudCB3aXNoZXMgdG8gZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB0byBhbiBvYmpl Y3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyB0aGF0IGlzIHJlYWNoYWJsZSBvbmx5IHZpYSBhIGZpcmV3YWxsIChzdWNoIGRldGVybWlu YXRpb24gaXMgbGVmdCB1cDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7Jm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiksIGl0IG11c3Qgb3BlbiBh IFRDUCBjb25uZWN0aW9uIHRvIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFwcHJvcHJpYXRlIFNPQ0tTIHBvcnQgb24gdGhlIFNP Q0tTIHNlcnZlciBzeXN0ZW0uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+SG93IGEgY29ubmVjdGlv biBmcm9tIGEgY2xpZW50IHRvIGEgc2VydmVyIHdpdGggRFNUQD1TT0NLU19Qcm94eSB3aWxsIGJl IHJlbGF5ZWQgdG8gdGhhdCByZW1vdGUgc2VydmVyIHdpdGhvdXQgZ2x1aW5nIGNvbm5lY3Rpb25z IGluIGJvdGggc2lkZXM/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0J3MgY2FsbGVkIGEgY29udmVudGlvbmFsIHByb3h5LiBUaGUgM1dIUyBj b21wbGV0ZXMgdG8gdGhlIFNPQ0tTIHNlcnZlciwgdGhlbiB0aGUgU09DS1Mgc2VydmVyIG9wZW5z IGEgbmV3IGNvbm5lY3Rpb24uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPltNZWRdIFRoZSBleHRlcm5hbCBiZWhhdmlvciBpcyB0aGF0IGEgcmVjZWl2ZWQg U1lOIHdpbGwgdHJpZ2dlciBhbiBvdXRnb2luZyBTWU4uIFdoYXQgaGFwcGVucyBpbnNpZGUgdGhl IHByb3h5IGl0c2VsZiBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4NCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPC9zcGFuPiZxdW90O29wZW4gYSBUQ1AgY29ubmVjdGlv biZxdW90OyBtZWFucyBmaW5pc2hpbmcgdGhlIDNXSFMuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij5UaGF0IOKAnGdsdWXigJ0gY2Fu IGJlIHNlZW4gYXMgdHJhbnNsYXRpbmcgcGFja2V0cyBieSBtZWFucyBvZiBTTkFUL0ROQVQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPihz aWRlIG5vdGU6IEnigJltIHN1cmUgdGhhdCBSRkMxOTI4IHdpbGwgbmV2ZXIgYmUgcHVibGlzaGVk IGFzIGl0IGlzIGluIDIwMTcuIEkgaGVhciBmcm9tIGhlcmUgcGVvcGxlIHRoYXQgd2lsbCBhcmd1 ZSB0aGF0IFJGQzE5MjggaXMgdW5kZXJzcGVjaWZpZWQpJm5ic3A7DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZXkgY2FuIHVwZGF0 ZSB0aGF0IFJGQyBpZiB0aGV5IHdhbnQuIEhvd2V2ZXIsIHRoYXQgUkZDIHNwZWNpZmllcyBhIGNv bnZlbnRpb25hbCBhcHBsaWNhdGlvbiBsYXllciBwcm94eSAtIHNlZSBTZWN0aW9uIDMuPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+LSBpdCBkb2Vzbid0IGV2ZW4gbWVudGlvbiBzcGVjaWZpYyBUQ1Agc2VnbWVu dHMgYXQgYWxsLCBidXQgcmVmZXJzIG9ubHkgdG8gdGhlIHN0YW5kYXJkIFRDUCBBUEksIHdoZXJl IHVzZXIgZGF0YSB3b3VsZCBiZSBhdmFpbGFibGUgb25seSBhZnRlciB0aGUgM1dIUyBiZXR3ZWVu IHRoZSBjbGllbnQgYW5kIHRoZSBTT0NLUyBwcm94eS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90 OyI+W01lZF0gVGhhdOKAmXMgYWxzbyB0aGUgY2FzZSBmb3IgdGhlIE1QVENQIHByb3h5LiBUaGUg dXNlciBkYXRhIHdpbGwgYmUgYXZhaWxhYmxlIE9OTFkgb25jZSB0aGUgM1dIUyBpcyBjb21wbGV0 ZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NClNvIGEgU1lOIGFycml2ZXMgYXQgdGhlIE1QVENQIHByb3h5IGZyb20gdGhlIGNsaWVu dC4gV2hhdCBoYXBwZW5zIG5leHQ/PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPltNZWRdIEl0IGV4dHJhY3RzIHRoZSBhZGRyZXNzL3BvcnQgb2YgdGhlIHJl bW90ZSBzZXJ2ZXIgYW5kIHNlbmRzIGEgU1lOIHRvIHRoYXQgYWRkcmVzcy9wb3J0Lg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCklmIHRoZSBhbnN3ZXIgaXNuJ3QgJnF1b3Q7Y29tcGxldGUgdGhlIDNXSFMgdG8gdGhl IGNsaWVudCZxdW90OywgaXQncyB3cm9uZy4gPC9zcGFuPkJ1dCB0aGF0J3Mgbm90IHdoYXQgRkln IDUgaW4geW91ciBkb2Mgc2hvd3MuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPltNZWRdIFRoZSBwcm94eSBjYW4gKDEpIGNvbXBsZXRlIHRoZSAzV0hTIHRv IHRoZSBjbGllbnQ7IHRoZSBkb2N1bWVudCBzYXlzIHRoZSBmb2xsb3dpbmc6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJz cDsg4oCcQ29uY2VwdHVhbGx5LCB0aGUgTUNQIGFjdHMgYXMgYSByZWxheSBiZXR3ZWVuIGFuIHVw c3RyZWFtIE1QVENQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBjb25u ZWN0aW9uIGFuZCBhIGRvd25zdHJlYW0gVENQIGNvbm5lY3Rpb24u4oCdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyDigJxUaGUgTUNQIG1hcHMgYW4gdXBzdHJlYW0gTVBUQ1Ag Y29ubmVjdGlvbiAoYW5kIGl0cyBhc3NvY2lhdGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+Jm5ic3A7Jm5ic3A7IHN1YmZsb3dzKSBvbnRvIGEgZG93bnN0cmVhbSBUQ1AgY29ubmVjdGlv bi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDvi gJxBdCB0aGlzIHBvaW50LCB0aGVyZSBhcmUgdHdvIGVzdGFibGlzaGVkIGNvbm5lY3Rpb25zLiZu YnNwOyBUaGUgZW5kcG9pbnRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5i c3A7b2YgdGhlIHVwc3RyZWFtIE11bHRpcGF0aCBUQ1AgY29ubmVjdGlvbiBhcmUgdGhlIE11bHRp cGF0aCBUQ1AgQ2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBh bmQgdGhlIE1DUC4mbmJzcDsgVGhlIGVuZHBvaW50cyBvZiB0aGUgZG93bnN0cmVhbSBUQ1AgY29u bmVjdGlvbiBhcmUgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBN Q1AgYW5kIHRoZSBTZXJ2ZXIuJm5ic3A7IFRoZXNlIHR3byBjb25uZWN0aW9ucyBhcmUgYm91bmQg YnkgdGhlIE1DUC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5vciAoMikgY2FuIHByb2NlZWQgYSBsYSBOQVQgKGUuZy4sIEZpZyA1KS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBo YXZlIHRyYWRlLW9mZnM6IGlmIHdlIGNvbXBsZXRlIHRoZSAzV0hTIGJlZm9yZSBhbiBhbnN3ZXIg aXMgcmVjZWl2ZWQgZnJvbSB0aGUgc2VydmVyLCB3ZSBsb3NlIHRoZSBmb2xsb3dpbmcgZmVhdHVy ZSB0aGF0IHdlIHdvdWxkIGxpa2UgdG8gb2ZmZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7IFdoZXRoZXIgYW4gTUNQ IG11c3QgYmUgbWFpbnRhaW5lZCBpbiB0aGUgcHJvY2Vzc2luZyBvZiBhbiBNUFRDUDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgY29ubmVjdGlvbiB0aGF0IGludm9sdmUg TVBUQ1AtY2FwYWJsZSBjbGllbnRzIGFuZCBzZXJ2ZXIgaXMgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5j b25maWd1cmFibGUgcGFyYW1ldGVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPldoZXRoZXIgd2UgbmVlZCB0byBoYXZlIGJvdGggb3IgcmVjb21t ZW5kIG9uZSBhcHByb2FjaCBpcyBiZSB3b3JrZWQgb3V0IG9uY2Ugd2UgaGF2ZSBhIFdHIGRvY3Vt ZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgc3BlY2lmaWNhdGlvbiBpcyBub3QgZnJv emVuIGFuZCB5b3VyIHN1Z2dlc3Rpb25zL2NvbW1lbnRzIHdpbGwgYmUgdGFrZW4gaW50byBhY2Nv dW50Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQpGaWd1cmUgNSBvZiBTZWMgNS4yIG9mIHlvdXIgZG9jdW1lbnQgY2xlYXJs eSBzaG93cyBhbiBpbmNvbWluZyBTWU4gZ2VuZXJhdGluZyBhbiBvdXRnb2luZyBTWU4gYmVmb3Jl IHRoZSBjbGllbnQgU1lOL0FDSyBpcyByZXR1cm5lZC4NCjwvc3Bhbj5Zb3UgZG9uJ3QgbWVudGlv biBzcGxpdC1UQ1AgKGFuZCBpdCBoYXMgdGFrZW4gbW9yZSB0aGFuIHRvbyBsb25nIHRvIGZpZ3Vy ZSBvdXQgdGhhdCdzIHdoYXQncyBnb2luZyBvbiBoZXJlKSwgYnV0IHRoYXQgaXMgd2hhdCB5b3Ug c2hvdy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+b3IgYXJlIHlvdSBjb25mdXNp bmcgaXQgd2l0aCB0aGlzLCB3aGljaCBhZGRzIHNwbGl0IFRDUCB0byBhIFNPQ0tTIHByb3h5Ojwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3dubG9hZD9k b2k9MTAuMS4xLjM0Ljk5MTUmYW1wO3JlcD1yZXAxJmFtcDt0eXBlPXBkZiI+aHR0cDovL2NpdGVz ZWVyeC5pc3QucHN1LmVkdS92aWV3ZG9jL2Rvd25sb2FkP2RvaT0xMC4xLjEuMzQuOTkxNSZhbXA7 cmVwPXJlcDEmYW1wO3R5cGU9cGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIEJpbmdvLiBUaGF0IGlzIGV4YWN0 bHkgbXkgcG9pbnQuIFdlIG5lZWQgdG8gYXZvaWQgbWl4aW5nIGltcGxlbWVudGF0aW9uIGRldGFp bHMgd2l0aCBiYXNlIHNwZWNpZmljYXRpb25zLiBUaGF0IGlzIGV4YWN0bHkgdGhlIHJlYXNvbiB3 aHkgSSBzYWlkIGVhcmxpZXIgdGhhdCBtcHRjcA0KIHByb3h5IGRvY3VtZW50cyBvbmx5IGRlc2Ny aWJlIHRoZSBleHRlcm5hbCBiZWhhdmlvci4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBzbyBrZWVwIEFMTCBkaXNjdXNzaW9u cyBvZiBTWU4gKG9yIGFueSBzZWdtZW50IHRyYW5zbGF0aW9uKSBvdXQgb2YgdGhpcyBkb2N1bWVu dCAtIGluY2x1ZGluZyB0aGUgZmlndXJlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+W01lZF0gSeKAmW0g cGVyc29uYWxseSBmaW5lIHdpdGggeW91ciBwcm9wb3NhbCwgYnV0IEnigJltIHN1cmUgd2Ugd2ls bCBoYXZlIGEgbG90IG9mIGNvbW1lbnRzIGFza2luZyBmb3IgbW9yZSBkZXRhaWxzLiBGaWd1cmVz IGFyZSBub3Qgbm9ybWF0aXZlOyB0aGV5IGFyZQ0KIHByb3ZpZGVkIGZvciBpbGx1c3RyYXRpb24g cHVycG9zZXMuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KSWYgeW91IGNh biBleHBsYWluIHRoaXMgdXNpbmcgdGhlIGV4aXN0aW5nIFRDUCBBUEksIGUuZy4sIE9QRU4vQ0xP U0UvQUJPUlQvU1RBVFVTIGFuZCBTRU5EL1JFQ0VJVkUgKFJGQzc5MyBTZWMgMy45KSwgdGhlbiBz dXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KSG93IGRvIHlvdSBhY2hpZXZlIHplcm8tZGVsYXkgRTJFIG90aGVyd2lzZT8gT3IgYXJl IHlvdSBhc3N1bWluZyB6ZXJvLWRlbGF5IG9ubHkgd2l0aGluIHRoZSBNUFRDUCBjb25uZWN0aW9u PzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBX ZSBhcmUgYWNoaWV2aW5nIDAtUlRUIE1QVENQIHByb3h5aW5nIGJlY2F1c2UmbmJzcDs6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm81Ij48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBk b27igJl0IGhhdmUgb3V0IG9mIGJhbmQgc2lnbmFsaW5nIHRvIGNvbW11bmljYXRlIHdpdGggdGhl IHByb3h5IChmb3IgdGhlIHJlY29yZCwgdGhlcmUgYXJlICYjNDM7MTAgVENQIG1lc3NhZ2VzIHdo ZW4gU09DS1N2NSBpcyBpbiB1c2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIGluaXRpYWwgU1lOIGluY2x1ZGVzIHRoZSBpbmZv cm1hdGlvbiBhYm91dCB0aGUgdWx0aW1hdGUgc2VydmVyOyB0aGF0IHNlcnZlciB3aWxsIGJlIGNv bnRhY3RlZCBpbW1lZGlhdGVseS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5Gb3IgZXhhbXBsZSwgYmVjYXVzZSB3ZSBhcmUgbGV2ZXJhZ2luZyBvbiBC RUhBVkUgUkZDcywgYSBwcm94aWVkIE1QVENQIGNvbm5lY3Rpb25zIHdpbGwgZXhwZXJpZW5jZSB0 aGUgc2FtZSBkZWxheSBhcyBhIFRDUCBjb25uZWN0aW9uDQogdGhhdCBnb2VzIHRocm91Z2ggYSBD R04vTkFUNjQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQpCdXQgbm93aGVyZSBpbiB0aGF0IEFQSSBkb2VzIFRDUCB0 ZWxsIHlvdSB3aGVuIGEgU1lOIGFycml2ZXMgKmJlZm9yZSogc2VuZGluZyBhIFNZTi1BQ0suPGJy Pg0KPGJyPg0KPC9zcGFuPi0tLS0tPGJyPg0KQXMgdG8geW91ciBURk8gYXJndW1lbnQsIHRoZSBw cm9ibGVtIGlzIHRoaXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gd2hhdCBoYXBw ZW5zIHRvIHRoZSBmaXJzdCBNUFRDUCBjb25uZWN0aW9uIGZyb20gcHJveHkgdG8gcHJveHk/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xv clw6YmxhY2smcXVvdDsiPltNZWRdIERvIHlvdSBtZWFuIHRoZSBmaXJzdCBNUFRDUCBjb25uZWN0 aW9uIHRoYXQgaXMgcHJveGllZD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+T3IgdGhlIGZpcnN0IHN1YmZsb3cgb2YgYSBwcm94 aWVkIE1QVENQIGNvbm5lY3Rpb24/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgd2h5IGRvIHlvdSB0cmVhdCB0aGlz IGRpZmZlcmVudGx5IHRoYW4gYSB0eXBpY2FsIE1QVENQLCBhbmQgd2hhdCBpbmZvcm1hdGlvbiBs ZXRzIHlvdSBkbyBzbz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPltNZWRdIENhbiB5b3UgcGxl YXNlIGV4cGxpY2l0IHlvdXIgcXVlc3Rpb24/IEFyZSB5b3UgcmVmZXJyaW5nIHRvIGEgbXVsdGlw YXRoIGNsaWVudCwgbXVsdGlwYXRoIHNlcnZlciwgb3IgcHJveHk/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJJ20gYXNraW5nIGhvdyB0 aGUgTVBUQ1AgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSB0d28gcHJveGllcyBpcyBkaWZmZXJlbnQg ZnJvbSBhIHR5cGljYWwgTVBUQ1AgY29ubmVjdGlvbiBhcyBjdXJyZW50bHkgc3BlY2lmaWVkLjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBPSywg dGhhbmtzLiBJdCBpcyBub3QgZGlmZmVyZW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPk5vIGNoYW5nZSBpcyByZXF1 aXJlZCBmb3IgTVBUQ1AtdW5hd2FyZSBjbGllbnRzIGFuZCBzZXJ2ZXJzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPk1QVENQIHByb2Nlc3Np bmcgYXQgdGhlIE1QVENQLWF3YXJlIHNlcnZlciBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNp ZmljYXRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJs YWNrJnF1b3Q7Ij5NUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBjbGllbnQgaW4g dGhlIGR1YWwtcHJveHkgY2FzZSBmb2xsb3dzIHRoZSBiYXNlIE1QVENQIHNwZWNpZmljYXRpb24u DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7 Ij5NUFRDUCBwcm9jZXNzaW5nIGF0IHRoZSBNUFRDUC1hd2FyZSBjbGllbnQgaW4gdGhlIHNpbmds ZS1wcm94eSBjYXNlIHdpbGwgcmVxdWlyZSB0byBzdXBwbHkgdGhlIE1QX0NPTlZFUlQgaW4gdGhl IGluaXRpYWwgc3ViZmxvdy4gQSBwYXJ0IGZyb20NCiB0aGF0LCBpdCBmb2xsb3dzIHRoZSBiYXNl IE1QVENQIHNwZWNpZmljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxl dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBc O2NvbG9yXDpibGFjayZxdW90OyI+TVBUQ1AgcHJvY2Vzc2luZyBhdCB0aGUgcHJveHkgd2lsbCBy ZXF1aXJlIHRvIHByb2Nlc3MgdGhlIE1QX0NPTlZFUlQgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8g Y3JlYXRlIGEgZm9yd2FyZGluZyBzdGF0ZSBmb3IgdGhhdCBNUFRDUCBjb25uZWN0aW9uLg0KIEEg cGFydCBmcm9tIHRoYXQsIGl0IGZvbGxvd3MgdGhlIGJhc2UgTVBUQ1Agc3BlY2lmaWNhdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBs ZXNzIGludGVyZXN0ZWQgaW4gdGhlIGRldGFpbHMgb2YgdGhlIE1QVENQIG9wdGlvbnMgdGhhbiBp biBob3cgdGhlIEFQSSBjaGFuZ2VzLjxicj4NCjxicj4NClRoZSBjdXJyZW50IE1QVENQIEFQSSBv cGVucyBpbml0aWFsIGNvbm5lY3Rpb25zIG9ubHkgaW4gcmVzcG9uc2UgdG8gdXNlciBjYWxscyB0 byBPUEVOLiBUaGF0IGRvZXNuJ3QgYXBwZWFyIHRvIGJlIHRoZSBjYXNlIGhlcmUuPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQpJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGlzIGRvYyB0aGF0IHF1YWxp ZmllcyBhcyB3aGF0IFRGTyBjYWxscyBlaXRoZXIgYSBjb29raWUgYmV0d2VlbiBzZXNzaW9ucyBv ciBhbnkgc3Vic3RpdHV0ZSBiYXNlZCBvbiBhdXRoZW50aWNhdGlvbiBvciBhdXRob3JpemF0aW9u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+W01lZF0gSSBhbHJlYWR5IHByb3ZpZGVkIGEgcG9p bnRlciB0byB0aGUgc2xpZGVzIHdoZXJlIHRoaXMgaXMgZGlzY3Vzc2VkLiBZb3UgY2FuIGFsc28g cmVmZXIgdG8NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uYW0t bXB0Y3AtZGVwbG95bWVudC1jb25zaWRlcmF0aW9ucy0wMSNzZWN0aW9uLTUuMyI+DQpkcmFmdC1u YW0tbXB0Y3AtZGVwbG95bWVudC1jb25zaWRlcmF0aW9ucy0wMSNzZWN0aW9uLTUuMzwvYT46IDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyBUaGUgTmV0d29yayBQcm92aWRlciB0aGF0IG1hbmFnZXMgdGhlIHZhcmlv dXMgbmV0d29yayBhdHRhY2htZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IChpbmNsdWRpbmcgdGhlIE1DUHMpIG1heSBlbmZvcmNl IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcG9saWNpZXMgdXNpbmcgYXBwcm9w cmlhdGUgbWVjaGFuaXNtcy4mbmJzcDsgRm9yIGV4YW1wbGUsIGEgbm9uLWV4aGF1c3RpdmU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg O2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBs aXN0IG9mIG1ldGhvZHMgdG8gYWNoaWV2ZSBhdXRob3JpemF0aW9uIGlzIHByb3ZpZGVkIGhlcmVh ZnRlcjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCllvdSdyZSB0YWxraW5nIGFib3V0IGF1dGhvcml6YXRpb25zIG9mIHVzZXJzIGFuZCBh Y2Nlc3MgY29udHJvbC4gVEZPIGlzIGF1dGhvcml6aW5nIGNvbm5lY3Rpb25zIGluIG9yZGVyIHRv IGRlY2lkZSBpZiB0aGV5J3JlIG5ldyBvciBvbGQuIFRoZXkncmUgZGlmZmVyZW50IHRoaW5ncy48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhl eSBhcmUgZGlmZmVyZW50IHRoaW5ncyBidXQgYWNoaWV2ZSB0aGUgc2FtZSBwdXJwb3NlOiBwcmVz ZXJ2ZSB0aGUgc2VydmVyIGZyb20gbWlzdXNlL2FidXNlL0RvUy4gV2hldGhlciBNUFRDUCBwcm94 eSBoYXMgdG8gY2hlY2sgbmV3L29sZCBjb25uZWN0aW9ucw0KIGlzIGRlcGxveW1lbnQtc3BlY2lm aWMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5k b3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsuLi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJy Pg0KSSBhZ3JlZSB0aGF0IHlvdSdyZSBub3Qgc3RyaWN0bHkgY2xvbmluZyBURk8gLSBJTU8sIHlv dSdyZSB0cnlpbmcgdG8gcmVpbnZlbnQgVEZPIHdpdGhvdXQgbGV2ZXJhZ2luZyB0aGUgZXhwZXJp ZW5jZSB0aGUgY29tbXVuaXR5IGhhcyBkZXZlbG9wZWQgaW4gdGhhdCBwcm9jZXNzLCBhbmQgSU1P IHlvdSdyZSByZXBlYXRpbmcgc29tZSBvZiB0aGUgbWlzdGFrZXMgb24gdGhhdCBqb3VybmV5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyBcO2NvbG9yXDpibGFjayZxdW90OyI+W01lZF0gSSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRo aXMuIFdlIGFyZSBsZXZlcmFnaW5nIG9uIHRoZSBndWFyZHMgYXMgZGlzY3Vzc2VkIGluIFRGTyBz cGVjaWZpY2F0aW9uOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9y XDpibGFjayZxdW90OyI+QW50aS1zcG9vZmluZyBmaWx0ZXJzIGFyZSBpbiBwbGFjZSBpbiB0aGUg YWNjZXNzIHNlZ21lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9y XDpibGFjayZxdW90OyI+VEZPIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGEgY29va2llLWxlc3Mg c2NoZW1lIGlmIHRoZSBzZXJ2ZXIgaXMgaW1tdW5lLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCkFuZCBJIGRpc2FncmVlIHRoYXQgeW91IGhhdmUgcHJvdmVuIHlvdXIgc2VydmVyIHRv IGJlIGltbXVuZS48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBDYW4geW91IHByb3ZpZGUgYW4g ZXhhbXBsZSBvZiBhdHRhY2sgeW91IGhhdmUgaW4gbWluZCBmb3IgdGhlIE1QVENQIHByb3h5Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj5Kb2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933009E5E00FOPEXCNORMADcorp_-- From nobody Fri Apr 28 05:35:03 2017 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 44CA912EA7A for ; Fri, 28 Apr 2017 05:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw8_fSQOLq7g for ; Fri, 28 Apr 2017 05:34:48 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) (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 AF7B7129B22 for ; Fri, 28 Apr 2017 05:31:23 -0700 (PDT) Received: from [85.158.139.163] by server-15.bemta-5.messagelabs.com id 58/2E-01730-A1633095; Fri, 28 Apr 2017 12:31:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRWlGSWpSXmKPExsWi75nTpStmxhx pcPmPqMWL1z0sFp9XX2ezWLZ2BaMDs0fbl8lMHkuW/GTymPHpC1sAcxRrZl5SfkUCa8bh7x4F K3IrJm4+z9jAeD6zi5GLQ0hgO6NE17lXzF2MnEDOYUaJ9QsVIRJA9vE1/5khnE2MEm8/LmYFq WITcJA4+ughWIeIQKTElLk32UBsZoFUifX7msBqhAU8JL6+fM4KUeMp8enVXcYuRg4gO0zi4S FnkDCLgKrEjQ27WUBsXoFQiY8vrrJD7WKW6Dg1BWwmJ1Ci+XQjWBGjgKzEhg3nmSF2iUtsevY dbL6EgIjEw4un2SBsUYmXj/+xggxiFpjPKLFoKkQRr4CgxMmZT1hAjhASUJc4P9VhAqPoLCSj ZiFrmYWkBaJIX+LyvrOsELa2xLKFr5khbGuJGb8OskHYihJTuh+yQ9imEq+PfmRcwMixilG9O LWoLLVI10QvqSgzPaMkNzEzR9fQwFQvN7W4ODE9NScxqVgvOT93EyMwchmAYAfjrT7nQ4ySHE xKorylrMyRQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4RUyBcoJFqempFWmZOcAUApOW4OBREuH NA0nzFhck5hZnpkOkTjEqSonzRoMkBEASGaV5cG2wtHWJUVZKmJcR6BAhnoLUotzMElT5V4zi HIxKwrxMIFN4MvNK4Ka/AlrMBLSYxYUBZHFJIkJKqoFRjLHu5I1ZVSfyPtxWsZIvm9+rcv+Iv qKTfP6WMEWlK+E7jFIVr09ZpR292JCNQ780rfGq9/nfK75U2sczdDi6PF72iH/7CwbDs5y/XV bMUlrZGC7YY8GtVCb359r0N7unGvyOU+jIixE/7s909HBk1t9ZCe/P2/gkfe541h1puU5G8o2 SiYASS3FGoqEWc1FxIgC1KGKLVgMAAA== X-Env-Sender: ullrich.meyer@vodafone.com X-Msg-Ref: server-15.tower-188.messagelabs.com!1493382664!104963964!10 X-Originating-IP: [47.73.108.138] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7908 invoked from network); 28 Apr 2017 12:31:18 -0000 Received: from vgdpm12vr.vodafone.com (HELO voxe02hw.internal.vodafone.com) (47.73.108.138) by server-15.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Apr 2017 12:31:18 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 14:31:03 +0200 Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 14:31:03 +0200 Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 28 Apr 2017 14:31:03 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.88]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0294.000; Fri, 28 Apr 2017 14:31:01 +0200 From: "Meyer, Ullrich, Vodafone DE" To: "philip.eardley@bt.com" , "lars@netapp.com" CC: "multipathtcp@ietf.org" , "philip.eardley@bt.com" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQCSLSEA///y9gCAAAMwgIAACAeA//mir4D/7jX7gA== Date: Fri, 28 Apr 2017 12:31:01 +0000 Message-ID: <378851B30BE1AA4E85FFD1FAFE10ABE6A7272049@VOEXM20W.internal.vodafone.com> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0084_01D2C02C.0E7CF550" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 12:35:01 -0000 ------=_NextPart_000_0084_01D2C02C.0E7CF550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, herewith I want to declare very clearly our (Vodafone) interest on that MPTCP proxy work within the IETF. The work has our plenary support. Kind regards, Ullrich Meyer=20 Senior Engineer Service Design VPN Solution Engineering within Group Network Engineering and Delivery FixLine: +49 69 2169 3290 Mobile: +49 172 190 3120 Email: ullrich.meyer@vodafone.com Vodafone GmbH, D=FCsseldorfer Stra=DFe 15, 65760 Eschborn vodafone-deutschland.de=20 Die gesetzlichen Pflichtangaben finden Sie unter www.vodafone.de/pflichtangaben=20 -----Urspr=FCngliche Nachricht----- Von: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Gesendet: Dienstag, 25. April 2017 09:12 An: BOUCADAIR Mohamed IMT/OLN ; lars@netapp.com Cc: multipathtcp@ietf.org Betreff: RE: [multipathtcp] Consensus call on potential MPTCP proxy work Just to clarify our interpretation of the various hums during the = meeting. We interpreted them as indicating there was one topic that it was = worthwhile doing a consensus call on. We did not interpret the hums as indicating = clear consensus that we merely needed to confirm on the list. So far we see: In favour: christian.jacquenet@orange.com mohamed.boucadair@orange.com William Ivancic Stefano Secci Henderickx, Wim (Nokia - BE/Antwerp) David Allan I Markus.Brunner3@swisscom.com Robert Skog = Olivier Bonaventure Costin Raiciu Against: Joe Touch Juliusz Chroboczek Eggert, Lars It is therefore important to hear views from other people. Of course it = is also welcome for the technical discussion to continue (indeed, some = people may want more of the technical discussion before giving their view on = the consensus call). Thanks Phil & Yoshi -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: 21 April 2017 07:55 [cut] Lacking that information, I don't see a new element here that could lead = to change the consensus reached at the Chicago meeting (of course I'm not entitled to do that call anyway). ------=_NextPart_000_0084_01D2C02C.0E7CF550 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCHNUw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIID2TCCAsGgAwIBAgIQ arIkI0+EDLdJJ6IagXQjXDANBgkqhkiG9w0BAQUFADBQMQswCQYDVQQGEwJVSzEXMBUGA1UECgwO Vm9kYWZvbmUgR3JvdXAxKDAmBgNVBAMMH1ZvZGFmb25lIChJbnRlcm5hbCBEb21haW4gMjAwOSkw HhcNMDkwMzE4MTE0MzA2WhcNMjEwOTE4MTE0OTU5WjBQMQswCQYDVQQGEwJVSzEXMBUGA1UECgwO Vm9kYWZvbmUgR3JvdXAxKDAmBgNVBAMMH1ZvZGFmb25lIChJbnRlcm5hbCBEb21haW4gMjAwOSkw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZVTp5m4AgWqVAvGfrg5Db8FNe1pVQnotp NulXVLpGK7YAzfNbV78/sB2VdD8sk6xxW0PONLQ8jSVowM8hpLVNYKZbjRRfjczifsi7w6LdkEp2 OLsNg1iax+kWG5BHB7M507if90RlBNkJGRkq3AaelId4HgTmhXp0tsL42LLNyUtCf+G2xcaCjVZm gFRqxeuUcg9HfxhcUkWkoFAFV1OCS2ybh/BdrEtFgSnlVEFMZINu+4YPpk6SL3yc0OXCuOMp/RrG o82PbtPp2sGTIhf0vy7zF289Gd7ms/nJm5kmk6io8/4fTL7DedmtVk1pR2ZZBZN/yfV9p8/NZp1c 44CpAgMBAAGjga4wgaswDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE FKJge8eKIB+iQ7hqKS3n0eq309PQME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly9jcmwuY2Eudm9k YWZvbmUuY29tL2NybC9Wb2RhZm9uZUludGVybmFsRG9tYWluMjAwOS5jcmwwGQYDVR0gBBIwEDAO BgwqhjoAAe/1TwEBBQEwDQYJKoZIhvcNAQEFBQADggEBAHVnIMgbsTdu3F+Aq2HWeKattip5AiRQ rQQoWuvHjboo61iM5LF3NrzwfWSmdr3UZrpTlQruDUYBjgdoEaE5rGOose+bdYnBSdJnj938yQ2T fePCWEN9afM/o3vTjozas0xE2vIFbWyrXXUGx0Mq+fr9qdX6Zm2ZfAKaHX3v8uv3etn+kZPjxzyG rMpXDPalDYB5GZZ/My1HvzKsKkAUA2H3JhH1toPEB/VgxrJKDnSRHg2WVKTJJAwmf0/sD9E8YEd1 iCkVXr5SMo6tSCzoWyUBg4gCnIWDdvNNeWUhwsDRHhTYsQQPccMT4HuB825bJ3b2VTM8IVfD5Zi4 Yo7SxtowggQCMIIC6qADAgECAhN3AAAADYNIwkJ4MGFRAAAAAAANMA0GCSqGSIb3DQEBBQUAMFAx CzAJBgNVBAYTAlVLMRcwFQYDVQQKDA5Wb2RhZm9uZSBHcm91cDEoMCYGA1UEAwwfVm9kYWZvbmUg KEludGVybmFsIERvbWFpbiAyMDA5KTAeFw0xMzAzMDQxNTE1NTZaFw0yMTA5MDQxNTI1NTZaMFIx CzAJBgNVBAYTAlVLMRcwFQYDVQQKDA5Wb2RhZm9uZSBHcm91cDEqMCgGA1UEAwwhVm9kYWZvbmUg KEludGVybmFsIFNlcnZpY2VzIDIwMDkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA jj5eEwIKMBkDkVz7h9wI+nCxXvN940oKfiMqmyfBtJAhKCHpORJLvw4ewMVqMKGzluPxu6vpMDee /2q2FSOg3MdmEAG9sAvTKBFO7L8txf7as2FHkn/guNXmZJQI2vTiv8YcbGLKhRD2BQCgvTnrp6sA popiht7oRA9FNE/9LxA6yUN+phpbrLeKDHr9MND2sLL/Lqh1+KwdfphCnREwjod9QJXiyhwasTPt nq59Q/dKkpr2r+BL727/uMIx40GJKKI/iOcDNM6RrxKqcc/LdzvtcJxnq5lIj7568A4s//7XqREa KS5ZCTbu+7ohV8u1CIVYYLWm0VJhudw5EfaJeQIDAQABo4HSMIHPMA4GA1UdDwEB/wQEAwIBBjAd BgNVHQ4EFgQUtJ1QB4XPHGuZcucKfakN0+W2rWUwGQYDVR0gBBIwEDAOBgwqhjoAAe/1TwEBBQEw EgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBSiYHvHiiAfokO4aikt59Hqt9PT0DBOBgNV HR8ERzBFMEOgQaA/hj1odHRwOi8vY3JsLmNhLnZvZGFmb25lLmNvbS9jcmwvVm9kYWZvbmVJbnRl cm5hbERvbWFpbjIwMDkuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA6n1b23QQGSWsCKz8t/d7MBvSU 82mMbsgTk8tpGqYcrErmQjSyAWRDNurjXWlzSHtiLFR03gC5S5I6t1ZDra9GFgdFoNVzMxJTNP29 Ett1rPaKkbfFY13Uth/VNHVrHvRMFY7WIRQZ0U3rGLE254pmZ5dBTcc+0xUn0fF6NloKdXGGE31k YjaqEGUUSH32xckIxl1EEt4wL02ORp5zEi4rMpDzoUj3jb+qyokiVsRCfbe8t6JAEbwB0tkwARXE XZe0kZBTpvAKA761oHmUCXRzR6wPHVSI/he4EyteqmAbMGRtExlStOSitKB42xDzdXhgY5HdCoIK 0rt7LzPleB1qMIIFKTCCBBGgAwIBAgITdwAgMOEQvFu3KiM9HgABACAw4TANBgkqhkiG9w0BAQUF ADBSMQswCQYDVQQGEwJVSzEXMBUGA1UECgwOVm9kYWZvbmUgR3JvdXAxKjAoBgNVBAMMIVZvZGFm b25lIChJbnRlcm5hbCBTZXJ2aWNlcyAyMDA5KTAeFw0xNzA0MDMyMjQ1NDNaFw0xODA0MDMyMjQ1 NDNaMEMxFjAUBgNVBAMMDVVsbHJpY2guTWV5ZXIxKTAnBgkqhkiG9w0BCQEWGnVsbHJpY2gubWV5 ZXJAdm9kYWZvbmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwEic9kH+7/wA RpjNpGu5X6iE6QnQ1qp9W2Z0fPzRDrC5nw+Nsisc8D3rAI6kQnsR1iUjaS2TVzkb2cmGhO570w6r ArK+Q26ZSeZyT+ACvfr2jLx2kacJ35bcC+46itvoKTmBuqoZuNWk3453NaIC/sdsKhAZEJU6FItc tdqrkC7vlUAftZgeOfQTBfE1LGOIfhOeTggMcXYdN6lQUpe5tW93YTSVBoyrWuV8LWdzrrExzOs5 /C/xITYmHo6BND0RmNOs/8dFF3WjNqZK232cgAzyYPXAAAh34NAyoaPqpW1ZivXLHbfT2QXb6s++ S//9I8Lnl1JciEZIRC2GmMh0lQIDAQABo4ICBTCCAgEwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGC NxUI2olr9bBrgaGfGIOo5hWCr+8ggTuC74EKhZuKKAIBZQIBADAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMBoGA1UdIAQTMBEwDwYNKoY6AAHv9U8BAQUCBDAn BgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTm8aTTSKU9 Jhs8yaDGRr841FLIxzAfBgNVHSMEGDAWgBS0nVAHhc8ca5ly5wp9qQ3T5batZTBTBgNVHR8ETDBK MEigRqBEhkJodHRwOi8vY3JsLmNhLnZvZGFmb25lLmNvbS9jcmwvVm9kYWZvbmVJbnRlcm5hbFNl cnZpY2VzMjAwOSgxKS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFAGCCsGAQUFBzAChkRodHRwOi8v Y2VydC5jYS52b2RhZm9uZS5jb20vY2VydC9Wb2RhZm9uZUludGVybmFsU2VydmljZXMyMDA5KDEp LmNlcjAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AuY2Eudm9kYWZvbmUuY29tL29jc3AwJQYDVR0R BB4wHIEadWxscmljaC5tZXllckB2b2RhZm9uZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAIRAq9/V XP4qDjtcn131to/QmoLFDaTGDhqbCVxlmiCLcLLa9Qc2cb5bd29thp1LLFSWZjk9KyaTAYGT54J3 wGEgVyMyGLKklGdeta0x3POSaBiU581vcPJqmpL1ivaPH2I42uv+YyzacMPSMRHnETrJ5Rxx3ufZ 71g6e5Bd2o4AeDILiBhNCkOGU8F7Tz4MthKqm571JhwZlM9BqKoJhTFrd/dOxrrhEHJ27TVl6mhT sEGklRdnLrh7v9jeGkSi8S0Q659Mbq5nhxu8agWKnE90468k47zwjT1XvJ+MS6dFoor31KVpKYML LUzKM1MJ34LTUB/B0S/XWZ4hRegqgEUwggW0MIIEnKADAgECAhAGFWMNzGzTO/5Hve0s9sqJMA0G CSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBD QTAeFw0xNzAzMzAwMDAwMDBaFw0xODAzMzAxMjAwMDBaMIHPMQswCQYDVQQGEwJHQjESMBAGA1UE CBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MSgwJgYDVQQKEx9Wb2RhZm9uZSBHcm91cCBT ZXJ2aWNlcyBMaW1pdGVkMS0wKwYDVQQLDCRHcm91cCBOZXR3b3JrIEVuZ2luZWVyaW5nICYgRGVs aXZlcnkxFjAUBgNVBAMTDVVsbHJpY2ggTWV5ZXIxKTAnBgkqhkiG9w0BCQEWGlVMTFJJQ0guTUVZ RVJAVk9EQUZPTkUuQ09NMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1MRubAOisB3t WhHQG3wc83MPIYQ8fum+8t6suxu8RD6vXQ9gwvisXiygf9T1jaMXVXU0uG0odmHDyAwSkK1shaWw S5GDhm/1fjbuloIP06hiHnWnrxYB+e9GD2EBe6u9hpmy5u4n2c/DxPGoxpnwjsvYBRthNCafdH0k M66UoL9tyoW6dFBcS7BU9Y4Uc16fU8vn6mJIuypLEjTDeptUvfH8g23D3IVtfVwtBhZsx7yNJ9M3 knugzDYYOqJrsd3HP9ususI/dhzWu4no/EoAsF9upLmCji/Y+aZmYYbGVIXv0eLQ7VeL4qCyfVNp oqZq7mx/b+8IROvqS33I0WhsMQIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFFJ9ZnkuSj+aroOpBtodAmPj/uCnMAwGA1UdEwEB/wQCMAAwJQYD VR0RBB4wHIEaVUxMUklDSC5NRVlFUkBWT0RBRk9ORS5DT00wDgYDVR0PAQH/BAQDAgSwMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmG N2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMi5jcmww PaA7oDmGN2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1n Mi5jcmwweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5j b20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJB c3N1cmVkSURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAJ0754Vs+0vXZZoF2Aa/2mS5wvp+9spS xYkpvS1kLC18fT++0EslaobNPT0UdpmvsS+0+Ui+lo5z+1QtHZegcR3/ETmfgfE8SluBHyM1XfZV A66KkQpzvmQTvWAoBegUlsw7YYR8JH2mQoaJ4rMrvkEk3i82Hw3l/ueI9FGslUo/zZdBixar+KAT p5AKP/G5XU4fLBgVc1kX5Cs+St5tf9DRhKGAeZR6RuGFP/mUW4jnXKZ6BZ0afWx06D3nXx3AomYc I6tha6rDCK0bHYvNv5hGGhlgntinuKX4gPk4ltrA3kJAAX3Zz7/KiM0s+jMIbFqnEE4BxsGiiXhp Zac/Im4wggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBa Fw0yODExMDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAX BgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHf DtQVG093pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWw IxnGRTjXPUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AX Ef+9xYn1vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN 2Uba9s9Sp307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9 xX0IoSzCn3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGG MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGB BgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1 cmVkSURSb290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASC AaowggGmMIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0 AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAA YQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQ AC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEA ZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0 AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUky PIp5MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO 1Iknuf0dh3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKE EtkV9gpEV8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrL T1gPuXtdGwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/t TGHtBlgoGVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLj jt8hKlBXBMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDnTCCA5kCAQEweTBlMQswCQYDVQQGEwJVUzEV MBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAYVYw3MbNM7/ke97Sz2yokwDQYJYIZIAWUD BAIBBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDQy ODEyMzEwMFowLwYJKoZIhvcNAQkEMSIEIILQ8d4Ljey9voPlu9koW8eZOCWoQDBkC31nTmE7p75p MHgGCSsGAQQBgjcQBDFrMGkwUjELMAkGA1UEBhMCVUsxFzAVBgNVBAoMDlZvZGFmb25lIEdyb3Vw MSowKAYDVQQDDCFWb2RhZm9uZSAoSW50ZXJuYWwgU2VydmljZXMgMjAwOSkCE3cAIDDhELxbtyoj PR4AAQAgMOEwegYLKoZIhvcNAQkQAgsxa6BpMFIxCzAJBgNVBAYTAlVLMRcwFQYDVQQKDA5Wb2Rh Zm9uZSBHcm91cDEqMCgGA1UEAwwhVm9kYWZvbmUgKEludGVybmFsIFNlcnZpY2VzIDIwMDkpAhN3 ACAw4RC8W7cqIz0eAAEAIDDhMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0G CSqGSIb3DQEBAQUABIIBALTnxTgSdrkVeX6hDOlbqxepdFMySUXDD3pQAqWfB/3zTQdF90zfX6tM Y234we7mia1n+ooK1yA4AG1Qsib8wJKVBb4C/X7t0D8W7kOIVSWezxOp4WHSiqj+aFQHhURbh5Sn JSKgPwy7HAMGis+yfsNpmnpD++8vPVaizED02zJF6h7hQPv7HvnfA7fZMMsqSBAM5Yv+1Swc2+5p E5crDkZ088bD7XvzVj0ip9A42VRW5HPp1rOZYPVuzjb67sUfwZ6wmsyl5fB5PxNMh6Ycgf9/P7qX /dwzOs2fmJwutdzomxNwVv+3KZTljMIt1WoQInsdYrRGODPmhJV1JDU2fEkAAAAAAAA= ------=_NextPart_000_0084_01D2C02C.0E7CF550-- From nobody Fri Apr 28 08:50:08 2017 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 608BE1293F2 for ; Fri, 28 Apr 2017 08:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEjl59yH8mCG for ; Fri, 28 Apr 2017 08:50:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FBC128CDC for ; Fri, 28 Apr 2017 08:46:54 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SFkT4N024944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 08:46:30 -0700 (PDT) To: "Meyer, Ullrich, Vodafone DE" , "philip.eardley@bt.com" , "lars@netapp.com" Cc: "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <378851B30BE1AA4E85FFD1FAFE10ABE6A7272049@VOEXM20W.internal.vodafone.com> From: Joe Touch Message-ID: <4cebc0e9-fc76-46e1-f00e-15c8cce1d798@isi.edu> Date: Fri, 28 Apr 2017 08:46:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <378851B30BE1AA4E85FFD1FAFE10ABE6A7272049@VOEXM20W.internal.vodafone.com> Content-Type: multipart/alternative; boundary="------------5BBFDA42D34686B40DDB7287" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:50:06 -0000 This is a multi-part message in MIME format. --------------5BBFDA42D34686B40DDB7287 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Ullrich, FYI - the IETF is a place for individual expression, not corporate endorsement. So you, individually, support this work. Nothing else. Joe On 4/28/2017 5:31 AM, Meyer, Ullrich, Vodafone DE wrote: > Dear all, > > herewith I want to declare very clearly our (Vodafone) interest on that > MPTCP proxy work within the IETF. The work has our plenary support. > > Kind regards, > > Ullrich Meyer > Senior Engineer Service Design > VPN Solution Engineering within > Group Network Engineering and Delivery > FixLine: +49 69 2169 3290 > Mobile: +49 172 190 3120 > Email: ullrich.meyer@vodafone.com > > Vodafone GmbH, Düsseldorfer Straße 15, 65760 Eschborn > vodafone-deutschland.de > > Die gesetzlichen Pflichtangaben finden Sie unter > www.vodafone.de/pflichtangaben > > > -----Ursprüngliche Nachricht----- > Von: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Gesendet: Dienstag, 25. April 2017 09:12 > An: BOUCADAIR Mohamed IMT/OLN ; > lars@netapp.com > Cc: multipathtcp@ietf.org > Betreff: RE: [multipathtcp] Consensus call on potential MPTCP proxy work > > Just to clarify our interpretation of the various hums during the meeting. > > We interpreted them as indicating there was one topic that it was worthwhile > doing a consensus call on. We did not interpret the hums as indicating clear > consensus that we merely needed to confirm on the list. > > So far we see: > In favour: > christian.jacquenet@orange.com > mohamed.boucadair@orange.com > William Ivancic Stefano Secci > Henderickx, Wim (Nokia - BE/Antwerp) > David Allan I > Markus.Brunner3@swisscom.com Robert Skog Olivier > Bonaventure > Costin Raiciu > > Against: > Joe Touch > Juliusz Chroboczek Eggert, Lars > > > > It is therefore important to hear views from other people. Of course it is > also welcome for the technical discussion to continue (indeed, some people > may want more of the technical discussion before giving their view on the > consensus call). > > Thanks > Phil & Yoshi > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: 21 April 2017 07:55 > > [cut] > > Lacking that information, I don't see a new element here that could lead to > change the consensus reached at the Chicago meeting (of course I'm not > entitled to do that call anyway). > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------5BBFDA42D34686B40DDB7287 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Ullrich,

FYI - the IETF is a place for individual expression, not corporate endorsement.

So you, individually, support this work. Nothing else.

Joe


On 4/28/2017 5:31 AM, Meyer, Ullrich, Vodafone DE wrote:
Dear all,

herewith I want to declare very clearly our (Vodafone) interest on that
MPTCP proxy work within the IETF. The work has our plenary support.

Kind regards,

Ullrich Meyer 
Senior Engineer Service Design
VPN Solution Engineering within
Group Network Engineering and Delivery
FixLine: +49 69 2169 3290
Mobile: +49 172 190 3120
Email: ullrich.meyer@vodafone.com

Vodafone GmbH, Düsseldorfer Straße 15, 65760 Eschborn
vodafone-deutschland.de 

Die gesetzlichen Pflichtangaben finden Sie unter
www.vodafone.de/pflichtangaben 


-----Ursprüngliche Nachricht-----
Von: philip.eardley@bt.com [mailto:philip.eardley@bt.com] 
Gesendet: Dienstag, 25. April 2017 09:12
An: BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com>;
lars@netapp.com
Cc: multipathtcp@ietf.org
Betreff: RE: [multipathtcp] Consensus call on potential MPTCP proxy work

Just to clarify our interpretation of the various hums during the meeting.

We interpreted them as indicating there was one topic that it was worthwhile
doing a consensus call on. We did not interpret the hums as indicating clear
consensus that we merely needed to confirm on the list.

So far we see:
In favour:
christian.jacquenet@orange.com
mohamed.boucadair@orange.com
William Ivancic <ivancic@syzygyengineering.com> Stefano Secci
<stefano.secci@lip6.fr> Henderickx, Wim (Nokia - BE/Antwerp)
<wim.henderickx@nokia.com> David Allan I <david.i.allan@ericsson.com>
Markus.Brunner3@swisscom.com Robert Skog <robert.skog@ericsson.com> Olivier
Bonaventure <Olivier.Bonaventure@uclouvain.be>
Costin Raiciu <costin.raiciu@cs.pub.ro>

Against:
Joe Touch <touch@isi.edu>
Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Eggert, Lars
<lars@netapp.com>


It is therefore important to hear views from other people. Of course it is
also welcome for the technical discussion to continue (indeed, some people
may want more of the technical discussion before giving their view on the
consensus call).

Thanks
Phil & Yoshi

-----Original Message-----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: 21 April 2017 07:55

[cut]

Lacking that information, I don't see a new element here that could lead to
change the consensus reached at the Chicago meeting (of course I'm not
entitled to do that call anyway).




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

--------------5BBFDA42D34686B40DDB7287-- From nobody Fri Apr 28 08:57:45 2017 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 001EB12EA7F for ; Fri, 28 Apr 2017 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9Fiy4ddfZMw for ; Fri, 28 Apr 2017 08:57:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0C129C5E for ; Fri, 28 Apr 2017 08:54:26 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SFrika025550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 08:53:45 -0700 (PDT) To: mohamed.boucadair@orange.com Cc: "philip.eardley@bt.com" , "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E5E00F@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Fri, 28 Apr 2017 08:53:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5E00F@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:57:45 -0000 Med, There are two possibilities, as I already stated: a) this is a conventional proxy, which is fine with me b) this is a split-TCP proxy, which is out of scope IMO for this group and I do not support It's not feasible to endorse this work while letting this issue "float". The current doc is fairly clear on being (b). I have made my position clear and given the appropriate ADs a heads-up. Joe From nobody Fri Apr 28 11:23:59 2017 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 9F1C81243F6 for ; Fri, 28 Apr 2017 11:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH6pkGiDtWwJ for ; Fri, 28 Apr 2017 11:23:55 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 08D65120724 for ; Fri, 28 Apr 2017 11:22:59 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3SIMved022776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 20:22:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3SIMviN027412; Fri, 28 Apr 2017 20:22:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 044EFD7935; Fri, 28 Apr 2017 20:22:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id rh2EQVbFLQO6; Fri, 28 Apr 2017 20:22:56 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 086AAD789F; Fri, 28 Apr 2017 20:22:54 +0200 (CEST) Date: Fri, 28 Apr 2017 20:23:11 +0200 Message-ID: <87d1bw1je8.wl-jch@irif.fr> From: Juliusz Chroboczek To: Joe Touch Cc: "multipathtcp@ietf.org" In-Reply-To: <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 28 Apr 2017 20:22:58 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Apr 2017 20:22:57 +0200 (CEST) X-Miltered: at korolev with ID 59038881.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59038881.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59038881.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59038881.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 59038881.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59038881.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 18:23:58 -0000 >> [Med] The main point Joe is that the IETF has standard track documents >> that specify a TCP state machine when NAT is used. We are leveraging >> that state machine for the MPTCP proxy work. I think that's an important point. > However, that RFC [1928, ed.] specifies a conventional application layer > proxy I think that's an important counterpoint. -- Juliusz From nobody Fri Apr 28 11:57:40 2017 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 49B0F128BBB for ; Fri, 28 Apr 2017 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCn03VCZ0O74 for ; Fri, 28 Apr 2017 11:57:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E461286B2 for ; Fri, 28 Apr 2017 11:57:28 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SIv2TG000659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 11:57:03 -0700 (PDT) To: Juliusz Chroboczek Cc: "multipathtcp@ietf.org" References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <87d1bw1je8.wl-jch@irif.fr> From: Joe Touch Message-ID: Date: Fri, 28 Apr 2017 11:57:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <87d1bw1je8.wl-jch@irif.fr> Content-Type: multipart/alternative; boundary="------------891EBE72398437344D78EEB2" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 18:57:38 -0000 This is a multi-part message in MIME format. --------------891EBE72398437344D78EEB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/28/2017 11:23 AM, Juliusz Chroboczek wrote: >>> [Med] The main point Joe is that the IETF has standard track documents >>> that specify a TCP state machine when NAT is used. We are leveraging >>> that state machine for the MPTCP proxy work. > I think that's an important point. And I think it is incorrect, at least for the split-TCP case. At no point in the TCP state machine in RFC793 does the receipt of a SYN cause a new SYN to be generated to a different destination. Joe --------------891EBE72398437344D78EEB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 4/28/2017 11:23 AM, Juliusz Chroboczek wrote:
[Med] The main point Joe is that the IETF has standard track documents
that specify a TCP state machine when NAT is used. We are leveraging
that state machine for the MPTCP proxy work.

I think that's an important point.
And I think it is incorrect, at least for the split-TCP case.

At no point in the TCP state machine in RFC793 does the receipt of a SYN cause a new SYN to be generated to a different destination.

Joe
--------------891EBE72398437344D78EEB2-- From nobody Fri Apr 28 12:47:30 2017 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 50746129B0A for ; Fri, 28 Apr 2017 12:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWY6Cyxr5P_b for ; Fri, 28 Apr 2017 12:47:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 21CAC129B08 for ; Fri, 28 Apr 2017 12:46:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3SJkGf2007123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 21:46:16 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3SJkFPT008298; Fri, 28 Apr 2017 21:46:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9E469D78B7; Fri, 28 Apr 2017 21:46:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uWixXqroKi-O; Fri, 28 Apr 2017 21:46:14 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5F17AD789F; Fri, 28 Apr 2017 21:46:14 +0200 (CEST) Date: Fri, 28 Apr 2017 21:46:30 +0200 Message-ID: <874lx81fjd.wl-jch@irif.fr> From: Juliusz Chroboczek To: Joe Touch Cc: "multipathtcp@ietf.org" In-Reply-To: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <87d1bw1je8.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 28 Apr 2017 21:46:16 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Apr 2017 21:46:16 +0200 (CEST) X-Miltered: at korolev with ID 59039C08.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59039C07.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59039C08.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59039C07.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 59039C08.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59039C07.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 19:47:28 -0000 >>> [Med] The main point Joe is that the IETF has standard track documents >>> that specify a TCP state machine when NAT is used. We are leveraging >>> that state machine for the MPTCP proxy work. >> I think that's an important point. > And I think it is incorrect, at least for the split-TCP case. Yes, I think that what Mohammed is saying is that the "plain mode proxy", as currently defined, requires NAT-style techniques. I'd argue that this makes it neither plain nor a proxy. -- Juliusz