Thank you very much for the excellent review.

I do believe the “standardised” needs to change.

Authors, do you have comments on the rest?


On 06 Sep 2016, at 19:18, Dan Romascanu <> wrote:

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Gen-art mailing list

Reply via email to