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

[Joe Touch <[e-mail]>]

On 6/2/2016 7:58 PM, Henderickx, Wim (Nokia - BE) wrote:
> In-line
>
>
>
>
> On 02/06/16 10:17, "multipathtcp on behalf of Joe Touch" <[e-mail] on behalf of [e-mail]> wrote:
>
>>
>> On 6/2/2016 7:02 AM, [e-mail] wrote:
>>> Hi Behcet,
>>>
>>> As one of the operators very interested in this, I don’t think it is over blown and the use case you describe might be the first one for a number of operators, but others are following. Fundamentally it is about resource pooling of access networking resources (of whatever technology transporting IP).
>>>
>>> We are well-aware of the problems of a MPTCP-based solution (and draft-boucadair tries to solve some of them). However, we are not aware of any better standardized solution for multiple paths with heterogeneous characteristics of available and varying bandwidth, varying delays, and different packet handling characteristics. In case there is better ways of solving that problem let us know. 
>> Why wouldn't an overlay that employs dynamic routing be easier?
>>
>> It wouldn't incur the delays of using reliable delivery with messages
>> that don't preserve IP datagram boundaries and it's already supported
>> with existing equipment. Further, it could use much more sophisticated
>> path monitoring and choice.
>>
>> I.e., this is exactly what you'd get if you deploy something akin to
>> LISP and basically ignore the label distribution problem (which you
>> really don't have).
>>
>> Joe
> WH> it doesn’t solve the use case where packets of a flow have to be split over multiple links and reordering + congestion control is required for these flows. If these requirements were not there you’re right that routing can be used.

What you really don't want are:

     - to take a RTT hiccup to recover from a segment loss

    - to implement congestion control over your tunnels underneath
congestion control inside transport on the IP packets you carry

IMO, order preservation should be something done at the endpoints, not
in the net, but if that's all you have left you can implement that with
a fixed amount of delay at the egress collection point.

None of this is worth the complexity and side-effects of MPTCP, IMO.

Joe