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

[<[e-mail]>]

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[e-mail]]
Envoyé : jeudi 26 mai 2016 08:31
À : Olivier Bonaventure
Cc : Yoshifumi Nishida; BOUCADAIR Mohamed IMT/OLN; MultiPath WG; [e-mail]
Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Hi Olivier,

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure <[e-mail]<mailto:[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.

[Med] The draft says the following:

Section 5.1:


The data carried in UDP datagrams belonging to

   a given UDP flow are therefore transported in an MPTCP connection.



   The management of MPTCP connections that are triggered by UDP

   datagrams follows the guidelines documented in [RFC6824<https://tools.ietf.org/html/rfc6824>].

Section 5.2:

   A flow example is shown in Figure 5 to illustrate how TCP packets are
   generated to relay UDP datagrams using several subflows.  Non-SYN
   messages that belong to a given subflow do not include any PM option.
   Also, this example shows how subsequent UDP datagrams of this flow
   are transported over the existing subflow or how a new subflow is
   created.  In this example, the SYN segment issued to add a new
   subflow also includes data received in a UDP datagram.

and


   Figure 6 shows an example of UDP datagrams that are transported over

   MPTCP subflows.  Unlike the previous example, additional subflows to

   transport UDP datagrams of the same flow are established in advance

   between the CPE and the concentrator.

Do you think additional text is needed to make it clear? Thank you.

There is no description about using multiple subflows for a single TCP/UDP flow, or updating subflow mappings in the middle of a session.

[Med] Please refer to Figures 5 & 6.

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.

[Med] These assumptions are already called out in the draft, e.g.,

Section 1:


Also, it assumes the various

   network attachments provided to an MPTCP-enabled CPE are managed by

   the same administrative entity.

Section 4.2:


Given

      that this option is designed to be used in a controlled

      environment, this specification recommends to always place the PM

      options inside the payload of a SYN segment.

Do you think additional text is still required?