Last Call Review of draft-ietf-mptcp-architecture-
review-ietf-mptcp-architecture-tsvdir-lc-jennings-2010-12-24-00

I have reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any  issues raised.
Please consider these like any other last call comments,

Summary: This draft is ready for publication as Informational.

This draft is easy to understand and does a fine job of explaining the overall
big picture of the solution without going into the details of the the design.
In addition to being an architecture, it is also a set of requirements for the
protocol design. It describes a protocol that is consistent with, and meets the
goals of, the WG charter.  I raise two minor issues which folks might want to
consider but in my opinion it would be fine to publish the draft without any
changes to address these issues.

Minor Issues:

I was a little surprised not to see any discussion of OOB data. Would this be
support? send on both path? send only on one path?

I wonder if anything needs to be said about TCP options - particularly the case
where an application that thinks it is using TCP is actually dealing with MPTCP
and the options are different on the two paths. Consider a hypothetical case
like such as TCP Compression Filters. If an application had a socket level API
to turn this on and off and see if it was working or not, and one path
supported it but the other path went through an IDS systems that did not
support it, what would happen? Perhaps all that needs to be said is that each
option is separate and just because an given OS supports a specific option for
TCP, it does not mean the option will work for MPTCP. From a practical point of
view, when I look at the options in use today, this does not look like a big
deal for MPTCP.

Nits:

On page 8 2n'd para from bottom, you have

   as a significant deployment bottleneck for any transport
   that is not TCP

I think this should by changed to say "TCP or UDP" instead of just TCP