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

Christoph Paasch <cpaasch@apple.com> Sat, 06 August 2016 02:12 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 1091A12D1AF for <multipathtcp@ietfa.amsl.com>; Fri, 5 Aug 2016 19:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.438
X-Spam-Level:
X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 xpMasFwZrSEc for <multipathtcp@ietfa.amsl.com>; Fri, 5 Aug 2016 19:12:26 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C8212D18A for <multipathtcp@ietf.org>; Fri, 5 Aug 2016 19:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1470449546; x=2334363146; 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=N6bhiRm1Ez2qSZql1HgO2csxZyzpOKlctT6Xi1yB4zQ=; b=ymk7nuqSp0Roc6ff2eHi3QF0EcYmPPNBgcM/t4tv89gSBu0ja4J+MTBpMd2pj0eC ZEArVl+hQdAudHZLU6nnV9Z0u4eIb3zdPisMWoq1O2s/ZYmkURKQFkqsBNfsGD3G JJbbTQ4FLKSSVIKh4BTSzsdc0p1TlgFxAEe3Xu5r9ASsYJKKbZDi1epDjWeW8kfk aqqdD+LVWwYBLNwavGTOOJneBYhpoKihA0fxwlfvqLH7EmnQF6nNYiUIYRxFe8pj yBEh/s4t5SnDOWPYE3M4+j5614EaL8cBML2lixBkjjEtr7t4cPIBjeUuW16Uzmwt fT7H4eCzaOjJO2D2HTeLDQ==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 62.48.17422.A8745A75; Fri, 5 Aug 2016 19:12:26 -0700 (PDT)
X-AuditID: 11973e16-f793f6d00000440e-85-57a5478a03e3
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id BD.DD.01452.A8745A75; Fri, 5 Aug 2016 19:12:26 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_nAn06lv87rTRb6F0+n15lQ)"
Received: from [17.150.212.161] (unknown [17.150.212.161]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OBG00EGOU4P4T60@nwk-mmpp-sz12.apple.com>; Fri, 05 Aug 2016 19:12:26 -0700 (PDT)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <147FE680-0855-42BF-88BC-78EFDB6110D7@nokia.com>
Date: Fri, 05 Aug 2016 19:12:25 -0700
Message-id: <57AAFA48-D48A-4FF3-AC94-DBF4DE88880E@apple.com>
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>
To: Wim Henderickx <wim.henderickx@nokia.com>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUi2FDorNvlvjTcYOIXfovPq6+zWUz6vYnF gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4Mp4s/sAU8GTl0wVV7beZW5gfLSJqYuRg0NC wESiZQN7FyMnkCkmceHeerYuRi4OIYG9jBIvli2GSphIHNvazgiROMQosbrhHwtIgldAUOLH 5HtgNrNAmMTHo5uZQWwhgR4miZYTGSC2sICkRPedO8wQto9Ex5VpYPVsAloSb2+3s4LYnAK2 EpMX/AOrYRFQlVj1fw8jxMxQifanG5ggdtlI3N41A+q6xewSvzddAmsQEdCVWHvwGCPEpbIS T04uYgEpkhBYwCZx6tcL9gmMwrOQHDsLybGzgCHALKAuMWVKLkRYW+LJuwusELaaxMLfi5iQ xRcwsq1iFMpNzMzRzcwz10ssKMhJ1UvOz93ECIqT6XZiOxgfrrI6xCjAwajEw7tg3ZJwIdbE suLK3EOM0hwsSuK8q7YAhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA2JpiJbY7fKPtRM3fx rh/O1RNO3Ox+cHtG1b6lDztvxRh6fr6RfkruZFl15wquOhHrb8dqDulP5172Tdb7VM3NRL2T 7tcTtBYmnP66NeecmVnfqtvXU/WUHp99aH/YT3bN9p1SZe2eS4/lpKaIrPjC5lp84U6CtMKi QxvEmRpUm4WfPZ9x2sBViaU4I9FQi7moOBEAS1F45HQCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FB8RrfLfWm4QfNiLovPq6+zWUz6vYnF gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4Mp4s/sAU8GTl0wVV7beZW5gfLSJqYuRk0NC wETi2NZ2RghbTOLCvfVsXYxcHEIChxglVjf8YwFJ8AoISvyYfA/MZhYIk/h4dDMziC0k0MMk 0XIiA8QWFpCU6L5zhxnC9pHouDINrJ5NQEvi7e12VhCbU8BWYvKCf2A1LAKqEqv+72GEmBkq 0f50AxPELhuJ27tmQB2xmF3i96ZLYA0iAroSaw8eg7pUVuLJyUUsExgFZiG5bxaS+2YxcgDZ 6hJTpuRChLUlnry7wAphq0ks/L2ICVl8ASPbKkaBotScxEojvcSCgpxUveT83E2M4MAudN7B eGyZ1SFGAQ5GJR7eBeuWhAuxJpYVV+YCA4mDWUmEd7/d0nAh3pTEyqrUovz4otKc1OJDjNIc LErivI/kgVIC6YklqdmpqQWpRTBZJg5OqQZGbsXjYvlcSnPuut5frbIm0yLf99ft4tdNYV+q PtRZXrPV/+99Oic2V/dmtsWqANmFL7aLPM7idJG82Bi/6XsWp+jyk90prQusXhop/hZz/zOz QpQ1wCRzdVRFmF+Q9bKSMwu/H3Hb19HBzCQ2Y/7H359OnC48f6xfv3F9VHnvlaei3n2eXrpK LMUZiYZazEXFiQBYKMUaaAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3xVqp1YPYaG4VS6X1PsRCj8goJA>
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 02:12:29 -0000

Inline

> On Aug 5, 2016, at 6:32 AM, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com> wrote:
> From: Christoph Paasch <cpaasch@apple.com <mailto:cpaasch@apple.com>> on behalf of Christoph Paasch <cpaasch@apple.com <mailto:cpaasch@apple.com>>
> Date: Friday 5 August 2016 at 08:00
> To: Wim Henderickx <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>
> Cc: Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>, MultiPath TCP - IETF WG <multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>>
> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>> On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>> wrote:
>> From: Christoph Paasch <cpaasch@apple.com <mailto:cpaasch@apple.com>> on behalf of Christoph Paasch <cpaasch@apple.com <mailto:cpaasch@apple.com>>
>> Date: Thursday 4 August 2016 at 06:32
>> To: Wim Henderickx <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>
>> Cc: Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>, MultiPath TCP - IETF WG <multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>>
>> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>>> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>> wrote:
>>> From: <tpauly@apple.com <mailto:tpauly@apple.com>> on behalf of Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>
>>> Date: Thursday 4 August 2016 at 02:10
>>> To: Wim Henderickx <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>
>>> Cc: Alan Ford <alan.ford@gmail.com <mailto:alan.ford@gmail.com>>, "multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>" <multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>>
>>> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>>>> From: Alan Ford <alan.ford@gmail.com <mailto:alan.ford@gmail.com>>
>>>> Date: Wednesday 3 August 2016 at 09:20
>>>> To: Wim Henderickx <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>
>>>> Cc: Rao Shoaib <rao.shoaib@oracle.com <mailto:rao.shoaib@oracle.com>>, "multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>" <multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>>
>>>> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>>>>> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>> wrote:
>>>>> On 02/08/16 15:52, "Alan Ford" <alan.ford@gmail.com <mailto: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.

No, there is no extra signaling compared to the plain-mode option, as what I am proposing would be to put the SOCKS v4 framing in the SYN. So, there is no additional round-trip here.
Please explain (with a flow-diagram of segments sent) how the latency is higher in this proposal.

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

What we are basically saying is that you could think beyond MPTCP and not lock yourself into it. The benefit of the plain-mode option goes far beyond your current use-case (which is MPTCP-centric). So, designing it in a way that it is independent from the transport-protocol would add far more value to it.
The good thing is that designing it in such a way that it is independent from the transport-protocol is very straight-forward. You basically take the plain-mode option in its current form and remove the subtype-field. Then you are done. Easy :)


Cheers,
Christoph