Kacheong,
Thanks for your reply. You're correct. I should have used RTO vs. RTT.
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.
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.
Regards,
Chuck
At 04:46 PM 11/10/97 -0800, you wrote:
>> The reference in another message today about a patch (SUN's CONSULT-TCPLFN)
>> for Solaris 2.5.1 and below, adds support for Long Fat Networks
>> (RFC1323-TCP Extensions for High Performance). It is included in 2.6 (so
>> I've been told).
>
>Yes, Solaris 2.6 has all the RFC 1323 extensions.
>
>> Finally, there is one other nit that might present an obstacle to high
>> performance. If the default values for Solaris' retransmit timers
>> (tcp_rexmit_interval_initial, tcp_rexmit_interval_min,
>> tcp_rexmit_interval_max) are set below the RTT, then Solaris will
>> retransmit unacknowledged packets in spite of the fact that the RTT has not
>> yet expired. For example, it the RTT is 750 ms, make sure that the
>> retransmit timers are set to 1000 ms or more to preclude unnecessary
>> retransmissions.
>
>Well, RTT (round trip time) won't expire (-: The problem you mentioned was
>that the calculated RTO (timeout) was lower than RTT. This causes packets to
>be retransmitted unnecessarily. I think this RTO problem was discussed in
the
>last IETF tcp-impl WG meeting. RFC 1323 timestamp option allows TCP to get
>very accurate samples of RTT from every packets. TCP's RTO is calculated
using
>the following formula:
>
> RTO = sa + 4 * sd
>
>sa is the smoothed average of RTT samples and sd is the smoothed mean
>deviation of RTT samples. With timestamp, sa converges quickly to the
>real RTT while sd becomes very small. As you mentioned in a previous mail,
>RTT of satellite links may sometimes jump to 800ms. This kind of sudden jump
>may not be captured by sd. This can cause some unnecessary retransmissions.
>
>In BSD's TCP implementation, RTO usually has a ~500ms "buffer zone." So
>the above problem is not seen often. Solaris has a fine grain RTO, so you
>may see this problem sometimes. In 2.6, the workaround is to set
>tcp_rexmit_interval_extra to 500 to get an extra 500ms buffer zone like BSD.
>
>The tuning you suggested above is for a different bug in earlier releases of
>Solaris. 2.6 should not have that problem.
>
> K. Poon.
> [email protected]
Staff Systems Engineer (610) 531-3771
Lockheed Martin Corporation (610) 962-3698 FAX
King Of Prussia, PA [email protected] 1
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:32 EST