Re: [multipathtcp] RADIUS/DHCP (was RE: potential MPTCP proxy charter item)

[Mirja Kühlewind <[e-mail]>]

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, [e-mail] 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:[e-mail]] De la part de
>> Mirja Kühlewind
>> Envoyé : mardi 25 octobre 2016 14:07
>> À : JACQUENET Christian IMT/OLN
>> Cc : [e-mail]
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>>
>> Hi all, hi Christian,
>>
>> see below.
>>
>>> Am 20.10.2016 um 08:50 schrieb [e-mail]:
>>>
>>> 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:[e-mail]] De la part de
>> [e-mail]
>>> Envoyé : jeudi 20 octobre 2016 08:15
>>> À : Yoshifumi Nishida; [e-mail]
>>> Cc : [e-mail]
>>> 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:[e-mail]] Envoyé :
>>>> mercredi 19 octobre 2016 22:57 À : [e-mail] Cc
>>>> : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; [e-mail]
>>>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>>>>
>>>> Hello,
>>>>
>>>> On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure
>>>> <[e-mail]> 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
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>
>> _______________________________________________
>> multipathtcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multipathtcp