Re: [tcpm] RFC 1323: Timestamps option

David Borman wrote:

> Option #3
> ---------
> Do nothing, and leave Timestamps alone as they are currently defined. 
> You negotiate them in the SYN, and then include them in every packet
> from then on.

As an implementor, I'd vote for Option #3.  If the current behavior
is not broken, don't fix it.  Modifying it after so many years of
deployment may cause many troubles.  IMHO, the benefit of modifying
the handling, which is saving 12 bytes, is minor when compared to
the effort of diagnosing why a connection is not working.  If we
want to fix the overhead and other issues, such as auto-tuning, I'd
rather to have a new option or other methods than modifying the
current handling.

I'd like to have several clarifications on timestamps handling.

1. I think it is not stated explicitly that once timestamps option
   is enabled, it should always be used for a connection.  I have
   encountered TCP stack which stops sending timestamps option in
   the middle of a connection.  Could this be made explicitly in
   the update?  I also suggest putting a note on how to handle such
   behavior.  For example, once one side stops sending the option,
   the peer will treat it as if the option is never negotiated and
   also stops using it.

2. As described in CERT VU#637934, there are some inconsistencies
   in RFC 1323 and the not "published" RFC 1323bis.  This creates
   some "variants" of algorithms.  Since this update will obsolete
   both documents, please check the CERT report on the issues and
   clarify it on the update.

3. It is stated that RST should not have a timestamps option.  I
   think this is really not needed.  And it only causes extra check
   in the code not to do that.  For example, an app does an abortive
   close, the code needs to remove the timetstamps option from the
   connection to send the RST.  I don't think it causes any harm if
   the RST has the option.

-- 

						K. Poon.
						kacheong.poon@sun.com

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm