Re: [multipathtcp] Timestamp option for Multipath TCP

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 <
Olivier.Bonaventure@uclouvain.be> 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
> - 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
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>