Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

[Yoshifumi Nishida <[e-mail]>]

Hi Med,

I might want to see more feedback before the adoption call.
I've read the draft, but I think I still have some unclear points in the
draft.

I particularly would like to understand the following points as starting
point. Please let me know if I miss something.

1: This method requires CPEs to convert UDP or TCP into MPTCP and requires
Concentrators to convert back MPTCP into UDP or TCP. This could be rather
complex process than other approach such as GRE. So, what's the benefits to
utilize MPTCP here? I think the draft should describe some useful scenarios
to use MPTCP.

2: Including data in SYN is allowed in RFC793, but I'm not very sure how
many implementations actually accept it. I think the draft should discuss
this point. Also, what will happen if PM option is included in the payload,
but it is removed by the middleboxes?

Thanks,
--
Yoshi



On Thu, May 19, 2016 at 10:46 PM, <[e-mail]> wrote:

> Dear all,
>
> An updated version of the specification is available online:
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?include_text=1.
> This version takes into account comments that were received during the IETF
> meeting and other bilateral meetings.
>
> The authors do think that this effort is within the scope of this WG,
> especially this part of the charter:
>
> "Finally, the working group will explore whether an MPTCP-aware
> middlebox would be useful, where at least one end host is MPTCP-enabled.
> For example, potentially helping MPTCP's incremental deployment by
> allowing only one end host to be MPTCP-enabled and the middlebox acts as
> an MPTCP proxy for the other end host, which runs TCP; and potentially
> helping some mobility scenarios, where the middlebox acts as an anchor
> between two MPTCP-enabled hosts. The working group will detail what real
> problems an MPTCP-enabled middlebox might solve, how it would impact the
> Multipath TCP architecture (RFC6182), what proxy approach might be
> justified as compared against alternative solutions to the problems, and
> the likely feasibility of solving the technical and security issues."
>
> We would like to formally ask the WG to consider adoption of this draft.
>
> Comments, suggestions, and questions are more than welcome.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : I-D-Announce [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoyé : jeudi 19 mai 2016 17:45
> > À : [e-mail]
> > Objet : I-D Action: draft-boucadair-mptcp-plain-mode-07.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >         Title           : An MPTCP Option for Network-Assisted MPTCP
> > Deployments: Plain Transport Mode
> >         Authors         : Mohamed Boucadair
> >                           Christian Jacquenet
> >                           Denis Behaghel
> >                           Stefano Secci
> >                           Wim Henderickx
> >                           Robert Skog
> >                           Olivier Bonaventure
> >                           Suresh Vinapamula
> >                           SungHoon Seo
> >       Filename        : draft-boucadair-mptcp-plain-mode-07.txt
> >       Pages           : 31
> >       Date            : 2016-05-19
> >
> > Abstract:
> >    One of the promising deployment scenarios for Multipath TCP (MPTCP)
> >    is to enable a Customer Premises Equipment (CPE) that is connected to
> >    multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
> >    network attachments.  Because of the lack of MPTCP support at the
> >    server side, some service providers now consider a network-assisted
> >    model that relies upon the activation of a dedicated function called
> >    MPTCP concentrator.  This document focuses on a deployment scheme
> >    where the identity of the MPTCP concentrator(s) is explicitly
> >    configured on connected hosts.
> >
> >    This document specifies an MPTCP option that is used to avoid the
> >    encapsulation of packets and out-of-band signaling between the CPE
> >    and the MPTCP concentrator.  Also, this document specifies how UDP
> >    traffic, in particular, can be distributed among available paths by
> >    leveraging MPTCP capabilities.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-plain-mode-07
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>