TCP Extensions for Multipath Operation with Multiple Addresses

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

(Wesley Eddy) Yes

(Martin Stiemerling) Yes

Comment (2012-09-12 for -09)
No email
send info
As Pete noted:
The shepherd write-up is broken with respect to point (7). This should have been confirmed before submitting the draft to the IESG.

A comment where your response is requested:
Section 30, paragraph 6:
>    The value 0xf is reserved for Private Use.

  What is private use in your definition? In your testbed only or for
  your own protocol extension used on the public Internet? The first
  definition is Ok, with second some folks might step on other folks
  toes when running their code across the Internet at the same time.

Three comments for your considerations, but no need to respond to these:
Section 3.4.2., paragraph 3:

>    For security purposes, if a host receives a REMOVE_ADDR option, it
>    must ensure the affected path(s) are no longer in use before it
>    instigates closure.  The receipt of REMOVE_ADDR SHOULD first trigger
>    the sending of a TCP Keepalive [16] on the path, and if a response is
>    received the path SHOULD NOT be removed.  Typical TCP validity tests
>    on the subflow (e.g. ensuring sequence and ack numbers are correct)
>    MUST also be undertaken.

  Should such an event be logged? Looks like that something is going wrong.

Section 3.5., paragraph 9:

>    o  If host A does not receive a TCP RST in reply to its MP_FASTCLOSE
>       after one RTO (the RTO of the subflow where the MPTCP_RST has been
>       sent), it SHOULD retransmit the MP_FASTCLOSE.  The number of
>       retransmissions SHOULD be limited to avoid this connection from
>       being retained for a long time, but this limit is implementation-
>       specific.

  For the sake of the implementers: What is the guidance here on

Section 6., paragraph 15:

>    o  Traffic Normalizers [19] may not allow holes in sequence numbers,
>       and may cache packets and retransmit the same data.  MPTCP looks
>       like standard TCP on the wire, and will not retransmit different
>       data on the same subflow sequence number.  In the event of a
>       retransmission, he same data will be retransmitted on the original
>       TCP subflow even if it is additionally retransmitted at the

  s/he same data/the same data/

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2012-08-29 for -09)
No email
send info
I have several Comments that don't really merit a Discuss, but which you should really think about a little.


The description of Figure 13 could be clearer about the meaning of the 
value n. I.e., there are n Address IDs present.

You should probably say whether n=0 is allowed. 

Lastly, you should mark the unused bits on the figure as reserved.


In Figure 17, shouldn't the transition out of M_LAST-ACK (right-hand
side) be into M_TIME WAIT? Otherwise, the MPTCP PCB seems to not get


Are you really happy with "RFC Required" as the allocation policy for
the new MPTCP Option Subtypes registry? You understand that one person
could write an Independent Stream RFC and take all of the available 
code points in one go? Although you might hope that the IESG would spot
this and request the ISE to not publish the RFC, this seems like a risk.

Since the plan is to move to the Standards Track, why don't you change
this to "Standards Action"?

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-10-19 for -11)
No email
send info
- Something wrong with this just before the start of 3.2, might need
an RFC editor note:

   "the IDSN of a MUST be the least significant 64 bits of the SHA-1 hash"

- Change on page 38, new text says;

  "Further security considerations around the issue of	
   accidental or maliciously misdirecting ADD_ADDR messages are	
   discussed in Section 5."

I think that'd be better as:

   "Further security considerations around the issue of	
   accidentally mis-directed or maliciously directed ADD_ADDR 
   messages are	discussed in Section 5.

- This was a discuss point and I don't see a change for it, but
I'll let it go as a comment since its probably implied really.

Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

- And one old comment that also was once a discuss
and I guess you just don't wanna take on board;-)

What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important. 

Maybe just s/very/usually/


(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-08-29 for -09)
No email
send info
  This paragraph:
  > MPTCP's interpretation of, and effect on, regular single-path TCP
  > semantics are discussed in Section 4.
  seems to be out of place in the Terminology section.

Barry Leiba (was Discuss) No Objection

Comment (2012-10-04 for -10)
No email
send info
The authors have completely cleared up the description of the MP_CAPABLE flags, and the registry for them.  Thanks very much for working with me on this.

(Pete Resnick) (was No Record, Discuss) No Objection

Comment (2012-09-12 for -09)
No email
send info
This appears to me to be great work, and as an applications guy, I cannot wait for this to be deployed. The only thing that prevented me from balloting "Yes" instead of "No objection" is simply because much of the detailed technical work is beyond my knowledge base and I can't vouch for it personally. But what I do understand I'm very pleased by.

One addition that might serve folks well: You might add a section at the beginning or end of the document on open experimental issues that need to be addressed before going to standards track. In particular, 3.3.6, 3.3.7, and 3.8.2 point out such issues. I'm sure there are more. If you could summarize them in one section, it might be helpful.

(Robert Sparks) (was Discuss) No Objection

Comment (2012-10-08 for -10)
No email
send info
Would it be difficult to add a short summary to this document calling out what information the mptcp implementation is expecting to get from the API?

(Sean Turner) (was Discuss) No Objection

Comment (2012-10-22 for -11)
No email
send info
I've cleared.  Thanks for working with me on this draft.