Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Wed, 09 November 2016 15:37 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 546F6129588 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_SORBS_SPAM=0.5, 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 bdE7z5avkIeh for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:37:13 -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 4ED591294AD for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 07:37:12 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 97B0E2645DA; Wed, 9 Nov 2016 16:37:10 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 71D034C093; Wed, 9 Nov 2016 16:37:10 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Wed, 9 Nov 2016 16:37:10 +0100
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOpiznemdljzUmEGiGID3gGUCC6DQxrXA
Date: Wed, 9 Nov 2016 15:37:09 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAEB20@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <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> <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>
In-Reply-To: <06BEE9D3-CE48-406A-81D4-9797B34F1BCE@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_787AE7BB302AE849A7480A190F8B933009DAEB20OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/IY1e7q0gKMFqdrrNhL-VroYT81E>
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:37:15 -0000

Hi Joe,

Please see inline.

Cheers,
Med

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



On Nov 9, 2016, at 2:07 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Re-,

There are two cases :

·         UC#1 : MPTCP Client=================MPTCP Proxy----Server

·         UC#2 : Client---CPE(MPTCP Proxy)==== MPTCP Proxy----Server

For UC#1, I don’t see why the same port number will be returned by the OS given that TIME_WAIT is not expired.

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?

   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.

Joe




Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 9 novembre 2016 10:00
À : 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




You've just opened a connection using a pair of ports. You sent a RST, but RSTs are not reliable. So you can't reuse that port pair until TIME-WAIT expires.
[Med] This a fair observation. Another source port number will be used for the fallback connection (if any).
That is no longer TCP.
Remember that it is not TCP that picks these ports. The OS does when the user didn't but the user can.

Joe