[ih] ARPAnet Type 3 packets (datagrams)

[John Day]

Correct and implicit in what Vint said.  A MESSAGE was at most 8 
packets.  That was where the 8 limit Noel was talking about came from.

At 11:25 -0500 2009/11/26, Vint Cerf wrote:
>noel, wrong on your analysis of the RFNM. RFNM refers
>to MESSAGE (that is what the host sends). the Host
>does not get to send anything until it gets a RFNM (or
>Incomplete Transmission I guess)
>from the last MESSAGE, no matter how long or short
>the message was. A single packet message served
>as an automatic "get a block" request. A multipacket
>message does the "get a block" routine. The full
>MESSAGE is sent to the IMP from the Host and the
>Host is blocked until it gets a RFNM or Incomplete.
>You are correct that you could have up to 8 packets in
>flight but the Host is unaware of the breaking up of
>MESSAGES into packets.
>
>Vint
>
>
>On Nov 26, 2009, at 11:12 AM, Noel Chiappa wrote:
>
>>>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