Sliding window protocols (was Idle demon)

[Larry A. Shurr]

In article <2868 at wyse.wyse.com> bob at wyse.UUCP (Bob McGowen x4312 dept208) writes:
>In article <1990Aug23.143804.24954 at ux1.cso.uiuc.edu> peltz at cerl.uiuc.edu (Steve Peltz) writes:
>>In article <1990Aug23.051212.24281 at zorch.SF-Bay.ORG> xanthian at zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>>>                     ...  I'd be a little huffy about having my kermit
>>>session killed in mid-download because I hadn't sent a keystroke in a

>>But, but, kermit (and all other error-correcting download protocols) send in
>>keystrokes all the time!

>If my understanding of "sliding window" protocols is correct, it IS possible
>for a download to never (or seldom) have a response.  The basic idea is that
>if an error has not occured, why spend the overhead to ack the packet.  So
>a stream of packets flows until an error.  If no problems, then no input, so
>line is idle and off we go in the middle of the transfer somewhere.

Welllll... not quite.  We do get to avoid spending the overhead to ack 
some -- hopefully a substantial portion of -- the packets, but the basic
idea is that the communications medium has an unpredictable, but potentially
long, propogation delay.  If your connection is via a satellite link, the
round trip from ground station to satellite to ground station and back
again is a round trip of nearly 100,000 miles.  In such situations, a
protocol which sends a packet and awaits an ACK/NACK will spend of good
bit of time idle between packets while the packet travels to the far end
and an ACK/NACK travels back  -- over a sat link, we talking about 1/2
second or longer between packets.  A packet switching network offers
the potential for similar delays.

With sliding windows, we don't wait for an acknowledgement for each packet.
Instead, we format each packet with headers which contain (among other
things) sequence numbers and fields for things like last valid packet number
received and status codes.  Now we keep sending packets without waiting,
up until we get a certain number of packets ahead of the last valid packet
number the remote host told us it has received.  Meanwhile the remote host
can be sending us packets containing anything it wants to send to us -- if
the protocol is designed to be bidirectional -- with the last valid packet
number updated appropriately.  If the remote host has nothing to send us,
or if the protocol isn't bidirectional, it can send us occasional status
packets to let us know what the last valid packet received was.  If a
packet arrives garbled, it can send us a status packet to let us know
and we can retransmit.  Of course, we also send updated last-packet-
received data, as well.  The number of packets we can transmit "ahead"
before we need an acknowledgement is called the window size, and every
time the remote host updates the last valid packet number we can send
more packets, thus the window "slides" forward and hence the name of
"sliding window protocol."

Of course there are many more details required to make a sliding window
protocol complete, that I didn't go into (this is the net, not a textbook).

One result is, that though there may be relatively little activity
associated with ACK/NACK's, it isn't eliminated entirely.  Presumably --
hopefully -- this would be sufficient to keep the idle deamon happy.

regards, Larry
-- 
Larry A. Shurr (cbnmva!las at att.ATT.COM or att!cbnmva!las)
The end of the world has been delayed due to a shortage of trumpet players.
(The above reflects my opinions, not those of AGS or AT&T, but you knew that.)