TCP Timeout

Discussion in 'Cisco' started by Andy Low, Mar 2, 2004.

  1. Andy Low

    Andy Low Guest

    Hi,

    I posted an issue previously as follow:

    1) Host B --> Host A, src port:1878 dst port: 2000
    [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460

    2) Host A --> Host B, src port: 2000, dst port: 1878
    [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=536

    3) Host B --> Host A,
    [TCP ZeroWindow] src port:1878 dst port:2000 [RST]
    Seq=1 Ack=1576600895 Win=0 Len=0


    After much troubleshooting, I suspect that the problem might be a timeout
    issue at Host B. I would like to find out what's the timeout for Host B
    after this server send out a SYN packet?

    Whenever Host B recieve a SYN+ACK packet from Host A after 200-500ms. Host B
    will send out RST immediately. During other times when Host B receive
    SYN+ACK packet after 5-50ms, there is no issue.

    Does anyone know about the timeout after the first SYN packet is sent out?

    Andy
    Andy Low, Mar 2, 2004
    #1
    1. Advertising

  2. In article <c20mlt$vtb$>,
    Andy Low <_REMOVE_> wrote:
    >Hi,
    >
    >I posted an issue previously as follow:
    >
    >1) Host B --> Host A, src port:1878 dst port: 2000
    >[SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
    >
    >2) Host A --> Host B, src port: 2000, dst port: 1878
    >[SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=536
    >
    >3) Host B --> Host A,
    >[TCP ZeroWindow] src port:1878 dst port:2000 [RST]
    >Seq=1 Ack=1576600895 Win=0 Len=0
    >
    >
    >After much troubleshooting, I suspect that the problem might be a timeout
    >issue at Host B. I would like to find out what's the timeout for Host B
    >after this server send out a SYN packet?
    >
    >Whenever Host B recieve a SYN+ACK packet from Host A after 200-500ms. Host B
    >will send out RST immediately. During other times when Host B receive
    >SYN+ACK packet after 5-50ms, there is no issue.
    >
    >Does anyone know about the timeout after the first SYN packet is sent out?


    RFC 1122 specifies 500ms but most implementations use 200ms.

    alan
    Alan Strassberg, Mar 2, 2004
    #2
    1. Advertising

  3. Andy Low

    AnyBody43 Guest

    (Alan Strassberg) wrote in message news:<c22b0i$st5$>...
    > In article <c20mlt$vtb$>,
    > Andy Low <_REMOVE_> wrote:
    > >Hi,
    > >
    > >I posted an issue previously as follow:
    > >
    > >1) Host B --> Host A, src port:1878 dst port: 2000
    > >[SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
    > >
    > >2) Host A --> Host B, src port: 2000, dst port: 1878
    > >[SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=536
    > >
    > >3) Host B --> Host A,
    > >[TCP ZeroWindow] src port:1878 dst port:2000 [RST]
    > >Seq=1 Ack=1576600895 Win=0 Len=0
    > >
    > >
    > >After much troubleshooting, I suspect that the problem might be a timeout
    > >issue at Host B. I would like to find out what's the timeout for Host B
    > >after this server send out a SYN packet?
    > >
    > >Whenever Host B recieve a SYN+ACK packet from Host A after 200-500ms. Host B
    > >will send out RST immediately. During other times when Host B receive
    > >SYN+ACK packet after 5-50ms, there is no issue.
    > >
    > >Does anyone know about the timeout after the first SYN packet is sent out?

    >
    > RFC 1122 specifies 500ms but most implementations use 200ms.
    >
    > alan


    Hi,

    I was surprised by the above numbers since the RTT to the antipodes
    must be a big piece of 500ms.

    Above would imply that with "most implementations" I would never be
    able to open a TCP session between say London and Sydney.

    Let's try:

    Pinging solo.ucc.usyd.edu.au [129.78.64.24] with 32 bytes of data:

    Reply from 129.78.64.24: bytes=32 time=327ms TTL=234
    Reply from 129.78.64.24: bytes=32 time=323ms TTL=234
    Reply from 129.78.64.24: bytes=32 time=323ms TTL=234
    Reply from 129.78.64.24: bytes=32 time=324ms TTL=234
    ...... more about the same.

    Let's look at rfc 1122 for clarification...
    hmmmmmm "Requirements for Internet Hosts -- Communication Layers"

    Not much mention of TCP in there?

    I am sorry about being somewhat pedantic however the OP has a
    problem and I just want to help out.

    ++++++++++
    Constructive suggestions.

    I had a wee look at this the other day and have the following
    observations (probably not helpful)

    - Ethereal 0.9.15 displays real sequence numbers.
    - It would be VERY odd for a modern TCP stack to use SEQ 0
    in the SYN. For security reasons the Initial Sequence
    Number is supposed to be random.
    - tcpdump can offset seq nos. to zero for display.
    - tcpdump can be started with options that force the display of
    real seq numbers. I recommend that you give that a go.

    - I have seen something like this once before. There were two
    possible paths out of the network and we were using NAT.
    One of the NATters occasionally leaked a packet
    when it shouldn't which resulted in the TCP session being
    shut down.

    |-------NATter1------|
    LAN---| |---Server
    |-------NATter2------|

    This was a supposedly resilient (not Cisco) firewall setup and
    the idea was that any particular TCP session would go through
    one of the NATters. In the event of failure the other one could
    take over.

    Unfortunately from time to time one of the NATters would leak
    and forward a packet that it should not have.

    So a valid TCP packet on the LAN would be NATted by the wrong NATter.
    When it atrrived at the server it was not in a valid session so
    the server sent a RST which according to the TCP standard it must do.
    This RST packet was correctly NATted back on to the LAN
    which turned it into a VALID packet on the LAN within the
    original session BUT with the RST bit set. This TERMINATED
    the valid session. :-(((((

    We called a plumber to plug the leak but it was too complex
    for them and we had to just pull the plug.

    - Please repeat packet capture and make sure that you have the
    real sequence numbers.

    - Another possibility mentioned previously is that you have
    a duplicate address somewhere.


    1) Host B1 --> Host A, src port:1878 dst port: 2000
    [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
    --- Host B1 opens session

    2) Host A --> Host B2, src port: 2000, dst port: 1878
    [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=536
    --- Host A's reply though gets seen by host B2
    --- which has never heard of the session

    3) Host B2 --> Host A,
    [TCP ZeroWindow] src port:1878 dst port:2000 [RST]
    Seq=1 Ack=1576600895 Win=0 Len=0
    --- SO B2 sends a RST.

    Good luck.
    AnyBody43, Mar 3, 2004
    #3
  4. In article <>,
    (AnyBody43) wrote:

    > I was surprised by the above numbers since the RTT to the antipodes
    > must be a big piece of 500ms.
    >
    > Above would imply that with "most implementations" I would never be
    > able to open a TCP session between say London and Sydney.


    Why do you say that? The timeout we're talking about doesn't cause a
    connection failure, just a retransmission of the SYN packet. The
    connection attempt doesn't fail until you've been retransmitting for
    several minutes with no response.

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Margolin, Mar 3, 2004
    #4
  5. In article <>,
    AnyBody43 <> wrote:
    > (Alan Strassberg) wrote in message news:<c22b0i$st5$>...
    >> In article <c20mlt$vtb$>,
    >> Andy Low <_REMOVE_> wrote:

    [...]
    >> >Does anyone know about the timeout after the first SYN packet is sent out?

    >>
    >> RFC 1122 specifies 500ms but most implementations use 200ms.

    [..]
    >Above would imply that with "most implementations" I would never be
    >able to open a TCP session between say London and Sydney.
    >
    >Pinging solo.ucc.usyd.edu.au [129.78.64.24] with 32 bytes of data:
    >
    >Reply from 129.78.64.24: bytes=32 time=327ms TTL=234
    >
    >Let's look at rfc 1122 for clarification...
    >hmmmmmm "Requirements for Internet Hosts -- Communication Layers"
    >
    >Not much mention of TCP in there?


    RFC1122 clearly states delay MUST be < 500ms.
    This is THE Internet standard (STD0003).

    4.2.3.2 When to Send an ACK Segment

    A host that is receiving a stream of TCP data segments can
    increase efficiency in both the Internet and the hosts by
    sending fewer than one ACK (acknowledgment) segment per data
    segment received; this is known as a "delayed ACK" [TCP:5].

    A TCP SHOULD implement a delayed ACK, but an ACK should not
    be excessively delayed; in particular, the delay MUST be
    less than 0.5 seconds, and in a stream of full-sized
    segments there SHOULD be an ACK for at least every second
    segment.

    alan
    Alan Strassberg, Mar 3, 2004
    #5
  6. In article <c25je9$1io$>,
    (Alan Strassberg) wrote:

    > In article <>,
    > AnyBody43 <> wrote:
    > > (Alan Strassberg) wrote in message
    > >news:<c22b0i$st5$>...
    > >> In article <c20mlt$vtb$>,
    > >> Andy Low <_REMOVE_> wrote:

    > [...]
    > >> >Does anyone know about the timeout after the first SYN packet is sent
    > >> >out?
    > >>
    > >> RFC 1122 specifies 500ms but most implementations use 200ms.

    > [..]
    > >Above would imply that with "most implementations" I would never be
    > >able to open a TCP session between say London and Sydney.
    > >
    > >Pinging solo.ucc.usyd.edu.au [129.78.64.24] with 32 bytes of data:
    > >
    > >Reply from 129.78.64.24: bytes=32 time=327ms TTL=234
    > >
    > >Let's look at rfc 1122 for clarification...
    > >hmmmmmm "Requirements for Internet Hosts -- Communication Layers"
    > >
    > >Not much mention of TCP in there?

    >
    > RFC1122 clearly states delay MUST be < 500ms.
    > This is THE Internet standard (STD0003).
    >
    > 4.2.3.2 When to Send an ACK Segment


    How is this section relevant? The question is about retransmitting at
    the sender end, so I think the relevant section is this:

    4.2.3.1 Retransmission Timeout Calculation
    ....
    The following values SHOULD be used to initialize the
    estimation parameters for a new connection:

    (a) RTT = 0 seconds.

    (b) RTO = 3 seconds. (The smoothed variance is to be
    initialized to the value that will result in this RTO).

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Margolin, Mar 3, 2004
    #6
  7. Andy Low

    AnyBody43 Guest

    Barry Margolin <> wrote in message news:<>...
    > In article <c25je9$1io$>,
    > (Alan Strassberg) wrote:
    >
    > > In article <>,
    > > AnyBody43 <> wrote:
    > > > (Alan Strassberg) wrote in message
    > > >news:<c22b0i$st5$>...
    > > >> In article <c20mlt$vtb$>,
    > > >> Andy Low <_REMOVE_> wrote:

    > [...]
    > > >> >Does anyone know about the timeout after the first SYN packet is sent
    > > >> >out?
    > > >>
    > > >> RFC 1122 specifies 500ms but most implementations use 200ms.

    > [..]
    > > >Above would imply that with "most implementations" I would never be
    > > >able to open a TCP session between say London and Sydney.
    > > >
    > > >Pinging solo.ucc.usyd.edu.au [129.78.64.24] with 32 bytes of data:
    > > >
    > > >Reply from 129.78.64.24: bytes=32 time=327ms TTL=234
    > > >
    > > >Let's look at rfc 1122 for clarification...
    > > >hmmmmmm "Requirements for Internet Hosts -- Communication Layers"
    > > >
    > > >Not much mention of TCP in there?

    > >
    > > RFC1122 clearly states delay MUST be < 500ms.
    > > This is THE Internet standard (STD0003).
    > >
    > > 4.2.3.2 When to Send an ACK Segment

    >
    > How is this section relevant? The question is about retransmitting at
    > the sender end, so I think the relevant section is this:
    >
    > 4.2.3.1 Retransmission Timeout Calculation
    > ...
    > The following values SHOULD be used to initialize the
    > estimation parameters for a new connection:
    >
    > (a) RTT = 0 seconds.
    >
    > (b) RTO = 3 seconds. (The smoothed variance is to be
    > initialized to the value that will result in this RTO).


    Thanks for the corerctions.

    What a load of crap I wrote:)

    However, I have found this discussion and others like it
    very educational. Hope you don't mind educating me, too much.

    I recall years ago posting some info on the token ring L1
    protocol to which someone made a small but critical correction.
    I never forgot that, and some time later used the information
    to resolve one of the most subtle problems it has ever been
    my misfortune to encounter. [Token ring worked or didn't depending
    on the location of the active monitor which is the source of the
    bit clock (let's call it) for the whole ring]

    Thanks again.
    AnyBody43, Mar 5, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Richard Antony Burton

    ip nat tran tcp-timeout

    Richard Antony Burton, Dec 9, 2003, in forum: Cisco
    Replies:
    0
    Views:
    549
    Richard Antony Burton
    Dec 9, 2003
  2. JCVD
    Replies:
    2
    Views:
    7,806
    Hansang Bae
    Feb 19, 2004
  3. Kevin
    Replies:
    1
    Views:
    784
    Walter Roberson
    Nov 10, 2004
  4. DJ Chiro
    Replies:
    1
    Views:
    3,264
    Rowdy Yates
    Nov 7, 2003
  5. mark

    Windows XP TCP/IP DHCP timeout

    mark, Aug 26, 2005, in forum: NZ Computing
    Replies:
    2
    Views:
    3,178
Loading...

Share This Page