[multipathtcp] Comments on draft-ietf-mptcp-architecture-02

["SCHARF, Michael" <[e-mail]>]

Dear all,

I've read this document, and I think that it is in general in a good
shape.

Still, please find enclosed some thoughts on potential changes or
extensions. Unfortunately, I've missed the discussions in Beijing
concerning this document. I'd like to apologize if some comments have
already been raised elsewhere.

* In general, the document pretty frequently refers to the other drafts
in the MPTCP WG; yet, some of them will probably remain in draft status
for some time. I don't know whether this may be a formal problem.
Probably, an alternative would be to make the document a little bit more
self-contained. For instance, one could in most cases not refer to the
specific drafts, but instead to the type of document (something like:
"the MPTCP protocol specification will describe" instead of "document
[4] describes").

* According to section 1.2, the document distinguished between Multipath
TCP and MPTCP, and the abstract also uses the term "Multipath Transport
Protocol". It would make sense to explain more explicitly these slightly
different terms, e. g., in the introduction. Also, I think that one
should check throughout the document whether always the most appropriate
term is used. For instance, strictly applying the terminology, one could
argue that Figure 1 actually shows a "Simple Multipath TCP Usage
Scenario", as the MPTCP protocol details don't matter in that case.
Also, the terms "Multipath TCP" and "MPTCP" seem to get mixed up in
section 2, unless I miss something.

* I think it would be worth briefly discussing similarities and
differences of Multipath TCP's design choices and SCTP, e. g., somewhere
in section 2. It is pretty clear that there are fundamental differences
concerning network/application compatibility, congestion control, etc.,
but this might still be valuable information to readers less familiar
with SCTP.

* Section 4 somehow lacks a very brief description of the functions at
the receiver, which are, of course, pretty straightforward.

* Probably, it is up to me to raise this point: The explanation in
Section 5.4 why to use option encoding is pretty short. I wonder whether
it would make sense to record some of the discussions in particular from
the Maastricht meeting, e. g., a potential advantage of option encoding
concerning head-of-line blocking (when receive buffer space is scarce),
the implications of TCP offloading engines, etc. Some text from
draft-scharf-mptcp-mctcp might also be applicable.

* Section 7 should probably also mention that middleboxes/PEPs might
rewrite the receive window (increasing or decreasing it), and that
MPTCP's flow control may have to take this into account.

* Section 7 also doesn't explicitly list middleboxes that potentially
rewrite content (e. g., URIs), despite the discussions on this class of
middleboxes in past meetings.

* Nit: p. 18: "an MPTCP"


Best regards

Michael