Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Wed, 19 October 2016 09:46 UTC

Return-Path: <alan.ford@gmail.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 721931294B8 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 02:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 G5kTfrXdoUDH for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 02:45:59 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A2812959C for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 02:45:59 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id z189so40298817wmb.1 for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 02:45:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e93DByvDG0cUx+oUMJOaGaTEg3RA7a3Kg3qd8vOGSvY=; b=GzDGNpM/TuV6Tvy97SouhdoWSHsBQcFwnPftbjJUHsXNDw3Xt9ON9/Ot+/rwPk+4Aw Z/KAd58f52p+Len5ZlIxxgpI4ovS6NHLJS5sRajZDDRuSz+YGp8mm92LnxxyX0QJt5C/ lFvGsSDVC5iFK/HkoonkJIOOFhzGVSTjolqhFM0OD6iUuhiBv3nPy+ORF6E24Z0G5W8p PsMrf+lgiQJ2UT47gtAV+DIHDWoTyaWxMmL3zLGRQoGCiT7Yq9AkT7mDNMPVENY+n6fe R15BeaJd1ksVEcU72yh5uZ4n65Gf+1/tQjFIINS+Ps7OKcrefhdm+eWd7Anbh05QBeMO FP6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e93DByvDG0cUx+oUMJOaGaTEg3RA7a3Kg3qd8vOGSvY=; b=mg/PazwZMU32JdCOtlBE0gpHcPwlCRNys9L+psqd0A881zkOpsIPrl4juvenjYJZ9I jJ9td1Lr0uvWB4ap0wwGZsgnkd15G7DYmrd/h5MShHaRKQB5/wanPHhUoOcrIt0Q+D7P Arf5EVvxxSCs3n6fzsUV5VudLsxfibhItWu8jPimIfWDX8W7xh0mcyUqpURmVNlHP9VL T72kyiuKuKqKQ2HAaoqolGE6HiPJSatc7C9he819/7czRCmEiFIfGi3d6xWI9+6FgsV7 mtVHVTrDlGqYeUKXrAXqU1FA7wi5G9Vox7gtf0wVJGBimBNr6TPXACdmLZJVj2pbfmiy OwOA==
X-Gm-Message-State: AA6/9Rl7VnEka0x0SSej99SF70PldnAE0fPm1ykJSrlC/LViVz/Beer4QWRmw+E8LChjdQ==
X-Received: by 10.28.56.1 with SMTP id f1mr1942484wma.98.1476870357605; Wed, 19 Oct 2016 02:45:57 -0700 (PDT)
Received: from [10.44.28.203] (host81-142-89-185.in-addr.btopenworld.com. [81.142.89.185]) by smtp.gmail.com with ESMTPSA id yo1sm67696844wjc.16.2016.10.19.02.45.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Oct 2016 02:45:57 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009D94DFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Wed, 19 Oct 2016 10:45:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC6170D1-2CB9-4192-8FEB-5C4D030B520F@gmail.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <787AE7BB302AE849A7480A190F8B933009D94DFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/h4yHGoPIjs5mZagZ6n4goSbglUY>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [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: Wed, 19 Oct 2016 09:46:01 -0000

Do you guys expect any impact on the base protocol from this work?

Regards,
Alan

> On 19 Oct 2016, at 06:28, mohamed.boucadair@orange.com wrote:
> 
> Hi Mirja, 
> 
> I'm for these two cases to be included:
> * Case 1 is the mandatory piece to have.
> * Case 2 solves the problem for no TCP traffic while leveraging on the same extensions that are used for case 1.  
> 
> I do fully agree that case 2 requires inter-area/WG coordination. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
>> Envoyé : mardi 18 octobre 2016 17:46
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : Henderickx, Wim (Nokia - BE); philip.eardley@bt.com;
>> multipathtcp@ietf.org
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>> 
>> Hi Med, hi all,
>> 
>> there are two cases to distinguish here:
>> 
>> 1) you have one or two MPTCP proxies that terminate the TCP connection and
>> open a new MPTCP connection
>> 
>> 2) you tunnel other traffic over MPTCP
>> 
>> Case two is using TCP as a tunneling mechanism. This is discussed in
>> several working groups for different purposes and is not very straight-
>> forward in a lot of cases. Such an approach definitely needs coordination
>> and transport as well as tunnel expertise.
>> 
>> Which case are you talking about? While Phil’s proposal sounded rather
>> like case 1, your proposal sounds very much like case 2.
>> 
>> Mirja
>> 
>> 
>>> Am 18.10.2016 um 07:52 schrieb mohamed.boucadair@orange.com:
>>> 
>>> Hi Wim,
>>> 
>>> Yes, this can be main stream.
>>> 
>>> Cheers,
>>> Med
>>> 
>>> De : Henderickx, Wim (Nokia - BE) [mailto:wim.henderickx@nokia.com]
>>> Envoyé : lundi 17 octobre 2016 23:22
>>> À : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com;
>> multipathtcp@ietf.org
>>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>>> 
>>> Sorry for the late reply, but more in-line
>>> 
>>> From: multipathtcp <multipathtcp-bounces@ietf.org> on behalf of
>> "mohamed. boucadair" <mohamed.boucadair@orange.com>
>>> Date: Friday, 7 October 2016 at 09:08
>>> To: "philip.eardley@bt.com" <philip.eardley@bt.com>,
>> "multipathtcp@ietf.org" <multipathtcp@ietf.org>
>>> Subject: Re: [multipathtcp] potential MPTCP proxy charter item
>>> 
>>> Hi Phil,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
>> philip.eardley@bt.com
>>> Envoyé : lundi 8 août 2016 11:50
>>> À : multipathtcp@ietf.org
>>> Objet : [multipathtcp] potential MPTCP proxy charter item
>>> 
>>> 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.>
>>> 
>>> [Med] I would like to see the charter includes the following; “The
>> working group will also edit Network-Assisted Multipath provisioning
>> documents. In particular, the WG will specify DHCP options and RADIUS
>> attributes for MPTCP.”
>>> 
>>> 
>>> WH> I am fine with this, but why do we state experimental extensions?
>> Why is this not main stream?
>>> 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)
>>> [Med] IMHO, it is not odd to document in the mptcp wg how a Network-
>> Assisted MPTCP solution can also be applicable to other protocols (UDP in
>> particular). This work can be done jointly/closely with other WGs. The
>> important point is whether there is enough interest from the mptpcp WG
>> members to work on this.
>>> WH> indeed is to specify the means in MPTCP WG and other WG can be
>> consulted to review the work. If you split it out it becomes less
>> efficient from a protocol perspective.
>>> 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).
>>> 
>>> Thanks
>>> phil
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> multipathtcp mailing list
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp