[Tfug] Linux kernel tcp delay options 4e7uzube

[Bexley Hall]

Hi Adrian,

On 6/6/2013 3:24 PM, Adrian wrote:

>>> There are lots of threads about this and dev comments
>>> that Cyrus should do this from several years back... but it apparently
>>> didn;t get in (which really suprises me that no one has fixed this in the
>>> last 10 years since I last used Cyrus).
>>
>> Is there a counterargument as to why it "shouldn't"?  I.e., perhaps
>> <someone> intended it for use in a type of application where this
>> would be counterproductive?  Though one can argue for a configurable
>> option -- perhaps even "client/account specific"!
>
> I can't think of any of the top of my head. TCP ack delay/nagle is very useful
> for reducing packet load on very slow data streams (like typing or serial
> transfers) at the expense of latency. It waits for more data to try to send a
> single large packet instead of many small packets. On fast datastreams or
> large transfers it is irrelevant as the packet data is filled long before the
> timer expires.

Yes.  I try to design protocols that are *very* lightweight (in terms
of traffic costs) yet need timely delivery (e.g., I often write a
real-time network stack).  So, I usually omit that code from the
stack entirely (otherwise, it's effectively "dead code" and, thus, a
liability!)

> With IMAP, the server doing lots of small "OK" response packets in response to
> every client command request. If the kernel holds every "OK" data packet
> waiting for more to fill a packet, it can introduce a lot of latency.

I've never analyzed "typical" IMAP traffic -- *and* it's appearance to
the user -- to see what the consequences of going each way (wrt Nagle)
would be.  I was hoping someone (historically) might have justified
the use/disuse of TCP_NODELAY in those arguments.

[I admit that I can't see a reason NOT to use NODELAY, either!]

<shrug>

Another server choice?  Or, are you "8.5 months pregnant" with
Cyrus?  (Or, does it offer something that you can't easily get,
elsewhere??)

--don