[ih] ARPAnet Type 3 packets (datagrams)

[vint at google.com (Vint Cerf)]

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