Subject: [Tsvwg] RFC1323bis comments

From: Richard Wendland <[email-masked]>
Date: Fri, 7 Nov 2003 16:37:04 +0000 (GMT)

I have a comment on draft-jacobson-tsvwg-1323bis-00.txt.

I think the Windows TCP behaviour of sending a zero-valued TSecr on
SYN-ACK rather than using the TSval value sent on the SYN needs to be
addressed in RFC1323bis.  The new APPENDIX E Pseudo-code Summary does
not allow for this behaviour.

It looks to me like at least some implementations do not allow for this
behaviour, probably leading to SRTT and RTTVAR being initialised to very
large values at the SYN-ACK.  Looking at the FreeBSD source and TCP/IP
Illustrated Vol 2 I cannot find any code that disregards zero-valued
TSecr echoes.

It seems to me that the RFC1323 (and RFC1323bis) specification could
be read both to allow and dis-allow this behaviour.  Thus I think this
aspect of the specification should be made clearer.

The pertinent section of RFC1323bis is in 3.2:

    The Timestamp Echo Reply field (TSecr) is only valid if the ACK
    bit is set in the TCP header; if it is valid, it echos a
    timestamp value that was sent by the remote TCP in the TSval
    field of a Timestamps option.  When TSecr is not valid, its
    value must be zero.  The TSecr value will generally be from the
    most recent Timestamp option that was received; however, there
    are exceptions that are explained below.

a) If one takes the sentence "When TSecr is not valid, its value must
be zero." in isolation, it could be taken to mean that whenever an
implementation does not have a valid TSecr to hand (for whatever reason),
it is OK to send a zero TSecr.  This justifies the Windows implementation.

b) If one takes the paragraph as a whole, one can argue that the word
"valid" is specified for this paragraph to have a particular meaning:
"valid" = ACK bit set in header.  Thus all the sentence in a) really
means in this context "The TSecr in a TCP header without the ACK bit set
must have a value of zero".  So "if it is valid [ACK bit set], it echos
a timestamp value that was sent by the remote TCP in the TSval" applies
and Windows TCP is wrong not to echo the TSval it was sent on the SYN.

Interpretation b) can take support from "These TSval values are echoed
in TSecr values in the reverse direction." in 3.3, and the TS.Recent
discussion.

Whatever view is taken on the correct interpretation of RFC1323, at
this stage I do not think a new RFC should disregard at least 3 years
widespread practice by Windows TCP.  Windows probably does this because
it does not set up a full connection control block until the connection
is fully open, and so does not remember the SYN TSval in a way that can
be echoed in the SYN-ACK.  This is not entirely unreasonable behaviour.

If my argument that this area of the specification needs clarifying is
accepted, and the specification will permit the Windows TCP practice,
it has to be decided if it will allow a zero TSecr only on the SYN-ACK,
or on any segment where an implementation wishes to do this.

I do not have a view on this.  However it is worth noting that allowing a
zero TSecr anywhere an implementation chooses is pertinent to the issue
Reiner Ludwig raised ([Tsvwg] on 14 Aug 2003):

    Another open issue with RFC1323, I think, is the question of
    whether *every* segment MUST carry a TS option once that was
    negotiated in the SYN/SYN-ACK handshake.

since it impacts algorithms and testing in a similar way.

	Richard
-- 
Richard Wendland				[email-masked]

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg