Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 15 November 2016 14:35 UTC
Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DAF12961D for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 06:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxVoyovtXbIY for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 06:35:28 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0887126BF7 for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 06:35:27 -0800 (PST)
Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 417EC2784DE for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 23:35:26 +0900 (JST)
Received: by mail-ua0-f172.google.com with SMTP id 12so89052993uas.2 for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 06:35:26 -0800 (PST)
X-Gm-Message-State: ABUngvcDC7PQ+dYLZNK3UjISdD2ZzyUl7ISzXrcqzUPs2YmuNBuN8Zo6wD6CQVtQzFz1XJ49LgqO31B4SefU7Q==
X-Received: by 10.176.82.48 with SMTP id i45mr10917679uaa.126.1479220524438; Tue, 15 Nov 2016 06:35:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.84.152 with HTTP; Tue, 15 Nov 2016 06:35:23 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB0C69@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <aad12c71ad5748368c31385e1d099d60@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009DAF424@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249yfcOshFD0eO=mbod4kPAVC-=QGoWUDVy4DYTfL=EFLu3g@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009DB0C69@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 15 Nov 2016 06:35:23 -0800
X-Gmail-Original-Message-ID: <CAO249yffePk+ahsjRWzR3CDu5T9zqXti0X+PvvDyDpCTkoN=XQ@mail.gmail.com>
Message-ID: <CAO249yffePk+ahsjRWzR3CDu5T9zqXti0X+PvvDyDpCTkoN=XQ@mail.gmail.com>
To: mohamed.boucadair@orange.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/yGV8OacWspyGy8eYJix3cKDKJe0>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=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, <mohamed.boucadair@orange.com> wrote: > Hi Yoshi, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >> Envoyé : jeudi 10 novembre 2016 20:21 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : philip.eardley@bt.com; multipathtcp@ietf.org >> Objet : Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft- >> 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. -- Yoshi
- [multipathtcp] Questions on https://tools.ietf.or… philip.eardley
- Re: [multipathtcp] Questions on https://tools.iet… mohamed.boucadair
- Re: [multipathtcp] Questions on https://tools.iet… Yoshifumi Nishida
- Re: [multipathtcp] Questions on https://tools.iet… Olivier Bonaventure
- Re: [multipathtcp] Questions on https://tools.iet… mohamed.boucadair
- Re: [multipathtcp] Questions on https://tools.iet… Yoshifumi Nishida
- Re: [multipathtcp] Questions on https://tools.iet… mohamed.boucadair