[Gen-art] [gen-art] review: draft-ietf-mptcp-architecture-04

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 14 January 2011 21:12 UTC

Message-ID: <4D30BCCA.4000109@joelhalpern.com>
Date: Fri, 14 Jan 2011 16:14:50 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mptcp-architecture.all@tools.ietf.org, philip.eardley@bt.com
Subject: [Gen-art] [gen-art] review: draft-ietf-mptcp-architecture-04
Precedence: list

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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?

Nits/editorial comments:

[Gen-art] [gen-art] review: draft-ietf-mptcp-arch… Joel M. Halpern