Thank you very much for the excellent review. I do believe the “standardised” needs to change.
Authors, do you have comments on the rest? Jari On 06 Sep 2016, at 19:18, Dan Romascanu <droma...@gmail.com> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
