Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

[Fernando Gont <[e-mail]>]

Joe Touch wrote:

> As per subsequent exchanges, the doc breaks into three separate issues:
> 
> 	1) random starting timestamp
> 	2) monotonically increasing timestamp
> 		(required only per socket-pair)
> 	3) TIME_WAIT truncation
> 
> Note that #1 interferes with #2, because selecting a timestamp in the
> high end of the number space could present problems in maintaining #2
> over the long term for very busy hosts. 

I don't follow this. The timestamp clock can be initilized to a random
value. Once initilized, it's simply incremented as a counter. How does
this interfere with #2?


> However, let's put that aside
> for now, since we can easily say "pick something in the low 1/2 of the
> range)" to address that issue.

Timestamps are compared in the same way as sequence numbers, IIRC. So
you don't need to implement this "low 1/2" magic....



> The issues with #1 being a protection have already been discussed.
> Depending on how #1 is specified, there are varying implications.
> 
> The current spec for #1 requires:
> 
> 	a- a hash per socket pair (e.g., on receipt of a SYN)
> 
> 	b- larger retained state during TIME_WAIT

I don't follow "b". What's the additional state here? You just need to
keep TS.Recent, as RFC1323 already requires -- there's no additional state.


> 	c- retained state beyond TIME_WAIT (to enforce #2,
> 	since the timestamp start is per-socketpair)

I don't follow this one, either.

With the current I-D, timestamps are generated in the same way ISNs are
generated with RFC1948. So there's no requirement of "retained state
beyond TIME-WAIT state". Actually, this is the beuty of the RFC1948 scheme.



> (a) is expensive - 20 instructions per 32-bit word *in the critical
> path*, or 520 instructions. Compare that to roughly 100-300 instructions
> to process a TCP packet. You're more than doubling the cost for TCP
> processing in just this one step; other steps (randomizing ISN, etc.)
> make things worse. The only way around this is for everyone - client and
> server - to keep per-socketpair timestamps around for a long time.

Can you elaborate this statement a bit more?



> (b) is no big deal
> 
> (c), however, is huge. Busy servers already toss out TIME_WAITs early to
> save space. There's very little reason to believe they'd keep
> per-socketpair timestamps around to ensure monotonicity.

There's no need for that. Servers can still toss the TIME-WAIT state as
they currently do, with no harm.



> So let's expect that (c) won't happen. That means (a) requires
> computation, which is bad.
> 
> The only way to recover this, AFAICT, is to claim that the
> timestamp_start is selected by some arbitrary function, but reused
> across connections. It can't - and doesn't need to be - per-connection
> specific.

If the current proposed scheme (i.e., RFC1948-like) is used,
initialization doesn't matter: it's F() that provides the randomness.

If we recommend "a global timestamp shared by all connections", you just
initilize it to a random value at system boot time, just so that the
system uptime is not leaked. -- and that's it.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1