Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Wed, 09 November 2016 15:50 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 E44F01295C0 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.386
X-Spam-Level:
X-Spam-Status: No, score=-8.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] 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 3VC0j8z36jNu for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 07:50:13 -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 D41721295D9 for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 07:50:10 -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 uA9Fnfbl016819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Nov 2016 07:49:43 -0800 (PST)
To: mohamed.boucadair@orange.com
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <dd664340-8e78-61b0-9d5b-606d949bff2c@isi.edu>
Date: Wed, 9 Nov 2016 07:49:42 -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: <787AE7BB302AE849A7480A190F8B933009DAEB20@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------AAC0F1A7F564C3B695BA06F6"
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/57i3BHIjQvIAoSryGZoz7WiLBKw>
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:50:16 -0000


On 11/9/2016 7:37 AM, 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.

Joe