IETF Logo Mail Archive

Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Wed, 09 November 2016 15:59 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 83CBF1295F2 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.086
X-Spam-Level:
X-Spam-Status: No, score=-4.086 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=-0.001, 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 Hvgu8PmCxMRN for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:59:33 -0800 (PST)
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 24A611296E4 for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 07:58:42 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id A8289C0588; Wed, 9 Nov 2016 16:58:40 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 7F6161A0070; Wed, 9 Nov 2016 16:58:40 +0100 (CET)
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; Wed, 9 Nov 2016 16:58:40 +0100
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOqDinemdljzUmEGiGID3gGUCC6DQza3g
Date: Wed, 09 Nov 2016 15:58:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAEBF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.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> <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>
In-Reply-To: <dd664340-8e78-61b0-9d5b-606d949bff2c@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAEBF9OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/t6XXRoU2WeFQim0Z49mZV6uoP_s>
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: Wed, 09 Nov 2016 15:59:37 -0000

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; 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

v2.28.0 | Report a Bug | By Email | System Status