Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!CCV.BBN.COM!brescia
From: brescia@CCV.BBN.COM (Mike Brescia)
Newsgroups: comp.protocols.tcp-ip
Subject: What is a window (was: A New TCP Retransmission Algorithm)
Message-ID: <8704210324.AA09619@ucbvax.Berkeley.EDU>
Date: Mon, 20-Apr-87 21:22:47 EST
Article-I.D.: ucbvax.8704210324.AA09619
Posted: Mon Apr 20 21:22:47 1987
Date-Received: Wed, 22-Apr-87 00:03:39 EST
References: <12296103835.19.KLH@SRI-NIC.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 29


     The ITS TCP implementation, at least, often does reduce the window by
     more than the amount of bytes acknowledged; what it would really like
     to use is a packet count, rather than a byte count.

A little history comes to mind.  In early ARPANET days, NCP was the precursor
to TCP.  Each stream had what was termed an 'allocation', which was the set of
numbers used to enforce flow control.  A sender could not send more than the
allocation given it by the receiver.  "More what?", you ask.  Well, there were
2 numbers in the allocation, which had to be accounted each time you sent a
message.  There was the 'message count' and also the 'byte count'. (Maybe it
was a bit count, since NCP allowed arbitrary byte sizes.)  If a sender was
working with an allocation of 8 messages and 1000 bytes, it could send one 1000
byte message, or 8 one byte messages, or whatever else caused either the byte
or the message allocation to be used up.  The receiver, when buffers were
freed, would be expected to send back a new allocate, with incremental updates
to the numbers the sender was maintaining.  Hopefully, the receiver would hold
off a little while, and avoid sending an allocate for each message
received.  (Sounds like 'silly window syndrome'.)

In order to fix the problem of hung connections when allocate messages got
lost, there was a spec for a method to reset the allocations, but I don't
recall seeing it widely implemented.  The arpanet did not drop enough messages
to convince many people to put the work into their hosts.  (ARPANET still does
not drop many messages.)

"Those who do not learn from history, looostl.UU
21:0 G