Service Nagle

Unanswered Question
Jun 14th, 2008

Hi:

Nagle's algorithim is used for TCP-based applications to avoid send-side Silly Window Syndrome.

As far as Cisco router management is concerned, the service is used to optimize the Telnet or SSH session to the router by buffering the administrator's keystrokes and only sending a packet when a "sufficient" number of bytes are placed in the TCP segment. This avoids a situation in which each keystroke generates a TCP segment, which will generate 40 bytes of overhead for each character entered.

The purpose of enabling the Nagle service is to facilitate a remote management Telnet/SSH connection to a router in the event that the network is experiencing an inordinate amount of congestion or the router's CPU is bogged down as a result of a DOS attack.

OK, so what the heck is my question, right? Here goes...

If the Nagle service is meant to optimize the send-side/client connection for a TCP-based application, like Telnet or SSH, what does enabling Nagle on a router/switch do? Isn't the router or switch acting as the "server"/receiver in the session? Shouldn't the Nagle service be enabled on the administrator's computer or whatever device is being used as the "client"?

Any thoughts....?

Thanks

V

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Joseph W. Doherty Sat, 06/14/2008 - 20:04

Victor, my understanding of using the Nagle algorithm it's relevant to the local TCP stack only. If true, enabling Nagle on a router/switch should activate it against all outbound TCP packets sourced by the router/switch (unless overridden by the TCP application - assuming the router/switch TCP application can do the equivalent of TCP_NODELAY).

Richard Burts Sun, 06/15/2008 - 04:07

Victor

I am not sure what is the source of the information in the beginning of your post and so can not check for context. But I do not see anything in this:

"Nagle's algorithim is used for TCP-based applications to avoid send-side Silly Window Syndrome.

As far as Cisco router management is concerned, the service is used to optimize the Telnet or SSH session to the router by buffering the administrator's keystrokes and only sending a packet when a "sufficient" number of bytes are placed in the TCP segment. This avoids a situation in which each keystroke generates a TCP segment, which will generate 40 bytes of overhead for each character entered.

The purpose of enabling the Nagle service is to facilitate a remote management Telnet/SSH connection to a router in the event that the network is experiencing an inordinate amount of congestion or the router's CPU is bogged down as a result of a DOS attack."

that says it is client side. It talks about send side but I do not believe that it is the same as client side. It is my understanding that Nagle applies to both client and server connections and influences outbound transmissions for both.

HTH

Rick

lamav Sun, 06/15/2008 - 04:24

Joseph:

I hear what you're saying, but, as far as telnet and SSH, isn't the challenge really on the send-side, meaning from the administrator's perspective as he/she sends keystrokes to a router/switch? Check out this quote and link...

Rick:

Check out the link I am sending you. I will quote a bit of it...

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html

"Nagle's document specified a means of dealing with what he called the small packet problem, created when an application generates data one byte at a time, causing the network to be overloaded with packets (a situation often referred to as send-side silly window syndrome). A single character - one byte of data - originating from a keyboard could result in the transmission of a 41 byte packet consisting of one byte of useful information and 40 bytes of header data. This situation translates into 4000% overhead..."

Now, it is true that Nagle's algorithm is used for other TCP-based applications, not just telnet or SSH, of course. However, it's remote management that the Cisco service is trying to address. Given that, isn't the challenge on the send side, not the receive side (router side), ie keystrokes generated by the administrator...?

[EDIT] The only situation I can think of where enabling the Nagle service on a router or switch is useful is in the event that the device is being used as a jumpbox, ie, you Telnet or SSH from a router. [EDIT]

HTH

Victor

Joseph W. Doherty Sun, 06/15/2008 - 04:58

Yes, Nagle addresses the send side of TCP. Beyond the obvious issue of using a router/switch as, for instance, a telnet client, what happens when a router/switch echoes what you're typing to it in a telnet session. Suppose you disable Nagle on your client, i.e. every keystroke is sent as an IP packet. Without Nagle, the router/switch will also send an IP packet for every echoed character. With Nagle, it could accumulate several echoed characters into one packet. Again, Nagle is local to the host's TCP stack, it doesn't depend on the far side to also have it enabled.

As to why it's off by default on Cisco routers/switches, that could be because Cisco may have thought considering normal usage, there wasn't much need for it and having it off also avoids the problem of Nagle and delayed ACKs. Also, routers/switches are intended for that role, not TCP hosts, which also might be why on many routers other IP TCP commands, like selective-ack and path-mtu-discover are also disabled; or why ip tcp window-size default is only 4K.

lamav Sun, 06/15/2008 - 05:21

Good morning, Joseph:

Happy Father's Day, if it applies to you. :-)

I am in total agreement and already fully understand this part of what you say:

"Suppose you disable Nagle on your client, i.e. every keystroke is sent as an IP packet. Without Nagle, the router/switch will also send an IP packet for every echoed character. With Nagle, it could accumulate several echoed characters into one packet. Again, Nagle is local to the host's TCP stack, it doesn't depend on the far side to also have it enabled."

I know why the Nagle algorithm is used on the send-side/client. In fact, my initial post gives an explanatory narrative to the reader.

My question is with regard to the receive-side enabling of the service, as we do on a router or switch.

