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

["Ford, Alan" <[e-mail]>]

Hi Michael,

Thank you for your feedback about the draft, most changes you suggest are easy to incorporate in the next revision (although regarding the first point, a key purpose of this draft is to explain how the various outputs of the WG fit together to create a Multipath TCP solution, and therefore referring to these drafts is necessary in places). 

Regarding a paragraph about the comparison with SCTP, this would likely be useful to new readers but I would appreciate input from people more familiar with SCTP for some text. Here is some suggested text as a starting point:

2.4 Related Protocols
  There are several similarities between SCTP [RFC4960] and
  MPTCP, in that both can make use of multiple addresses at end hosts to give
  some multi-path capability. In SCTP, this is by default to support multihoming
  and mobility (i.e. a single path will change one of its end host addresses).
  Extensions are proposed to support simultaneous multipath transport
  [I-D.draft-tuexen-tsvwg-sctp-multipath] but these are yet to
  be standardised. SCTP is, however, a completely new transport protocol and
  as such does not meet the network and application compatibility goals as
  specified above. For network compatibility, there are issues with various
  middleboxes (especially NATs) that are unaware of SCTP and consequently
  end up blocking it. For application compatibility, applications need to
  actively choose to use SCTP, and with the deployment issues very few choose
  to do so. MPTCP's compatibility goals are in part based on these observations
  of SCTP's deployment issues.

Thanks,
Alan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of SCHARF, Michael
> Sent: 15 November 2010 12:29
> To: [e-mail]
> Subject: [multipathtcp] Comments on draft-ietf-mptcp-architecture-02
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp