Architectural Guidelines for Multipath TCP Development
RFC 6182

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) Yes

Comment (2011-01-19 for -)
No email
send info
An excellent document. Thanks for writing it.

I would change the urgent data support to a MAY, however.

Lars Eggert Yes

(David Harrington) (was Discuss) Yes

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-01-20 for -)
No email
send info
This is a useful document.

I believe that it would useful to the community to note much earlier, and with greater clarity, in the document that it is applicable to the ECMP case.  Whilst few hosts are dual attached most networks have ECMP, and better ECMP is the subject of work in the Routing area.

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) No Objection

Comment (2011-01-16 for -)
No email
send info
5.6.  Connection Identification

   Legacy applications will not, however, have access to this identifier
   and in such cases a MPTCP connection will be identified by the
   5-tuple of the first TCP subflow.  It is out of the scope of this
   document, however, to define the behaviour of the MPTCP
   implementation if the first TCP subflow later fails.  If there are
   MPTCP-unaware applications that make assumptions about continued
   existence of the initial address pair, their behaviour could be
   disrupted by carrying on regardless.  It is expected that this is a
   very small, possibly negligible, set of applications, however.  In
   the case of applications that have used an existing API call to bind
   to a specific address or interface, the MPTCP extension MUST NOT be
   used, since the applications are indicating a clear choice of path to
   use and thus will have expectations of behaviour that must be
   maintained, in order to adhere to the application compatibility

I am not convinced your use of MUST NOT is correct here. In fact, it seems that it is in direct conflict with the following paragraph:

   Since the requirements of applications are not clear at this stage,
   however, it is as yet unconfirmed what the best behaviour is.  It
   will be an implementation-specific solution, however, and as such the
   behaviour is expected to be chosen by implementors once more research
   has been undertaken to determine its impact.

I.e., it is actually possible to know from the current socket API what is the application intent in this case?

(Dan Romascanu) No Objection

Comment (2011-01-20 for -)
No email
send info
I support David's COMMENT

(Peter Saint-Andre) No Objection