Re: [multipathtcp] Questions on

Yoshifumi Nishida <> Tue, 15 November 2016 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94DAF12961D for <>; Tue, 15 Nov 2016 06:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JxVoyovtXbIY for <>; Tue, 15 Nov 2016 06:35:28 -0800 (PST)
Received: from ( [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0887126BF7 for <>; Tue, 15 Nov 2016 06:35:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 417EC2784DE for <>; Tue, 15 Nov 2016 23:35:26 +0900 (JST)
Received: by with SMTP id 12so89052993uas.2 for <>; Tue, 15 Nov 2016 06:35:26 -0800 (PST)
X-Gm-Message-State: ABUngvcDC7PQ+dYLZNK3UjISdD2ZzyUl7ISzXrcqzUPs2YmuNBuN8Zo6wD6CQVtQzFz1XJ49LgqO31B4SefU7Q==
X-Received: by with SMTP id i45mr10917679uaa.126.1479220524438; Tue, 15 Nov 2016 06:35:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 15 Nov 2016 06:35:23 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB0C69@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <787AE7BB302AE849A7480A190F8B933009DAF424@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DB0C69@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <>
Date: Tue, 15 Nov 2016 06:35:23 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Questions on
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2016 14:35:31 -0000

Hi Med,
Sorry for my slow response. I put comments in lines.

On Sun, Nov 13, 2016 at 11:20 PM,  <> wrote:
> Hi Yoshi,
> Please see inline.
> Cheers,
> Med
>> -----Message d'origine-----
>> De : Yoshifumi Nishida []
>> Envoyé : jeudi 10 novembre 2016 20:21
>> Cc :;
>> Objet : Re: [multipathtcp] Questions on
>> boucadair-mptcp-plain-mode-09
>> Hi Med,
>> Thanks for the clarification. So, in my understanding,
>> off-path/on-path concept is like the followings.  (please point out if
>> I miss something)
>> on-path (implicit mode) ... The client doesn't need to know the
>> presence of MCP. The adpp just specifies the server address for the
>> end point of mptcp connection.
> [Med] Yes, this is only for the initial subflow. Subsequent subflows will use an address of the proxy.
>> off-path (explicit mode) ... The client needs to know the presence of
>> MCP. The app needs to use MCP's address for the destination. It also
>> need to get MCP's address (via DHCP or something else) and tells mptcp
>> stack to put it in MP_CONVERT option (via API?)
> [Med] this may be one way to implement it, but this is not my favorite one. I suggest the following:
> * The application does not need to know about the on-off/path modes.
> * This is handled at the MPTCP service level: if an address is configured via DHCP (or other means), it will behave in the Explicit mode.
> * MP_CONVERT option(s) are inserted by the MPTCP server accordingly.

Hmm. OK. But, DHCP is outside of mptcp. How the info from DHCP will be
delivered to mptcp without using API?

>> In this case, I think the off-path clients need to know that they are
>> off-path nodes and need to rely on MCP *before* communication starts.
> [Med] This is typically an information that is provided during network attachment, etc. For example,
> * a cellular device can retrieve the MCP information during the PDP context activation by means of a dedicated PCO Information Element.
> * a CPE will retrieve this information when it bootstraps.
> Note that  the client needs DNS information and other important service elements before to make use of a service. That's not particular to MPTCP.
>> But, I'm not very sure how they get such knowledge.
> [Med] Same as for DNS and other services (SBC, etc.). Do you foresee any particular issue?

i might miss something here. but, please let me explain a bit more.
BTW, I am looking at the figure 1 in the draft.
Let's say when H1 got address via DHCP, it found a MCP address in the
option. H1 doesn't know RM supports mptcp or not.
So, it use MCP as destination for mptcp connection. But, when RM
happens to be a mptcp node, this will be suboptimal.

To avoid this, I guess H1 needs to go into on-path mode (ignore MCP
info and use RM for destination) for this RM.
But, this might mean H1 will need to change modes based on
destinations and looks tricky.