Subject: [multipathtcp] RFC6824bis - New Handshake - Implementation feedback

From: Christoph Paasch <[email-masked]>
Date: Mon, 10 Apr 2017 08:17:59 +0200

Hello,

as mentioned during IETF'97 meeting, I implemented the new
MP_CAPABLE-handshake from RFC6824bis in the Linux Kernel.

Overall, it is not that complex to implement the new MP_CAPABLE-option. I am
currently still fighting with a bug, but once this is fixed I will work on
open-sourcing my code.

Nevertheless, I have some feedback that might be good to add
into RFC6824bis and also some notes of the style "watch out, this is tricky
in the implementation!" :

page 16:
* "If, however, A..." - it might be good to show here again the new
  MP_CAPABLE-option (or refer to Figure 4 two pages higher). I was looking
  for the figure but didn't really found it right away.

* "If B has data to send first, then the reliable delivery of the ACK
   can be inferred by the receipt of this data with an appropriate MPTCP
   Data Sequence Signal (DSS) option (Section 3.3)."

   Actually, it is the reception of a DATA_ACK that tells A that B has
   received the MP_CAPABLE. Not (as the above sentence states), the
   reception of a DSS-option.

* It might be good to go through some scenarios with the new
  MP_CAPABLE-option. For example:
  A sends MP_CAPABLE in the third ACK (B receives this thid ACK) and then
  (a bit later) sends data + the new MP_CAPABLE-option (this latter packet gets
  lost). Then, B sends data to A with a DATA_ACK.

  A receives the data sent by B with the DATA_ACK. Now, A's
  retransmission-timer expires and it tries to resend the data. The
  question now is: Should it use a regular DSS-option in the retransmission,
  or should it use the new MP_CAPABLE-option.

  It ultimately does not matter (the server should support receiving both),
  but it's an interesting sceanrio that might be worth describing IMO.

* We should describe, how this works with TSO. In particular, when using
  TSO, the new MP_CAPABLE-option will be copied to all segments (by the
  TSO-NIC). Now, when we have to retransmit one of these segments due to
  packet-loss, the sender might use a DSS-option this time or the new
  MP_CAPABLE-option (depending on whether or not he received a DATA_ACK).

  Basically, these last two points mean that the new MP_CAPABLE-option and
  DSS-option are "interchangeable". Meaning, if at one point I start sending
  data (sequence-number 1 to 100) and thus use the new MP_CAPABLE-option,
  later on I might decide to retransmit any byte within this sequence-range
  (1 to 100) with a regular DSS-option (if the server sent me a DATA_ACK
  back). Doing it that way, makes things on the sender-side a bit easier
  from an implementation-point-of-view.

* When using TFO, it might be worth to specify that the server cannot send a
  DATA_ACK as long as he hasn't received the MP_CAPABLE with the key by the
  client.

* What if the client wants to send an ADD_ADDR before sending the new
  MP_CAPABLE? It should be fine, but again the server should be graceful to
  this.

* The server still has to support receiving out-of-order data (aka, data
  with a DSS-option). So, he will have to queue this and wait for the new
  MP_CAPABLE-option. This is nothing special from an implementation
  point-of-view, but might be worth mentioning in the RFC.

Regards,
Christoph