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

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure <
[e-mail]> wrote:

> Yoshifumi,
>
>>
>> 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.
>>
>
> There is already operational experience with this type of solution and it
> turns out that using MPTCP to support TCP traffic in hybrid access networks
> is a much better approach than using a tunneling technique like GRE. In an
> hybrid access network such as DSL+LTE, there are two types of problems that
> need to be tackled :
>
> 1. How to hide the different addresses used on the DSL and LTE networks
> 2. How to achieve efficient load balancing over networks having different
> characteristics (delay, bandwidth, packet losses) that change dynamically
>
> GRE solves the first problem in a clean manner. However, it causes two
> issues when you consider the second problem :
>
> a. Since paths have different delays, doing per packet load balancing
> creates massive reording that results in bad TCP performance
> b. Since the two underlying paths are hidden by encapsulation, TCP's
> congestion control scheme cannot probe the different paths and adjust ths
> congestion window correctl. This results in bad TCP performance as well.
>
> An MPTCP-based solution solves these problems in a clean manner since
> MPTCP sees the different paths and can use them efficiently.
>
> You can find some additional information in the Tessares whitepaper
> published last year
>
> http://www.tessares.net/white-papers/
>
> There is already operational experience with this type of MPTCP-based
> solutions and if you think that this would be useful, we could organise a
> presentation at the next IETF meeting on this experience


I think I understand general idea.
But, as far as I read the draft, I got an impression that a UDP or a TCP
flow will be mapped to a single subflow of a mptcp session.
There is no description about using multiple subflows for a single TCP/UDP
flow, or updating subflow mappings in the middle of a session.
I think the draft should mention these cases.


>> 2: Including data in SYN is allowed in RFC793, but I'm not very sure how
>> many implementations actually accept it.
>>
>
> Well, the deployment of TFO shows that this is possible.
>
> 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?
>>
>
> 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.


Hmm. then, I think these presumptions should be listed in the draft.
But, one concern is the proposal will be too specific to standardize if
there're too much presumptions...

Thanks,
--
Yoshi