Re: [multipathtcp] Timestamp option for Multipath TCP

Hi Olivier,

Following up from IETF98 here, could you clarify what docs changes would be required for your proposals here to be applied, both in terms of 6824bis, and for any references (e.g. 7323)?

Regards,
Alan

> On 29 Mar 2017, at 16:14, Christoph Paasch <cpaasch@apple.com> wrote:
> 
> 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
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp