After a poke and a prod from someone else here about this delay algorithm being used for timeouts, having that default to 0 doesn't seem like it would be appropriate either as it could severely hamper network connectivity in legitimate timeout cases.
It seems like MS' TCP stack seems to think a RST is the same as a timeout. argh!! Andy Jess Holle wrote: > I just set this parameter to 0 and the issue went away entirely. > > Good catch, Ruediger! Thank you -- and all who helped on this thread! > > It would appear that Microsoft's documentation slipped a decimal place > somewhere as it would appear there is about 0.3 second delay on the > initial retry and about a 0.6 second on the second -- resulting in > about a 1 second overall delay when other overhead/latency is included. > > I don't see a way to reduce this delay and overall concur with Andy > that this parameter should be 0 by all rights. Any thoughts? > > -- > Jess Holle > > Andy Wang wrote: >> Ruediger Pluem wrote: >>>>> >>>>> According to the Microsoft >>>>> (http://support.microsoft.com/default.aspx/kb/314053) >>>>> >>>>> TcpMaxConnectRetransmissions >>>>> Key: Tcpip\Parameters >>>>> Value Type: REG_DWORD - Number >>>>> Valid Range: 0 - 0xFFFFFFFF >>>>> Default: 2 >>>>> Description: This parameter determines the number of times that TCP >>>>> retransmits a connect request (SYN) before aborting the attempt. The >>>>> retransmission timeout is doubled with each successive retransmission >>>>> in a particular connect attempt. The initial timeout value is three >>>>> seconds. >>>>> >>>>> >>>>> So, looks like with default of 2 retransmits there is at least 9 >>>>> second delay. >>>>> >>>> I thought the problem was with local connects to a port, to which no >>>> process listens to. In this case the OS should immediately sending a RST >>>> (reset) and the client should not resend the SYN. I expect this >>>> TcpMaxConnectRetransmissions to be used in the case, were the remote >>>> server doesn't send any answer (neither RST nor SYN/ACK) and the client >>>> needs to retry the connection establishment after some timeout. That >>>> shouldn't be the case here, because the local system should always be >>>> able to send a RST if nothing is listening on the port. >>>> >>>> Except there's a local firewall with packet drop coming into the game >>>> (or name resolution timeouts, or ...). >>>> >>> >>> Exactly my understanding of the problem. So I see no use in >>> TcpMaxConnectRetransmissions >>> for this case. >>> >>> Regards >>> >>> Rüdiger >>> >>> >>> >> Looks like it might be the retry issue: >> 3963 13.831213 source destination TCP 1230 >> > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 >> 4087 14.280717 source destination TCP 2608 >> > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 >> 4088 14.280735 source destination TCP 1230 >> > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 >> 4238 14.827581 source destination TCP 2608 >> > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 >> 4239 14.827603 source destination TCP 1230 >> > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 >> >> >> The RSTs occur remotely and Windows retries twice. >> >> 1428 4.025656 unixsource destination TCP 57864 > 1230 >> [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=0 >> 1429 4.025674 unixsource destination TCP 1230 > 57864 >> [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 >> >> That's the same exchange from an HP-UX source to a linux destination. >> >> I'm assuming that windows pulls the same crap for localhost traffic >> even though we can't capture it to prove the case. Oh the joys of >> TCP/IP troubleshooting on Windows :) >> >> Andy >> >
