Re: [multipathtcp] Two proxy scenario (network proxy off path)

"cpaasch@apple.com" <cpaasch@apple.com> Wed, 29 March 2017 16:23 UTC

Return-Path: <cpaasch@apple.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 2C7C812943A for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 09:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 vyYPgtVnm66a for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 09:23:29 -0700 (PDT)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3F2129444 for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 09:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490804609; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=febupaqGz30igTv5ot4AcGM8Nwy9tR4GAlZ03my85y8=; b=r8i+zRhBuJYrkHNulFRqmpNJfsWkgAnygYZoDzLlBxV+546RQwBSxZBIulIN2seA qDYkWtU97M+/rmKVCX3LLyciMybNJd1bT9HEvi6m1kfsd5J857wNZ9I83WFKpqED /jDBM1zTQUQTnsd3dA261eonkYVl0KfrGIvicCtIBM0MUQO4xFBPZA5O/DvQp4AC VMrOnrhWqfaLMMr2DR88gkwWjGSwRwvVVkc931PfoQ/Ckw8TZEoeFqkWkfaISOUE VR3iWtfsn5qicoi2EcQ+7v5rHwoSZh4MLdzImribwueQfMbp4NWSiYmDVpeHbxVP xRCs4LSYHbETbQOWvZX0yA==;
Received: from relay21.apple.com (relay21.apple.com [17.171.128.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 83.65.25383.08FDBD85; Wed, 29 Mar 2017 09:23:29 -0700 (PDT)
X-AuditID: 11973e12-003389a000006327-40-58dbdf806098
Received: from ma1-mmpp-sz07.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay21.apple.com (Apple SCV relay) with SMTP id 8D.C8.19192.08FDBD85; Wed, 29 Mar 2017 12:23:28 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="iso-8859-1"
Received: from localhost ([17.168.191.252]) by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONL00L1Z474WK40@ma1-mmpp-sz07.apple.com>; Wed, 29 Mar 2017 09:23:28 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Wed, 29 Mar 2017 11:23:27 -0500
From: "cpaasch@apple.com" <cpaasch@apple.com>
To: mohamed.boucadair@orange.com
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Message-id: <20170329162327.GH2779@dhcp-8507.meeting.ietf.org>
References: <70EAECD3-22A6-420A-B84C-04B0673020DF@nokia.com> <20170329153901.GF2779@dhcp-8507.meeting.ietf.org> <3D71318E-8644-4FB3-8C7F-9DD4E5AFE89B@nokia.com> <20170329154652.GG2779@dhcp-8507.meeting.ietf.org> <787AE7BB302AE849A7480A190F8B933009E4303A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-reply-to: <787AE7BB302AE849A7480A190F8B933009E4303A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUiuLohTbfx/u0Ig+WThS0Ov33KbvF59XU2 i2VrVzBaTPq9icWBxaPty2QmjyVLfjJ53L11icmj5dlJtgCWKC6blNSczLLUIn27BK6Mf6ea mQs6HCr6jmxna2B8q9XFyMkhIWAi0XfwMVsXIxeHkMA6Jonj7VdZYBLPnu9mBbGFBM4ySvzu dwaxeQUEJX5MvgdUw8HBLCAvceRSNkiYWUBa4tHfGewQto5E7/dvzBAzm5gktk/vYAZJCAtI SnTfuQNmswioSrxfuBhsPpuArsSNt+fZQGwRAQWJfW39LCDNzAKrGSWalnYwQjS7S3w80s8G cYSdxIN56xghNmxkklgwfT1YEadAisSSXfvAbFEBZYm/h++BTZIQ2MImsfH9HqYJjCKzkHwx C+GLWUi+mIXkiwWMLKsYhXITM3N0M/NM9BILCnJS9ZLzczcxgqJmup3QDsZTq6wOMQpwMCrx 8Cqsvh0hxJpYVlyZe4hRmoNFSZxXfN+tCCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MttXN 50PWxax0kBfLv5vw9Mvsv7NuZIltb/myRG7Jl8JjPM+dN1ZynH0/T37CHp5ZFdwTfJINUt/8 z3LUcf5lOc3GMHpe7fy33+edYRP+I5+8/V/kZ47/l5on5MvOk27K41lv0rCnQLur1VNV0CB5 /1T3Fc6Nx+Qjwvq/HhOfszGv2qxmN8cuJZbijERDLeai4kQAR8eYZHsCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUiuLqBVbfh/u0Ig3ebdS0Ov33KbvF59XU2 i2VrVzBaTPq9icWBxaPty2QmjyVLfjJ53L11icmj5dlJtgCWKC6blNSczLLUIn27BK6Mf6ea mQs6HCr6jmxna2B8q9XFyMkhIWAi8ez5blYQW0jgLKPE735nEJtXQFDix+R7LF2MHBzMAvIS Ry5lg4SZBaQlHv2dwQ5h60j0fv/G3MXIBdTaxCSxfXoHM0hCWEBSovvOHTCbRUBV4v3CxWDz 2QR0JW68Pc8GYosIKEjsa+tnAWlmFljNKNG0tIMRotld4uORfjaII+wkHsxbxwixYSOTxILp 68GKOAVSJJbs2gdmiwooS/w9fI9lAqPgLCSHz0I4fBaSw2chOXwBI8sqRsGi1JzESiNDvcSC gpxUveT83E2MkDBP28H4/5zhIUYBDkYlHt6KtbcjhFgTy4orcw8xSnAwK4nwup0CCvGmJFZW pRblxxeV5qQWH2KU5mBREufdYw+UEkhPLEnNTk0tSC2CyTJxcEo1MB548qlq4s8zfj5fTot6 +fROunVGuX+nl/G0c1+z+1v+zOHLqFmWafC822DfjYtfsw933r1ZeudMXd+MZdF/Zh5Ya/6x snWi61e74i29P1h+eYuIdiWJ5jPmRP7lvJ+86Mp/w2pb0w3L1upMLpb9ese4yHaReEnTtG87 WhhrvsamxNjfS2pN6FZiKc5INNRiLipOBABM0mzYbwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/hXeOiY0RiOpOhH6z8urFiUOl7Ig>
Subject: Re: [multipathtcp] Two proxy scenario (network proxy off path)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Mar 2017 16:23:33 -0000

On 29/03/17 - 16:13:18, mohamed.boucadair@orange.com wrote:
> Christoph,
> 
> If you remove the initial TCP connection,
> If you remove the authentication negotiation,
> If you include the payload of the original SYN as part of the NEW SOCKS request
> 
> You are just cloning the MP_CONVERT behavior by overloading SOCKS semantic without providing an extra feature compared to the MP_CONVERT.
> 
> For the particular case of IPv6 when source address/prefix preservation is required, I don't see how this can be supported by SOCKS. Of course, you can modify the SOCKS command to clone MP_CONVERT :) 

The point is that we should try to do something that is architecturally clean,
without being closely linked to MPTCP.

Just imagine, if you deploy a proxy that enables the use of TCP-BBR, a
congestion-control that is much better than what servers/clients currently
use. This would also need a 0-RTT proxying solution (even if it is not
using MPTCP).


The point I am trying to make is that a 0-RTT proxying solution is not
something that the MPTCP working-group should be in charge of. There are
other places in the IETF that are probably more appropriate for this.


Christoph

> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : cpaasch@apple.com [mailto:cpaasch@apple.com]
> > Envoyé : mercredi 29 mars 2017 10:47
> > À : Henderickx, Wim (Nokia - BE/Antwerp)
> > Cc : philip.eardley@bt.com; BOUCADAIR Mohamed IMT/OLN;
> > multipathtcp@ietf.org
> > Objet : Re: [multipathtcp] Two proxy scenario (network proxy off path)
> > 
> > On 29/03/17 - 15:42:59, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
> > > Christoph, yes but again it something new and less optimal from the
> > proposed MP_CONVERT IE in the SYN.
> > 
> > No, that's what I wrote below. It's not less optimal. It's exactly the
> > same in
> > terms of performance as MP_CONVERT IE in the SYN!
> > 
> > 
> > Christoph
> > 
> > 
> > >
> > > On 29/03/2017, 10:39, "cpaasch@apple.com on behalf of Christoph Paasch"
> > <cpaasch@apple.com> wrote:
> > >
> > >     Hello Wim,
> > >
> > >     inline:
> > >
> > >     On 29/03/17 - 15:29:04, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
> > >     > Phil, you will be a bit more optimal but not a lot as you can see
> > or you end up changing the SOCKs protocol. Even if you do this MP_CONVERT
> > IE will always be the most optimal and hence this is what we propose for
> > doing this proxy function.
> > >     >
> > >     > On 29/03/2017, 10:12, "multipathtcp on behalf of
> > philip.eardley@bt.com" <multipathtcp-bounces@ietf.org on behalf of
> > philip.eardley@bt.com> wrote:
> > >     >
> > >     >     By non-chatty, I meant a version that didn't do all the
> > authentication messages. After all, the home gateway and network proxy can
> > be expected to know about each other already - at least don't need to do
> > for every new TCP connection from devices behind home gateway
> > >     >
> > >     >     -----Original Message-----
> > >     >     From: mohamed.boucadair@orange.com
> > [mailto:mohamed.boucadair@orange.com]
> > >     >     Sent: 29 March 2017 06:30
> > >     >     To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>;
> > multipathtcp@ietf.org
> > >     >     Subject: RE: Two proxy scenario (network proxy off path)
> > >     >
> > >     >     Hi Phil,
> > >     >
> > >     >     Can you please clarify what you mean by a "non-chatty
> > version"? version of what?
> > >     >
> > >     >     You can refer to Section 3 of RFC1928 to have an idea about
> > the number of messages that are required before sending actual traffic
> > when SOCKSv5 is used.
> > >     >
> > >     >     Below an excerpt of signaling messages observed to create an
> > initial subflow using SOCKSv5:
> > >     >
> > >     >     ==============
> > >     >     (MP Client) ->    TCP SYN    ->  (MCP)
> > >     >                        <- TCP SYN/ACK <-
> > >     >                        ->    TCP ACK    ->
> > >     >                        -> SOCKS Method Request (1)(a) ->
> > >
> > >     you would of course use TFO with SOCKS, so that you gain one RTT.
> > >
> > >     If then in addition to that you remove the authentication part of
> > SOCKS, and
> > >     you can even put the payload right after the SOCKS Connection
> > Request inside
> > >     the SYN-payload, then you are effectively also at a 0-RTT connection
> > >     establishment.
> > >
> > >
> > >     Christoph
> > >
> > >
> > >     >                        <-    TCP ACK (b)   <-
> > >     >                         <- SOCKS Method Response (2)(c) <-
> > >     >                         ->   TCP ACK (d)   ->
> > >     >                         -> SOCKS Authentication Request (3)(e) ->
> > >     >                         <-    TCP ACK (f)    <-
> > >     >                         <- SOCKS Auth. Response (4)(g) <-
> > >     >                         ->   TCP ACK (h)   ->
> > >     >                         -> SOCKS Connection Request (5)(i) ->
> > (MCP)
> > >     >                         <-   TCP ACK (j)                   <-
> > (MCP)
> > >     >
> > (MCP)  -> TCP SYN (k) -> (Server)
> > >     >
> > (MCP)  <- SYN/ACK (l) <- (Server)
> > >     >                         <- SOCKS Connection Response (n) (6) <-
> > (MCP) -> TCP ACK (m) -> (Server)
> > >     >                         ->   TCP ACK (o)  ->
> > >     >     =================
> > >     >
> > >     >     I let you compare it with the 0-RTT and 0-extra signaling
> > approach with MP_CONVERT IE.
> > >     >
> > >     >     Cheers,
> > >     >     Med
> > >     >
> > >     >     > -----Message d'origine-----
> > >     >     > De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De
> > la part de
> > >     >     > philip.eardley@bt.com Envoyé : mardi 28 mars 2017 20:24 À :
> > >     >     > multipathtcp@ietf.org Objet : [multipathtcp] Two proxy
> > scenario
> > >     >     > (network proxy off path)
> > >     >     >
> > >     >     > Hi,
> > >     >     >
> > >     >     > I'm now thinking about the scenario where there are two
> > proxies, one
> > >     >     > in the home gateway or Customer Premises Equipment and one
> > in the
> > >     >     > network, both under the control of the operator. And looking
> > at the 'explicit mode'
> > >     >     > scenario, which - if I get it right - means that the network
> > proxy is
> > >     >     > not on the default path. (It's safe to assume that the home
> > gateway
> > >     >     > proxy is on the default path)
> > >     >     >
> > >     >     > Thinking about the use of SOCKS in this context.
> > >     >     >
> > >     >     > Earlier Olivier said (in the context of the smartphone
> > scenario -
> > >     >     > sorry if your comments don't apply to this scenario and I'm
> > just
> > >     >     > creating
> > >     >     > confusion) that there are different variants of SOCKS that
> > can be
> > >     >     > used, which mainly depend on the number of messages that are
> > used to
> > >     >     > authenticate.
> > >     >     > In the two proxy scenario, it's probably reasonable to
> > assume that the
> > >     >     > home gateway and network proxy are already authenticated. So
> > a
> > >     >     > non-chatty version would be ok.
> > >     >     >
> > >     >     > Is that right?
> > >     >     >
> > >     >     > Thanks
> > >     >     > phil
> > >     >     >
> > >     >     > _______________________________________________
> > >     >     > multipathtcp mailing list
> > >     >     > multipathtcp@ietf.org
> > >     >     > https://www.ietf.org/mailman/listinfo/multipathtcp
> > >     >
> > >     >     _______________________________________________
> > >     >     multipathtcp mailing list
> > >     >     multipathtcp@ietf.org
> > >     >     https://www.ietf.org/mailman/listinfo/multipathtcp
> > >     >
> > >     >
> > >     > _______________________________________________
> > >     > multipathtcp mailing list
> > >     > multipathtcp@ietf.org
> > >     > https://www.ietf.org/mailman/listinfo/multipathtcp
> > >
> > >