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

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

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