A small capture is here Please confirm or correct my analysis: Looking at #17, It appears that some packets were dropped on their way from the server (10.230.36.138) to the client (10.3.2.205). As a result, the client receives a TCP segment with a sequence number higher than the expected one (out of order segment). The client updates the server with regards to the dropped/missing TCP segment by sending "DupAcks" to the server. (If say 20 packets were dropped, the client only sends DupAcks for the single packet it was expecting). After sending 55 DupAcks, the server finally fast retransmit that single packet. We don't know why it took 55 DupAcks. It could be the server setting or DupAcks not making it to the server. I could be totally wrong. So please advice. Thanks asked 12 Jul '16, 12:44  sshamim |
One Answer:
The packet loss is always signaled by setting the ACK number to the last byte of payload the was received without a gap. So if anything is lost, the ACK number stays on the last successful byte, no matter how many more packets make it through. ACK is only increased when the retransmission arrives. 55 Dup ACKs has nothing to do with a server setting, or them not making it through. It just takes a while for the Fast Retranmission to make it through. It's a little hard to tell because you didn't capture the TCP handshake, so we don't know the initial round trip time. I guess you suffer from a minor case of buffer bloat. See this question: https://ask.wireshark.org/questions/39043/1500-duplicate-acks-before-retransmission answered 12 Jul '16, 13:02  Jasper ♦♦ |
