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: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <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