This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Duplicate Ack Count Up to 300 without retry

0

I am troubleshooting periodic slowness in a streaming application running over the Internet. A trace from the client shows duplicate ack storms occasionally, which is not unusual in itself. WHat is odd is that wireshark is reporting up to 300 dup ack's for the same sequence before a Fast Retransmit comes through from the server. I've tested this using the same client against two different servers of the same type with the same application located on different host sites and I'm getting dup ack retries of between 15 and 300. It is my understanding that most stacks have the default maxdupack value somewhere between 1 and 3

I can't post the trace due to confidentiality, but here is the export using tcp.analysis.duplicate_ack filter from one server

5634    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#280] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5422170 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5635    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#281] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5423630 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5636    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#282] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5425090 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5637    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#283] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5426550 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5638    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#284] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5428010 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5639    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#285] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5429470 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5640    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#286] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5430930 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5641    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#287] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5432390 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5642    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#288] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5433850 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5650    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#289] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5435310 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5651    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#290] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5436770 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5652    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#291] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5438230 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5653    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#292] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5439690 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5654    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#293] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5441150 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5655    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#294] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5442610 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5656    53:36.8 Client  Server  TCP 90  [TCP Dup ACK 5063#295] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5444070 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5661    53:36.9 Server  Client  TCP 66  [TCP Dup ACK 5660#1] 6100 > 53048 [ACK] Seq=5449910 Ack=48939 Win=191 Len=0 SLE=48967 SRE=48981
5664    53:36.9 Server  Client  TCP 60  [TCP Dup ACK 5663#1] 6100 > 53048 [ACK] Seq=5451358 Ack=48981 Win=191 Len=0
5665    53:36.9 Client  Server  TCP 90  [TCP Dup ACK 5063#296] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5445530 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5666    53:36.9 Client  Server  TCP 90  [TCP Dup ACK 5063#297] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5446990 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5667    53:36.9 Client  Server  TCP 90  [TCP Dup ACK 5063#298] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5448450 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5668    53:36.9 Client  Server  TCP 90  [TCP Dup ACK 5063#299] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5449910 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858
5669    53:36.9 Client  Server  TCP 90  [TCP Dup ACK 5063#300] 53048 > 6100 [ACK] Seq=48981 Ack=5004558 Win=10738 Len=0 SLE=5035270 SRE=5451358 SLE=5032350 SRE=5033810 SLE=5013318 SRE=5030890 SLE=5008938 SRE=5011858

asked 04 Sep '14, 11:16

DICOM_Tracer's gravatar image

DICOM_Tracer
1111
accept rate: 0%

edited 04 Sep '14, 11:17

Jasper's gravatar image

Jasper ♦♦
23.8k551284


One Answer:

0

Diagnosing things with huge ASCII dumps is really painful, so I doubt many of us will spent any amount of time on trying to figure things out with it. A trace would be much more useful, and if you're concerned about confidentiality you can use TraceWrangler to sanitize your trace. In your case you can strip all TCP payload since this is strictly a TCP layer problem (well, it shows on TCP, but you have most likely a buffer problem).

Let me guess - the trace is a conversation where the sender has a bandwith larger than the target, maybe by factor 10 (e.g. a file server on a 1G link, with a client on 100MBit, or 10G to 1G)? Your trace shows the typical result of a huge amount of packets filling up a buffer somewhere (e.g. on a router or a switch port) and packet loss occurs. The receiver sends duplicate ACKs and the sender triggers a fast retransmission, but unfortunately that retransmission has to get in line at the end of the (still completely filled) buffer - which is why it takes so long to get through, and which is also why you see so many dup acks. By the way, this is not a lot of dup acks - I had a trace where there were over 1000 of them for a 10G -> 1G -> 100 Mbit connection, with double buffering.

Just guessing, because there isn't much more I can do with a partial ASCII dump ;-)

answered 04 Sep '14, 11:25

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 04 Sep '14, 11:26

Thank you for the response. I understand the limited value of the ascii dump. You're reply was appreciated. We had come to a similar understanding but it is helpful to someone else's experience.

(05 Sep '14, 07:51) DICOM_Tracer