[ih] ARPAnet Type 3 packets (datagrams)

[Noel Chiappa]

    > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>

    > The Technical Information Report 89 .. 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

It's more likely due to the fact that terminology had not yet taken its
modern meanings; the term "packet", to them, meant strictly an IMP-IMP frame,
as that term always had in the context of the ARPANET.


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

Well, one would have to look at each NCP to be sure, but yeah, I would expect
that every NCP that got a Transmission Incomplete (of any subtype), would have
treated that as a fatal error on the connection. In _theory_ it was probably
possible for the host to save a local copy of the message, and not discard it
until it got a RFNM, and have it available to retransmit if it got a TI, but
I'd be stunned if any NCP actually did so. If nothing else, the RFNM/TI
process was not end-end, so even if you got a TI subtype 3, there was probably
no guarantee that the destination IMP had not in fact actually delivered the
packet to the host before crashing and restarting, so resending could create a
duplicate, and NCP had no sequence numbers of its own to weed out
duplicates...

BTW, I'm not sure if a TI is what an IMP sent to the source host, when it
didn't get a RFNM from the destination IMP, and could not get a reply even
after timing out and re-querying the destination IMP (which was what we were
discussing there) - it might have returned a 'Destination IMP Dead' error
(type 7, subtype 0).

	Noel