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

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> Hi, Joe,
> 
>> By randomizing the initial timestamp, we now need to keep per-connection
>> timestamp offsets, which increases both state and processing. 
> 
> Huh? I don't follow this. Could you clarify what's the "extra state" and
> "extra processing" you're referring to?

   timestamp = T() + F(localhost, localport, remotehost, remoteport,
   secret_key)

Either I need to keep the result of F(...), or I need to recompute for
each timestamp. The former costs processing, the latter costs state.

Either way, you're adding an index and an add to the timestamp
calculation. That's processing. We're talking about extra steps for
every packet.

>> It also
>> means that incoming connections to socket pairs in TIME_WAIT would
>> silently fail roughly half the time, requiring undue timeouts.
> 
> Joe, please read the I-D. It's *without* this RFC1948-like scheme that
> timeouts/delays could occur. -- this mod actually improves the handling
> of incoming connection requests (SYNs), allowing connections that would
> have otherwise failed.

The document never asserts that the "secret_key" would never change.

If it does change, you run the risk that F(...) will end up being
sufficiently lower that you fall through your checks and treat the SYN
as a silent discard, which causes delays.

Joe





> 
> (see also the reference to Mike Silbersack's presentation at BSDCan)
> 
> Thanks,