4 ms·

This neglects the fact that IP imposes a fixed per-packet overhead. More packets means lower efficiency. Using larger packets reduces the overhead as a percen

This neglects the fact that IP imposes a fixed per-packet overhead. More packets means lower efficiency. Using larger packets reduces the overhead as a percentage of traffic, so is desirable regardless of the TCP window size. Higher efficiency means higher bandwidth, which means lower latency for small transfers. Waiting for two 10-byte packets yields latency equal to the higher of the two latencies. Waiting for one 20-byte packet is, on average, lower latency (because you take one sample instead of worst-of-two).

kazinator 9y ago
Of course, we want to be using the largest packets that the underlying network allows. My comment is about using larger packets specifically while relying on fragmentation to deliver them. Fragmentation re-introduces the overhead since fragments carry IP headers. If a protocol already segments data into datagrams and reassembles them into a stream, it derives no advantage from IP fragmentation. IP fragmentation basically provides the possibility of operating in the face of misconfiguration (hopefully temporarily), with reduced performance (better than no performance at all). (Of course I'm not saying that since TCP chops the data into pieces and has a sliding window that can scale, there is no downside to making the pieces small just for the heck of it, like 50 bytes of payload!)