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

[Olivier Bonaventure <[e-mail]>]

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

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


Olivier