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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
