On Tue, 20 Jan 2004, Richard Wendland wrote: > This does suggest Ken is seeing TSecr messed up in some other way than > simple zeroing.
Or working from an old codebase... we'll have to wait for him to respond to find out. KEN! KEN! WHERE ARE YOOOOOO? > I'd expect this to be a pretty rare event, and perhaps my suggestion > that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a > good enough solution on its own for a rare event. It should certainly > avoid the insane -450000000 tp->t_rxtcur Ken has seen. It's simple to > implement, does what was probably originally intended, and also protects > from bizarre problems with non-timestamp option SRTT calculation. > > Full validation of TSecr would be nice, but perhaps excessive for > something that should not happen. A 64 second RTO may discourage such > strangeness :) > > Richard I think that just ensuring proper capping of the timeout is good enough, the other timestamp issue I was referring to is how it (incorrectly) scales with hz. I think I'll take a look at both of these problems once I catch up on other patches I have in the pipeline. Mike "Silby" Silbersack _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