So, the question is "Why enable Nagle on the router or switch, which are acting as the RECEIVERS of telnet/SSH sessions from a client, when Nagle is meant to address SEND-SIDE data flow?"

[EDIT] Stated differently, how does the behavior of the router/switch change with regard to sending data and acknowledgements is concerned with Nagle enabled on them? [EDIT]

As far as asking why Nagle is disabled by default, I never did. Im not sure what part of my post you interpreted as me asking that question. Anyway, I do agree with you on that point, too. :-)

Thanks

Victor

Pravin Phadte Sun, 06/15/2008 - 05:58

Hi,

The link provided by joseph has some good info.

The Nagle congestion-control algorithm is something that is turn on to improve the performance of their Telnet sessions to and from the router. When using a standard TCP implementation to send keystrokes between machines, TCP tends to send one packet for each keystroke typed. On larger networks, many small packets use up bandwidth and contribute to congestion.

Without service nagle on a Cisco router, each character in a Telnet session is a separate CPU interrupt. Hence, a command such as show tech will force a large number of CPU interrupts, impacting the performance of the router. From a Cisco point of view, the Nagle service not only helps to optimize the Telnet session but also lessens the load on the router.

lamav Sun, 06/15/2008 - 06:15

Hi, Pravin:

Two things:

1.) I provided the link, not Joseph. I did it to answer Rick's concern...

2.) When you say "Without service nagle on a Cisco router, each character in a Telnet session is a separate CPU interrupt."

Can you explain that further? Because that is exactly my question. How does the router's behavior change when Nagle is enabled? Yes, each packet received by the router will require a CPU interrupt to process it, so you want the sender to send one big TCP segment with many bytes of data, instead of many segments with little data in each. Understood. But accumulating data in bigger segments is a function of Nagle on the send/client side.

Victor

Pravin Phadte Sun, 06/15/2008 - 10:31

Nagle talks about two concepts.

1. Congestion collapse

2. The small-packet problem

Congestion collapse: In a datagram network when the end to end transmutation the gets congested the round trip increases (ms). This is a normal behavior in the networks as load increases we see the ms increasing. In this kind of network it's sure that the datagram will not be acknowledged and will be dropped in end increasing the round trip (ms), increasing the buffers on the network and degrading the network.

This causes the round trip time to be at its max. Packets are been send several time which are not acknowledged eventually some packets reaching at the end.

The small-packet problem

When TCP is used for the transmission of single-character messages originating at a keyboard, the typical result is that 41 byte packets (one byte of data, 40 bytes of header) are transmitted for each byte of useful data. This 4000% overhead is annoying but tolerable on lightly loaded networks. On heavily loaded networks, however, the congestion resulting from this overhead can result in lost datagram's and retransmissions, as well as excessive propagation time caused by congestion in switching nodes and gateways. In practice, throughput may drop so low that TCP connections are aborted.

With the Nagle Algorithm, a TCP session works as follows. Each TCP connection can have only one outstanding (in other words, unacknowledged) segment. While waiting for the acknowledgment (ACK), additional data is accumulated, and this data is sent as one segment when the ACK arrives. Instead of sending a single character at a time, the TCP session tries to accumulate characters into a larger segment and send them after an ACK for the previous segment is received. The rate at which data is sent depends on the rate at which ACKs are received for the previous segments. This self-clocking mechanism enables a TCP session to send fewer segments on a slower or a congested link when compared to a faster, uncongested link.

What causes the CPU interrupt, Data is been transfer from the router to the telnet session causes the interrupts. Each character in a telnet session which is not buffered until the Acknowledgement (ACK) is received will eventually increase the CPU interrupts. This would be mostly noticed in a high link utilization and many telnet sessions to the router.

This is what I understood after reading the RFC896.

I guess i am clear and what everyone knows already

Accumulating data in bigger segments is a function on the send/Client side.

Yes it is and its same counts when it a connection to the router. It's a two way communication and both will send and receive data. Show tcp Vty will provide you with the output.

Since the question now arise what if the send /client does not have any service nagle enabled ?

A document from Microsoft which says that the service nagle can be disabled. Also it has some telnet output server/client.

http://msdn.microsoft.com/en-us/library/ms883043.aspx

I apologize to you for relating the link to Joseph.

Joseph W. Doherty Sun, 06/15/2008 - 09:38

So, the question is "Why enable Nagle on the router or switch, which are acting as the RECEIVERS of telnet/SSH sessions from a client, when Nagle is meant to address SEND-SIDE data flow?"

Correct, Nagle is applied to sending TCP packets. However, since a receiving host could send response packets back to the sending host, it could have an impact on that traffic. That's why my example even noted your sending host could have Nagle off but how a router/switch would physical echo telnet keystroke packets (as the receiver) could be impacted by whether Nagle is enabled or not on the router/switch. Again, this is in addition to its possible impact to the router/switch being for example a telnet client. In other words, Nagle doesn't know or care about sender or receiver, only whether it possibly delays outbound TCP data until the ACK is received from the prior sent packet.

lamav Sun, 06/15/2008 - 15:23

Pravin/Joseph:

Thank you so much for your time and effort. This is one of those things that I have to continue thinking about on my own until I make sense out of it in my head.

You have both contributed greatly to this effort.

Victor

Actions

This Discussion