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

[ih] ARPAnet Type 3 packets (datagrams)

1. ARPANET was a peculiar amalgam. It had a datagram interface for  
HOST MESSAGES (potentially multipacket objects, up to 8 IMP packets of  
1008 bits each). But it reserved space for multi-packet messages at  
the destination IMP before sending one - acting sort of like a  
connection setup - and did IMP-level retransmission of packets at link  
layer. The ROUTE of the packets was indeterminate in the sense that it  
was NOT set during "connection" (ie space reservation) set up. Dynamic  
alternate routing was a feature. No new MESSAGE (from the host) was  
permitted until the host received a Request for Next Message (RFNM)  
from its serving IMP. The IMPS did not themselves use RFNM between  
each other (unless a FAKE HOST was sending the message and even then,  
the RFNM went to the sending fake host, not between intermediate  
IMPs). MESSAGES were delivered in sequenced order, so in that sense,  
ARPANET acted as if it were offering a virtual circuit service. There  
was no retransmission from host to host with the NCP protocol because  
this reliability was provided by the ARPANET IMPs. I don't remember  
now whether lack of a RFNM triggered a retransmission from the  
originating IMP but it seems likely this was the case given that NCP  
didn't have a retransmission philosophy.

2. Larry Roberts pressed hard for a virtual circuit form of interface  
for Telenet because he felt that he could not "sell" datagram service.  
He thought he could sell "virtual circuit" service (sequenced  
delivery) as a substitute for dedicated circuits, but at a lower  
price. We debated this when I urged him to try TCP/IP but this was in  
the 1975 time frame and TCP was still unsplit from IP and very  
experimental. He engaged with Remi in France, and two others in the UK  
(John <something> at BT) and Canada (David? Horton at Datapac) to  
develop what became X.25.

3. The XMAS lockup was a consequence of a memory failure in the  
Harvard IMP that caused its "distance vector table" to report that it  
was zero hops from everywhere in the ARPANET so everyone sent all  
their traffic to Harvard and it crashed for lack of memory. I don't  
think this was a reassembly lockup since Harvard IMP was not the  
destination, just the intermediate hop.

On Nov 26, 2009, at 8:50 AM, John Day wrote:

> As with most early attempts they don't quite fit the categories that  
> coalesce later.  The ARPANET was not as pure connection as X.25, but  
> not pure datagram either.  Although, I remember one evening around  
> 74-75 Danthine sitting in my living room insisting that the ARPANET  
> was not a datagram network!  ;-)  But then that was Danthine.
> Did the Xmas lock up occur because they were multi-packet control  
> messages and not subject to the end-to-end RFNM in NCP?
> If I remember right, weren't there also hop-by-hop RFNMs in the IMP- 
> IMP protocol?
> Which brings up another question.  I had always thought that X.25  
> originated mostly with the French PTT.  I have heard stories that  
> the Telenet guys had a strong hand in its design.  What is the case?
> At 0:32 -0500 2009/11/26, Vint Cerf wrote:
>> Richard, ARPANET was not circuit switched in the traditional sense  
>> of the word. Packets were dynamically routed. There was end/end  
>> RFNM for flow control (that actually inhibited use of things like  
>> the TCP/IP window in the NCP protocol). Buffer space was reserved  
>> at the far end to deal with reassembly lockup. "get a block" "got a  
>> block" handshake assured that no multi-packet message would be  
>> initiated without adequate space in the destination IMP.  There was  
>> no priority for type 3 packets. there was priority for ARPANET (IMP  
>> level) control packets.
>> On Nov 25, 2009, at 7:16 PM, Richard Bennett wrote:
>>> That really is ironic. If the circuit-switched service in ARPA and  
>>> X.25 was good for anything at all, it should have been good for  
>>> voice, but I'm guessing you guys tried voice over datagram over  
>>> circuits and found it didn't work worth crap, probably because of  
>>> high loss rates and excessive queuing inside the ARPANET. I also  
>>> wonder of the type 3 service didn't have the effect of boosting  
>>> the priority of voice packets in some way.
>>> Vint Cerf wrote:
>>>> the type 3 packets were explicitly used for real-time packet  
>>>> voice and later packet video experiments. This would have been in  
>>>> the 1975 time frame (but Danny Cohen and Steve Casner would know  
>>>> for sure as they were at ISI; Lincoln Labs was also involved and  
>>>> we used their packet digitizers/compressors. Duane Adams managed  
>>>> the packet voice activity during the time I was at DARPA so I am  
>>>> copying him too. I don't seem to have steve casner's email but I  
>>>> think he is now at PARC.
>>>> vint
>>>> On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>>>> I've discussed this issue recently with a key member of the IMP  
>>>>> team at BBN and he (unsurprisingly) has a very different  
>>>>> recollection of the facts. A datagram mode was added to the IMP  
>>>>> and to X.25 switches fairly early. Datagrams appeared on  
>>>>> research networks well before TCP/IP was defined; CYCLADES had  
>>>>> them in 1972.
>>>>> The BBN people have not been able to tell me whether the NWG  
>>>>> ever took advantage of the datagram mode in the IMP; that was  
>>>>> outside their department.
>>>>> RB
>>>>> Bob Braden wrote:
>>>>>> My memory was that BBN included type 3 (Uncontrolled or "raw")  
>>>>>> messages in the IMP protocol as an experiment, which they then  
>>>>>> considered too dangerous to use . BBN disabled them at  
>>>>>> (almost?) all hosts (almost?) all the time, I believe.  TCP/IP  
>>>>>> used standard reliably-delivered IMP traffic. But the facility  
>>>>>> must have been enabled for the packet voice experiments shown  
>>>>>> in that marvelous video.
>>>>>> My memory on this point is hazy, but probably Vint can correct  
>>>>>> me. When Barry Leiner became (D)ARPA Program Manager for the  
>>>>>> Internet research program, he became determined that BBN should  
>>>>>> try using Type 3 IMP-IMP packets for normal TCP/IP flows. He  
>>>>>> complained to the ICCB/IAB that BBN was resisting.  He insisted  
>>>>>> that the experiment be tried for 24 hours. Unfortunately I  
>>>>>> don't recall that the experiment ever happened;
>>>>>> it is more than possible that BBN stone-walled his demand.
>>>>>> Bob Braden
>>>>>> '
>>>>> --
>>>>> Richard Bennett
>>>>> Research Fellow
>>>>> Information Technology and Innovation Foundation
>>>>> Washington, DC
>>> --
>>> Richard Bennett
>>> Research Fellow
>>> Information Technology and Innovation Foundation
>>> Washington, DC