I think you are giving the documentation writer too much credit, Chuck. My
guess is the writer read up on Nagle in "TCP/IP Illustrated" by Stevens,
and paraphrased what's in that book, even though the Nagle discussion is
relevant to end stations, not relays.
Or maybe the writer read up on Nagle at Microsoft's TechNet. Search for
Nagle in this article, which also seems to be based on Stevens, and is
relevant to Windows NT:
http://www.microsoft.com/TechNet/winnt/reskit/sur_tcp2.asp
Consider the labor shortage. &;-) Can't you imagine a server documentation
writer getting a job at Cisco despite a lack of understanding of how a
router differs from a server? I can.
The Cisco information is in the document that also describes configuring a
router's name, customizing the prompt, handling idle Telnet connections,
and other "basic tasks that you can perform to manage the general system
features of the Cisco IOS software � those features that are generally not
specific to a particular protocol." I don't think it has much to do with a
router's two fundamental tasks of forwarding packets and learning paths. I
think it has to do with making your Telnet session to a router appear faster.
Priscilla
At 07:11 PM 12/17/00, Chuck Larrieu wrote:
>I don't know. This looks like another one of those things where we'd have to
>find the people at Cisco who actually introduced this service to the IOS to
>explain why it is there and what function it performs. The 12.1 command
>reference most certainly indicates that the router is acting on behalf of
>end stations. The fact that it is stated that one should now enable the
>algorithm if XRemote and XWindows is in operation on the network indicates
>to me, at least, that pass through traffic effected.
>
>-------------
>When using a standard TCP implementation to send keystrokes between
>machines, TCP tends to send one packet for each keystroke typed, which can
>use up bandwidth and contribute to congestion on larger networks.
>
>John Nagle's algorithm (RFC 896) helps alleviate the small-packet problem in
>TCP. The first character typed after connection establishment is sent in a
>single packet, but TCP holds any additional characters typed until the
>receiver acknowledges the previous packet. Then the second, larger packet is
>sent, and additional typed characters are saved until the acknowledgment
>comes back. The effect is to accumulate characters into larger chunks, and
>pace them out to the network at a rate matching the round-trip time of the
>given connection. This method is usually good for all TCP-based traffic.
>However, do not enable the Nagle slow packet avoidance algorithm if you have
>XRemote users on X Window sessions.
>-------------
>
>Does one use X-windows sessions to connect to the router? Sorry, my Unix is
>poor. If I am an X user, and I open a telnet session to the router from my X
>desktop, is this what we are talking about?
>
>Chuck
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Sunday, December 17, 2000 6:14 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Nagle's algorithm
>
>Agreed - I abbreviated my response a bit more than I should have. I was
>thinking along the lines that a gateway/IMP (always makes me think of
>Maxwell's demon)/router at the time of RFC 896 wouldn't be likely to be
>looking into the TCP layer and acting on it.
>Also, the IOS command reference comments "This method is usually a good
>[sic] for all TCP-based traffic. However, do not use the service nagle
>command if you have XRemote users on X Window sessions."
>
>JMcL
>---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 18/12/2000
>01:08 pm ---------------------------
>
>
>Priscilla Oppenheimer <[EMAIL PROTECTED]> on 18/12/2000 11:00:33 am
>
>
>To: [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>cc:
>
>
>Subject: RE: Nagle's algorithm
>
>
>At 10:15 AM 12/18/00, [EMAIL PROTECTED] wrote:
> >Flem, thanks for the confirmation.
> >Chuck, given the age of the RFC, I seriously doubt that Nagle intended the
> >router to do anything too complicated.
>
>Routers were always part of the TCP/IP architecture, even if they were
>called gateways or Interface Message Processors? But I agree with your main
>point that routers generally don't play a role with the Nagle algorithm,
>unless the router is one of the TCP endpoints.
>
>
> >The Cisco command reference I suspect was written by somebody who didn't
> >delve too deeply into what the command does. I guess I would have
>expected
> >some note pointing out that it only applies to sessions terminating at the
> >router,
>
>That's for sure.
>
> >if that is the case, as most IOS commands affect through traffic
> >(OK, most commands don't deal with the transport layer...)
> >And how many people use XWindows to connect to a router?
>
>Well don't forget Telnet runs on top of TCP too.
>
>Priscilla
>
>
> >JMcL
> >
> >
> >
> >"Chuck Larrieu" <[EMAIL PROTECTED]>@groupstudy.com on 15/12/2000
>05:29:54
> >pm
> >
> >Please respond to "Chuck Larrieu" <[EMAIL PROTECTED]>
> >
> >Sent by: [EMAIL PROTECTED]
> >
> >
> >
> >To: <[EMAIL PROTECTED]>
> > <[EMAIL PROTECTED]>
> >cc:
> >
> >
> >Subject: RE: Nagle's algorithm
> >
> >
> >Jen, I see your point. I just finished a quick read of RFC 896 (Congestion
> >Control in IP/TCP Internetworks)
> >
> >Recognizing that TCP is responsible for end to end reliable data
> >communications, it would seem reasonable to think that the Nagle service
> >should not effect transit traffic.
> >
> >On the other hand, the RFC does mention issues on slow links, and does
> >mention gateways ( routers ) in a couple of places in a way that imply
>that
> >the edge router is the place where the mechanism is best put to use. The
> >Cisco references I browsed appear to quote verbatim from the RFC, talking
> >about the single character of data in a TCP packet, and the overhead
> >involved. The further description of the service Nagle implies ( but does
> >not state - in my reading, anyway ) that a router running service Nagle
> >acts
> >as a host proxy, almost in a stateful manner, examining the behaviour of
> >the
> >traffic, and acting accordingly.
> >
> >I'm too sleepy to attempt to get through RFC 2001 this evening. The intro
> >to
> >that one talks about modern TCP implementations, saying to me, anyway,
>that
> >maybe congestion control mechanisms such as Nagle are now built into end
> >station stacks.
> >
> >What were your thoughts from your reading?
> >
> >Chuck
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
>Of
> >[EMAIL PROTECTED]
> >Sent: Thursday, December 14, 2000 6:34 PM
> >To: [EMAIL PROTECTED]
> >Subject: Nagle's algorithm
> >
> >Does setting 'service nagle' on a router have any effect on TCP sessions
> >transitting the router, or does it only have an effect on sessions that
> >terminate at the router?
> >Various bits on CCO vaguely imply that it affects through traffic, but
> >having read up on how Nagle's algorithm works, I can't see how it could -
> >as it works at the TCP layer, I think it should only affect sessions where
> >the router is a session endpoint.
> >
> >Can anyone confirm this, or am I missing something?
> >
> >Ta,
> >JMcL
________________________
Priscilla Oppenheimer
http://www.priscilla.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
