Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Tue, 08 November 2016 14:47 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 0C1CA129CD2 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, RCVD_IN_SORBS_SPAM=0.5, 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 hXuRjsWjVgph for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:47:09 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1439129CD8 for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 06:47:08 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1446E22C99D; Tue, 8 Nov 2016 15:47:07 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.59]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D30184C0AD; Tue, 8 Nov 2016 15:47:06 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 15:47:06 +0100
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOcywnemdljzUmEGiGID3gGUCC6DPJurQ
Date: Tue, 8 Nov 2016 14:47:05 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE2DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <e2733084-d91a-a4b3-0c2a-9643fc456e1b@isi.edu>
In-Reply-To: <e2733084-d91a-a4b3-0c2a-9643fc456e1b@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.8.140316
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/uiGM66Lnie2zXuOho5nPz_oYQWM>
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:47:11 -0000

Re-,
 
The point Joe, is that if we define the MP_CONVERT option as a TCP option or if we require EDO to be present to explicitly indicate the data offset, we are adding new failure vectors compared with the other design that leverages on MP_CAPABLE to achieve the same result.

The table cites the failure cases. 

Please let me know if I misunderstood your question.

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:touch@isi.edu]
> Envoyé : mardi 8 novembre 2016 15:31
> À : BOUCADAIR Mohamed IMT/OLN; Mirja Kühlewind;
> Olivier.Bonaventure@uclouvain.be
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> 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