Re: [multipathtcp] Timestamp option for Multipath TCP

[Christoph Paasch <[e-mail]>]

Hello Olivier,


On 23/03/17 - 15:33:57, Olivier Bonaventure wrote:
> 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

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