Hi, I have a trace file which makes me be confused on the behavior of tcp-delayed Ack. As you can see, 192. send 7 tcp segments to 10., but where is the Ack for packet #3 and #4.Shouldn't we expect to see an Ack for those two packets according to the rule of tcp-delayed Ack? We see the Ack from 10. at packet #10, which acked all of the bytes including #8. Is it a right behavior? Note: if you cannot see the full picture, please copy paste the link _http://img.my.csdn.net/uploads/201312/31/1388471175_2006.jpg directly to the web browser. thank you! asked 30 Dec '13, 22:32  SteveZhou |
2 Answers:
RFC 1122 says that "...in a stream of full-sized segments there SHOULD be an ACK for every second segment." The use of "SHOULD" in the RFC means that this behavior is not mandatory, and an implementation may adopt different behavior. There are TCP/IP stacks that send Delayed ACKs less often than every other segment. In other words, an ACK for every other segment is not really a rule. answered 31 Dec '13, 01:14  Jim Aragon |
Packets 3-9 all arrive at the same time so when they were traced the receiving TCP didn't see them yet. answered 30 Dec '13, 23:44  mrEEde |
I think this packet trace was NOT captured on 10., because right after getting #3 and #4, the receiver tcp should generate an Ack to them according to the rule of tcp delayed-ack. What do you mean for arrive at the same time? From tcp perspective, shouldn't the tcp stack code always triage the function call to generate a Ack for every other packet?
Or do you mean we do have an Ack for #3 and #4, just wireshark cannot capture it?