Subject: [multipathtcp] Ack of MP_CAPABLE

From: Mark Handley <[email-masked]>
Date: Wed, 27 Jul 2011 17:40:47 -0400

Tim raised the issue of whether putting the active opener's key in the
third packet of the TCP handshake causes a problem if that ack is
lost.

Here's what the draft says:

   Furthermore, in order to ensure reliable delivery of the ACK
   containing the MP_CAPABLE option, a server MUST respond with an ACK
   segment on receipt of this, which may contain data, or will be a pure
   ACK if it does not have any data to send immediately.  If the
   initiator does not receive this ACK within the RTO, it MUST re-send
   the ACK containing MP_CAPABLE.  In effect, an MPTCP connection is in
   a "PRE_ESTABLISHED" state while awaiting this ACK, and only upon
   receipt of the ACK will it move to the ESTABLISHED state.

I think this addresses the issue,  but it adds an RTT of latency if
the client wishes to send before receiving the ACK, which to me is
unacceptable.  Perhaps we should say that if the client wishes to send
data before receiving the ACK, the first segment MUST contain both a
DSN and MP_CAPABLE.  Otherwise the client cannot distinguish whether
or not the MP_CAPABLE containing the key was received.

- Mark