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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-mptcp-architecture-tsvdir-lc-jennings-2010-12-24

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