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

Can ACKs happen outside the RWIN?

0

I hope this is a straightforward question. Can the receiving side send ACKs at significantly less than the RWIN size? Example:

Note the bytes in flight

Receiving side 1.1.1.1
Sending side 2.2.2.2

48  0.000   1.1.1.1 2.2.2.2 TCP printer > netviewdm1 [ACK] Seq=3 Ack=32798 Win=64296 Len=0 TSV=26412037 TSER=3842799487
49  0.029   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 1368]
50  0.000   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 2736]
51  0.000   1.1.1.1 2.2.2.2 TCP printer > netviewdm1 [ACK] Seq=3 Ack=35534 Win=64296 Len=0 TSV=26412040 TSER=3842799519
52  0.000   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 1368]
53  0.000   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 2736]
54  0.000   1.1.1.1 2.2.2.2 TCP printer > netviewdm1 [ACK] Seq=3 Ack=38270 Win=64296 Len=0 TSV=26412040 TSER=3842799519
55  0.000   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 1368]
56  0.000   2.2.2.2 1.1.1.1 LPD LPD continuation [Number of bytes in flight: 2720]
57  0.000   1.1.1.1 2.2.2.2 TCP printer > netviewdm1 [ACK] Seq=3 Ack=40990 Win=64296 Len=0 TSV=26412040 TSER=3842799519

Even though the RWIN is 64296, the receiving side (Windows)keeps sending ACKs after only 2 packets, with a total bytes in flight of less than 4 KB. This happens for the duration of the transfer, which averages 26 KBps over a 12 Mbps MPLS port w/ 30-35 ms latency. TCP scaling is off.

I don't understand, can someone help me?

asked 15 Jun '12, 13:14

BlueArcher's gravatar image

BlueArcher
6●1●1●3
accept rate: 0%

One Answer:

0

This is normal behavior. The fact that there is not an ACK for every packet is because Delayed ACK has been enabled. RFC 1122 says that there SHOULD be an ACK for at least every second segment, and this is the most commonly seen behavior. However, the use of SHOULD means that an implementation can disregard that recommendation if desired, so you will sometimes see ACKs less often than every two segments.

There is no real performance problem with ACKing every two packets, rather than less often. If the data flow is bidirectional, the ACKs will piggyback on data packets. If the data flow is unidirectional, there is no data flowing in the direction of the ACK packets, so the empty ACK packets are not contending with data packets for use of the wire.

answered 15 Jun '12, 13:36

Jim%20Aragon's gravatar image

Jim Aragon
7.2k●7●33●118
accept rate: 24%

edited 15 Jun '12, 13:47

I guess I am confused because I expect the RWIN to determine when an ACK is sent? Without scaling, every 65 KB an ACK would be sent vs this case of every 4 KB. It seems like this is a very inefficient way to transmit data over higher latency because you are waiting on the ACKs before sending more data.

Or are you saying that the ACKs are sent independently of the incoming data stream? I.E. the sending machine is not sending 2 segments and then waiting for an ACK.

(15 Jun '12, 14:04) BlueArcher

To further my question, how can I determine why the transfer is only running at 26 KBps over what should be 8-12 Mbps of available bandwidth? The high ACK rate was my only lead :)

(15 Jun '12, 14:08) BlueArcher

RWIN does not determine when ACKs are sent. RWIN determines how much data can be unacknowledged at any given time. The receiver is sending ACKs every two packets, but the sender is not waiting for the ACKs before sending more data. The sender is sending continuously.

If the receiver waited until RWIN bytes were sent before responding with an ACK, then the sender would have to pause until the ACK was received. Because of the frequent ACKs, the sender never has to pause, because it is constantly informed that there is room in the receive buffer of the receiving system.

(15 Jun '12, 14:24) Jim Aragon

Thank you sir!

(15 Jun '12, 15:46) BlueArcher