Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt)

[Brian Trammell <[e-mail]>]

On 26 May 2014, at 11:37, Eggert, Lars <[e-mail]> wrote:

> Hi,
> 
> On 2014-5-23, at 18:55, Joe Touch <[e-mail]> wrote:
>> Current total for SYN options in widespread concurrent use (as already described in sec 6.4):
>> 
>> 	2	SACK permitted
>> 	10	timestamp
>> 	3	window scale
>> 	4	MSS
>> 	------------------
>> 	11 bytes
> 
> I think it was Mark Allman who questioned a while ago whether the benefits of the timestamp option are worth spending 10 bytes in every packet. (But I can't find the email now.)
> 
>> 	11	widespread basic options
>> 	16	TCP-AO
>> 	20	MPTCP
>> 	--------------------
>> 	47
> 
> If we could shave those off, we'd be at 37 even with AO. It wouldn't make the option space any bigger for the future, but it would get us out of the current situation, and would make a combination of some crypto and MPTCP be deployable.

SACK and WScale are in use by the majority of sources, but (depending on where you're looking from), only about a third of senders ever use the timestamp options (lots of sources; the most recent is CCR April '14, Honda et al "Rekindling Network Protocol Innovation with User-Level Stacks", introduction), largely an effect of OS-level defaults. So an either-or approach for TS or TCP-AO would probably work.

(Doing this would make in-path passive measurement of RTT on mostly-unidirectional flows basically impossible, but in a post-BCP188 world we should probably be working on instrumenting endpoints for debugging and monitoring, anyway...)

Cheers,

Brian