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

<Markus.Brunner3@swisscom.com> Fri, 05 August 2016 06:58 UTC

Return-Path: <Markus.Brunner3@swisscom.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 73DE412B029 for <multipathtcp@ietfa.amsl.com>; Thu, 4 Aug 2016 23:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.486
X-Spam-Level:
X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 1KRVaJWQqCYm for <multipathtcp@ietfa.amsl.com>; Thu, 4 Aug 2016 23:58:12 -0700 (PDT)
Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) (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 4735012D12B for <multipathtcp@ietf.org>; Thu, 4 Aug 2016 23:58:12 -0700 (PDT)
Received: by mail.swisscom.com; Fri, 5 Aug 2016 08:58:06 +0200
From: <Markus.Brunner3@swisscom.com>
To: <cpaasch@apple.com>, <wim.henderickx@nokia.com>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlqAzeUeA393fHgCAAAZOAIABOu0AgABZCQCAAMu/AIAAwvIAgABXKoCAAEQxgIAABS8AgAGP0oCAABsWgIAAMYgA
Date: Fri, 5 Aug 2016 06:58:05 +0000
Message-ID: <4C8E7478-06B6-45FE-B442-BE4D1EDEA463@swisscom.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>
In-Reply-To: <2E6A891C-DF7B-4AF0-987F-642FA8D2D052@apple.com>
Accept-Language: de-CH, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [138.190.134.7]
Content-Type: multipart/alternative; boundary="_000_4C8E747806B645FEB442BE4D1EDEA463swisscomcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/AwzmWllP__PiQjxrBilocZcotf4>
Cc: 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: Fri, 05 Aug 2016 06:58:15 -0000

Christoph,

The Leg you are talking about however is exactly an hybrid access leg, and that is exactly where MPTCP comes in. So this is not independent of hybrid access. I have said in a previous conversation, that there are other options for that leg, but that MPTCP has already a lot of nice features and properties for that leg and has only a very small set of problems (as Med nicly summarized). That problems we would like to be fixed for that particular deployment option of MPTCP. And yes we could open the whole discussion of something new or different for that leg.

Marcus

<snip>

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.


Cheers,
Christoph