Multipath TCP (MPTCP) Application Interface Considerations
draft-ietf-mptcp-api-07
Yes
(Wesley Eddy)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
Note: This ballot was opened for revision 06 and is now closed.
Wesley Eddy Former IESG member
Yes
Yes
(for -06)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2012-11-08 for -06)
Unknown
Nice document -- well written and interesting. Just a few minor, non-blocking comments (happy to chat about them if you like): -- Section 3.1 -- 3.1. Performance Impact One of the key goals of adding multipath capability to TCP is to improve the performance of a transport connection by load distribution over separate subflows across potentially disjoint paths. Furthermore, it is an explicit goal of MPTCP that it should not provide a worse performing connection than would have existed through the use of single-path TCP. A corresponding congestion control algorithm is described in [7]. The following sections summarize the performance impact of MPTCP as seen by an application. The word "impact" is a dicey one: historically, it refers to a collision. Because of that, it has a negative connotation: something that has "impact on our schedule" is assumed to hurt the schedule, not help it. "Performance impact" carries an implication of poorer, not better, performance. I strongly suggest you change the section title to "Performance Improvements" (or the neutral "Effect on Performance"). I would also like to see "impact" changed to "effect" throughout the document, but perhaps the editors and WG will disagree. Remember that these are non-blocking comments, and you don't have to change this just because I said so. Also, "should not provide a worse..." is pretty awkward. May I suggest, "Furthermore, it is an explicit goal of MPTCP that it provide a connection than performs at least as well as one using single-path TCP." -- Section 4.6 -- "Socket buffet dimensioning" should, I think, refer to buffers, not buffets, tasty affairs though the latter be. -- Section 5.3.3 -- If no port number is provided by the application, the port number is automatically selected by the MPTCP implementation, and will usually be the same across all subflows. Is it worth saying any more about this? If not, what's the value of knowing that the port number will "usually" be the same, if it's not behaviour that applications can rely on? It should be noted that this signal is only a hint, and an MPTCP implementation MAY only use a subset of the addresses. This is fine, but might be mis-read: someone might take "MAY only use" to mean "is only allowed to use" (as though it were "MUST only use"). You might consider re-wording this to say, "MAY use only a subset", or, maybe better, "MAY select only a subset". -- Section 10 -- The views expressed here are those of the author(s) only. I normally wouldn't quibble about anything written in an Acknowledgments section, and I'm sure this is boilerplate text that comes from elsewhere. But it's patently false (and I'm on the fence about whether this should be a DISCUSS): what's expressed in this document comes from the MPTCP working group, and, indeed, the IETF as a whole, not from the authors only. Is there a way you can fix this text that would be acceptable to the BMBF, the Trilogy Project, etc? Maybe, "The views expressed here are those of the IETF," or, "The views expressed here are those of the Internet community." ?
Benoît Claise Former IESG member
No Objection
No Objection
(for -06)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -06)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -06)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2012-11-13 for -06)
Unknown
A good document and I almost hit the 'YES' button instead of 'No Objection', but I have some comments below. My main point is whether there is the need to define the data types for the parameters of the socket API. The implementers are free to do whatever they like. However, I can see that the data types are for information only. But this isn't so clear from the document. Here are the comments and I would like to see a response to them, though it is mandatory to respond: Section 5.3.1., paragraph 7: > Table 1 shows a list of the abstract socket operations for the basic > configuration of MPTCP. The first column gives the symbolic name of > the operation. The second and third columns indicate whether the > operation provides values to be read ("Get") or takes values to > configure ("Set"). The fourth column lists the type of data > associated with this operation. In addition to IP addresses, an > application MAY also indicate TCP port numbers, as further detailed > below. I would add that the data types are listed for information only. Section 5.3.1., paragraph 10: > o TCP_MULTIPATH_ENABLE: This value SHOULD only be set before the > establishment of a TCP connection. Its value SHOULD only be read > after the establishment of a connection. The usage of 'SHOULD' isn't right here, or asking differently: Can a MPTCP isocket return to regular TCP socket once the connection is established? I would propose to simply say 'should only be set'. Section 5.3.1., paragraph 13: > o TCP_MULTIPATH_SUBFLOWS: This value is read-only and SHOULD only be > used after connection setup. I am not sure that the 'SHOULD' is correct here. It is more than it doesn't make sense to use this before a connection has been setup, but there is nothing that prevents apps in doing so, but they need to cope with the resulting error. Section 5.3.1., paragraph 14: > o TCP_MULTIPATH_CONNID: This value is read-only and SHOULD only be > used after connection setup. Same comment as for TCP_MULTIPATH_SUBFLOWS. Section 5.3.2., paragraph 1: > An application can explicitly indicate multipath capability by > setting TCP_MULTIPATH_ENABLE to a value larger than 0. In this case, TCP_MULTIPATH_ENABLE is a boolean (at least in your above table) which can either take true or false, which depends on the programming language used, but 'by larger than 0 looks' odd, as 0 can be also true, if negative logic is used Section 5.3.2., paragraph 4: > An application can disable MPTCP setting TCP_MULTIPATH_ENABLE to a > value of 0. In that case, MPTCP MUST NOT be used on that connection. Again a zero, but it should read false. Section 5.3.2., paragraph 5: > After connection establishment, an application can get the value of > TCP_MULTIPATH_ENABLE. A value of 0 then means lack of MPTCP support. > Any value equal to or larger than 1 means that MPTCP is supported. Again integer vs. boolean values. Section 5.3.5., paragraph 2: > This SHOULD be a 32-bit number, and SHOULD be the locally unique (e. > g., the MPTCP token). Is there really the need to nail down what type the connection ID is? And can we mandate this anyhow, as it is implementation specific to a node? Stating that is should locally unique seems to me enough. Section 6.1., paragraph 2: > API developers MAY wish to integrate SCTP and MPTCP calls to provide > a consistent interface to the application. Yet, it must be This 'MAY' is misplaced, as it is more a hint to implementers that they might consider an integrated API. This is sort of also enfored by the last sentence which says that this integration is anyhow out of scope. Section 11.2., paragraph 1: > [8] Sarolahti, P., "Multi-address Interface in the Socket API", > March 2010. Any information what the type of document this is? Draft, paper, etc?
Pete Resnick Former IESG member
No Objection
No Objection
(2012-11-14 for -06)
Unknown
[Note: These are things I've found in my review with a couple of comments from friends in Apps. I've asked -- no, begged -- the apps-discuss list for some additional opinions as we all seem to have missed this during Last Call. Mea culpa; bad AD. I will update with additional comments should they come in. At this point, I see no showstoppers, so I'm leaving this as No Objection.] 4.2.2 This section gives me the most pause. I am worried (though not enough to hold up the document over) about how the legacy getsockname and getpeername APIs will perform. In particular: This problem is addressed as follows: If used by a legacy application, the MPTCP stack MUST always return the addresses of the first subflow of an MPTCP connection, in all circumstances, even if that particular subflow is no longer in use. Is it possible that an IP Address/Port pair can be reused while a connection is still in progress? So, I start on 1.2.3.4:23456. MPTCP makes some subflows, and then 1.2.3.4:23456 goes away. Is it possible for another process on the machine to pick up 1.2.3.4:23456 at this point? On a different note: As this address may not be valid any more if the first subflow is closed, the MPTCP stack MAY close the whole MPTCP connection if the first subflow is closed (i.e. fate sharing between the initial subflow and the MPTCP connection as a whole). I don't understand why this is in there. Of course, any implementation can close a connection for any reason it chooses, but that MAY makes it sound like fate sharing the initial subflow is a good idea. AFAICT, it's a terrible idea. Why is this paragraph in there? If fate-sharing the initial subflow remains, I assume this will be configurable in the Advanced API, yes? It is not mentioned in Appendix A. 5.3.1: Why is the connection identifier only 32-bit?
Ralph Droms Former IESG member
No Objection
No Objection
(2012-11-15 for -06)
Unknown
1. Minor clarifications in section 5.3.1: TCP_MULTIPATH_ADD: "add a new local address to an existing MPTCP connection," is it allowed to add multiple addresses to an existing connection? Similarly: "Remove a local address from an MPTCP connection," is it allowed to remove multiple addresses from an MPCTCP connection? In both cases, Table 1 indicates "list of addresses" 2. Minor clarification in section 5.3.2: Table 1 defines TCP_MULTIPATH_ENABLE as boolean, while section 5.3.2 has text: "setting TCP_MULTIPATH_ENABLE to a value larger than 0." For consistency, is TCP_MULTIPATH_ENABLE a boolean or integer type? (I see that this comment is the same as a Comment issue raised by Martin Stiemerling.)
Robert Sparks Former IESG member
No Objection
No Objection
(2012-11-14 for -06)
Unknown
Apologies if I missed it, but is there a way using this Basic API for an application to learn that the mptcp stack it is using has accepted a new substream without polling? If not, should there be? Or was this explicitly deferred to the advanced API?
Ron Bonica Former IESG member
No Objection
No Objection
(for -06)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -06)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-01-22)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-01-19)
Unknown
Thanks for adding the text about TLS. (This comment is the same as before, I can't recall if we/you decided it was worth thinking about or not;-) - Would it be useful to add a security consideration to the effect that applications may need to revisit some assumptions about the sockets API that could impact on security? Not sure what text precisely but I'd expect new buffer problems might be likely here in practice if the size of the return from getpeername() etc changes and not all calling code is aware that MPTCP is in use.
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-11-15 for -06)
Unknown
I am not an expert on mptcp, but will note that from a routing point of view using a different IP address is only one way of hinting to us that you want a packet to go on a different path to the destination. If the bottle neck is not at the first hop and you are singly attached, routers can use other fields to make ECMP choices if that is of any help to you.