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

[<[e-mail]>]

Hi Shoaib,

I'm sure you have good reasons why TCP is not used between the client and the server in the first place. Calling out those reasons is helpful. 

As a side note, the plain mode specification does not enforce (yet) a validation check to assess whether the address conveyed in the option is distinct from an address that belong to the MPTCP node that receives the option. I.e., if that node receives an option that includes ones of its IP addresses, it is an indication that the data is to be consumed locally, not forwarded outside. Wouldn't that solve the first part of your "address mapping" concern? 
 
BTW, I added a note to the draft to indicate the following:

* An implementation must ignore PM options that include multicast, broadcast, and host loopback addresses.

Cheers,
Med

> -----Message d'origine-----
> De : Rao Shoaib [mailto:[e-mail]]
> Envoyé : mercredi 1 juin 2016 18:16
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail];
> [e-mail]
> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> 
> 
> 
> On 05/30/2016 02:22 AM, [e-mail] wrote:
> > Hi Shoaib,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : multipathtcp [mailto:[e-mail]] De la part de
> Rao
> >> Shoaib
> >> Envoyé : samedi 28 mai 2016 10:56
> >> À : [e-mail]; [e-mail]
> >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> >>
> >>
> >>
> >> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote:
> >>> Rao,
> >>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote:
> >>>>> The assumption is that this solution will be deployed in controlled
> >>>>> environments and only used between the CPE and the Concentrator.
> Since
> >>>>> the operator controls the two networks that are bound together, he
> can
> >>>>> verify that there are no middleboxes that drop the PM option.
> >>>>>
> >>>>>
> >>>>> Olivier
> >>>> I am extremely interested in encapsulating UDP in MPTCP but this
> >>>> solution is very specific and hence why should it even be
> standardized
> >> ?
> >>> There is a clear demand from operators for a solution to this problem
> >>> in hybrid access networks.
> >> OK but this solution is very specific to the mobile network.
> > [Med] The solution is not specific to the mobile network, but targets
> all network providers who want to allow their customers to make use of all
> available network attachments (e.g., fixed, WLAN, cellular, etc.)
> The way it is designed it is very specific to a particular use case and
> is not a generic encapsulation solution.
> >
> >   We would
> >> prefer a generic encapsulation solution which has no address mapping.
> > [Med] It seems that you want to cover the case of an MPTCP-enabled host
> communicating an MPTCP-enabled server exchanging any protocol data inside
> an MPTCP connection? Can you please confirm/infirm?
> Yes. We want a generic MPTCP encapsulation solution with no address
> mapping. Address mapping and other features (like single connection)
> should be separate options.
> >> Maybe the address mapping part should be made optional based on a flag
> ?
> > [Med] The technical details can be worked out once we understand your
> deployment case.
> >
> > [snip]
> OK.
> >
> >
> > After re-reading the draft I think the proposal for encapsulation is
> > pretty good, only minor details need to be cleared up.
> >
> > [Med] Thank you. We are more than open to discuss those details.
> >
> >
> Great. I think first we need to decide if we want a generic
> encapsulation solution (which is why I want) or do we entangle it with
> the other requirements of the cellular deployment.
> 
> Shoaib