Re: [9fans] Nagle algorithm

["Sean M. Doran" <smd@cesium.clock.org>]

Andrew Simmons <andrew@mbmnz.co.nz> writes:

> What's wrong with Nagle?

What's RIGHT with Nagle:

       - bigger packets, on average
         - more bytes/packet -> less wasted header overhead
         - more bytes/packet -> fewer packets per bit per second

         both of these are very good for the network,
         since the cost of modern day high-speed
         networking is driven by header processing and is
         pps limited, while the cost of practical
         networking (last mile, and in places like
         New Zealand) is driven by total amount of
         traffic, and you don't want to pay for headers
         rather than data useful to the end user

       - Nagle does not inflate the congestion window or
         delay during a bulk transfer: if there are lots
         of bytes being transmitted, the Nagle delay
         doesn't happen

Moving Nagle into the application, as is suggested later
in the thread, is awkward: it needs to know the segment
size, which is affected by the receiver's advertised MSS,
the local MTU and the path MTU.  The latter two of these can
change during the lifetime of a TCP conversation.

The usual complaint about Nagle is that it punishes
applications which deliberately exchange short packets.
However, it is almost always possible to turn Nagle off on
a per-connection basis, for those (relatively rare)
applications which are upset by the increased transmit delay.

The problem with simply "eliminating" Nagle is that a
bulk-transfer application which DELIBERATELY schedules
lots of small writes that do not queue at the TCP send
level, will generate lots of small packets.  This causes
the TCP congestion window to inflate faster, and gives such
applications an unfair advantage over applications which
make larger writes that queue at the TCP send level, where
they can be coalesced.   The inflated congestion window
means that when congestion does happen (TCP deliberately
provokes it), the small-write/small-segment application
will get a larger share of the bottleneck's bandwidth.
This is perverse behaviour, since the application in
question is a less efficient bandwidth consumer, since it
generates more header data per user datum.

The generation of large amounts of small packets should
always been seen as antisocial.

      Sean.