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

["Jari Arkko" <[e-mail]>]

Jari Arkko has entered the following ballot position for
draft-ietf-mptcp-experience-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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.