Re: [tcpm] RFC 1323: Timestamps option

[Fernando Gont <[e-mail]>]

Hi David,

I'm inclined for option #3, too.

Some comments inline....


>Option #2
>---------
[....]
>The question then is, how do you negotiate Timestamps without turning
>them on?  My suggestion would be to send a Timestamps option with the
>special format TSval=0,TSecr=0.  If you receive this in a SYN, then
>the request is to negotiate knowledge of the Timestamps option.  The
>returning SYN,ACK would also need to contain TSval=0,TSecr=0 to
>complete the negotiation.  If you are connecting to a site that
>doesn't support this feature but does support Timestamps, it would
>respond with TSval=xxx,TSecr=0.  At that point, Timestamps are now
>enabled.  The downside of this is that now the originator has started
>their Timestamps values at 0, and must continue from there with their
>timestamps; they can't just suddenly jump to some arbitrary value
>because that could break PAWs.

IIRC, there are some implementations that randomize the TCP sequence 
number, but use monotonically increasing timestamp generator.
Those implementations would cause, the BSD hack of allowing the 
establishment of a new connection if the ISN of the new incarnation 
of the conenction is larger than the last seq number seen on the old 
connection to fail fail.
IIRC, Linux also takes into account the Timestamp. Thus, if you 
randomize the ISN, but use a monotonically increasing timestamp 
generator, the hack would still succeed.

However, option #2 above would break this.


[....]
>So why should we change things?  My recollection was that the primary
>motivation was to conserve option space, to avoid having to put in
>the extra 12 bytes of TCP options on every packet until we get to the
>point where the sequence space might wrap, and then turn them on so
>that we can get PAWS to protect the rest of the connection.

I assume this means that one would turn timestamps on when starting a 
bulk transfer on the connection (?).

If so I'm not sure the space we'd be saving would be worth the 
additional complexity: For most application protocols usually 
employed for bulk transfers, the bulk transfer is preceded by only a 
few packets (to establish the TCP connection and send the application 
request). So option space would be saved in only a few segments.

Am I missing something?

Also, in order to enable timestamps midstream, I guess applications 
should perform a call to setsockopt() or the like? If so, this 
require specification of the corresponding socket option, would 
require applications to be modified, and we would also requier us to 
agree on "what the option should default to", etc.

So, unless some strong reason is raised for going with option #1 or 
option #2, I would stick with option #3.

Thanks,

-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm