Re: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
<mohamed.boucadair@orange.com> Thu, 10 November 2016 12:54 UTC
Return-Path: <mohamed.boucadair@orange.com>
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 A211A129653 for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 04:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.115
X-Spam-Level:
X-Spam-Status: No, score=-4.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 skhrh1gB9aqv for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 04:54:08 -0800 (PST)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE6F12964F for <multipathtcp@ietf.org>; Thu, 10 Nov 2016 04:54:07 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2B8CEC0E14 for <multipathtcp@ietf.org>; Thu, 10 Nov 2016 13:54:06 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id EA0821A005D; Thu, 10 Nov 2016 13:54:05 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 13:54:05 +0100
From: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
Thread-Index: AdI7RtWPXAJrxKOvRqmf0uDPFFIgTgABYgFQ
Date: Thu, 10 Nov 2016 12:54:05 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF424@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <aad12c71ad5748368c31385e1d099d60@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <aad12c71ad5748368c31385e1d099d60@rew09926dag03b.domain1.systemhost.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAF424OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/DIxj_2DHkigzGgC2kWWqolFfP9Q>
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: Thu, 10 Nov 2016 12:54:10 -0000
Hi Phil, Please see inline. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com Envoyé : jeudi 10 novembre 2016 12:40 À : multipathtcp@ietf.org Objet : [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09 A few questions Sections 4 & 5 discuss operation with a single-ended proxy, ie one end host is MPTCP-enabled and the other end host is 'legacy' TCP. The figures and discussion seem to assume the MPTCP-enabled end host initiates the connection. Is the case also covered where the TCP end host initiates the connection? [Med] Yes. We already have those details in -08 of the draft and some of the details were presented in Buenos Aires meeting (see slide 14 of https://www.ietf.org/proceedings/95/slides/slides-95-mptcp-1.pdf) We removed these details because we wanted to make sure that the base behaviour is well understood. In Sections 4 & 5, the MPTCP-enabled end host is assumed to know the address of the TCP end host. I assume this is through existing techniques. [Med] Yes. It may mean that an operator has to be careful, for instance if they're doing caching at the edge of the network and the proxy is more central. from the point of view of the path packets take, this seems the same drawback as if tunnelling is present - not sure if there could be unpleasant mptcp protocol interactions? [Med] Two comments here: · This is an issue for MPTCP in general: https://tools.ietf.org/html/draft-ietf-mptcp-experience-07#section-3.9 · The location of the MCP is deployment-specific. An operator that controls both access legs is likely to make sure that DNS service is appropriately configured. An example would be to collocate the MCP with the BNG function and mandate the use of the DNS server provisioned via the fixed line. Other approaches can be considered but this is really deployment-specific. In section 6, two-ended MPTCP proxy (neither end host is MPTCP-enabled) << If the downstream MCP is deployed on-path, it only terminates MPTCP connections that carry an empty MP_CONVERT option inside their SYN (i.e., no address is conveyed). If the MCP receives a SYN segment that contains the MP_CAPABLE option but no MP_CONVERT option, it MUST forward the SYN to its final destination without any modification. >> Comment: I found the description confusing. Not sure what downstream and upstream mean, as the figure shows bi-directional communications. [Med] Section 6 clearly indicates what is meant by Upstream and Downstream MCP Upstream Downstream C <---> MCP <===========> MCP <------------> S +<=============>+ Legend: <===>: MPTCP leg <--->: TCP leg Figure 7: A Client interacts with a Server through an upstream and a downstream Multipath Conversion Points and Upstream Downstream +--+ +-----+ +-----+ +--+ |C1| | MCP | | MCP | |S1| +--+ +-----+ +-----+ +--+ C@1 uMCP@1 uMCP@2 dMCP@ S@ ... Further, the use case section states the following: == In this use case, neither the Client nor the Server support MPTCP. Two MCPs are used as illustrated in Figure 2. The upstream MCP is embedded in the CPE while the downstream MCP is located in the provider's network. The CPE is attached to multiple access networks (e.g., xDSL and LTE). The upstream MCP transparently terminates the TCP connections initiated by the Client and converts them into MPTCP connections. Upstream Downstream +--+ +-----+ +-----+ +--+ |H1| | MCP | | MCP | |RM| +--+ +-----+ +-----+ +--+ | | | | |<---TCP--->|<========MPTCP Leg===========>|<---TCP--->| | | | | Figure 2: Network-assisted MPTCP (CPE-based Model) == Off path and on path I also found confusing. [Med] Fair comment. We thought that the reader is familiar with the deployment models in: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html#section-5.2 If I get it right, on path means that you guarantee the first subflow goes through the proxy [Med] Yes. For example, the proxy is on the default forwarding path of a primary link. - what happens if it doesn't? [Med] Network-assisted MPTCP connections will fail. Note that if the primary link is unavailable for some reason, (1) the service cannot be provided through the secondary link in situations where only private IPv4 addresses are assigned on the secondary link or (2) some communications may not be established if only IPv6 prefixes are assigned in that link. what benefit does having this extra on-path (implicit mode) mechanism bring? (I know there's been some discussion on this, is there a summary of the conclusion?) [Med] It may allow for quick network-assisted MPTCP deployments if a provider does not want to wait for the MP_CONVERT to be fully endorsed. Native MPTCP connections will be broken because the MCP will systematically revert them to TCP. The support MP_CONVERT will solve that problem for the implicit mode. BTW, as an editor of the document, I'm trying to avoid mandating explicit or implicit as this should be the responsibility of each operator. How does the first proxy know the address of the most appropriate second proxy (ie the proxy nearest the other end host)? [Med] This is done by means of DHCP, for instance. Please refer to Section 6.2.2: In this section, we assume that the upstream MCP has been configured with one address of the downstream MCP. This address can be configured statically, dynamically distributed by means of a DHCP option [I-D.boucadair-mptcp-dhc<https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09#ref-I-D.boucadair-mptcp-dhc>] or by any other means that are outside the scope of this document. The mechanism mentions a token, is this a re-use of one of the existing tokens in https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ or a new one? [Med] This is the token defined in https://tools.ietf.org/html/rfc6824: Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID". Thanks [Med] Thank you. phil
- [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