[multipathtcp] potential MPTCP proxy charter item

<philip.eardley@bt.com> Mon, 08 August 2016 09:49 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 64D0A12D1E0 for <multipathtcp@ietfa.amsl.com>; Mon, 8 Aug 2016 02:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.848
X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jIHip8v0nfpP for <multipathtcp@ietfa.amsl.com>; Mon, 8 Aug 2016 02:49:57 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D8A12D1BE for <multipathtcp@ietf.org>; Mon, 8 Aug 2016 02:49:56 -0700 (PDT)
Received: from EVMHT04-UKBR.domain1.systemhost.net ( by EVMED02-UKBR.bt.com ( with Microsoft SMTP Server (TLS) id; Mon, 8 Aug 2016 10:49:50 +0100
Received: from rew09926dag03d.domain1.systemhost.net ( by EVMHT04-UKBR.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 8 Aug 2016 10:49:55 +0100
Received: from rew09926dag03b.domain1.systemhost.net ( by rew09926dag03d.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 10:49:53 +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, 8 Aug 2016 10:49:54 +0100
From: philip.eardley@bt.com
To: multipathtcp@ietf.org
Thread-Topic: potential MPTCP proxy charter item
Thread-Index: AdHxWbUCMvV2F7dASMGmgM35ml/5/Q==
Date: Mon, 08 Aug 2016 09:49:53 +0000
Message-ID: <c96a67008ee045dda304a983cfb3de73@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_c96a67008ee045dda304a983cfb3de73rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/58xnZSzLCvDTWyUhS_eLZCTVx28>
Subject: [multipathtcp] potential MPTCP proxy charter item
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, 08 Aug 2016 09:49:59 -0000

I had thought a potential charter item could be something on the lines of:

<Experimental Extensions to the MPTCP protocol to enable an MPTCP-aware middlebox to act as an MPTCP proxy for an end host, which runs TCP. One or both end hosts may be MPTCP-unaware, and the MPTCP proxy(s) is (are) not necessarily on the default routing path(s). The working group will also detail, in an Informational document, the use cases /deployment scenarios and the operational considerations.>
However, if I get the discussion right, this is not quite right.
* assume a controlled environment (to avoid a problem where the message reaches the 'wrong' proxy) (IETF usually prefers generally applicable protocols)
* assume some (?additional) 'header swapping' protocol and a new signalling protocol (not an mptcp extension - so probably in INTAREA WG's remit)

If the above is roughly right, then I think some extra work is needed before we can get a clear charter item. Can some of the work that isn't mptcp extensions be cleanly separated out? Can you be clear what deployment assumptions are being made (and preferably reduce them, so there is wider applicability). Personally I'd also find it very helpful if the plain/transparent 'merged' draft could try and follow the guidance about protocol models in RFC4101 (personally I found the plain mode doc difficult to understand).