[ih] ARPAnet Type 3 packets (datagrams)

[Vint Cerf]

the confusion appears to revolve around the term "message"

I am pretty sure that "message" meant an object up to about 8000 bits
from a HOST. The HOST-IMP protocol (BBN 1822) allowed one of
these at a time per logical LINK. Link construct was part of the HOST- 
IMP
protocol. The IMPs broke messages into packets  of up to 1008 bits each.

You are correct, Noel, that "get a block" "got a block" was introduced
after Bob Kahn and I demonstrated reassembly lockup (by sending
multiple messages, one each on a distinct logical link).

Single packet MESSAGES served as their own reservation requests
and were retransmitted from the source IMP if the implicit "get a  
block" failed.

at least that's what my aging memory tells me. I think I wrote a  
detailed
RFC about how the revised mechanisms worked.

vint




On Nov 26, 2009, at 1:00 PM, Noel Chiappa wrote:

>> From: "Bernie Cosell" <bernie at fantasyfarm.com>
>
>> IMPs *only* buffered packets at the modem-output queue. There was
>> no source-IMP buffering of data for the destination-IMP.
>
> The 1972 FJCC paper does seem to indicate that this was not true of
> single-frame messages, viz (pg. 743):
>
>  "We minimize the delay for a short message by transmitting it to the
>  destination immediately while keeping a copy in the source IMP. If
>  there is space at the destination, it is accepted and passed on to a
>  Host and a RFNM is returned; the source IMP discards the message when
>  it receives a RFNM."
>
> Did this continue to be the case, do you recall?
>
>
>>> a host was allowed to have up to 8 packets 'in flight' to a given
>>> destination at a time (basically - there are more details).
>
>> I don't think that hosts knew about packets
>
> Apologies all, I was not sufficiently precise in my terminology; I  
> was using
> "packet" in the modern sense (in part because I'd just been looking  
> at the IMP
> interface code in the MIT router code :-), not in the old 'IMP subnet
> transmission unit' sense.
>
> (That's partly why I've started using the neologistic term 'frame'  
> for the
> IMP-IMP things, because that term is not ambiguous; I retain  
> 'message' for the
> host-host things, as it is also not ambiguous.)
>
> 	Noel