Subject: Re: internet draft on suggested mod to the Nagle algorithm

From: David Borman <[email-masked]>
Date: Fri, 5 Feb 1999 11:06:35 -0600 (CST)

> Date: Thu, 04 Feb 1999 11:07:01 -0800
> From: "Eric A. Hall" <[email-masked]>
> Subject: Re: internet draft on suggested mod to the Nagle algorithm
>
> > whereas the current Nagle code would produce:
> > 
> >         1st write:      send 1460 bytes  (defer 40 bytes)
> >         2nd write:      send 40 + 1420 = 1460 bytes (defer 80 bytes)
> >         3rd write:      send 80 + 1380 = 1460 bytes  (defer 120 bytes)
> >                         (wait for ACK or timeout)
> >                         send 120 bytes
> > 
> > and the proposed Nagle (and the current BSD/OS) would produce:
> > 
> >         1st write:      send 1460 bytes
> >                         send 40 bytes
> >         2nd write:      send 1460 bytes (defer 40 bytes)
> >         3rd write       send 40 + 1420 = 1460 bytes (defer 80 bytes)
> >                         (wait for ACK or timeout)
> >                         send 80 bytes
>
> This is at least one extra send operation, which can't be a good thing,
> particularly when the network is over-utilized (or near to it) already.
> While this isn't as bad as Rick's example (1461-byte writes), it is
> still bad utilization. (I'd hate to own the network that did both.)
>
> I'd say that based on this info, it is better to just disable Nagle if
> your application is going to be writing small (1.5 segments) chunks, and
> leaving it enabled for applications that do large writes, rather than
> introducing lots of new frames to the network.

But turning off Nagle is even worse.  You then get:
	1st write:	send 1460 bytes
			send 40 bytes
	2nd write:	send 1460 bytes
			send 40 bytes
	3rd write:	send 1460 bytes
			send 40 bytes

Also, I might not have said it, but this example was to show
3 separate transaction requests, not 1 transaction done with
3 writes.  If it was one request, it should really be done with
a single 4500 byte write, yeilding:

	4500 write:	send 1460 bytes
			send 1460 bytes
			send 1460 bytes
			(wait for ACK or timeout)
			send 120 bytes
the difference being that with the modified Nagle algorithm, the
wait for ACK or timeout would be skipped.

		-David Borman, [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 05 Feb 1999 10:08:03 -0800

> a single 4500 byte write, yeilding:

You're not showing any response activity so it's hard to guess what's
really going on.

If the sender is actually waiting for a response from the far-end after
writing each block of 1500 bytes, then disabling Nagle on the sender
would be the most efficient thing:

          Response

          Response
etc.

If the client is writing 3 blocks of 1500 bytes because that's how it
was written, then it should be deleted. :)   Unfortunately, since you're
not showing any responses, we have to assume that's what is happening.
In this case, the app should at least know that it is doing multiple
writes for a single operation, since it's not waiting for a response.

>         3rd write:      send 1460 bytes

Six sends when writing 3 blocks >1 segment.

> > >                     (wait for ACK or timeout)

Five sends. Better.

> > >                     (wait for ACK or timeout)

Four sends. Best.

If the app knows that it's going to send >2 segments in an operation, it
should use Nagle. If the app knows that it's going to send <2 segments
in a single operation, it should disable Nagle.

Modifying Nagle doesn't benefit either of those scenarios. It might
benefit a scenario where the client doesn't know what its doing.

ps--I'm at the end of what appears to be a very long list. I don't see
my posts until several hours after sending them. This makes reading and
participating somewhat difficult. Apologies if out-of-order.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com