Re: [multipathtcp] New Version Notification for draft-boucadair-mptcp-plain-mode-10.txt

Alan Ford <> Thu, 23 March 2017 23:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC13C129516 for <>; Thu, 23 Mar 2017 16:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqupENsCaOtR for <>; Thu, 23 Mar 2017 16:40:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7C89127058 for <>; Thu, 23 Mar 2017 16:40:43 -0700 (PDT)
Received: by with SMTP id y18so987971itc.1 for <>; Thu, 23 Mar 2017 16:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ck7IzmXsCvOLBDDx64Bgj1IyVZnjmXGyQliFg8Ad2wk=; b=jp9j6zk0mr3p57M7/vsfCqW1Lm3LTdN6ENuAE6hcNTfEH9agSD4Tv5K6myCwSJl3YU uTmgL+KMOp1DiNewBoBkc0+SjY9ECvzTYc0VVy8uQnqaFJf+CrD5DCtYqiY7PMV0kaHx BsP09pHvQB++2kPoGbd3lJN/L83UOoHVzTYQ1vCPrtO6qa6AzDYSjAEb5TcpFJ+4cvWn FNoucVaX5+BstCPqVXSML0JFLRa/dH1eCOQnhDqfyfQ5jO3oOaP1+FIjkMPYU1DJI+4A uAPo/7ot9KRGTxqOqe4gtS8bXtadXBIwoQrNUoGeEE+eko8HfpCN5blWjemiE+qN1aCa C2fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ck7IzmXsCvOLBDDx64Bgj1IyVZnjmXGyQliFg8Ad2wk=; b=bgp6Hj/S+jTFIjiSB/eYq7sKlVY8PYKA+o651dbRY9KOzTZJX3HdquFee/Lu4yJjl9 1ykuj1vfZ/ENJTK12fSmaom4mPujrs0FIRD7YRjAs6azbPNmIRLuXA1Jw3VUqESAgdjg ruEAF8tH3IF0b5A/MC0CLTQv42ArcWr4Sw3Ph8w/fB+nS+aRa/buuvt/8clufFYkX397 K1nZYgE8Lm9ubleW1gvC2gl8RDWuj3qRV7mSnXvTSZENybUPOn/3Mc2kwPKfnoxfRc3X D9Vzuy4HudjK61sC2knhCFQDsQxlzumVB4riNwLkvCUddlFGgsNUB0+rF4ThmEiwpoV2 osVg==
X-Gm-Message-State: AFeK/H3tmUDSANXbKjFrUNxQTu2yLZUEas3JLxNqz85L75F4P+ijF1W59anhoDJuR3BfLg==
X-Received: by with SMTP id p202mr367944itb.97.1490312443170; Thu, 23 Mar 2017 16:40:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y21sm374329ioi.0.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Mar 2017 16:40:12 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_38361FA2-18E3-4C7B-89F7-4B87FDD37DEA"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E214F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 23 Mar 2017 23:40:11 +0000
Message-Id: <>
References: <> <787AE7BB302AE849A7480A190F8B933009E214F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [multipathtcp] New Version Notification for draft-boucadair-mptcp-plain-mode-10.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Mar 2017 23:40:47 -0000

Hi Med, all,

Thanks for this, and I’m sorry it’s taken a couple of weeks to respond. This document is certainly clearer to follow than previous versions and it’s clearer where you’re going with this now. You have two different ways of implementing MPTCP proxying which work in different deployment scenarios.

My main concern remains the need for this MP_PREFER_PROXY option.

The use case as I see it is for the CPE acting as an MCP to insert this into the flow in order to signal for the other MCP to pick up the flow and proxy it. But I still find myself asking why?

Why is this solution uniquely better than either:

- Explicitly address the MCP using MP_CONVERT; or
- Just insert MCP into everything which doesn’t support MPTCP anyway

This would potentially require DHCP to deliver the MCP address for point 1, and potential policy configuration as to what to proxy and what not to for point 2, but are these significant issues? What sort of policy would a client be able to apply which a proxy would not be able to? And are there any scenarios why the MP_PREFER_PROXY bit is the only way of achieving what you want?

Given this option is now a separate option and not a bit in the MP_CAPABLE handshake I am less concerned about its impact on the base protocol spec, since this can be kept entirely separate, but I am still puzzled as to the actual real-world requirements of this rather than the other two options.

As a side issue, and not to derail this conversation, I’d rather the term “MP_CONVERT" didn’t look quite so much like an MPTCP option when it wasn’t.


> On 10 Mar 2017, at 08:43, wrote:
> Dear all, 
> A new version of the draft is available online. This version integrates the comments that were raised on the mailing list. 
> We had many off-line discussions with Alan, this version is the outcome of those discussion. The main changes are:
> * MP_CONVERT object does not consume anymore the MPTCP option codepoints space.
> * A new MPTCP option (MP_PREFER_PROXY) is defined to demux native connections vs proxied one when the implicit mode is in use.
> * MCPs are now able to detect if remote MCPs do not support MP_CONVERT
> * Only TCP is covered
> * Interference with TFO are discussed 
> Comments, questions, and suggestions are always welcome.
> Cheers,
> Med
>> -----Message d'origine-----
>> De : []
>> Envoyé : vendredi 10 mars 2017 08:52
>> À : Wim Henderickx; Luis M. Contreras;; Wouter
>> Cloetens; Suresh Vinapamula; Denis Behaghel; BOUCADAIR Mohamed IMT/OLN;
>> Suresh Vinapamula; Robert Skog; Luis Contreras; JACQUENET Christian
>> IMT/OLN; Bart Peirens; Ullrich Meyer; Denis Behaghel; Olivier Bonaventure;
>> SungHoon Seo; Stefano Secci
>> Objet : New Version Notification for draft-boucadair-mptcp-plain-mode-
>> 10.txt
>> A new version of I-D, draft-boucadair-mptcp-plain-mode-10.txt
>> has been successfully submitted by Mohamed Boucadair and posted to the
>> IETF repository.
>> Name:		draft-boucadair-mptcp-plain-mode
>> Revision:	10
>> Title:		Extensions for Network-Assisted MPTCP Deployment Models
>> Document date:	2017-03-09
>> Group:		Individual Submission
>> Pages:		25
>> URL:  
>> mptcp-plain-mode-10.txt
>> Status:
>> plain-mode/
>> Htmlized:
>> mode-10
>> Diff: 
>> plain-mode-10
>> Abstract:
>>   Because of the lack of Multipath TCP (MPTCP) support at the server
>>   side, some service providers now consider a network-assisted model
>>   that relies upon the activation of a dedicated function called MPTCP
>>   Conversion Point (MCP).  Network-Assisted MPTCP deployment models are
>>   designed to facilitate the adoption of MPTCP for the establishment of
>>   multi-path communications without making any assumption about the
>>   support of MPTCP by the communicating peers.  MCPs located in the
>>   network are responsible for establishing multi-path communications on
>>   behalf of endpoints, thereby taking advantage of MPTCP capabilities
>>   to achieve different goals that include (but are not limited to)
>>   optimization of resource usage (e.g., bandwidth aggregation), of
>>   resiliency (e.g., primary/backup communication paths), and traffic
>>   offload management.
>>   This document specifies extensions for Network-Assisted MPTCP
>>   deployment models.
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
> _______________________________________________
> multipathtcp mailing list