Last Call Review of draft-ietf-mptcp-experience-06

Request Review of draft-ietf-mptcp-experience
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-09-13
Requested 2016-09-01
Authors Olivier Bonaventure, Christoph Paasch, Gregory Detal
Draft last updated 2016-09-06
Completed reviews Genart Last Call review of -06 by Dan Romascanu (diff)
Opsdir Last Call review of -06 by Qin Wu (diff)
Assignment Reviewer Dan Romascanu 
State Completed Snapshot
Review review-ietf-mptcp-experience-06-genart-lc-romascanu-2016-09-06
Reviewed rev. 06 (document currently at 07)
Review result Ready with Issues
Review completed: 2016-09-06


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-mptcp-experience-06

Reviewer: Dan Romascanu
Review Date: 9/6/16
IETF LC End Date: 9/13/16
IESG Telechat date: 9/15/16

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.'

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

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.

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.

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.

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

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.