[ih] ARPAnet Type 3 packets (datagrams)

[Noel Chiappa]

    > From: Vint Cerf <vint at google.com>

A few clarifications/expansions...

    > it reserved space for multi-packet messages at the destination IMP
    > before sending one - acting sort of like a connection setup

To make explicit what's implicit here, single-frame (the term I use for the
IMP-IMP packets) messages were sent as their own request, so small host-host
messages did not see that delay.

    > did IMP-level retransmission of packets at link layer.

To be clear, I believe this was hop-by-hop, not end-to-end, but this is
from memory; I'm too lazy to go pull out the IFIPS IMP paper (and in any
case, this may have changed after the paper was written, but I would
classify that as unlikely, though).

Text in the 1822 specification (5/1978 edition, pp. 3-2) appears to verify
this, because it talks about getting an 'Incomplete Transmission' instead
of a RFNM if the message was "lost in the network due to an IMP failure";
one wouldn't need such a message if the source IMP still had a copy of the
message (or frame), which it could have re-transmitted on an end-end
basis, so the source IMP's copy must have been pitched after the next-hop
IMP had (locally) acknowledged it.

    > 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).
Attempting to send a 9th before the RFNM for the first has been received
would cause the IMP to block the host (i.e. shut down the hand-shake
bit-serial interface in the Host->IMP direction) until the first RFNM for
that destination arrived. One could have up to 8 packets 'in flight' at a
time to more than one destination, too.

As I recall, the IMP might block you _anyway_, even at less than 8 to a
given destination, for flow-control reasons in the net (e.g. no free
buffers), but you were _guaranteed_ to get blocked at 9.

    > The IMPS did not themselves use RFNM between each other

The wording here could be confusing. According to 1822 (5/1978 edition,
pp. 3-2/3-3), IMPs did look for the RFNM from the far end (i.e. on an
end-end basis), and on a timeout would query the destination IMP
(repeatedly so) until it saw either a RGNM or Incomplete Transmission,
giving up only after 30 seconds or so.

    > 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.)

    Noel