[ih] Arpanet incomplete messages and host level retransmissions
Matthias Bärwolff
mbaer at cs.tu-berlin.de
Mon Jan 11 09:04:01 PST 2010
The following issue has been touched on here recently, but I'd be very
happy about some additional data points on the issue: I understand that
when a destination IMP's timer for all packets of a message to arrive
triggered, it will have inquired with the source IMP whether "everything
is fine", sort of. Now, in case the source IMP or host died before
sending off the whole message, and is dead still, the destination IMP
will tell its host so, and all is good.
But, what if packets of a message got lost inside the subnetwork, and
retransmission would be the way to go? The source IMPs did not have the
capabilities of sending entire messages again, and, yes, people from
both sides (BBN and host sites) say that message losses inside the
subnetwork were very rare indeed. But still. While the host-host
protocol did not have sequence numbers, NCP should have been able to use
the missing RFNM to find out which data to retransmit (provided, of
course, it kept a copy) -- and, in fact, RFC 528 mentions such
retransmission, albeit at a somewhat higher conceptual layer (the
terminal handling inside the TIPs):
"In March [1973] the TIP program (and the programs of several other
Hosts) was changed to retransmit messages for which the Incomplete
Transmission indication was returned; some Hosts (e.g. MULTICs) have
done this from the start. This modification has turned out to be
relatively simple, and we urge other Hosts to consider implementing some
sort of error recovery software." (p. 7)
Does anyone here know what exactly Multics did in the respect here
mentioned? Was retransmission at the host-host protocol layer an
approach that was pursued further? Or was retransmission only
implemented as part of TIPs, file transmission (checkpoints), etc.?
Thanks for your comments.
Matthias
--
Matthias Bärwolff
www.bärwolff.de
More information about the Internet-history
mailing list