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

[<[e-mail]>]

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.)

 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?

> 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]
> >>
> >> Also the concentrator stuff is deployment specific and should added as
> >> an application header.
> >
> > What do you mean by concentrator stuff ?
> Address mapping stuff -- Use of D bit.
> >
> >> What needed is a standard way (new option) to signal the other end that
> >> the current message needs special handling and that's it. How such a
> >> message is handled can be implementation specific.
> >
> > In hybrid access networks, MPTCP_based bonding for UDP is mainly
> > useful for large flows. In this case, creating an MPTCP connection per
> > flow implies that you do not need to reproduce the IP and UDP headers
> > in the MPTCP connection
> >
> For our use case (Host Environment) preserving ports and reducing number
> of connections is more important. Including protocol message header
> allows use of the same connection for encapsulating any protocol and any
> port. Also note that size of UDP header is only 8 bytes and we can omit
> checksum and reduce it to 6 bytes which is a very small fraction for
> even a 1K message size.
> 
> 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.

> Shoaib
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp