Skip to main content

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.