server taking 22.5 seconds to retransmit packet - TCP-IP

This is a discussion on server taking 22.5 seconds to retransmit packet - TCP-IP ; On a packet capture that I did, Packet #298 from Server to Client Seq = 55913, Ack = 2314, Len = 1460 The above packet is saying... "Thanks for packet number 296 (ack 2314 (Seq + Len of packet #296)), ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: server taking 22.5 seconds to retransmit packet

  1. server taking 22.5 seconds to retransmit packet

    On a packet capture that I did,

    Packet #298 from Server to Client Seq = 55913, Ack = 2314, Len = 1460

    The above packet is saying...
    "Thanks for packet number 296 (ack 2314 (Seq + Len of packet #296)),
    also here is 1460 Bytes of data"

    Packet #299
    >From client to server

    Seq = 2314, Ack = 55913, Len = 0

    The above packet is saying...
    "Thanks for packet #298"
    But if you notice...the Ack number didn't include the addition of the
    Len of #298

    Am I correct in saying that the client got the packet but it was
    corrupt, or was too busy to process the packet so it requested the
    server to resend (hence Ack value of 55913).


  2. Re: server taking 22.5 seconds to retransmit packet


    mr.fixit.dave@googlemail.com wrote:
    > Packet #298 from Server to Client Seq = 55913, Ack = 2314, Len = 1460


    > Packet #299
    > >From client to server

    > Seq = 2314, Ack = 55913, Len = 0
    >
    > The above packet is saying...
    > "Thanks for packet #298"


    No it's not. It's saying "I'm expecting packet with sequence number
    55913"

    > But if you notice...the Ack number didn't include the addition of the
    > Len of #298


    No it didn't. With the information you've provided so far, we can't
    tell whether #298 was delivered successfully to the client.

    > Am I correct in saying that the client got the packet but it was
    > corrupt, or was too busy to process the packet so it requested the
    > server to resend (hence Ack value of 55913).


    Corrupt or "too busy" are possibilities. It is not correct to say
    "requested server to resend". TCP can only acknowledge data receipt.
    It cannot explicitly request retransmission.

    /chris


  3. Re: server taking 22.5 seconds to retransmit packet

    mr.fixit.dave@googlemail.com wrote:
    > On a packet capture that I did,


    > Packet #298 from Server to Client Seq = 55913, Ack = 2314, Len = 1460


    > The above packet is saying...
    > "Thanks for packet number 296 (ack 2314 (Seq + Len of packet #296)),
    > also here is 1460 Bytes of data"


    TCP doesn't know from packet numbers. Those are likely just a figment
    of the imagination of your traffic sniffing software. All TCP talks
    about are sequenc numbers. In the context of the ACKnowledgement
    number that would be the sequence number at the "leftmost edge" of the
    first "hole" in the sequence number space. Or, the next expected
    in-order sequence number.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: server taking 22.5 seconds to retransmit packet

    In article <1156876656.014783.71020@i3g2000cwc.googlegroups.co m>,
    googlegroups@marget.com wrote:

    > mr.fixit.dave@googlemail.com wrote:
    > > Packet #298 from Server to Client Seq = 55913, Ack = 2314, Len = 1460

    >
    > > Packet #299
    > > >From client to server

    > > Seq = 2314, Ack = 55913, Len = 0
    > >
    > > The above packet is saying...
    > > "Thanks for packet #298"

    >
    > No it's not. It's saying "I'm expecting packet with sequence number
    > 55913"
    >
    > > But if you notice...the Ack number didn't include the addition of the
    > > Len of #298

    >
    > No it didn't. With the information you've provided so far, we can't
    > tell whether #298 was delivered successfully to the client.


    In particular, packet #299 could have been sent by the client before the
    client received #298.

    >
    > > Am I correct in saying that the client got the packet but it was
    > > corrupt, or was too busy to process the packet so it requested the
    > > server to resend (hence Ack value of 55913).

    >
    > Corrupt or "too busy" are possibilities. It is not correct to say
    > "requested server to resend". TCP can only acknowledge data receipt.
    > It cannot explicitly request retransmission.


    When there's a gap in the sequence numbers of received packets, the
    receiver is supposed to retransmit the ACK of the segment before the
    gap. This is conventionally considered a request that the sender
    retransmit the missing one.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: server taking 22.5 seconds to retransmit packet


    Normally a corrupted packet will be answered by a lot of repeated acks
    (duplicate acks they are called in ethereal). This is a kind of request
    for retransmission of a packet.
    In this case it looks as whether the packet has never been received.
    However a timeout of 22.5 seconds is very long.


  6. Re: server taking 22.5 seconds to retransmit packet


    Normally a corrupted packet will be answered by a lot of repeated acks
    (duplicate acks they are called in ethereal). This is a kind of request
    for retransmission of a packet.
    In this case it looks as whether the packet has never been received.
    However a timeout of 22.5 seconds is very long.


  7. Re: server taking 22.5 seconds to retransmit packet

    Thanks for all your input on this.

    http://www.fixitdave.pwp.blueyonder....es/capture.jpg

    That is a screen shot of the capture, I have filtered on port number
    and blanked out most of the IP details.

    easterman wrote:
    > Normally a corrupted packet will be answered by a lot of repeated acks
    > (duplicate acks they are called in ethereal). This is a kind of request
    > for retransmission of a packet.
    > In this case it looks as whether the packet has never been received.
    > However a timeout of 22.5 seconds is very long.



  8. Re: server taking 22.5 seconds to retransmit packet


    mr.fixit.dave@googlemail.com wrote:
    > Thanks for all your input on this.
    >
    > http://www.fixitdave.pwp.blueyonder....es/capture.jpg
    >
    > That is a screen shot of the capture, I have filtered on port number
    > and blanked out most of the IP details.


    mr.fixit.dave-

    What packet capture software are you using ? Most packet capture
    software is woefully inadequate when it comes to TCP analysis. A
    time-scaled ladder diagram will save you a lot of hair-pulling. See an
    example here
    http://www.unleashnetworks.com/image.../tcpladder.png


  9. Re: server taking 22.5 seconds to retransmit packet

    In article <1157714474.011098.239840@m73g2000cwd.googlegroups. com>,
    mr.fixit.dave@googlemail.com wrote:

    > Thanks for all your input on this.
    >
    > http://www.fixitdave.pwp.blueyonder....es/capture.jpg
    >
    > That is a screen shot of the capture, I have filtered on port number
    > and blanked out most of the IP details.


    Your screen shot doesn't show sequence or ack numbers, so we can't tell
    what, if anything, was lost or retransmitted. From what we can see, it
    look like frame 299 is likely to be an ACK of the data in frame 298, and
    then host 194 didn't have anything new to send to host 10.1 for 22
    seconds.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread