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

<< 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.>>
If possible the WG can discuss a solution for a while without worrying about this - at least to get to a protocol model that we like. then we (or rather Mirja & IESG) can worry about Whether this needs a re-charter, another wg involved etc

-----Original Message-----
From: cpaasch@apple.com [mailto:cpaasch@apple.com] 
Sent: 29 March 2017 11:23
To: mohamed.boucadair@orange.com
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Two proxy scenario (network proxy off path)

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