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

<philip.eardley@bt.com> Tue, 02 August 2016 14:48 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 7FE0512D696 for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 07:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.877
X-Spam-Level:
X-Spam-Status: No, score=-3.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 32t_5TErv7Zy for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 07:48:26 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0B912D178 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 07:48:25 -0700 (PDT)
Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Aug 2016 15:48:22 +0100
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 2 Aug 2016 15:48:23 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 15:48:21 +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; Tue, 2 Aug 2016 15:48:22 +0100
From: <philip.eardley@bt.com>
To: <rao.shoaib@oracle.com>, <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgD5RCMAATQmZwAAK5VLAA==
Date: Tue, 2 Aug 2016 14:48:22 +0000
Message-ID: <3400ecfa3006459fb5d16c70f4746495@rew09926dag03b.domain1.systemhost.net>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <e6c10e9e-d3c6-af46-b996-19d59cdb0c86@oracle.com>
In-Reply-To: <e6c10e9e-d3c6-af46-b996-19d59cdb0c86@oracle.com>
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.216.161.25]
Content-Type: multipart/alternative; boundary="_000_3400ecfa3006459fb5d16c70f4746495rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/2ZvuqGNesKvY9y9RFwdqu4bMrXQ>
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: Tue, 02 Aug 2016 14:48:30 -0000

That's not quite what I meant.
I was referring to defining a new tunnelling protocol or "swapping the headers" protocol or something similar. I think this is not something that mptcp wg would standardise - at least, I think we would have to liaise with other WGs (Intarea wg) about this - as it would seem more in their remit than ours. If this is something that we know in advance the proxy work will require (rather than something that may emerge when we develop the solution), then we probably should start the discussion sooner than later

phil


From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Rao Shoaib
Sent: 01 August 2016 19:51
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy


I do not understand why TCP is in scope and any other protocol is not. At the Yokohama IETF most in the room were interested in encapsulating UDP. In fact encapsulating TCP has more implications (due to its end to end congestion control) than UDP and hence that needs to be studied.

A compromise could be that we define a generic option that means, interpret the header enclosed or some thing like that. It's too bad that the mobile environment can not deal with the extra header. In which case it should always use transparent proxying.

Rao.
On 07/26/2016 08:07 AM, philip.eardley@bt.com<mailto:philip.eardley@bt.com> wrote:
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?)  (this is important as a charter item would start by talking about the issue it was tackling - and then may mention some starting points or assumptions about the solution)
Plain mode involves a signalling protocol (extension to mptcp - I assume this would be in scope of a prospective charter); then subsequently a way of handling the actual traffic (UDP seems out of scope; TCP I'm not sure to what extent this would be in scope). Do I understand this right? Comments?
Thanks
phil