[ih] ARPAnet Type 3 packets (datagrams)

[Matthias Bärwolff]

Please see also the very bottom of this email.

Bernie Cosell wrote:
>
>>     > No new MESSAGE (from the host) was permitted until the host received
>>     > a Request for Next Message (RFNM) from its serving IMP.
>>
>> Umm, not quite; 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 -- hard to remember [and I've 
> loaned out my copy of the listing] but I believe that the host just sent 
> a "message" and the packetizing happened in the IMP, invisibly to the 
> host.
>   

Just to add yet another take on this point, normal (local) and distant
hosts didn't know about packets (Very Distant Hosts would, though,
having to implement a reliable transmission package, see section F in
the 1822 report); but still, an IMP would block the Host-IMP interface
after having received the first 1000 or so bits of a message, issue a
storage allocation request to the destination IMP, and only upon having
this allocation let the Host continue send over the rest of the message
(pp. 3-3 to 3-5 in the 1822 report).

The Technical Information Report 89 (The Interface Message Processor
Program) as of 1978 even goes so far and speaks outright of packets,
even though this is probably just due to convenience rather than
technical strictness:

"As soon as the source IMP takes in the first packet of a multi-packet
message, it sends a small control message to the destination IMP
requesting that reassembly storage be reserved at the destination for
this message. It does not take in further packets from the Host until it
receives an allocation message in reply. The destination IMP queues the
request and sends the allocation message to the source IMP when enough
reassembly storage is free; at this point the source IMP sends the
message to the destination." (p. 4)


>   
>>     > I don't remember now whether lack of a RFNM triggered a
>>     > retransmission from the originating IMP
>>
>> My supposition is that this would have been impossible, as it seems (see
>> above) that the source IMP discarded its copy of the message once the next-hop
>> IMP had acknowledged receipt of all the frames of it. (Whether this discarding
>> was frame-by-frame, or message-at-a-time, I have no idea.)
>>     
>
> That's correct.  It was up to the host to resend the message.
>   

But NCP would never do that either, would it? The maximum thing that
would happen if something went wrong was going back to checkpoints in
file transfers (see e.g. RFC 542, NIC 17759), right?

Matthias