Re: [multipathtcp] Jari Arkko's Discuss on draft-ietf-mptcp-experience-06: (with DISCUSS and COMMENT)

Olivier Bonaventure <> Thu, 27 October 2016 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B43101296B5; Thu, 27 Oct 2016 13:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WGjZXG7zfP66; Thu, 27 Oct 2016 13:07:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 169251293E9; Thu, 27 Oct 2016 13:07:38 -0700 (PDT)
Received: from mbpobo.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 13D8C67DD70; Thu, 27 Oct 2016 21:59:23 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 13D8C67DD70
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1477598363; bh=M3lJynexeDrWh0sPDcPu8YlwR91FI0UAukP0gp0oDRE=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=SARNd61aOen3lVZvzY5vHwuy9HmTh2gjYYYrwTRoF9tTa5p/EEwVakuQt+buKvsAp PPPHrmLGMxWWPpK2rKU65os9II3yP2n9qTv/VnLq7B9lFv8V80F9FdyRIYCTGqBFiS J4VMfdD1yRxCN+sHF/mlmPZEINgVXP7CjIJKBit0=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-5
References: <>
To: Jari Arkko <>, The IESG <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Thu, 27 Oct 2016 21:59:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 13D8C67DD70.AAFB2
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] Jari Arkko's Discuss on draft-ietf-mptcp-experience-06: (with DISCUSS and COMMENT)
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: Thu, 27 Oct 2016 20:07:41 -0000


Thanks for your comments. The draft has now been updated and will be 
pushed on the IETF servers.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This is a great document, thank you for writing it.
> I have one small change request though (based on Dan Romascanu's Gen-ART
> review):
>> Multipath TCP was standardized in [RFC6824]
> Please change this to "specified" (RFC 6824 is experimental).

This has been corrected.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I would also like to request that the authors look at Dan's other
> comments:
> ---
> Summary: Ready with issues
> A very useful and well written document, which gathers implementation
> and deployment experience and expands the list of the Multipath TCP
> Use Cases. A few minor issues described below, if addressed, could
> improve the clarity and usability of the document.
> Major issues:
> Minor issues:
> 1. The 'Introduction' section starts with the statement:
> Multipath TCP was standardized in [RFC6824] and five independent
>   implementations have been developed.
> Saying 'was standardized' seems misleading to me, as RFC 6824 is an
> experimental RFC, so not even standards-track (this putting aside the
> discussions whether RFCs are standards). Actually at no point this
> document mentions that Multipath TCP is Experimental, this seems odd.


> 2. It would be useful to clarify the statement about the iOS
> implementation of Multipath TCP in the Introduction by mentioning what
> 'single application' is referred.
> However, this particular Multipath TCP implementation is currently only
> used to support a single application.'

This has been fixed. We also reference a forthcoming IETF journal 
article that explains some lessons learned from this large deployment on 

> 3. I am questioning whether the 'Multipath TCP proxies' section really
> belongs to the use cases or rather to operational experience. After
> all it's about a strategy of deployment of Multipath TCP in cases
> where clients and/or servers do not support Multipath TCP but the need
> exists probably because of the combination of one or several other use
> cases.

Both approaches are still. Given that there is ongoing work on 
specifying extensions to better support MPTCP proxies, we have chosen to 
leave the discussion in the use case section. If the work on MPTCP 
proxies progresses well, we could have more operation experience with 
these proxies that would warrant another document.
> 4. In section 3.5:
> There have been suggestions from Multipath TCP users to modify the
>   implementation to allow the client to use different destination ports
>   to reach the server.  This suggestion seems mainly motivated by
>   traffic shaping middleboxes that are used in some wireless networks.
>   In networks where different shaping rates are associated to different
>   destination port numbers, this could allow Multipath TCP to reach a
>   higher performance.  As of this writing, we are not aware of any
>   implementation of this kind of tweaking.

This part has been updated because with the new socket API enables, this 
could be done inside an application.
> Beyond the potential problems described in the following paragraph, is
> such a 'tweak' consistent with the protocol definition, or would it
> need to cause changes in the protocol as defined now? A clear
> recommendation seems to be needed here.

There is a tussle that should be discussed in rfc6824bis. On other hand, 
using different destination ports for additional subflows causes a 
burden on the server from an implementation viewpoint. On the other 
hand, using different destination ports could allow an application to 
bypass some middleboxes that are known to interfere.
> 5. A more clear recommendation would be useful also in 3.8. It is not
> clear here whether the segment size selection is a design or a tuning
> issue that can/should be added to applications.

A Multipath TCP implementation should not allow an application to set 
different MSS sizes for different subflows. Unfortunately, this is not 
sufficient since in most cases the MSS that is used for a subflow is a 
consequence of the MSS clamping used by middleboxes on the path of this 
subflow. We have added the following sentences:

Given the prevalence of	middleboxes that clamp the MSS,	Multipath
TCP implementations must be able to efficiently	support	subflows
with different MSS values. The strategy	described above	is a possible
solution to this problem.

> Nits/editorial comments:
> 1. Section 3.12 contains a timed statement 'As of September 2015 ...'
> which should be updated or maybe edited to make it less
> time-dependent.

> 2. It seems to me that [RFC6824] and [RFC6181] should be Normative
> References as they describe the protocol extensions, and the initial
> list of use cases which is expanded by this document. Without reading
> these two documents, this one does not make too much sense.


Thanks for your comments