Thanks for the pointer, interesting idea. Some comments below.
> --- "Joseph Conlin" <JCONLIN@xxxx> wrote:
> I see in the archives and the code that I have looked at (2.4.22,
> 2.6.0-test8) that the Minshall algorithm is being used to reduce the
> effects of Nagle/delayed ACK interaction. I haven't seen any mention of
> the following solution, proposed as an IETF draft RFC by Joe Doupnik
> If anyone is interested, I have an Excel spreadsheet that shows some
> testing I did with FreeBSD using Nagle-off, Nagle-on, and Doupnik using
> HTTP requests. It shows that Doupnik gets the same packet-size
> efficiency as Nagle-on while getting better throughput than having
> Nagle-off. Let me know if you would like a copy.
Yes please, but only if you have some comparisons with Linux 2.4+ which
the Nagle+Minshall extensions, which should not have the perf problem reported
the draft (which measures Linux 2.2).
Reading through the draft, the tradeoff the new proposal makes is in allowing
control to the transmitter to send packets at it's (application's) whim, at the
of larger number of small packets in transit at any point in time within the
For example, as quoted within the draft:
"In an extreme case the application may perform
single octet writes in massive succession before reading a response.
If the network can drain data faster than the application can create
data (a classical queueing problem) then massive quantities of tiny
segments will appear on the network. That imposes a very heavy load
on both hosts and network communications"
The current Linux Nagle+Minshall combo can have at most one "small" unacked
in transit in the network at any given time, while in the new approach, if the
stack guesses application behavior incorrectly, it's possible that there could
numerous small packets flooding the network. (For example, think someone typing
in a ssh/telnet session).
In addition, more packets means potentially increased interrupt processing on
host (modulo napi or interrupt mitigation), thereby making me question the
to the transmitter.
And IIRC, the whole point of Nagle was to conserve network bandwidth by not
applications flood the network with small packets. If I read this draft
tries to get the tcp stack to guess application behavior to accomplish the same
but is liable to get it wrong.
I'd love to see any perf numbers you have with linux 2.4. The intent of
the Minshall extensions was to eliminate the kind of Nagle problems described
draft, and thus far, I haven't seen any reports of problems on linux-netdev
still being a good network citizen).
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search