brescia@CCV.BBN.COM (Mike Brescia) (04/21/87)
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 GCERF@A.ISI.EDU (04/21/87)
Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level. It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint
CERF@A.ISI.EDU.UUCP (04/21/87)
Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint