Re: [multipathtcp] RADIUS/DHCP (was RE: potential MPTCP proxy charter item)
Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 26 October 2016 11:19 UTC
Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 8EAF0129A91 for <multipathtcp@ietfa.amsl.com>; Wed, 26 Oct 2016 04:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level:
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] 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 amg8B51MJp7L for <multipathtcp@ietfa.amsl.com>; Wed, 26 Oct 2016 04:19:37 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C79129A99 for <multipathtcp@ietf.org>; Wed, 26 Oct 2016 04:19:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0F881D9315; Wed, 26 Oct 2016 13:19:35 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id chCshoxT235b; Wed, 26 Oct 2016 13:19:34 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BA8B2D930D; Wed, 26 Oct 2016 13:19:34 +0200 (MEST)
To: mohamed.boucadair@orange.com, JACQUENET Christian IMT/OLN <christian.jacquenet@orange.com>
References: <dc2137a5-38de-43ee-9360-eec0f6f3aa7b@OPEXCLILM22.corporate.adroot.infra.ftgroup>
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Message-ID: <9fe25f09-da5a-7111-4d43-319344cb7cb7@tik.ee.ethz.ch>
Date: Wed, 26 Oct 2016 13:19:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <dc2137a5-38de-43ee-9360-eec0f6f3aa7b@OPEXCLILM22.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/BzBcmGByBR1LM7SFa_5dp1M6f0k>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] RADIUS/DHCP (was RE: 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, 26 Oct 2016 11:19:40 -0000
Hi Med, sorry you are right about the DHC charter. I didn't check closely enough what you are proposing. I guess radext is a different case and I would need to check with the responsible AD (Kathleen in this case). However, I would actually like to postpone any decision till after the banana bof. While your dhcp/radius options/attributes are specific to MPTCP use only, I could also imagine and extension that could be used for different bonding proxies with e.g. a flag indicating that MPTCP is supported. Maybe contact the banana bof chairs. I know they've looking for someone to presentation the mptcp approach. Mirja On 25.10.2016 16:09, mohamed.boucadair@orange.com wrote: > Hi Mirja, > > You said: > >> DHCP/RADIUS extension go into the DHC working group. They are charter to >> specify these kind of extensions and you can start this work there >> immediately. > > But, I'm afraid this may not be that accurate. > > DHC charter says explicitly the following: > > "Definitions of new DHCP options that are delivered using standard > mechanisms with documented semantics are not considered a protocol > extension and thus are outside of scope for the DHC WG. Such options > ^^^^^^^^^^^^ > should be defined within their respective WGs and reviewed by DHCP > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > experts in the Internet Area Directorate. However, if such options > require protocol extensions or new semantics, the protocol extension > work must be done in the DHC WG." > > FWIW, dhc WG provided useful comments for https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-05. > > While for RADIUS, I already presented there twice (https://tools.ietf.org/html/draft-boucadair-mptcp-radius-02) The radext community provided useful comments, but when I asked for adoption it is not clear how to proceed because MPTCP is not on their radar. > > Your guidance on how to advance those specifications is appreciated. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de >> Mirja Kühlewind >> Envoyé : mardi 25 octobre 2016 14:07 >> À : JACQUENET Christian IMT/OLN >> Cc : multipathtcp@ietf.org >> Objet : Re: [multipathtcp] potential MPTCP proxy charter item >> >> Hi all, hi Christian, >> >> see below. >> >>> Am 20.10.2016 um 08:50 schrieb christian.jacquenet@orange.com: >>> >>> WG, >>> >>> Let me second Med's recent replies to Yoshi, Mirja and Alan. >>> >>> I too believe the mptcp WG is the right placeholder to work on an MPTCP >> extension that can accommodate use cases which are currently being >> investigated, marketed and - yes - deployed (for some of them, with their >> procession of already-documented drawbacks (TCP-only communications) and >> flaws, like QoS-affecting signaling delays) by some operators. >>> >>> These use cases mainly fall under the so-called hybrid access service >> offering umbrella, so that end-users can take advantage of various access >> network technologies for the sake of optimized resource usage, among other >> incentives. >> >> I agree that these use case are interesting and work is needed here. See >> further below. >> >>> >>> I also believe MPTCP is the right solution to address such use cases. >> >> As I mention previously there are two very different deployment scenarios: >> a connection-terminating MPTCP proxy or a MPTCP tunnel solution. In >> general using TCP as a tunneling technology is challenging and has a >> broader scope than just MPTCP. >> >> >>> As I already mentioned a while ago, working on an extension that can >> facilitate the establishment of MPTCP connections in a network-assisted >> fashion as we call it in the current Plain Transport Mode option draft >> will not hinder MPTCP massive adoption but rather encourage it. >>> >>> I also know there are already prototype implementations of such >> extension that are currently being tested. >>> >>> I therefore support the adoption of the MPTCP proxy charter item by the >> mptcp WG, as this work addresses very concrete and short term use cases >> that have been publicized by several operators. >>> >>> And I think that this WG should start working asap on the set of >> deliverables mentioned by Med in his recent response to Mirja: MPTCP >> extension specification, deployment scenarios and operational >> considerations and DHCP/RADIUS-based provisioning means. >> >> An MPTCP extension specification is clearly in scope for MPTCP and can be >> done right now without a charter change. >> >> I’m not sure if deployment scenarios need to be documented (in an RFC). As >> you said above there are already prototype and some real deployments as >> well. Not sure why we need additional documentation here. >> >> Operational consideration might or might not below in the MPTCP working >> group. However, there is the BANANA BoF in Seoul that will discuss hybrid- >> access services (and different approach to provide this service). >> Depending where this effort goes that might be a better home or some wg in >> intarea. >> >> DHCP/RADIUS extension go into the DHC working group. They are charter to >> specify these kind of extensions and you can start this work there >> immediately. >> >> I’m not saying we shouldn’t do this work; I’m just saying that MPTCP might >> not be the right group for all parts of this work. This is my >> recommendation as transport AD but I’m sure a rechartering discussion in >> the IESG would provide similar feedback. >> >> Mirja >> >> >> >>> >>> Cheers, >>> >>> Christian. >>> >>> -----Message d'origine----- >>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de >> mohamed.boucadair@orange.com >>> Envoyé : jeudi 20 octobre 2016 08:15 >>> À : Yoshifumi Nishida; Olivier.Bonaventure@uclouvain.be >>> Cc : multipathtcp@ietf.org >>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item >>> >>> Hi Yoshi, >>> >>> The discussion I had with many operators is that they would like to see >> both TCP and UDP addressed with the ** same solution**. This is why we >> came up with the proposal to leverage MPTCP for other protocols (UDP, >> mainly). >>> >>> So, what I would ideally like to see in the mptcp WG proposed charter is >> (with "X" being MPTCP): >>> >>>> 1: Protocol X proxy: >>>> It speaks protocol X on behalf of communicating endpoints . >>>> From one end's point of view, it looks as if the other end speaks >>>> protocol X. >>> >>> And >>> >>>> 3: Protocol X-Y / Protocol Y-X gateway >>>> Convert protocol X into protocol Y, or convert protocol Y into >>>> protocol X for protocol connectivity/compatibility, etc. >>> >>> I know Olivier/Stefano have a better name to denote both these cases. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] Envoyé : >>>> mercredi 19 octobre 2016 22:57 À : Olivier.Bonaventure@uclouvain.be Cc >>>> : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org >>>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item >>>> >>>> Hello, >>>> >>>> On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure >>>> <Olivier.Bonaventure@uclouvain.be> wrote: >>>>> Mirja, >>>>>> >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> There is a very clear demand for this type of solution and there are >>>> various >>>>> implementations that are available or are being developped. Several >>>>> deployments exist and there is a large demand for this type of >> services. >>>> It >>>>> would be silly for the IETF to ignore this use case after having >>>>> spent >>>> years >>>>> to specify the Multipath TCP protocol. >>>> >>>> I also think we should not ignore the use case. >>>> But, I am somehow thinking that we might want to clarify the >>>> terminologies a bit more so that we can have more clear focus. >>>> >>>> I might be wrong, but these words give me the following impressions. >>>> >>>> 1: Protocol X proxy: >>>> It speaks protocol X on behalf of communicating endpoints . >>>> From one end's point of view, it looks as if the other end speaks >>>> protocol X. >>>> >>>> 2: Tunneling over protocol X >>>> Protocol X carries other protocol Y packets (by using >>>> encapsulation) All info in protocol Y (headers, etc) will be >>>> preserved. >>>> >>>> 3: Protocol X-Y / Protocol Y-X gateway >>>> Convert protocol X into protocol Y, or convert protocol Y into >>>> protocol X for protocol connectivity/compatibility, etc. >>>> Some info in the original protocol might be lost due to the >>>> conversion. >>>> >>>> If I follow these impressions, it seems that some proposals are close >>>> to 3. (again, I might be wrong) I might want to check if we want to >>>> clarify this point in the charter or leave it ambiguous. >>>> I am just wondering if we might need to clarify the terminology or >>>> adding some texts to avoid miscommunications. >>>> >>>> Thanks, >>>> -- >>>> Yoshi >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> __________________________________________________________________________ >> _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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
- [multipathtcp] RADIUS/DHCP (was RE: potential MPT… mohamed.boucadair
- Re: [multipathtcp] RADIUS/DHCP (was RE: potential… Mirja Kühlewind