[ih] ARPAnet Type 3 packets (datagrams)

[Vint Cerf]

1. if the HOST message was small enough to fit in a single IMP packet,  
the whole packet was sent as an implicit request for storage. Either  
you got a RFNM back or I guess Incomplete Transmission. I don't  
remember but don't think that the source IMP held a copy of the packet  
for retriansmission.

2. If the HOST sent a message that was longer than a single IMP packet  
(1008 bits) the IMP halted bit transfers on the interface (except for  
the VDH case which was much more complex) using the bit level controls  
on the physical interface) until it got back an 8 packet reservation.  
There were only two reservations: 1 packet and 8 packets, regardless  
of the actual length of the HOST message.

3. NCP did NOT retransmit; it relied on the IMPs.

vint


On Nov 27, 2009, at 9:17 AM, Matthias Bärwolff wrote:

> 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