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

[Fernando Gont <[e-mail]>]

Hi, Mark,

> It seems to me we (Joe, you and I) have converged to viewing the 
> TIME_WAIT truncation business as worth a work item, but the need or 
> desire for unpredictable timestamps seems to not be worthwhile. 
> Truncation requires monotonically increasing timestamps across 
> connections to be somehow ensured.  Seemingly that is such a mundane
>  requirement that we don't have to wade into the particulars of it in
>  this document.  Is this summary reasonable?  And, if so, is that OK 
> with everyone else?

As a result of our discussion, I think a possible way forward would be
for the doc to just require monotonically-increasing timestamps across
connections, and TIME_WAIT truncation (with RFC2119-language).

However, I think that an appendix (with no normative language) that
describes a few possible algorithms to achieve monotonically-increasing
timestamps might still be helpful/useful.

One might include in that appendix the trivial "global timestamps clock"
(with randomized initial value at system boot time) and the RFC1948-like
scheme. My rationale is that if we're requiring monotonically-increasing
timestamps, it would be helpful to at least mention possible approaches
(without any requirements or specific choice).

Some stacks already randomize timestamps (trivially....with random()
)(e.g., OpenBSD). And my take is that unless we offer them an algorithm
that generates unpredictable timestamps, they might not want to use the
predictable "global timestamp clock" approach. -- and I think it would
be best if everybody jumped into the "monotonically-increasing
timestamps" wagon, no matter whether they are predictable or not.

This is just me thinking out loud. -- If there's contention on the
timestamps generation thing, I have no problem with splitting the I-D,
and striping off the "timestamps generation algorithms" from the current
I-D.

Thoughts?

Thanks!

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