Consider the use of TCP in a Telnet remote terminal client. How should the keyboard input be
buffered at the client? Investigate Nagle’s and Clark’s algorithms [Nagle 1984, Clark 1982] for
flow control and compare them with the simple algorithm described on page 103 when TCP is
used by
(a) a web server,
(b) a Telnet application,
(c) a remote graphical application with continuous mouse input.

What will be an ideal response?

The basic TCP buffering algorithm described on p. 105 is not very efficient for interactive input. Nagle’s
algorithm is designed to address this. It requires the sending machine to send any bytes found in the output
buffer, then wait for an acknowledgement. Whenever an acknowledgement is received, any additional
characters in the buffer are sent. The effects of this are:
a) For a web server: the server will normally write a whole page of HTML into the buffer in a single write.
When the write is completed, Nagle’s algorithm will send the data immediately, whereas the basic
algorithm would wait 0.5seconds. While the Nagle’s algorithm is waiting for an acknowledgement, the
server process can write additional data (e.g. image files) into the buffer. They will be sent as soon as
the acknowledgement is received.
b) For a remote shell (Telnet) application: the application will write individual key strokes into the buffer
(and in the normal case of full duplex terminal interaction they are echoed by the remote host to the
Telnet client for display). With the basic algorithm, full duplex operation would result in a delay of 0.5
seconds before any of the characters typed are displayed on the screen. With Nagle’s algorithm, the first
character typed is sent immediately and the remote host echoes it with an acknowledgement piggy
backed in the same packet. The acknowledgement triggers the sending of any further characters that have
been typed in the intervening period. So if the remote host responds sufficiently rapidly, the display of
typed characters appears to be instantaneous. But note that a badly-written remote application that reads
data from the TCP buffer one character at a time can still cause problems - each read will result in an
acknowledgement indicating that one further character should be sent - resulting in the transmission of
an entire IP frame for each character. Clarke [1982] called this the silly window syndrome. His solution
is to defer the sending of acknowledgements until there is a substantial amount of free space available.
c) For a continuous mouse input (e.g. sending mouse positions to an X-Windows application running on a
compute server): this is a difficult form of input to handle remotely. The problem is that the user should
see a smooth feedbvack of the path traced by the mouse, with minimal lag. Neither the basic TCP
algorithm nor Nagle’s nor Clarke’s algorithm achieves this very well. A version of the basic algorithm
with a short timeout (0.1seconds) is the best that can be done, and this is effective when the network is
lightly loaded and has low end-to-end latency - conditions that can be guaranteed only on local networks
with controlled loads.