> If I understand your response, I think you're suggesting that it is good
> practice to set the retransmit timers ~500 ms above expected or actual RTT.
It seems that no one has complained about this BSD behavior for unnecessary
retransmission, except that BSD sometimes takes too long to retransmit. BTW,
the minimum of BSD's RTO is 1 second.
> Now I have a question. The timestamp option is very significant for long
> delay pipes where the RTT is only measured once per window where a window
> may have in excess of 8 packets or more, resulting is a very coarse
> measurement of the actual RTT. Does 2.6 automatically invoke the timestamp
> option when the TCP send/recv windows exceed 65535 bytes? How does Solaris
> 2.6 handle this? Cray UNICOS enables this option whenever the window scale
> option is used.
There are 3 ndd parameters in 2.6 to control the RFC 1323 extensions.
tcp_wscale_always (default 0)
If set to 1, TCP will always send SYN segment with the window scale
option, even if the option value is 0. Note that if TCP receives a
SYN segment with the window scale option, even if the parameter is set
to 0, TCP will respond with a SYN segment with the window scale
option, and the option value is set according to the receive window
size.
tcp_tstamp_always (default 0)
If set to 1, TCP will always send SYN segment with the timestamp
option. Note that if TCP receives a SYN segment with the timetstamp
option, TCP will respond with a SYN segment with the timestamp option
even if the parameter is set to 0.
tcp_tstamp_if_wscale (default 0)
If set to 1, and window scale option is enabled for a connection, TCP
will also enable the timestamp option for that connection.
In addition, if an application setsockopt(SO_RCVBUF) to a value larger than
64K before connect(), TCP will enable the wscale option no matter what the
value of tcp_wscale_always is.
So to get Cray's behavior, you need to set tcp_tstamp_if_wscale to 1.
K. Poon.
[email protected]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:32 EST