Subject: [multipathtcp] Fwd: Pete Resnick's No Objection on draft-ietf-mptcp-api-06: (with COMMENT)

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Nov 2012 12:30:54 -0500

-------- Original Message --------
Subject: Pete Resnick's No Objection on draft-ietf-mptcp-api-06: (with
COMMENT)
Date: Wed, 14 Nov 2012 20:02:34 -0800
From: Pete Resnick <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Pete Resnick has entered the following ballot position for
draft-ietf-mptcp-api-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[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?