Subject: [multipathtcp] Timestamp option for Multipath TCP

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 23 Mar 2017 15:33:57 +0100

Hello,

The standard timestamp option for TCP is defined in RFC7323. It is 
widely implemented and used. It has two main objectives :

- timing measurements
- protection agains wrapped sequence numbers

Given the importance of the second utilisation, RFC7323 has mandated the 
presence of a timestamp option in each segment once negotiated in the 
three-way handshake. For Multipath TCP, the DSN option already protects 
us from PAWS problems and it should not be mandatory to include 
timestamps in each packet sent over a Multipath TCP connection. Given 
the length of the timestamp and DSN options these two options already 
consume a large number of bytes and could limit the number of SACK 
blocks that can be placed inside acknowledgements.

I will only be able to attend the Chicago meeting remotely, but I would 
like to start a discussion on the utilisation of timestamps by Multipath 
TCP on the list. I see two possibilities, but there are possibly more :

1. Ask for a revision of RFC7323 that allows timestamp options to be 
optional in packets of Multipath TCP connections

2. Define a new Multipath TCP option to carry timestamps. The 
utilisation of this option would be included in Multipath TCP and thus 
no option besides MP_CAPABLE would need to be included in the SYN.

Do you have any opinion on these two possibilities ?

Thanks

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 24 Mar 2017 11:47:53 -0700

Hi Olivier,

I personally prefer 1, but I might prefer some generic framework as I am
guessing there will be other cases that we don't want timestamps for PAWS.

BTW, are we sure that DSN option can provide protections against PAWS? We
cannot guarantee DSN option appears on all segments..
--
Yoshi

On Thu, Mar 23, 2017 at 7:33 AM, Olivier Bonaventure <
[email-masked]> wrote:

> Hello,
>
>
> The standard timestamp option for TCP is defined in RFC7323. It is widely
> implemented and used. It has two main objectives :
>
> - timing measurements
> three-way handshake. For Multipath TCP, the DSN option already protects us
> from PAWS problems and it should not be mandatory to include timestamps in
> each packet sent over a Multipath TCP connection. Given the length of the
> timestamp and DSN options these two options already consume a large number
> of bytes and could limit the number of SACK blocks that can be placed
> inside acknowledgements.
>
> 2. Define a new Multipath TCP option to carry timestamps. The utilisation
> of this option would be included in Multipath TCP and thus no option
> besides MP_CAPABLE would need to be included in the SYN.
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Alan Ford <[email-masked]>
Date: Wed, 29 Mar 2017 03:16:35 +0000

Hi Olivier,

Are these really mutually exclusive options? Relaxing the 7323 requirement
seems the right thing to do anyway; adding an option is a nice extra for
people that need TS for measurements other than PAWS.

But we could in theory put timestamp negotiation in MP_CAPABLE so we define
what it means for one end to require timestamps, and then use regular TCP
timestamps - no need for it to be a MPTCP option.

Or we could say that MP_CAPABLE + Timestamp = TS required. Then that makes
it negotiable; 6824bis would be changing the semantics of the presence of
today's TS option.

Regards,
Alan

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 29 Mar 2017 11:12:10 +0000

I guess this is well known: Making 7323 more flexible has been discussed multiple times in TCPM because of the TS option space consumption.

BTW, there will be a discussion in TCPM today related to PAWS.

Michael

From: multipathtcp [mailto:[email-masked]] On Behalf Of Alan Ford
Sent: Mittwoch, 29. März 2017 05:17
To: [email-masked]; multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] Timestamp option for Multipath TCP

Hi Olivier,

Are these really mutually exclusive options? Relaxing the 7323 requirement seems the right thing to do anyway; adding an option is a nice extra for people that need TS for measurements other than PAWS.

But we could in theory put timestamp negotiation in MP_CAPABLE so we define what it means for one end to require timestamps, and then use regular TCP timestamps - no need for it to be a MPTCP option.

Or we could say that MP_CAPABLE + Timestamp = TS required. Then that makes it negotiable; 6824bis would be changing the semantics of the presence of today's TS option.

Regards,
Alan

On Thu, 23 Mar 2017 at 09:34, Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

- timing measurements

Thanks

Olivier

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

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 29 Mar 2017 15:05:58 +0200

Yoshifumi,
> BTW, are we sure that DSN option can provide protections against PAWS?
> We cannot guarantee DSN option appears on all segments..

If there is a valid DSS option, either DSN mapping or DSN ack, then the 
segment cannot be a replay of an old segment. If we use long mappings, 
then there are two different situations :

- long mapping but TSO copies the DSS option inside each packet
- long mapping and no TSO

In the second case, we need to ensure that each packet contains some 
information that allows to support PAWS. DSS and timestamp would work

Olivier

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 29 Mar 2017 10:14:56 -0500

Hello Olivier,

On 23/03/17 - 15:33:57, Olivier Bonaventure wrote:
> of bytes and could limit the number of SACK blocks that can be placed inside
> acknowledgements.
> 
> I will only be able to attend the Chicago meeting remotely, but I would like
> to start a discussion on the utilisation of timestamps by Multipath TCP on
> the list. I see two possibilities, but there are possibly more :
> 

if we do this, how would MPTCP decide whether or not to put a TS-option in
the segment? And will this decision-process still allow to be fully protected
against PAWS (when TSO-is used and the DSS-option does not end up on every
segment)?

I can't think of a way to achieve this, because whenever we would decide to not put
a TS-option, later on after 2^32-bytes this original data might be subject
to being the "victim" of PAWS, even if we then switch into a mode where we
use TS.

> 2. Define a new Multipath TCP option to carry timestamps. The utilisation of
> this option would be included in Multipath TCP and thus no option besides
> MP_CAPABLE would need to be included in the SYN.

I like this approach, because it seems to me to consume less option-space.

How would this timestamp look like in the DSS-option? Would it still be 32-bits?
I think we can make it less than 32-bits, right?

Christoph