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

Question regarding TCP traffic capture and TCP RENO

0

I took a capture of a simple TCP transmission of an image from an web page. However, analyzing the trace I found several issues that don't fit with what I know about TCP Reno (which I'm positive is what the web server has implemented). The entire capture can be found here: CloudShark

  • In several occasions, the client (me) sent back several packages with the same ACK, but different WND. I was explained that, so long as the ACK number was the same, this would trigger a retransmission in the server. However, it doesn't happen. For instance, I have something like this: https://pastebin.com/8hyGVJHT. So why doesn't that trigger a retransmission?

  • Another thing that I see is that sometimes it does trigger a retransmission, but only if there is a [TCP Previous segment not captured] before it, and the client sends several duplicated ACK (which don't show up in the trace like [TCP Dup ACK Package#DuplicateNumber]: https://pastebin.com/zF9fBKRk. So, why does TCP retransmit that package, if there is no flag for duplicate ACK?

  • Finally, I see that when the client sends duplicate ACK packages, it sends many. I had understood that after the server receives 3, in fast retransmit, it retransmits the missed package: https://pastebin.com/XyUDVydZ. So, why does the server take longer to recognize the duplicate ACK?

Thanks.

asked 02 Apr '17, 14:09

Heathcliff's gravatar image

Heathcliff
11115
accept rate: 0%

edited 02 Apr '17, 14:38


2 Answers:

2

There is a real packet loss at the beginning of the capture.

Data packets #6 & #7 are OK (ACKed by #15 & #16), then there's a gap that should trigger Dup-ACKs in response to each of #8-#14. So we should get 7 Dup-ACKs.

From a pure "ACK Sequence Number" perspective, #17-#23 are those Dup-ACKs, which all acknowledge the data up to data packet #7 (before the missing packet).

Data packets #24-#27 should also trigger Dup-ACKs. Again, #28-#31 are those Dup-ACKs too, again acknowledging just up to #7.

However, #17-#23 and #28-#31 each also increase the Receive Window size.

I think that core of the problem (at least for your first question) is the definition of "Duplicate ACK". I think that Wireshark, your receiving client and the commercial packet analysis software that I use, do not count these as Duplicate-ACKs because they also include the window size increase.

I found RFC 5681 that defines Dup-ACKs. (Earlier RFCs 2001 and 2581 discuss them but don't mention what should happen if a Dup-ACK also contains a changed window value).

Start of quote.

DUPLICATE ACKNOWLEDGMENT:

An acknowledgment is considered a "duplicate" in the following algorithms when

(a) the receiver of the ACK has outstanding data,

(b) the incoming acknowledgment carries no data,

(c) the SYN and FIN bits are both off,

(d) the acknowledgment number is equal to the greatest acknowledgment received on the given connection (TCP.UNA from [RFC793]) and

(e) the advertised window in the incoming acknowledgment equals the advertised window in the last incoming acknowledgment.

Alternatively, a TCP that utilizes selective acknowledgments (SACKs) [RFC2018, RFC2883] can leverage the SACK information to determine when an incoming ACK is a "duplicate" (e.g., if the ACK contains previously unknown SACK information).

End of quote.

It would therefore appear that a receiver should not include Receive Window changes in any ACK packets that it wants to be treated as Dup-ACKs.

Thus, the TCP stack in the receiving client is behaving badly.

Under this definition, the Dup-ACKs seen in your capture are not classified as Dup-ACKs, even though they are each indicating an acknowledgement of the same data.

Now, since the sending server doesn't interpret these as Dup-ACKs, it appears to wait for a Retransmission Timeout (RTO) of 2.8 seconds before filling in the gap with #32.

Later in the capture, we see #64 but it is lost before it gets to the client. There are many Dup-ACKs in response to that gap (as seen at the receiving client) before it is filled in by #132 (a retransmission of #64).

There is another real gap between #113 & #114 which is filled in by #148. This is a faster gap fill, partially due to the Dup-ACKs from #64.

Lastly, #150 is a retransmission of #130 (which we saw but must have been lost before it got to the client).

Other observations:

Yes, based on those 3-way handshake times, we would deduce that the capture point is 480 ms away from the client and a further 200 ms away from the server. Is this artificial or are your end-points on the opposite sides of the world?

It looks like this client is generating ACKs to every data packet rather than doing the usual delayed ACK mechanism (which only ACKs every second data packet). Did you purposely configure this or is the default behaviour of your client TCP stack?

Can you tell us what your client is - so that we can be aware to look out for this behaviour in future?

answered 04 Apr '17, 01:56

Philst's gravatar image

Philst
4311616
accept rate: 27%

edited 04 Apr '17, 20:42

1

@Philst: very informative and clear. Thank you.

(04 Apr '17, 06:04) Heathcliff

Thanks @Heathcliff. I did find a more definitive RFC and have replaced the quoted area in my answer with the newer, better information.

I've also added a couple of questions in "Observations" section at the end. It would be good to know what your client device is so that we can be on the lookout for this incorrect behaviour in future.

I also added my own question #60562

https://ask.wireshark.org/questions/60562/does-wireshark-not-count-a-duplicate-ack-if-it-also-contains-a-receive-window-change

about the Dup-ACK definition and behaviour.

Please press the "tick" in the answer if you think it is correct.

(04 Apr '17, 20:51) Philst

1

The cloudshark file cannot be accessed - my userid does not have permission to view this file. So my answers are based on your description only.

Your first pastebin file shows TCP Window Updates, which occur when your application (browser) has read the data and the client's TCP is offering larger window sizes again and therefore are not indicative of a missing segment that would require re-transmission.

... only if there is a [TCP Previous segment not captured] before it
That is what I would expect to see when looking at a capture close to the receiver. When a segment gets lost 'upstream' wireshark will detect this and mark it accordingly .

If a segment gets lost early in a batch of segments, the client will send a duplicate ACK for every out of order segment - immediately - and those ACKs take some time to reach the server. As the Server can only react when it sees the 3rd duplicate ACK you can see more than 3 duplicate ACKs before the fast retransmitted packets arrives at the client- especially when you look at a trace at the client (receiver).

Regards Matthias

answered 02 Apr '17, 21:44

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

@mrEEde I've changed the capture to make it public.

(03 Apr '17, 06:57) Heathcliff

The trace shows some very strange timing behavior, given that the 2 Ubuntu stacks are co-located in the same network.
Why are you seeing 200ms delay between SYN and SYN_ACK and another 480 ms delay to complete the 3-way handshake?

Are the Linuxes running on bare metal or in a VM?

(03 Apr '17, 10:47) mrEEde