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

<philip.eardley@bt.com> Mon, 01 August 2016 15:46 UTC

Return-Path: <philip.eardley@bt.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 DB78212DC89 for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 08:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.908
X-Spam-Level:
X-Spam-Status: No, score=-3.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 SZHNlSz_nQvB for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 08:46:00 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693AD12DC87 for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 08:45:59 -0700 (PDT)
Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Aug 2016 16:45:56 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 1 Aug 2016 16:45:57 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 16:45:57 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 1 Aug 2016 16:45:57 +0100
From: <philip.eardley@bt.com>
To: <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgD5RCMAACN7ZwABC2yHYA==
Date: Mon, 1 Aug 2016 15:45:57 +0000
Message-ID: <5fadd9cfcc01401b84db03052e165c69@rew09926dag03b.domain1.systemhost.net>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be>
In-Reply-To: <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.202.232]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/bv5QOd5CBNGVBemewfHw-FOIzBE>
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: Mon, 01 Aug 2016 15:46:03 -0000

Thanks.
So, for text for a potential work item, we could say something like "the WG assumes that the HAG is not necessarily on the default routing path between the end hosts".  This then leaves open whether we solve this problem in the mptcp-based protocol (as per plain mode) or solve it in the underlying layer (eg through a tunnel - transparent mode).
Do we assume that the other end of the mptcp segment is on the default routing path?  I suppose this is the case for the CPE example we usually have in mind - but since we want a general protocol, it would be good if this end also need not be on the default end-to-end path. 

It was also suggested to have a second (informational) document.
As a point of reference, our charter currently says (this is about one-ended proxy): << The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues.>>
So a potential work item may say something like:
The working group will detail the use cases /deployment scenarios, the operational considerations and .... [anything else? Interaction with endhost-to-endhost MPTCP?]

Incidentally, it may be possible to use some of the text from draft-deng-mptcp-mobile-network-proxy ?

I also note that draft-boucadair-mptcp-plain-mode has a very open-ended ipr statement. Do you think it could be made more specific (at some point)? 

phil


-----Original Message-----
From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] 
Sent: 27 July 2016 09:43
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>om>; multipathtcp@ietf.org
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Phil,

> So far this discussion has made me a bit confused. Let me ask a 
> specific
> question:-
>
> Why do we need both transparent and plain mode? If these are 
> addressing different usage scenarios, please explain them (in a 
> paragraph?)

The two modes address different deployment scenarios.

In the transparent mode, the HAG resides on the path to/from the client. 
There are many ways in current networks to ensure that the HAG is on the path of the clients that it serves. The transparent mode requires one option to distinguish between end-to-end MPTCP connections (directly established by the client using an MPTCP stack) and proxied connections. 
During IETF96, the authors of plain-mode and transparent-mode agreed that the transparent-mode draft would use an emply plain mode option to indicate that a connection has been proxied.

In the plain-mode, the HAG does not need to be on the path to/from the client. The plain-mode option is used to signal the original source/destination address of the connection depending on the usage.




Olivier