Re: [multipathtcp] potential MPTCP proxy charter item

[<[e-mail]>]

Hi Phil, 

I remember, as well :-)

The drafts were completely rewritten to take into considerations the comments and also to help the chartering effort. Here is the set of the Network-Assisted MPTCP documents:

* An MPTCP Option for Network-Assisted MPTCP: https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09 
* Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational Considerations: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00 
* DHCP Options for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06 
* RADIUS Extensions for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-radius-03 

Questions, comments and suggestions are more than welcome!

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[e-mail]] De la part de
> [e-mail]
> Envoyé : mercredi 26 octobre 2016 10:13
> À : [e-mail]; JACQUENET Christian IMT/OLN
> Cc : [e-mail]
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi,
> I remember in Berlin discussion about a new /merged version of Med and
> Olivier's drafts - with a nice description of the protocol model to make
> it easier to understand (both the high-level approach, and the assumptions
> - especially as these are different to those of RFC6824). I think this
> would make it easier to write text for a new charter item. (at least my
> attempt to write a new charter item a while back was inaccurate
> /inadequate).  Is this possible please?
> I agree we want this work to happen - it's great to see MPTCP being widely
> used and we want standardisation.
> 
> Best wishes
> Phil.
> 
> -----Original Message-----
> From: multipathtcp [mailto:[e-mail]] On Behalf Of
> Mirja Kühlewind
> Sent: 25 October 2016 13:07
> To: [e-mail]
> Cc: [e-mail]
> Subject: 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
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp