Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Tue, 08 November 2016 14:31 UTC

Return-Path: <touch@isi.edu>
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 6BB15129CC8 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 WWpwUQ_WNY9x for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:31:21 -0800 (PST)
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 DBE96129CBA for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 06:31:21 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uA8EUhNP000412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Nov 2016 06:30:44 -0800 (PST)
To: mohamed.boucadair@orange.com, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be> <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch> <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu> <787AE7BB302AE849A7480A190F8B933009DADEAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <e2733084-d91a-a4b3-0c2a-9643fc456e1b@isi.edu>
Date: Tue, 8 Nov 2016 06:30:44 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DADEAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/1LSqTkcowucFmFANShpzRrFVOWU>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 14:31:24 -0000

Hi, Med,

I cannot parse the note below. Can you please clarify? Or maybe it is
more useful to address my specific issue with SYN data as option, in
response to your other email today.

Joe


On 11/7/2016 10:37 PM, mohamed.boucadair@orange.com wrote:
> Hi Joe, 
>
> It is encouraging to consider using EDO, but the current approach we adopted for the MP_CONVERT option have the same failure risk as for introducing MPTCP at the scale of the Internet. 
>
> Using EDO and/or defining MP_CONVERT as a TCP option exacerbates the failure vectors. Below a table that summarizes the failures that will be experienced for the MP_CONVERT case as a function if the design approach: 
>
>    +------------------+-----------+-----------+-----------+------------+
>    |                  | MP_CONVERT| MP_CONVERT| MP_CONVERT| MP_CONVERT |
>    |                  |   MPTCP   |    TCP    |   MPTCP   | TCP Option |
>    |                  |   Option  |   Option  |  Option + |   + EDO    |
>    |                  |           |           |    EDO    |            |
>    +------------------+-----------+-----------+-----------+------------+
>    | MPTCP-unfriendly |    FAIL   |    FAIL   |    FAIL   |    FAIL    |
>    |             path |           |           |           |            |
>    +------------------+-----------+-----------+-----------+------------+
>    |   EDO-unfriendly |     NA    |     NA    |    FAIL   |    FAIL    |
>    |             path |           |           |           |            |
>    +------------------+-----------+-----------+-----------+------------+
>    | "Unknown TCP opt |     NA    |    FAIL   |     NA    |    FAIL    |
>    |  ion"-unfriendly |           |           |           |            |
>    |             path |           |           |           |            |
>    +------------------+-----------+-----------+-----------+------------+
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe
>> Touch
>> Envoyé : lundi 7 novembre 2016 16:56
>> À : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be
>> Cc : multipathtcp@ietf.org
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>>
>>
>>
>> On 11/7/2016 7:42 AM, Mirja Kühlewind wrote:
>>> Do you mean the MCP forwards the original SYN (and basically does
>> nothing if the server supports MPTCP) or does the MCP terminate the TCP
>> connection and start a new TCP connection with MP_CAPABLE towards the
>> server?
>>> Mirja
>> If you're OK with needing to terminate a failed option exchange, then it
>> might be possible to use EDO in the SYN in its current form.
>>
>> TCPM decided to prohibit that in the general case, but I could ask them
>> to allow that in very limited environments (but it could NEVER be
>> default on).
>>
>> Note - the use cases I'm hearing appear to assume very strong knowledge
>> about the other end of the connection and the path. In that case, you
>> probably can skip most - if not all - of the 'negotiation' options and
>> just start using them during the SYN too. However, if you say "no, we
>> need to confirm", then you would not be able to use EDO inside the SYN.
>>
>> Joe
>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp