It is somewhat long but interesting .
All this nagle stuff has to to with end systems .
At the bottom of this email is nagle himself about
some tcp end station problems .....
flem
Newsgroups: poster
Subject: Re: Nagle algo. in Unix-TCP
Summary:
Expires:
References: <[EMAIL PROTECTED]>
Sender:
Reply-To: [EMAIL PROTECTED] (John Nagle)
Followup-To:
Distribution:
Keywords:
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(Richard Wolsoi) writes:
>
>My question regards the Nagle algorithms for
>small-packet avoidance, which have been implemented
in >the various flavors of UNIX now running around.
>
>A colleague of mine has written an RPC mechanism to
>run over TCP sockets on UNIX systems and we are
seeing >some very strange performance numbers for
certain >kinds of messaging. An ethernet trace and
several >minutes with the source code convinced us
that TCP was >delaying both data sends and
acknowledgements in an >effort to avoid silly windows.
>
>Part of the$problem comes from the RPC implementation
>which makes two send system calls for each request or
>reply (no flames please we are dealing with some
>serious history here) in that UNIX sends out the
>information in two different packets. The first goes
>out immediately (as the Nagle algorithm prescribes)
>while the second is delayed until the first is acked.
>Unfortunately, the ack is delayed as part of the
>receiver's half of the bargain and so we were seeing
a >whopping 10 packets per second. Now for my
question. >Is there any way to defeat the Nagle
algorithms under
>standard implementations? I seem to recall that the
>Tahoe (or is it Tajo) release of 4.3 had such a
defeat >wlich was put in for X-11, but we don't have
systems >which are quite so modern. Specifically, we
are using >SunOS 3.4, Ultrix 3.0 and UTS
something-or-other with >WIN-UTS.
What seems to have happened here is that several
mechanisms in TCP are interacting with a strange kind
of application to produce poor performance.
First, "silly window syndrome" is irrelevant here.
Silly window syndrome occurs when the window is full
most of the time, but here, we have the tinygram
problem, which occurs when the window is empty most
of the time. It's a common misconception that the two
problems are the same. They are not. They are
handled by separate code in the UNIX implementation,
incidentally.
The problem here seems to be that tinygram elimination
and delayed ACKs, both performance improvements in
TCP, are interacting with this new RPC application.
Delayed ACKs are something that first appeared in
TOPS-20, which is a system that runs TELNET in remote
echo most of the time. (So do most UNIX TELNET
implementations, not that they really need to.) The
idea there was
to make the bet that when a packet came in on a TCP
connection, the application would probably have
something to reply with shortly.
Therefore, TCP was gimmicked to delay sending an ACK
for about 100ms, in hopes that the application layer
would send something back and that this would be
piggybacked on the application layer's reply. Note
that this is an assumption built into the transport
layer about the behavior of the application layer.
Delayed ACKs will cut traffic in half on slow TELNET
operations, and they don't bother FTP. So they seemed
like a big win at the time, when there were few TCP
applications beyond TELNET, FTP, and mail.
TCP with delayed ACKs and tinygram elimination sending
will support the following kinds of applications well.
1) Big data pipes, like FTP.
2) TELNET-type interaction.
3) Request-reply type transaction protocols.
But here, we have someone who is trying something that
has the property that it does
SEND
SEND
wait for reply.
This doesn't take turns the way a typical transaction
protocol does, so the guesses built into TCP are bad
for this situation. This, this sort of use creates
problems. Of course, as the writer points out, doing
multiple tiny sends is a bad thing on general
principles. It's always better to do one big send
than lots of little ones, given that you're not
waiting
anxiously for an answer. Sending a 1-byte message
takes 41 bytes across the net, plus any overhead at
the link layer. It's that 40:1 expansion that led to
the need for tinygram elimination. Presumably this
RPC
package is sending a bit more data at a time, so the
expansion factor may be smaller, but it may still be
significant.
One solution might be to make whatever RPC package
he's using go through the standard UNIX I/O library
(stdio) and flush the output stream just before
reading from the input stream or before reading from
another
source. This would improve the buffering situation.
This is really a buffering problem, after all.
TCP is trying to protect the network from dumb
applications. We fixed it back in 1985 so that when
the application is dumb, the application suffers,
not the network. We have here a dumb application
layer.
John Nagle
--- Marty Adkins <[EMAIL PROTECTED]> wrote:
> Here's an old one I saved in my archives but you
> could probably search
> for it on nexial as well. The main situation it
> addresses is the use
> of a router as a commserver, with a dumb terminal
> attached or dialed up.
>
> Marty Adkins Email:
> [EMAIL PROTECTED]
> Mentor Technologies Phone: 410-280-8840
> x3006
> 275 West Street, Plaza 70 WWW:
> http://www.mentortech.com
> Annapolis, MD 21401 Cisco CCIE #1289
> > Received: from spot.Colorado.EDU
> ([EMAIL PROTECTED] [128.138.129.2]) by
> ccci.com (8.8.5/8.7.3) with ESMTP id TAA18611; Wed,
> 26 Feb 1997 19:27:06 -0500 (EST)
> > Received: (from daemon@localhost)
> > by spot.Colorado.EDU
> (8.8.5/8.8.4/CNS-4.1p)
> > id QAA17553 for cisco-ml1; Wed, 26 Feb 1997
> 16:19:40 -0700 (MST)
> > Received: from puli.cisco.com (puli.cisco.com
> [171.69.1.174])
> > by spot.Colorado.EDU
> (8.8.5/8.8.4/CNS-4.1p) with SMTP
> > id QAA17120 for <[EMAIL PROTECTED]>; Wed,
> 26 Feb 1997 16:19:19 -0700 (MST)
> > Received: (billw@localhost) by puli.cisco.com
> (8.6.12/8.6.5) id PAA13961; Wed, 26 Feb 1997
> 15:16:43 -0800
> > Date: Wed, 26 Feb 97 15:16:43 PST
> > From: William "Chops" Westfield <[EMAIL PROTECTED]>
> > To: Crocker Sean SSgt 786CS/SCBM
> <[EMAIL PROTECTED]>
> > Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
> > "'KRATOCHVIL.KEITH'"
> <[EMAIL PROTECTED]>,
> > "'[EMAIL PROTECTED]'"
> <[EMAIL PROTECTED]>,
> > "'[EMAIL PROTECTED]'"
> <[EMAIL PROTECTED]>
> > Subject: RE: Nagle question
> > In-Reply-To: Your message of Wed, 26 Feb 1997
> 21:27:23 +0100
> > Message-ID:
> <[EMAIL PROTECTED]>
> > Content-Type: text
> >
> > Actually Paul did, just in a truncated manner.
> What he is saying is
> > that enabling the Nagle algorithm on the
> router will affect the traffic
> > that is originated directly FROM the router or
> is addressed directly TO
> > the router (hence "terminated").
> >
> > So your guess is correct, it's the
> characteristics for the router as a
> > host or end-station. Service nagle is
> especially good to enable if you
> > are, say, telnetting to the router via a 56
> kbps link or slower.
> >
> > I asked the same question last year, answered
> by Paul. I had to reread
> > the docs for a bit before the filament would
> start glowing :-).
> >
> > It's worth pointing out while we're talking about
> this, that as far as I can
> > tell, the "slow start congestion avoidance"
> algorithms mandated by various
> > sources pretty much devolve to the Nagle algorithm
> for connections with
> > non-continuous traffic (ie always doing "slow
> start" == "Nagle algorithm")
> >
> > I thought that was pretty neat when I realized it,
> but it also means that
> > a slow-start tcp might be subject to some of the
> weird interactions that
> > cause the Nagle algorithm to be off by default in
> a cisco...
> >
> > BillW
> > cisco
> >
> >
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
