Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 10 November 2016 07:20 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 E1101129A36 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 23:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.105
X-Spam-Level:
X-Spam-Status: No, score=-4.105 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=-1.497, 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 vtqfXSTT64I0 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 23:20:40 -0800 (PST)
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 843F9129A33 for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 23:20:39 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 9537E20B81; Thu, 10 Nov 2016 08:20:37 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 5DEFA4005D; Thu, 10 Nov 2016 08:20:37 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 08:20:36 +0100
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOqJtnemdljzUmEGiGID3gGUCC6DRzrzQ
Date: Thu, 10 Nov 2016 07:20:36 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF0FD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu> <00ba6ab8-8fbf-ab19-b996-b84b87ad5520@isi.edu> <F9AAAF6C-DF82-412E-9C88-9043CC1EC3AA@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE088@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ca2610f2-4f1b-5123-1e6e-697dfbe7cdc7@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE31D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <fe1856! ! 0f-098e-6953-55b9-f9d147b87c48@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE767@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <A728A74C-CB70-4B09-B44D-8D0D412505E9@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE807@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06BEE9D3-CE48-406A-81D4-9797B34F1BCE@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAEB20@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <dd664340-8e78-61b0-9d5b-606d949bff2c@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAEBF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84d3392a-f365-03fa-2c0a-c9223f9c6a60@isi.edu>
In-Reply-To: <84d3392a-f365-03fa-2c0a-c9223f9c6a60@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_787AE7BB302AE849A7480A190F8B933009DAF0FDOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/-UE1wiWPlxNNLPC82Q4SxVTpCJs>
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: Thu, 10 Nov 2016 07:20:42 -0000

Hi Joe,

At least from where I sit, I don’t see this is different from how fallback to TCP is handled in MPTCP.

For TCP, it would be good to record this in EDO and EOS specifications.

Thank you.

Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 9 novembre 2016 17:01
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org
Objet : Re: [multipathtcp] potential MPTCP proxy charter item


It might not be for MPTCP, but it's a huge issue for TCP.

Which begs the question of whether MPTCP would then be diverging so far from TCP that it isn't TCP anymore.

Joe

On 11/9/2016 7:58 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
Re-,

Thank you for the clarification.

Noted. As I don’t have concrete cases where there will be a need to pick a particular port, I’m not sure this is a big issue.

Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 9 novembre 2016 16:50
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>; multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item




On 11/9/2016 7:37 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

TCP is asked to connect once. You seem to now expect it to try twice - TCP cannot (it can't pick ports by itself) and user land cannot be expected to or may not be able to.
[Med] How that is different from establishing many TCP subflows between the same pair of IP address, using distinct source port numbers: https://tools.ietf.org/html/draft-ietf-mptcp-experience-07#section-3.4?

The difference is that the ports of the primary flow are no longer under your control.

I don't know if there's a workaround for MPTCP, but this is exactly why this technique cannot work for TCP in general. Further, if it doesn't work for TCP, then MPTCP is no longer TCP in some cases (which means it can't be used as such interchangeably).




   This subflow manager creates N subflows between the same pair of IP
   addresses.  The N subflows are created by the client and differ only
   in the source port selected by the client.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since the MPTCP Proxy in UC#2 is tracking TCP connections (TCP/MPTCP glue), it is the responsibility of the MPTCP Proxy to select the source port to use. This is similar to a NAT function. We are leveraging on the TCP BEHAVE recommendations.

 It might not be able to use the source port it wants either.
[Med] The only case I see is when all external ports are exhausted. This is a very very extremely case.

I'm speaking of a case where you want/need to pick both port numbers.
[Med] Acked.


Joe