Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Wed, 09 November 2016 16:01 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 A296B1294AD for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 08:01:33 -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 rYzrnzAlQ24w for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 08:01:31 -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 C224612947F for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 08:01:31 -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 uA9G0hLA017809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Nov 2016 08:00:44 -0800 (PST)
To: mohamed.boucadair@orange.com
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <84d3392a-f365-03fa-2c0a-c9223f9c6a60@isi.edu>
Date: Wed, 09 Nov 2016 08:00:44 -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: <787AE7BB302AE849A7480A190F8B933009DAEBF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------B649549FD4789A2C55FD4370"
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/cG-rD9pLFyMMzUs5EvLB-Pindek>
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 16:01:34 -0000

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