Hello Wilfried,

Here are some other infos that may help/explain

Key: Tcpip\Parameters
Value Type: REG_DWORD-Number
Valid Range: 0-0xFFFFFFFF
Default: 5

Description:  This  parameter  controls  the  number of times TCP will
retransmit   an   individual  data  segment  (not  connection  request
segments)  before aborting the connection. The retransmission time-out
is  doubled with each successive retransmission on a connection. It is
reset  when  responses  resume. The base time-out value is dynamically
determined by the measured round-trip time on the connection.

Key: Tcpip\Parameters
Value Type: REG_DWORD-Time in milliseconds
Valid Range: 1-0xFFFFFFFF
Default: 1000 (one second)

Description: This parameter determines the interval between keep-alive
retransmissions  until  a  response  is  received.  Once a response is
received,  the  delay  until the next keep-alive transmission is again
controlled  by  the  value  of  KeepAliveTime.  The connection will be
aborted   after   the   number   of   retransmissions   specified   by
TcpMaxDataRetransmissions have gone unanswered.

Key: Tcpip\Parameters
Value Type: REG_DWORD-Time in milliseconds
Valid Range: 1-0xFFFFFFFF
Default: 7,200,000 (two hours)

Description:  The  parameter controls how often TCP attempts to verify
that  an  idle  connection  is  still  intact  by sending a keep-alive
packet.  If  the  remote system is still reachable and functioning, it
will  acknowledge  the keep-alive transmission. Keep-alive packets are
not sent by default. This feature may be enabled on a connection by an

Dead Gateway Detection

Dead  gateway  detection is used to allow TCP to detect failure of the
default  gateway  and to make an adjustment to the IP routing table to
use  another  default  gateway.  The  Microsoft  TCP/IP stack uses the
TRIGGERED  RESELECTION  method  described in RFC 816, with some slight
modifications  based  upon customer experiences and feedback. When any
TCP  connection  that  is  routed  through  the  default  gateway  has
attempted  to  send  a TCP packet to the destination a number of times
equal  to  one-half  of  the registry value TcpMaxDataRetransmissions,
without  receiving  a  response, the algorithm changes the Route Cache
Entry  (RCE)  for  that  one remote IP address to use the next default
gateway in the list. When 25 percent of the TCP connections have moved
to  the  next  default gateway, the algorithm advises IP to change the
computer's  default  gateway  to  the one that the connections are now
using. For example, assume that there are currently TCP connections to
11  different  IP  addresses that are being routed through the default
gateway.  Now  assume  that the default gateway fails, that there is a
second   default   gateway   configured,   and   that  the  value  for
TcpMaxDataRetransmissions  is  at the default of 5. When the first TCP
connection   tries   to   send   data,   it   will   not  receive  any
acknowledgments.  After  the  third  retransmission,  the RCE for that
remote  IP address will be switched to use the next default gateway in
the  list.  At  this  point, any TCP connections to that one remote IP
address  will  have  switched over, but the remaining connections will
still  try  to  use  the original default gateway. When the second TCP
connection tries to send data, the same thing will happen. Now, two of
the  11  RCEs  will  point  to  the  new  gateway.  When the third TCP
connection  tries  to send data, after the third retransmission, three
of  11  RCEs  will  have  been switched to the second default gateway.
Because,  at  this point, over 25 percent of the RCEs have been moved,
the  default  gateway  for the whole computer will be moved to the new
one.  At  this point, that default gateway remains the primary one for
the  computer  until it experiences problems (causing the dead gateway
algorithm to try the next one in the list again) or until the computer
is  restarted.  When  the  search reaches the last default gateway, it
returns to the beginning of the list.

TCP Retransmission Behavior

