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

[Yoshifumi Nishida <[e-mail]>]

Hi Med,

On Mon, May 30, 2016 at 1:48 AM, <[e-mail]> wrote:

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

Well, It is still not very clear to me how each UDP packet is mapped to a
mptcp session.
How do you distinguish each UDP packet ? Is it based on 4-tuple or others?
The notion of Internal transport session identifier is a bit ambiguous.
If 4-tuple is not used, how do you construct packets when you send back
them at CPE?


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

hmm, even though it is designed to be used in a certain environment, what
if it is used in other situations?
I personally think the draft is a bit ambiguous on this point.
--
Yoshi