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

Hi Fernando,

first of all, I didn't read your draft, so please apologizes my
maybe stupid remark.

I guess your algo. is not compatible with the timestamp generation
in RFC 4987 (3.6.  SYN Cookies). Right?

Should we mention that?

Alex

Am 26.03.2010 um 11:53 schrieb Fernando Gont:

> 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: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm