Subject: [multipathtcp] RFC7323 and MPTCP

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 24 Sep 2014 20:56:52 +0200

Hello,

RFC7323, the revision for RFC1323, has been published recently. A key 
change compared to RFC1323 is the following paragraph :

    Once TSopt has been successfully negotiated, that is both <SYN> and
    <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
    segment for the duration of the connection, and SHOULD be sent in an
    <RST> segment (see Section 5.2 for details).  The TCP SHOULD remember
    this state by setting a flag, referred to as Snd.TS.OK, to one.  If a
    non-<RST> segment is received without a TSopt, a TCP SHOULD silently
    drop the segment.  A TCP MUST NOT abort a TCP connection because any
    segment lacks an expected TSopt.

The motivation for this paragraph is that the TCP timestamps are used 
for two different purposes :
  - measure round-trip-times
  - protect against wrapped sequence numbers

For regular TCP the protection against wrapped sequence numbers requires 
the presence of the timestamp option in all segments.

For MPTCP, there is no need to protect against wrapped sequence numbers 
since MPTCP already uses 64 bits sequence numbers. When MPTCP has been 
negotiated, the only (but sometimes useful) usage of the timestamp 
option is to measure round-trip-times. If an MPTCP stack needs to send a 
segment that includes a DSS option, a timestamp option and SACK blocks, 
I think that it should have the possibility of removing the timestamp 
option to have enough space for a larger SACK block. I don't think that 
there is already an implementation that already contains this optimisation.

I tried to fight against this MUST in the tcpm mailing list, but failed 
and the result of the consensus was the above paragraph.

We have two possibilities to keep flexibility in MPTCP :
- write a short RFC that clarifies the role of the timestamp option in MPTCP
- write a section in RFC6824bis that clarifies the role of the timestamp 
when MPTCP is used

I would opt for the second solution and request that RFC6824bis once 
published updates RFC7323. This could be done with a paragraph like :

    If MPTCP and TSopt have been successfully negotiated, that is both
    <SYN> and <SYN,ACK> contain TSopt and MP_CAPABLE, then the TSopt
    MAY be sent in every non-<RST> segment for the duration of the
    connection, and SHOULD be sent in an
    <RST> segment (see Section 5.2 for details). If the MPTCP connection
    falls back to regular TCP, e.g. due to  middlebox interference, then
    the rules defined in RFC7323 will apply again, i.e. the TSopt MUST
    be sent in every non-<RST> segment.

My concern is that if firewalls apply RFC7323 in a strict manner, they 
could cause operationnal problems by dropping MPTCP segments that do not 
contains the TSOpt.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Sep 2014 12:01:48 -0700

FWIW, I don't think it's a good idea for MPTCP to use TCP options in a
nonstandard manner. That would severely complicate option implementation.

IMO, either use the option as it's defined - which may be overkill for
MPTCP - or define a new MPTCP extension for its own optional use of
timestamps.

Joe

On 9/24/2014 11:56 AM, Olivier Bonaventure wrote:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 25 Sep 2014 00:50:59 -0700

Hi,
I second to Joe. I personally think we might have some situations where we
don't need PAWS even without MPTCP.
I prefer more generic approach for this. (I hope someone could check A-PAWS
proposal...)

Thanks,
--
Yoshi

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 25 Sep 2014 10:43:51 +0000

There are quite some doubts in TCPM whether the use of timestamps for RTT measurement (only) is really worth the effort (i.e., option space).

Wouldn't it be sufficient if an MPTCP-enabled connection responder just does not negotiate timestamps when MPTCP is advertised in the connection setup?

Michael