I've a Windows 7 laptop on which I'm viewing a YouTube video using Mozilla Firefox web browser. There is nothing else being viewed on the internet except YouTube. No other browser/browser tab is open. The laptop is connected to the internet over an Ethernet connection. Here is what I see: after a few initial packets, I notice that there is a pattern in TCP's segment - ACK transmission. Around 10 TCP segments are being ACKed via a single TCP ACK. This pattern keeps on repeating. All the TCP segments have the same source IP address so I'm assuming that they come from the same server. My initial guess was that this could be due to TCP delayed ACK mechanism. However, that does not seem to be the case. According to RFC 1122, with a stream of full-sized incoming segments, ACK responses must be sent for every second segment. Additionally, I checked the packets that constitute the initial SYN-ACK handshake. The MSS that is agreed upon is 1460 Bytes. So this means that there should have been 5 ACKs instead of just one. I know that Windows 7 uses Compound TCP. But I'm not sure that this is something to do with a TCP version since all version must be RFC compliant, correct? I also performed another experiment and took a couple of traces for the following sources: YouTube, Amazon Prime Video, Pandora. I see a similar trend. In fact, I always see a set of 10 segments being ACKed by a single TCP ACK. What is it that I'm missing here? I'm attaching a snapshot of what I saw. I've also added a bytes in flight column as well. |
That screenshot is quite useless unfortunately, so it would be better to share a PCAP instead - the reason is that your question is SEQ/ACK number related, but we don't see those numbers except for a few packets. Bytes in flight is not always relevant as this issue is also depending on the point of capture, RTT and distance. It is also quite possible (and not at all illegal) to ACK more than two packets - I've seen many stacks do that. RFCs are guidelines and not always respected, and in this case the rule you're quoting from RFC 1122 is a "SHOULD" rule, not a "MUST" (section 4.2.3.2, second paragraph). Also note that RFC 1122 was published in 1989 (which is an eternity ago in network technology) and has been updated in RFCs 1349, 4379, 5884, 6093, 6298, 6633, 6864, and 8029. I didn't check but it is very likely that most of the things in 1122 are long updated with newer findings and guidelines. So: no, unfortunately you are mistaken. "All version" do not need to be RFC compliant, and often cannot be, because there are different approaches that may even contradict each other. In the end, it comes down to "whatever works efficiently" - and if there is no packet loss, ACKing 10 packets instead of 2-2-2-2-2 is pretty efficient, and many modern stacks adjust their ACK ration according to the transmission success. I bet you'll see that 2-packet-ACK pattern again when packets are lost, because a faster ACK rhythm helps detecting packet loss faster. 1
Thanks for your reply. I really appreciate it. I do have a couple of follow up questions to make sure my understanding is accurate:
Again, thanks a lot for your response. It was very informative and useful.
(07 Jul '17, 18:35)
alphasneaky
1
(08 Jul '17, 03:16)
Jasper ♦♦
Thanks very much.
(08 Jul '17, 14:06)
alphasneaky
|