Document: draft-ietf-mptcp-architecture-04
    Architectural Guidelines for Multipath TCP Development
Reviewer: Joel M. Halpern
Review Date: 14-Jan-2011
IETF LC End Date: Closed
IESG Telechat date: 20-Jan-2011

Summary: This document is almost ready for publicaiton as an Informational
RFC>  The items below should be evaluated before publication.

Major issues:
    A new requirement, "break-before-make" is added in the security design
decisions section (section 5.8).  Even if this is merely a desirable behavior,
it should be described in the behaviors before being referenced in the design
decisions.

Minor issues:
   The introduction could b e clearer about the assumptions regarding unused
resources.  As written, it gives the reader that there are unused resources
scattered around the Internet waiting to be used if we were only more clever.
While this is arguably true for the direct link to multi-homed hosts, and may
be true within sites or for the case of multiple links between a site and its
ISPs, this is rarely true for links within and between ISPs.  ISPs engineer
traffic loading on links to balance cost and utilization.
    Conversely, if the goal really is to change the traffic distribution in
the Internet core and to over-ride operator traffic engineering, then we have
a serious disconnect of goals, and operators will be very unhappy once they
realize it.  Better clarity indicating that we are not trying to do that would
help.  (Picking access addresses is, as far as I cen tell, legitimately the
users purview.  Controlling the path within the ISPs between such addresses is
not, I think, the users purview.)
    Such a change would also bring the introduction more in line with what the
proposals actually do.

    I would expect some mention of latency in the goals in section 2.1.  Is
the design constrained to preserve latency behavior?

    There seems to be an implicit requirement from the buffering description
(section 5.3) to allow either side of the communication to select which
connections are to be actively used.  Is this a goal or requirement?  Shold it
be stated somewhere?  If not, should the text in section 5.3 about selecting
whcih connections are used be tuned somewhat?