On Wed, Nov 08, 2000 at 11:14:42PM +1100, Anthony Rumble wrote:
> Perhaps someone who knows exactly what "Nagle" is and does, could perhaps
> explain a little more in depth what it is and what it does, and why to the
> list, so that we could all know more about it.
An example shows it better than a description...
Without the Nagle Algorithm.
Consider a telnet session. You hit one key about every 1/10th of a second.
Telnet tries to send each character as you type it. TCP does the same.
This means that every 1/10th of a second you're sending a TCP packet
which contains around 40 bytes of header and 1 byte of data - or a
total of 410 bytes/second to send 10 characters/second.
With the Nagle Algorithm.
You still type one key every 1/10th of a second, and telnet still tries to
send each character as you type it.
For the first packet, TCP will send it as per normal. The difference is
that TCP will not send the next packet until the first has been acknowledge
by the remote host. Over a fast link, the delay for the ack might be a
few milliseconds, so the 2nd character (which get sent to TCP 100ms after
the first is sent) will be sent instantly, and nagle has no effect.
However, over a slower link the delay might be 450ms. This means that the
2nd through 6th characters will all be held at the TCP layer, and all
transmitted in one packet. Ditto for the 7th to 11th characters, etc.
The means that with a delay of 450ms, only 2-3 packets, or around 100
bytes/second (including header) will be sent - saving around 3/4 of the
traffic from the first example.
The advantage of Nagle is that it's self-paceing. If you're on a fast (and
thus most likely high-bandwidth) link you get instant transmission of
data, without worring about the bandwidth used. If you're over a slow
(and thus most likely low-bandwidth) link you get slower transmission, but
at a huge bandwidth saving! The slower the link, the less traffic you send.
Of course, like most things there's a few disadvantage - the one Howard
mentioned is one of the more common. Function keys and the like (including
arrows) are transmitted by sending an escape character, followed quickly by
another character. Over a fast link this will normally work fine (normally
- see below!) but over a slow link the second character will not be sent
until the first is ACKed, resulting in a delay which is often too great for
the remote system to detect it as a function combination.
Just to confuse matters further, there's another "feature" in TCP called
"delayed ACK". This is basically an attempt by a system to save traffic by
reducing the number of ACK packets it has to send (as you can ACK multiple
received packets with a single ACK).
Delayed ACK works by not ACKing a recevied packet immediately, but instead
waiting a short period - usually around 200ms - to see if there's any other
packets coming. If no other packets arrive in that time it will finally send
the ACK.
This saves on traffic, but can cause delays for the ACK if there's no
further packets.
The problems occur when you mix the Nagle stuff with the delayed ack stuff.
The soruce host will not send the 2nd packet until it gets a reply from the
destinstion to the first, but the destination will not send a reply for
200ms, which means the 2nd packet (the one containing the 2nd part of
the time-sensitive escape sequence!) will be delayed for 200ms, which
means it gets mis-interpreted by the destination.
The best fix I've seen for this is a for telnet to add some intelligence
about what to do when it gets an escape character - by waiting for a
fraction of a second and waiting for another character, and then sending
both at once this problem is overcome!
Clear as mud?
Scott.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
