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

Trying to understand Nagle

0

I've been going thru some information about Nagle and Delayed ACKs and looking at some trace files of my own to see the the concepts in play. Here's a partial of the trace I've been looking at. What I don't understand is how packet 345 is getting put on the wire.

Packet 344 went out because it is full MSS, but why did 345 go out before the ACK was received for 344? Doesn't that violate the Nagle buffering rule? Even if the PSH bit was set on packet 345 it shouldn't have gone out because there was unacknowledged traffic (344) on the wire unless the hold-down timer expired, right?

alt text

asked 26 Oct '13, 17:14

dsuida's gravatar image

dsuida
466710
accept rate: 0%


One Answer:

0

My guess is that the Nagle algorithm buffered more bytes than it cold fit into a single packet while waiting for the ACK that is coming in in packet 343, so it sends two packets (344 and 345). I base that assumption on the fact that the Size for packet 344 is 1500 according to your length column, so I guess that is the Ethernet payload size, and it is full.

answered 27 Oct '13, 02:18

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

  1. 341 and 342 are the 3-way handshake. 343 - the client send 390 with PSH bit set. Data goes right away as there are no unACK'd packets. 344 - Server sends data and piggy-backs ACK for 343. 345 - server sends another chunk of data with PSH set, but is not MSS size and with very little delay. Nagle should not let this go, because it's not full MSS, as the client has not ACK'd 344 yet, nor has the Nagle timer expired (guessing on that last statement).

Are you suggesting the Nagle timer has expired?

(27 Oct '13, 08:51) dsuida

Oh, I oversaw the PSH bit being mentioned - PSH bits force immediate sending, overruling Nagle buffering. It is usually set for the last packet of a transmission consisting of multiple packets, so that there is no artificial delay caused by the wait for additional data that will never happen.

(27 Oct '13, 11:13) Jasper ♦♦