I'm getting SEVERAL entries in my packet capture that I beleive indicate lost packets. TCP Dup ACK & TCP Retrasmission to be specific. I see there is a problem here, but can someone walk me step by step through identifying what the cause of this is? I'm assuming that somewhere within the capture it will tell me the workstation or piece of equipment that is causing this problem?? asked 03 Jan '13, 14:27  pstage edited 04 Jan '13, 00:01  Guy Harris ♦♦ |
3 Answers:
Your trace is not indicating lost packets as much as you think - you just got tons of duplicate packets in there, which Wireshark will mark as retransmissions or duplicate ACKs. This is usually caused by spanning multiple source ports or a VLAN. I deduplicated your trace using editcap like this:
and everyhting looked a lot better. There still are duplicates that editcap won't remove because you captured packets before and after they were routed (you can tell from the TTL and the MAC layer). With all those remaining duplicates it's a hard thing to say what really goes on, but I doubt that it is as bad as it seemed to you, especially when you also had the real duplicates still in the file. answered 08 Jan '13, 12:12  Jasper ♦♦ edited 08 Jan '13, 12:13 |
Sorry. Packet traces will not tell you where the lost is happening. To do that, you have to capture at multiple capture points - not always practical. Are you seeing FAST RETRANSMISSIONS or just RETRANSMISSIONS? Not all packet losses are equal, some are more damaging than others (in terms of performance). If you can post your trace file somewhere, folks may be able to download it an help you analyze it. answered 03 Jan '13, 17:08  hansangb edited 04 Jan '13, 07:07 |
There is an interesting conversation going on between 192.168.1.35 ( sender ) and 192.168.3.54 ( receiver ) where we see a lot of zero window size on the .54 side. Although we don't have the SYN > SYN/ACK it looks like window scaling is not enabled on the .54 machine. The sender sends 65k of data which the sender ACKs with the large number of ACKs that we see whilst reducing the window but increasing the ACK by 2920 bytes which indicates that the receiver is buffering the data but the application is not consuming it. Given that the time taken for each of these events ( zero window, zero window probe and window update ) can be 1.5 -2s then performance for this particular app will be slow. If the app can't handle 65k of date then I'm not sure enabling window scaling will help, the sender would just send more data and the receiver would just buffer the now increased window size worth of data until the app can consume it. In this case it looks like application level delay for this particular conversation. answered 14 Jan '13, 02:26  tenkrow Of course it could be that the sender only sends in 65k chunks, certainly the PSH biit is set on the last packet indicating the sender has no more data to send and it's always set on the last packet at around 65k, we'd need to see the 3 way handshake to find out if WS is on and what it's at. It's still application level delay. (14 Jan '13, 04:37) tenkrow |
I'm just seeing retransmissions. That and duplicate ACK messsages #1 to the hundreds. A short sample capture can be downloaded here. https://www.dropbox.com/sh/a8bub6yryq1v407/MDkooy5E8c Any help would be greatly appreciated!