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 value found for 'p.get_dochistory.rev' **)
No email
send info
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 value found for 'p.get_dochistory.rev' **)
No email
send info
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 value found for 'p.get_dochistory.rev' **)
No email
send info
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 goals. 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 value found for 'p.get_dochistory.rev' **)
No email
send info
send info
I support David's COMMENT