Subject: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis-05

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 17 Jan 2016 19:54:26 -0800

Hi,
I've read draft-ietf-mptcp-rfc6824bis-05.
I think it nicely integrates previous discussions and it makes lots of
senses, although I might want to clarify several points.
I have listed my comments below.

1: We now have several types of MP_CAPABLE.
   1) contains only first 4bytes
   2) contains sender's key
   3) contains sender and receiver's key
   4) contains sender and receiver's key and data length (+checksum)

   It is a bit unclear to me that which types of MP_CABLE used in which
packet. For example, 1) should be used for SYN, but it might be possible to
use 3) for SYN as it is not prohibited in the draft. If an endpoint
receives 2) in SYN, what it should respond?
   Or, what will happen if the 3rd ACK with data uses 3) instead of 4)?

  Also, I might want to clarify the only way to identify these types of
MP_CAPABLE is to check the option length in the draft.

2: It might not be very clear when initiator can confirm whether the key's
arrived at responder or not when it sends data at first.

   For example, after sending MP_CAPABLE with data, what if it receives
normal TCP ACK?
   Should it fallback to normal TCP or continue MPTCP as it might receive
DATA_ACK eventually?

3: The syn coolie draft proposed a recovery mechanism for the case where
the first data packet is lost in stateless server.
    We don't consider this case in this draft?

4: What if there is not enough option space to put MP_CAPABLE in the first
data?
    Do we fallback or continue MPTCP as the 3rd ACK may arrive?

5: I personally prefer to explain explicitly that we don't have to set
MP_CAPABLE in the first data when it already received DSS from its peer.

6: "An implementation MUST be able to receive and process both 64-bit or
32-bit sequence number value..."
    -> Should it be "64-bit and 32-bit"?

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 18 Jan 2016 20:59:19 -0800

Hello Yoshifumi,

> receives 2) in SYN, what it should respond?

I think, we should prohibit this in the protocol a host should fallback to
regular TCP when the peer uses the incorrect MP_CAPABLE message in a
segment.

>    Should it fallback to normal TCP or continue MPTCP as it might receive

If at the beginning of a session a host receives a TCP ACK that acknowledges
data but does not include a DATA_ACK, the host will do a seamless fallback
to regular TCP. It does so because from the host's point-of-view there is a
middlebox that is removing MPTCP-options from non-SYN segments.

>     We don't consider this case in this draft?

In SYN-cookie draft we considered this as a "bonus" for MPTCP as it allows
to recover from packet-loss where TCP will fail when facing stateless
webservers.
I think we could include it in RFC6824bis, although it is more of an
implementation choice to implement such an optimisation.

>     Do we fallback or continue MPTCP as the 3rd ACK may arrive?

Yes, continuing MPTCP might be a good approach here.

> MP_CAPABLE in the first data when it already received DSS from its peer.

Yes, I think we can do this.

Thanks for your feedback,
Christoph

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Alan Ford <[email-masked]>
Date: Tue, 19 Jan 2016 15:45:10 +0000

Hi,

Thanks for  your feedback!

> regular TCP when the peer uses the incorrect MP_CAPABLE message in a

It says in the draft:

   o  SYN (A->B): only the first four octets (Length = 4).

   o  SYN/ACK (B->A): B's Key for this connection (Length = 12).

   o  ACK (no data) (A->B): A's Key followed by B's Key (Length = 20).

   o  ACK (with first data) (A->B): A's Key followed by B's Key followed
      by Data-Level Length, and optional Checksum (Length = 22 or 24).

   The contents of the option is determined by the SYN and ACK flags of
   the packet, along with the option's length field.  For the diagram
   shown in Figure 4, "sender" and "receiver" refer to the sender or
   receiver of the TCP packet (which can be either host).

Which I thought was fairly clear on which options can be used on which
packets, but I'll look at clarifying the text to put some MUSTs in there.

> Yes, I think we can do this.

The relevant text is:

   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).  If, however, A
   wishes to send data first, it would not know whether the ACK has
   successfully been received, and thus whether the MPTCP is
   successfully established.  Therefore, on the first data A has to send
   (if it has not received any data from B), it MUST also include a
   MP_CAPABLE option, with additional data parameters.  This packet may
   be the third ACK if data is ready to be sent by the application, or
   may be a later packet if the application only later has data to send.

But if this is not explicit enough, I will look to make it even clearer.

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 21 Jan 2016 00:55:42 -0800

Hi Christoph,

> middlebox that is removing MPTCP-options from non-SYN segments.

I basically agree. But, I think it means if responder doesn't (or cannot)
set DATA_ACK in the first ack for data packets, it will cause fallback. In
my understanding, when to set DATA_ACK is a bit ambiguous, but I am
thinking that we might need some rules here.

> implementation choice to implement such an optimisation.

I got it. I don't think this is an important item for the core spec.
I just would like to clarify the intention behind it.

> Yes, continuing MPTCP might be a good approach here.

OK. I might prefer to clarify it in the draft.

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 21 Jan 2016 09:24:32 -0800

> thinking that we might need some rules here.

I agree it is a bit ambiguous.

Currently, this fallback at the beginning of a subflow is documented only in
Section 3.8. It might be good to explain it in Section 3.3.1 and 3.3.2, to make clear
that at the beginning of a subflow segments must contain a DSS and DATA_ACK.

Cheers,
Christoph