[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] Arpanet raw messages, voice, and TCP

Noel Chiappa wrote:
>     > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>
>     > I gather from the 1822 report .. that hosts could send uncontrolled
>     > messages (one packet messages at that) that would be delivered without
>     > paranoid error control IMP-to-IMP and without RFNMs and retransmissions.
> This is probably not very useful/interesting, but I looked at the MIT/Proteon
> router ARPANet interface code (which dates from circa 1981/2, if memory
> serves), and it had no capability to send Uncontrolled (type 0, subtype 3)
> mesaages. (It would correctly process any it received, though.)

Thanks, this is by no means "not very useful/interesting", in fact it is
one of the only data points on the issue I have yet come across.

>     > What experiments or actual applications did people do with the raw
>     > messages?
> Note that Uncontrolled messages could not be longer than 1 IMP-IMP frame
> (which was 1008 _bits_, IIRC). That's because to send a message longer than 1
> IMP-IMP frame, the sending IMP had to first allocate a re-assembly buffer at
> the destination IMP. Doing so would obviously be in conflict with the whole
> goal of Uncontrolled messages (fast/cheap transmission), but a maximum packet
> size of ~120 bytes would obviously not have been that much use for TCP/IP in
> general.

I don't understand this. Even the 1974 Cerf/Kahn specification of TCP
knew of "breaking up messages into segments", because "the local network
may limit the maximum transmission size" and which are, in turn,
packaged into an internetwork packet. While hosts were eventually
expected to accept IP packets of at least 576 bytes, they sure can cope
with smaller packets, too (even, say, just the header). Why then would
126 bytes foreclose experimenting with TCP/IP?

I am aware that the uncontrolled mesages could not be multi-packet
messages. And, unlike ordinary single-packet messages they would not be
subject to the source-destination-IMP ack/retransmit facility. This is
precisely the reason why I would sort of consider them an early variant
(or at least a conceptual anticipation) of the later IP packets. And,
surely it must have been more fun playing around with higher level
end-to-end reliability in a network that actually does drop a packet

It would really by interesting to learn more about the ICCB/IAB versus
BBN clash on dropping TCP onto uncontrolled Arpanet messages, as alluded
to in the earlier Bob Braden email.


> 	Noel

Matthias B?rwolff