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

[Rao Shoaib <[e-mail]>]

BTW another use case we have is to use multiple TCP flows for different 
priority messages. In such a deployment we would not divide a single UDP 
packet and send it over multiple TCP streams but the complete message 
will be sent on a single stream based on the priority. This would avoid 
head of line blocking due to large messages for small high priority 
messages.

Shoaib

On 06/03/2016 12:53 AM, Rao Shoaib wrote:
>
>
> On 06/03/2016 12:41 AM, [e-mail] wrote:
>> 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.
> MPTCP allows us to break a large UDP message into several segments and 
> use multiple paths, Plus the added reliability. This reminds me of 
> another issue, what happens if a fragment other than the 1st one that 
> carries the header shows up first ? We need a header in each packet 
> that indicates the order and association just like IP fragmentation.
>>
>> 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?
> Correct but why would I even want to send an IP address ? Why can't 
> there be a flag to indicate that this packet carries no address 
> translation information. Ideally encapsulation should be an option on 
> it's own as it has nothing to do with address translation.
>
> Shoaib
>>   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
>