Re: How do I alter values for TCP timeouts (SRTT & RTO)

Thanks again for your reply. Well with your experience and you think they
cant be set I'll think I'll put this venture on hold.

Yes I've looked throught the registry settings but nothing looked remotely
like it is to alter the settings. Some registry settings dont exist and are
default values unless they are actually created (eg TcpInitialRtt).

Dave Patrick from the Registry forum sent me the following link which seems
to show all there is to alter in the MS realm. It is included for info of
anyone interested.

http://support.microsoft.com/?id=120642

Here's just hoping some boffin happens upon my post with the holy grail of
answers! cheers David

"Dan Seur" wrote:

> You're very welcome, Dave. I looked at 793 before responding earlier
> (1981? that's 10 years after my 1st involvement with
> RAND/ISI/DARPA/Arpanet) and came away with the sense that these min/max
> settings may or may not be subnet-settable - up to the coders, which
> would mean sometimes they're hardcoded. I think some flavors of *NIX
> have them settable externally. No idea about MS products. NT3.1 had a
> situation where it ate itself if the settings weren't just right in a
> high speed (I mean really high speed) net, according to one old post
> from Argonne or somewhere.
>
> I hope some other poster with the real scoop on what you can and can't
> do with these parameters will come in with good info instead of
> speculation like mine. Good luck.
>
> PS: have you gone down all the registry TCP Parameters lists item by
> item? Things sometimes have names that are....well....oddly chosen. :-)
>
> hotdogdave wrote:
>
> > Thanks for your reply Dan
> >
> > Well recompiling is a bit above my level if that is what is required and
> > drifts out of scope of our task to get 'out of the box' IP apps to work over
> > HF albeit with a few tweaks. I consider altering registry settings to fall
> > within the scope.
> >
> > I would be disappointed if these values cannot be set somewhere as settings
> > such as TcpInitialRtt , and TcpMaxDataRetransmissions can be.
> >
> > These values all refer to RFC 793 and all these values are talked about in
> > suggested ranges - leading me to assume that they can be altered. Possibly MS
> > has not implemented the RFC with non-alterable default values while say,
> > Linux has.
> >
> > Your right in saying there may be times when the radio cannot simply make a
> > link hence why some maximum timeout is required. What I'm finding is one node
> > will have a quick TCP response and dynamically alter its RTT to say 25 secs.
> > The next time this is not long enough and it will retransmit (half duplex)
> > over the incoming response. The system generally works 90% but occasionally
> > gets its 'knickers in a knot'. The data wont get through until a TCP protocol
> > attempts to retransmit (eg SMTP failed mail retry).
> >
> > There are 2 ways I can think of to overcome this, set LBOUND to a min, or
> > give less weight of SRTT to the last measured RTT. This algorithm is given
> > from one of the links below;
> >
> > Windows 2000 TCP Retransmission Behavior
> > TCP starts a retransmission timer when each TCP segment is sent and then
> > waits for an acknowledgment to come back before the retransmission timer
> > expires. This technique is the Positive Acknowledgment Retransmission (PAR)
> > scheme.
> >
> > In Windows 2000 every new TCP connection request uses an initial
> > retransmission timer value that is set to three seconds. This value can be
> > changed using the TcpInitialRtt Registry parameter. If a TCP connection
> > cannot be established, it is retried TcpMaxDataRetransmissions times (the
> > default is two times).
> >
> > For established TCP connections, the number of retransmissions is controlled
> > by the TcpMaxDataRetransmissions Registry parameter (set to 5 by default).
> > The retransmission timeout is adjusted dynamically as per RFC 793,"TCP DARPA
> > Internet Program Protocol Specification" to adjust for the delay
> > characteristics of the connection. A Smoothed Round Trip Time (SRTT)
> > calculation is used as described in the following sidebar.
> >
> > In some situations TCP retransmits before the retransmission timer expires.
> > This situation commonly occurs when TCP implements a fast retransmit feature,
> > described in RFC 2581, "TCP Congestion Control" and explained in the
> > following sidebar.
> >
> >
> > --------------------------------------------------------------------------------
> >
> > Calculating Smoothed Round Trip Time (SRTT)
> >
> > Measure the elapsed time between sending a data octet with a particular
> > sequence number and receiving an acknowledgment that covers that sequence
> > number. This measured elapsed time is the Round Trip Time (RTT). Based on the
> > RTT, compute a Smoothed Round Trip Time (SRTT) as
> >
> > SRTT = ( [alp] * SRTT ) + ((1-[alp]) * RTT)
> >
> > [alp] is a weighting factor whose value is between 0 and 1 (0 <= [alp] < 1).
> > The SRTT is an estimated timeout. The SRTT computation, therefore, takes into
> > account its old SRTT value and the new RTT value and takes a weighted average
> > of these two. When [alp] = 0.5, SRTT is just the simple average of old SRTT
> > and the RTT values:
> >
> > SRTT = (SRTT + RTT)/2 when [alp] = 0.5
> >
> > When [alp] is less than 0.5, a greater weight is given to the actual Round
> > Trip Time (RTT). When [alp] is greater than 0.5, a greater weight is given to
> > the previous estimated Round Trip Time (SRTT).
> >
> > When [alp] = 0 or almost 1, you have the two extremes. When [alp] = 0, SRTT
> > is always set to RTT; and when [alp] is almost 1, a fixed SRTT is used with
> > little deference to the actual RTT that is implied. Needless to say, the two
> > extremes are seldom used in actual practice but are useful for understanding
> > the nature of the weighted average.
> >
> > The SRTT is then used to compute the retransmission timeout (RTO) using the
> > following:
> >
> > RTO = min[UBOUND,max[LBOUND,([beta]*SRTT)]]
> >
> > UBOUND is an upper bound on the timeout (for example, one minute), and
> > LBOUND is a lower bound on the timeout (for example, one second). These
> > values ensure that the RTO will fall between LBOUND and UBOUND. [beta] is a
> > delay variance factor to change the sensitivity to the delay. If [beta] is
> > set to 1, RTO will be set to SRTT unless the SRTT value is below LBOUND or
> > above UBOUND. This value ([beta] = 1) makes TCP sensitive to packet loss and
> > does not cause TCP to wait for a long time before retransmitting. However,
> > small delays might cause unnecessary retransmissions. To make TCP less
> > susceptible to small delays, a larger [beta] value might be used. RFC 793
> > suggests using a value from 1.3 to 2.0.
> >
> > above extract from
> > http://www.informit.com/articles/article.asp?p=130716&seqNum=4&rl=1
> >
> > "Dan Seur" wrote:
> >
> >
> >>Not positive, but I believe you'll discover that lbound & ubound are set
> >>in the source code of whatever TCP you're using, and resetting would
> >>involve a recompile of that module. Not highlevel stuff, likely not in
> >>registry.
> >>
> >>Further I believe the max (ubound) setting is dynamically adjusted
> >>according to ongoing retransmit durations, and in most implementations
> >>can exceed your 35 second ping by close to a minute and a half.
> >>
> >>Is it possible your radio link is occasionally completely blocked for
> >>periods exceedingf a few hundred seconds? Jammed? Hdw/sftw glitch?
> >>
> >>As I say, cum grano salis etc.
> >>
> >>hotdogdave wrote:
> >>
> >>>Hi
> >>>
> >>>Can anyone please help?! : )
> >>>
> >>>I am working with a Win2000 IP network over a HF radio system with high
> >>>latencies (ping = 35 secs). Putting the jokes aside of 'why bother'!, we
> >>>occasionally get a TCP timeout occurring. I know this is because the reply
> >>>takes longer than the TcpTimeout setting. The MS info on this is at
> >>>
> >>>http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58802.asp
> >>>
> >>>I have changed the TcpInitialRtt value in the registry but this is an
> >>>initial value to start the Smoothed RTT (SRTT) which is then dynamically
> >>>calculated
> >>>using a given formula discussed in
> >>>
> >>>http://www.informit.com/articles/article.asp?p=130716&seqNum=4&rl=1
> >>>
> >>>SRTT is calculated by values such as [alp], [beta]. Retransmit TimeOut (RTO)
> >>>is then calculated from SRTT and also has values such as upper and lower
> >>>bounds (UBOUND, LBOUND). I have done a lot of searching and can find lots of
> >>>information on what I have discussed above, but nothing about where I can set
> >>>the values above. The articles indicate that these values may be altered. I
> >>>assume these are set in the registry, like TcpInitialRTT, but I cant find out
> >>>where.
> >>>
> >>>cheers David
> >>>sunny England
> >>>
> >>>
> >>>---
> >>>avast! Antivirus: Inbound message clean.
> >>>Virus Database (VPS): 0549-1, 12/05/2005
> >>>Tested on: 12/5/2005 10:45:17 AM
> >>>avast! - copyright (c) 1988-2004 ALWIL Software.
> >>>http://www.avast.com
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>---
> >>avast! Antivirus: Outbound message clean.
> >>Virus Database (VPS): 0549-1, 12/05/2005
> >>Tested on: 12/5/2005 11:25:28 AM
> >>avast! - copyright (c) 1988-2004 ALWIL Software.
> >>http://www.avast.com
> >>
> >>
> >>
> >>
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0549-1, 12/05/2005
> > Tested on: 12/5/2005 12:25:47 PM
> > avast! - copyright (c) 1988-2004 ALWIL Software.
> > http://www.avast.com
> >
> >
> >
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 0549-1, 12/05/2005
> Tested on: 12/5/2005 12:42:48 PM
> avast! - copyright (c) 1988-2004 ALWIL Software.
> http://www.avast.com
>
>
>
>
.

