Skip to main content

TCP Extensions for Multipath Operation with Multiple Addresses
RFC 6824


(Wesley Eddy)

No Objection

(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)

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

Martin Stiemerling Former IESG member
Yes (2012-09-12 for -09)
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/
Wesley Eddy Former IESG member
Yes (for -09)

Adrian Farrel Former IESG member
No Objection
No Objection (2012-08-29 for -09)
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"?
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-10-04 for -10)
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.
Benoît Claise Former IESG member
No Objection
No Objection (for -09)

Brian Haberman Former IESG member
No Objection
No Objection (for -09)

Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09)

Pete Resnick Former IESG member
(was No Record, Discuss) No Objection
No Objection (2012-09-12 for -09)
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.
Ralph Droms Former IESG member
No Objection
No Objection (for -09)

Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2012-10-08 for -10)
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?
Ron Bonica Former IESG member
No Objection
No Objection (for -09)

Russ Housley Former IESG member
No Objection
No Objection (2012-08-29 for -09)
  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.
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-10-22 for -11)
I've cleared.  Thanks for working with me on this draft.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-10-19 for -11)
- 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/

Stewart Bryant Former IESG member
No Objection
No Objection (for -09)