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

[John Heffner <[e-mail]>]

On Tue, Mar 23, 2010 at 12:01 PM, Joe Touch <[e-mail]> wrote:
> By randomizing the initial timestamp, we now need to keep per-connection
> timestamp offsets, which increases both state and processing. It also
> means that incoming connections to socket pairs in TIME_WAIT would
> silently fail roughly half the time, requiring undue timeouts.

If I understand correctly, that's not the case.  The function from Section 2:
  timestamp = T() + F(localhost, localport, remotehost, remoteport, secret_key)
has no per-connection state*, and should not result in any issues with
TIME_WAIT connections.  Though it does not say so explicitly, my
understanding is that secret_key is intended to be a system-wide value
initialized on boot with random data..

It seems like a very reasonable approach to me -- low-cost and easy to
implement with no major downsides.

  -John


* I guess there would be some soft state, because you'll want to cache
the value of F().