Relevant Pages

  • Re: How do I alter values for TCP timeouts (SRTT & RTO)
    ... What I'm finding is one node will have a quick TCP response and dynamically alter its RTT to say 25 secs. ... There are 2 ways I can think of to overcome this, set LBOUND to a min, or give less weight of SRTT to the last measured RTT. ... TCP starts a retransmission timer when each TCP segment is sent and then waits for an acknowledgment to come back before the retransmission timer expires. ... A Smoothed Round Trip Time calculation is used as described in the following sidebar. ...
    (microsoft.public.win2000.general)
  • Re: How do I alter values for TCP timeouts (SRTT & RTO)
    ... will have a quick TCP response and dynamically alter its RTT to say 25 secs. ... give less weight of SRTT to the last measured RTT. ... TCP starts a retransmission timer when each TCP segment is sent and then ... Calculating Smoothed Round Trip Time ...
    (microsoft.public.win2000.general)
  • Re: How do I alter values for TCP timeouts (SRTT & RTO)
    ... There are similarities in ACK/NACK requirements and consequent code mods between ultrafast interhost TCP and reeeeallllly slllooooowww TCP down stringand can-based links... ... There are 2 ways I can think of to overcome this, set LBOUND to a min, or give less weight of SRTT to the last measured RTT. ... TCP starts a retransmission timer when each TCP segment is sent and then waits for an acknowledgment to come back before the retransmission timer expires. ...
    (microsoft.public.win2000.general)
  • RE: FreeBSD 4.x and OS-X tcp performance
    ... I have seen such a problem with TCP flows between FreeBSD 4.5 and SUN servers. ... However, RFC 2001 describes Fast Retransmission, where the third ... suffers badly from any packet loss. ...
    (freebsd-net)
  • Re: Ping (ICMP) in Java over TCP?
    ... > But how does this Java Applet calculate the Round Trip Time? ... Using TCP, as far as I can see. ... or ICMP, but it's a valid ballpark estimate. ... from Java though, short of using JNI to interface to pcap or such-like. ...
    (comp.lang.java.help)
Loading