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
Thanks. asked 02 Apr '17, 14:09 Heathcliff edited 02 Apr '17, 14:38 |
2 Answers:
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 edited 04 Apr '17, 20:42 |
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 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 @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. Are the Linuxes running on bare metal or in a VM? (03 Apr '17, 10:47) mrEEde |
@Philst: very informative and clear. Thank you.
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.