Re: TCP timestamp starting value

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Jul 21, 2016 at 07:52:03PM +0200, Edgar Fuß wrote:
> JS> While I can understand the desire the somewhat correlate the timestamps
> JS> of different connections on a short term time frame, any network stack 
> JS> that depends on them to remain stable over a long time is IMO plainly 
> JS> broken.
> Yes. So what? Do you seriously expect IBM to fix the AIX network stack 
> because some perfectly standard conformant niche OS doesn't meet their 
> false expectations?

Actually yes, I do. I dare to say that there are more systems using the
NetBSD network stack than AIX installations. As I said, the assumption
is completely invalid. Filling a bug report for broken network stacks
should always be the first part. You would be surprised by how often
such choices tend to be made again by other systems. Let me illustrate
this by just pointing to the wide spread use of NAT today. For a fixed
destination, you can make *no* reasonable assumptions about how many
systems are hiding behind the same source IP. As such, you can easily
see a 100 different systems all with different start values for the
timestamp access your system in a short time frame. That's no different
to the behavior NetBSD exposes deterministically. That alone should be a
good argument to get IBM's engineering department to actually care about
it.

As I said, I don't really have a problem with using
HASH(src,dst) + uptime as initial timestamp value. The performance
impact should be small enough. I do believe that the discussed concerns
regarding visiblity of reboots can be easily mitigated by randomized
reseeding, if the concern is reasonable. I do not see an advantage
towards using the real time here, even the lack of monotonic behavior.

Joerg