TCP starts a retransmission timer when each outbound segment is handed
down  to  IP. If no acknowledgment has been received for the data in a
given   segment   before  the  timer  expires,  then  the  segment  is
retransmitted.  For  new connection requests, the retransmission timer
is  initialized  to  3  seconds, and the request (SYN) is resent up to
TcpMaxConnectRetransmissions  times (the default for Windows NT 5.0 is
2  times, down from 3 in Windows NT 4.0). On existing connections, the
number     of     retransmissions     is     controlled     by     the
TcpMaxDataRetransmissions  registry  parameter  (5  by  default).  The
retransmission  time-out  is  adjusted  "on  the  fly"  to  match  the
characteristics  of  the  connection  using  Smoothed  Round Trip Time
(SRTT)  calculations  as  described  in RFC 793. The timer for a given
segment  is  doubled  after each retransmission of that segment. Using
this  algorithm,  TCP  tunes  itself  to  the  "normal"  delay  of   a
connection.  TCP  connections  over  high-delay  links  will take much
longer to time out than those over low-delay links.

The  following  trace  clip shows the retransmission algorithm for two
hosts connected over Ethernet on the same subnet. An FTP file transfer
was  in  progress  when  the  receiving host was disconnected from the
network.  Because  the  SRTT  for  this connection was very small, the
first  retransmission  was sent after about one-half second. The timer
was  then doubled for each of the retransmissions that followed. After
the  fifth retransmission, the timer was once again doubled, and if no
acknowledgment  was  received  before  it  expired, the connection was

delta  source ip    dest ip      pro flags description
0.000  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760
0.521  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760
1.001  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760
2.003  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760
4.007  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760
8.130  TCP .A.., len: 1460, seq: 8043781, ack: 
8153124, win: 8760

There  are  some  circumstances  under  which TCP will retransmit data
prior  to  the retransmission timer expiring. The most common of these
occurs due to a feature known as fast retransmit. When a receiver that
supports  fast  retransmit receives data with a sequence number beyond
the  current  expected  one,  then  it  is  likely  that some data was
dropped.  To  help  make  the sender aware of this event, the receiver
immediately  sends  an  ACK,  with  the ACK number set to the sequence
number  that  it  was  expecting. It will continue to do this for each
additional  TCP segment that arrives containing data subsequent to the
missing data in the incoming stream. When the sender starts to receive
a  stream of ACKs that are acknowledging the same sequence number, and
that sequence number is earlier than the current sequence number being
sent,  it  can  infer that a segment (or more) must have been dropped.
Senders  that  support  the fast retransmit algorithm will immediately
resend  the  segment that the receiver is expecting to fill in the gap
in  the  data,  without waiting for the retransmission timer to expire
for  that segment. This optimization greatly improves performance in a
lossy  network  environment.  By  default,  Windows  NT  5.0 resends a
segment  if  it  receives three ACKs for the same sequence number, and
that  sequence  number lags the current one. This is controllable with
the  TcpMaxDupAcks  registry  parameter.  See also the section in this
paper on Selective Acknowledgements.

TCP Keep-alive Messages

A  TCP keep-alive packet is simply an ACK with the sequence number set
to  one  less  than  the current sequence number for the connection. A
host  receiving  one  of  these  ACKs will respond with an ACK for the
current  sequence  number.  Keep-alives can be used to verify that the
computer  at  the  remote  end of a connection is still available. TCP
keep-alives   can  be  sent  once  every  KeepAliveTime  (defaults  to
7,200,000 milliseconds or two hours), if no other data or higher level
keep-alives  have been carried over the TCP connection. If there is no
response  to a keep-alive, it is repeated once every KeepAliveInterval
seconds.  KeepAliveInterval  defaults  to 1 second. NetBT connections,
such  as  those  used  by  many  Microsoft networking components, send
NetBIOS  keep-alives  more  frequently, so normally no TCP keep-alives
will  be sent on a NetBIOS connection. TCP keep-alives are disabled by
default,  but  Windows  Sockets  applications  can  use the SetSockOpt
function to enable them.


To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to