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

How much data for each ack ?

0

I am looking at the sample Wireshark capture from http-google101.pcapng ( available from http://wiresharkbook.com/wireshark101.html )

No.     Time            Source                Destination           Protocol Length Info 
 11 04:38:53.329529 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 12 04:38:53.329535 74.125.224.80         24.6.173.220          HTTP     863    Continuation or non-HTTP traffic
 13 04:38:53.329537 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 14 04:38:53.329540 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 15 04:38:53.329542 74.125.224.80         24.6.173.220          HTTP     1290   Continuation or non-HTTP traffic
 16 04:38:53.329544 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 17 04:38:53.329547 74.125.224.80         24.6.173.220          HTTP     358    Continuation or non-HTTP traffic
 18 04:38:53.335202 24.6.173.220          74.125.224.80         TCP      54     35145 > http [ACK] Seq=289 Ack=9500 Win=65780 Len=0
 19 04:38:53.352442 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 20 04:38:53.354411 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 21 04:38:53.354416 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 22 04:38:53.354419 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 23 04:38:53.354421 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 24 04:38:53.354424 74.125.224.80         24.6.173.220          HTTP     1484   Continuation or non-HTTP traffic
 25 04:38:53.357432 24.6.173.220          74.125.224.80         TCP      54     35145 > http [ACK] Seq=289 Ack=18080 Win=65780 Len=0

From frame 11 to frame 25, it appears to be a transfer of data from the server to client via TCP. There is an ACK for every few TCP segments.

Is there a rule stating that the receiver must send an ACK after receiving a maximum of xxx TCP segments ?

I did some research and got confused.. Window size, Selective Repeat protocol etc appeared in my searches =/

asked 17 Jun '14, 08:29

Dinged's gravatar image

Dinged
367711
accept rate: 0%

edited 17 Jun '14, 08:32


2 Answers:

2

Since the question is on what the written rule is, and specifically what the written rule is for the receiver, the answer is yes there is a written rule (ACK after two segments), but it is a "SHOULD" rule and it wasn't clearly defined even at that level until after the original RFC.

RFC 2581 section 4.2 has it. It's kind of funny because they're adding ambiguity between implementations through their 'unambiguous' statement. They are clear about how unclear we can be:

Specifically, an ACK SHOULD be generated for at least every second full-sized segment, and MUST be generated within 500 ms of the arrival of the first unacknowledged packet.

The requirement that an ACK "SHOULD" be generated for at least every second full-sized segment is listed in [Bra89] in one place as a SHOULD and another as a MUST. Here we unambiguously state it is a SHOULD.

The original TCP RFC 793 says they should be ACKed “without undue delay” and suggests piggybacking if possible (page 73). Any RFC 2581-compliant TCP stack is mandated to ACK inside of 500 ms though.

Also, as a general comment it is almost always best to go to the RFC or white paper if you have a question on a firm rule for a protocol. Especially in multi-vendor scenarios it’s a universal language between them, and suppliers/vendors will usually agree to be bound by them in a negotiation as well.

answered 18 Jun ‘14, 20:43

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

edited 18 Jun ‘14, 20:45

1

Disclaimer: I'll try to keep the answer simple - that's why I dont mentioned the cases where my rule of thumb is not applicable...

So yes and no -> there is just one rule stating that after a maximum of data send (which is the value defined through window size) the sender has to wait for an ACK before sending more data.

Usually when looking at windows systems, you'll see that there is one ACK after two TCP segments in most cases. With *nix systems its heavily dependend on the exact system, but in most cases you will also be able to see a "pattern" within an ongoing data transfer.

So every stack has its own behaviour about when and how to ACK incoming data, but all have in common that they try to ACK regularly and early so that the transmission keeps flowing.

answered 18 Jun '14, 11:22

Landi's gravatar image

Landi
2.3k51442
accept rate: 28%