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

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 15 Nov 2010 13:29:22 +0100

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

---

From: "Ford, Alan" <[email-masked]>
Date: Mon, 29 Nov 2010 17:25:37 -0000

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

---

From: <[email-masked]>
Date: Mon, 29 Nov 2010 17:33:14 +0000

> SCTP is, however, a completely new transport protocol and
> specified above.

SCTP went standards-track ten years ago.

completely new, you say?

---

From: "Ford, Alan" <[email-masked]>
Date: Mon, 29 Nov 2010 17:35:45 -0000

Thanks, bad phraseology :-)

> From: [email-masked] [mailto:[email-masked]]
> Sent: 29 November 2010 17:33
> To: Ford, Alan; [email-masked];
[email-masked]
> Subject: RE: [multipathtcp] Comments on
draft-ietf-mptcp-architecture-02

---

From: "SCHARF, Michael" <[email-masked]>
Date: Tue, 30 Nov 2010 18:55:21 +0100

Alan, 

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

yes, I agree that that they are necessary in some 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

I think that this text is quite reasonable (apart from the "new", of course). I am not an SCTP expert, but I think that the following statement could maybe make sense as well:

It might be possible to use rather similar algorithms or heuristics both for MPTCP and for SCTP concerning certain functions that are needed in both cases, e. g., a management of paths. However, the additional protocol features of SCTP (e. g., unordered delivery) typically result in additional constraints that the design of MPTCP does not have to take into account.

Just a thought...

Michael