Re: [multipathtcp] towards a potential work item on two-ended proxy

Alan Ford <alan.ford@gmail.com> Sat, 06 August 2016 20:47 UTC

Return-Path: <alan.ford@gmail.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 CF9FD12D147 for <multipathtcp@ietfa.amsl.com>; Sat, 6 Aug 2016 13:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TBzWBK4FVSQE for <multipathtcp@ietfa.amsl.com>; Sat, 6 Aug 2016 13:47:47 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 9D50612B019 for <multipathtcp@ietf.org>; Sat, 6 Aug 2016 13:47:47 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id u134so285788563ywg.3 for <multipathtcp@ietf.org>; Sat, 06 Aug 2016 13:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bTr2LtEktYTygPrrWd2m7XFzHka1j27iDltFPy0nFN4=; b=QbtPiwy9erj8z1LDV2IrPUmRKzIBNLaL0buWGljvQb9GnAPA3CQpD2qa+QpDYpq16Y K6aEX/RsZnY7/DRJ2NSFYDNbMIL+3aIuErQARhz7rBauEFb2CnZ//96FJvqrYRDABoe6 aPoHihE4xlzovzlJbI6LW3YX9Le3mcXHmMDh9jjyQo/GKmb66I/pc5OIQAX5KZrWFHsF QrDU0O5RZMyb+PdBNk4khhVzT2qnGQFAbLQ2iyp2v30ysu0XB2qKF0p1zKRzTV/VjwhY uoxygHL0xC3Mm0mUEL6NTHhjNkvB3O0JBf+zkUtNZMPNmCX7eUs6rzm+ctN8N5AMi6ud dqxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bTr2LtEktYTygPrrWd2m7XFzHka1j27iDltFPy0nFN4=; b=jk9q3LcoNDeqCqA9DNsYiV+RLnx/EhBel4phbSSsvNq04OrM31iAyz65kppEkp3Z+h Ni9U5npE2Y5SZn4KqPeAbuU2R4VfgW7IXhD2BAhSPGhDu7EDQzm8PZp+rw9hHUFrvLh8 6iuKkqr8GOppjXOdBD8l7wCaRcwxBGjw6QrTnw4dI1+yLUlruBC5yGMNC7jTse83pyag XHiZEbvcDr0YUb9kIIvezq1EdBpZGLOvcVbCRP9dGNKjD+MUu0mrOAqG5mtUp+KixCDz RkaVoNx4GDvh8tWNdpQJdRKVVWFSgdt3Ou5YR0ywssZhQEqS9ZZ9wycHGZMFzACfzF1d 9OFA==
X-Gm-Message-State: AEkoouvAhjNsTdp1x8LUCilYUIUsby3ITXvLcIrt99hTiePszs1RDYm43Fx3hKEDCaiPWIrY/Z0XHaCdDzeVcQ==
X-Received: by 10.129.115.131 with SMTP id o125mr60179541ywc.99.1470516466771; Sat, 06 Aug 2016 13:47:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.166.146 with HTTP; Sat, 6 Aug 2016 13:47:45 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E023B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <3100ff74-0c7d-1815-03a1-aa4cec36d1e4@oracle.com> <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com> <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com> <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com> <E0278B51-F3D8-4762-B597-41959E7BCF12@gmail.com> <08A92759-0446-440B-A76E-2E89518E1336@nokia.com> <F9F23B1F-D802-4971-857F-4BF455EDCF5D@gmail.com> <FCC775C9-EA48-4E7D-A48D-3059C255569A@nokia.com> <4221AE86-54DA-4177-91B5-D1A03C101F71@apple.com> <F6D0E786-4CFC-44F0-8B22-1A3376D92D44@nokia.com> <49C1C516-FE48-4254-B784-9EFC0F430468@apple.com> <E1036C03-C042-4F56-8EFC-A23475BE6233@nokia.com> <2E6A891C-DF7B-4AF0-987F-642FA8D2D052@apple.com> <147FE680-0855-42BF-88BC-78EFDB6110D7@nokia.com> <787AE7BB302AE849A7480A190F8B933008E023B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alan Ford <alan.ford@gmail.com>
Date: Sat, 6 Aug 2016 21:47:45 +0100
Message-ID: <CAOs_kTZuj+MF7_UJNCk+BL8CzqyLfS-VeaPZD5qeYPJ3cCMsKw@mail.gmail.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary=001a1149310aa36de905396d4b9a
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0TrvTo-0BqW93whIQRav06qdHw0>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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: Sat, 06 Aug 2016 20:47:51 -0000

Absolutely, and I'm excited to see MPTCP finding a use in this way :-)

My concerns are around pragmatism too: firstly, ensuring any solution does
not add complexity or introduce issues in the base MPTCP protocol where it
is not required, or for what is a specialist use; and secondly, that you
are not limiting functionality of your solution in the future.

However, I do not think there is much point continuing this debate until we
see the consolidated proxy draft (plain mode + transparent) which was
discussed in Berlin - this may well make the goals of this work clearer.

Regards,
Alan

On Friday, 5 August 2016, <mohamed.boucadair@orange.com> wrote:

> Re-,
>
>
>
> Fully agree with Wim. It is all about a pragmatic solution to an
> engineering problem.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* multipathtcp [mailto:multipathtcp-bounces@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp-bounces@ietf.org');>] *De la
> part de* Henderickx, Wim (Nokia - BE)
> *Envoyé :* vendredi 5 août 2016 15:33
> *À :* Christoph Paasch
> *Cc :* MultiPath TCP - IETF WG
> *Objet :* Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> In-line
>
>
>
> *From: *Christoph Paasch <cpaasch@apple.com
> <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> on behalf of
> Christoph Paasch <cpaasch@apple.com
> <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>>
> *Date: *Friday 5 August 2016 at 08:00
> *To: *Wim Henderickx <wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>>
> *Cc: *Tommy Pauly <tpauly@apple.com
> <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>>, MultiPath TCP - IETF
> WG <multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hello,
>
>
>
> inline...
>
>
>
> On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <
> wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote:
>
>
>
> In-line sorry was on the road yesterday
>
>
>
> *From: *Christoph Paasch <cpaasch@apple.com
> <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>> on behalf of
> Christoph Paasch <cpaasch@apple.com
> <javascript:_e(%7B%7D,'cvml','cpaasch@apple.com');>>
> *Date: *Thursday 4 August 2016 at 06:32
> *To: *Wim Henderickx <wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>>
> *Cc: *Tommy Pauly <tpauly@apple.com
> <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>>, MultiPath TCP - IETF
> WG <multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hello,
>
>
>
> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <
> wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote:
>
> *From: *<tpauly@apple.com
> <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>> on behalf of Tommy
> Pauly <tpauly@apple.com <javascript:_e(%7B%7D,'cvml','tpauly@apple.com');>
> >
> *Date: *Thursday 4 August 2016 at 02:10
> *To: *Wim Henderickx <wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>>
> *Cc: *Alan Ford <alan.ford@gmail.com
> <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>>, "
> multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>" <
> multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
>
>
> On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <
> wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote:
>
>
>
> Alan, in-line
>
>
>
> *From: *Alan Ford <alan.ford@gmail.com
> <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>>
> *Date: *Wednesday 3 August 2016 at 09:20
> *To: *Wim Henderickx <wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>>
> *Cc: *Rao Shoaib <rao.shoaib@oracle.com
> <javascript:_e(%7B%7D,'cvml','rao.shoaib@oracle.com');>>, "
> multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>" <
> multipathtcp@ietf.org
> <javascript:_e(%7B%7D,'cvml','multipathtcp@ietf.org');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hi Wim, all,
>
>
>
> Comment inline...
>
>
>
> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <
> wim.henderickx@nokia.com
> <javascript:_e(%7B%7D,'cvml','wim.henderickx@nokia.com');>> wrote:
>
> On 02/08/16 15:52, "Alan Ford" <alan.ford@gmail.com
> <javascript:_e(%7B%7D,'cvml','alan.ford@gmail.com');>> wrote:
>
>
> I’m trying to distinguish the various use cases; can we confirm this is
> correct?
>
> Transparent Mode
> - Source address = real source address
>
> WH> not always since NAT can be in the path
>
> - Destination address = real destination address
> - Transparent proxies create MPTCP functionality in the stream, adding and
> removing the MPTCP headers, mapping seq numa, etc
> - Latest proposal is to add an indicator to say “this is proxied” so that
> a proxy can intercept it
>
> WH> indeed or not intercept it based on the indication
>
>
> Plain Mode
> - Source address = real source
>
> WH> could also be NATed in some use cases
>
> - Destination address = proxy destination address
> - Signalling protocol inside indicates real destination address
>
> WH> or SRC address
>
>
> So - please correct me if this is wrong - but the main difference is that
> Plain Mode is targeted towards a proxy server whereas the transparent mode
> does not change src/dst addresses?
>
> WH> the main difference is mainly DST IP is changed to get explicit
> routing to the proxy versus being implicit in the transparent case
>
>
>
> OK, so my understanding appears correct here.
>
> WH> yes
>
>
>
> The issue I see with a generic proxy bit is that it does not contain any
> context about what kind of proxy is being intercepted. You could be sending
> in good faith expecting it to be picked up by Proxy from Operator A, but in
> fact is picked up by Operator B.
>
> WH> the network assisted proxy is mainly targeting single
> operator/controlled operator use cases to avoid these issues.
>
>
> As I’ve said before, the plain mode option is not MPTCP-specific and is
> simple a signal that says “everything that follows is actually targeted for
> IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could
> know where to find a proxy (e.g. a well-known anycast address) then
> addresses could be rewritten and packets forwarded, with no need for any
> MPTCP protocol changes.
>
> WH> you would still need to know the original destination IP@ that the
> application wanted to go to.
>
>
>
> Which is the point of the signalling protocol - the proposed “plain mode
> option” which is actually carried in the payload. My issue with this is
> that this is _not MPTCP-specific_. This is simply a signal above the
> transport layer to inform a proxy what the real destination is.
>
>
>
> WH> I hear, you and I understand but we have an explicit use case for this
> with MPTCP and so far not in any other protocol. Hence I think it is good
> to extend MPTCP with this capability and liase with other WG(s) about this.
>
>
>
> While you may have a use-case for having proxies work with your MPTCP
> solution, it does not directly follow that the MPTCP protocol or WG is the
> best place to specify how the proxy works. This really does seem like a
> proxy solution that can be made more generic, and at the very least belongs
> as a protocol that is run within the MPTCP stream. This is what the SOCKS
> protocol does, and there is no reason you can't run SOCKS over MPTCP, or
> create a new variant of SOCKS or a similar protocol that you will run on
> top of MPTCP for your solution. Indeed, it could be seen as a benefit to
> work on the proxying solution independently from MPTCP, since that way it
> can be used for other transports. The end result will be the same, and the
> architecture will be cleaner.
>
>
>
> WH> given the extension is specific in TCP?MPTCP since we carry the
> information in a SYN packet it becomes specific to the protocol and hence I
> still believe it fits.
>
>
>
> The information is actually carried in the payload. So, it is not really
> part of TCP/MPTCP. Carrying it in the SYN is just because TCP does not
> prevent carrying data in the SYN-segment.
>
>
>
> WH> we added it in the payload due to limited option space available in TCP
>
>
>
> Other transport mechanisms have other means and can adopt a similar
> information element but the way the protocol consumes it is specific and
> should be done in the protocol afais.
>
>
>
> I disagree that the information is consumed by MPTCP. It is rather
> consumed by the application sitting right on top of MPTCP, because this is
> the one that is reading the data out of the MPTCP-stream and forwarding it
> over to final destination. And MPTCP itself is not really using the
> plain-mode option.
>
>
>
> If you look at Socks v4, it is actually carrying the exact same
> information than the plain-mode option (besides the protocol-field). So, an
> implementation could easily put the Socks-client request in the
> SYN-payload. The proxy who receives that can then (after connecting to the
> final server) reply in the SYN/ACK with the Socks-server option in the
> SYN/ACK's payload. And from there on, the data will be forwarded from one
> side to the other.
>
>
>
> This would be a low-overhead handshake for the proxy without the chatty
> overhead of Socks v5.
>
>
>
> WH> Latency matters here and people already experienced that additional
> signaling messages with its roundtrip  degrades QoE. Even adding 2 message
> is not the right way to go and hence we want to add the informational
> elements in the messages in MPTCP.
>
>
>
> I am 100% sure that the way I described it is not adding more latency
> compared to the current plain-mode option proposal. Can you please explain,
> how my suggestion "degrades QoE" (compared to the plain-mode option) ?
>
>
>
> WH10> my understanding is that you propose to add an additional out of
> band singling which need to negotiate the capabilities. This means extra
> signaling on top of what MPTCP does, so this is where your extra latency
> comes from.
>
>
>
> As such we need to enhance the information elements in TCP/MPTCP protocol
> to indicate that there is some data available that needs to be consumed by
> the proxy to operate properly. You need to extend the protocol to provide
> this capability in my view.
>
> The addition of adding a sub flow in MPTCP also provides addressing
> information and we need similar information for the MPTCP proxy (do the
> proxy or not, src/dst info, etc).
>
> We carry the data in the SYN due to limited option space but we could
> carry it in the option data as well. As such it becomes TCP specific and we
> believe it is best to leverage on the TCP framework to extend  this
> capability.
>
>
>
> Wrt. to *"as such it becomes TCP specific" *: Just because one
> arbitrarily puts some information in the TCP-option space does not make the
> information TCP-specific by design...
>
> WH10> if 99% of what we need is in the MPTCP stack why should we not use
> this. We have multi-path, we get congestion management, re-ordering, etc in
> MPTCP and we need this for the hybrid access use case. Our goal is to
> extend the capabilities on top of MPTCP since it does not of what we need.
> We just need to enhance it with some capabilities specific to the hybrid
> access use case and if you don’t need them you can avoid them.
>
>
>
>
>
>
>
> Let's put MPTCP aside for a moment.
>
>
>
> Basically, the network that you are targeting has some characteristics
> that make a certain transport protocol more adapt for a certain leg of the
> end-to-end path. So, the goal is to enable the use of a special transport
> protocol over this leg of the network.
>
> To do so, the byte-stream that is sent by the application from the
> client/server needs to be taken out of TCP and transmitted over this
> special transport protocol. Thus, the TCP-connection is being terminated at
> the CPE such that the byte-stream can be extracted out of TCP. This
> byte-stream is then sent over the specialized transport protocol to the
> concentrator on a specific port-number. The concentrator then terminates
> the special transport protocol so that it can extract the byte-stream out
> of it and sends the byte-stream to the final server over TCP.
>
> Now, as the concentrator is not always on the IP-path between CPE and
> server, the CPE actually needs to use the destination IP-address of the
> concentrator in the segments that are using the specialized transport
> protocol. So, this is the "plain-mode" that you are addressing. To let the
> concentrator send the byte-stream to the final server, the CPE needs to
> tell to the concentrator which IP the server has. To do so, the CPE places
> this information in the payload of the first segment that it sends to the
> concentrator by using the specialized transport protocol. This is exactly
> what you are doing with the plain-mode option.
>
>
>
>
>
> As you can see, in the above description of the hybrid access solution,
> there is nothing that is specific to MPTCP and nothing specific to the use
> of multiple interfaces or hybrid accesses. The sole use of the plain-mode
> option is to convey to the concentrator what the IP-address of the server
> is. Whether or not to do proxying is simply done by addressing the traffic
> to the concentrator by using a the proxy port-number.
>
>
>
> So, standardizing this is probably useful. But should not be done as part
> of MPTCP, because the plain-mode option is orthogonal to MPTCP.
>
>
>
> WH10> I get what you say but if I can re-use 99% of what is in MPTCP why
> should I define a new protocol to achieve the same thing. I can add
> something to the protocol to achieve the functionality, why should we not
> leverage this. This is why we call this an MPTCP proxy. If people don’t
> want to use it they don’t have to consume it. If people want to use the
> mechanism in another protocol they can. We just want to add this capability
> on top of an already existing MPTCP protocol which give us the capabilities
> we need. that’s all
>
>
>
>
>
> Cheers,
>
> Christoph
>
>
>