[ih] Failures of the early Internet

[Jack Haverty]

Ahah!  Another piece of history falls into place.

I recall Vint asking me at some point if I'd be willing to take over the 
gateway work and turn the core Internet into a 24x7 operation, as the 
Arpanet had become by then.  I didn't have a clue how to do that but it 
sounded like a fun project so I said "Sure".   That may have occurred at 
the same Internet meeting that Noel recalls.

The gateway work moved shortly thereafter, from BBN Div4 (where Packet 
Radio work happened) to BBN Div6 (where Arpanet and various TCP 
implementations were done).

I didn't find out until years later that some of the Div4 folks were 
sure that I had "stolen" their project.   That wasn't true, but I was 
blamed for it.

Now we know the Truth.   Noel was the culprit!

Jack Haverty


On 1/22/24 15:11, Vint Cerf via Internet-history wrote:
> While I don't remember this specific incident it sounds authentic (I often
> write down action items to remember them).
> It may be that I was intending to move into an operation posture, in which
> case I would want the same division that was monitoring the Arpanet IMPs to
> be monitoring the gateways.
>
> v
>
>
> On Mon, Jan 22, 2024 at 5:55 PM Noel Chiappa<jnc at mercury.lcs.mit.edu>
> wrote:
>
>>      > On Fri, Jan 19, 2024 at 9:20 PM Jack Haverty wrote:
>>
>>      > Anybody else have recollections of early failures...?
>>
>> This may not be the _kind_ of failure you're thinking of, but I remember
>> one...
>>
>> We had just brought up the first ARPANET-connected gateway at MIT, and we
>> needed to let the BBN 'core' gateways (I forget what the jargon name for
>> them
>> was at that point) know where MIT (net 18.) was connected, now.
>>
>> So, I got a copy of the GGP spec (IEN-30, or IEN-109), but I was too
>> busy/lazy to do a full implementation of GGP - I just typed in (in octal!)
>> a
>> 'routing update' packet that showed MIT-GW as connected to net 18, along
>> with
>> a few lines of code to send a copy, once a minute, to a list of gateways on
>> the ARPANET (here:
>>
>>    GWTAB:.BYTE   12,3,0,50               ; BBN
>>          .BYTE   12,2,0,31               ; CSS-GATEWAY
>>          .BYTE   12,1,0,24               ; DCEC
>>          .BYTE   12,3,0,110              ; RCC-GATEWAY
>>
>> is a copy of a later version of the table). I loaded this in to the MIT-GW,
>> started it up - but it didn't seem to be working.
>>
>> Shortly thereafter, IIRC, I got a call from someone at BBN, saying
>> something
>> like 'are you sending us GGP packets?' Apparently all their gateways had
>> crashed - after they got my routing update.
>>
>> It turns out they had changed the format of routing updates - but nobody
>> had
>> gotten around to updating the GGP documentation. So I had been sending them
>> old-format routing updates - which gave the BBN gateways indigestion.
>>
>> I remember that at the next Internet meeting, I wound up telling Vint this
>> story (probably because somebody had been giving me grief about 'crashing
>> all
>> the BBN gateways'), and he got this look on his face, and pulled out his
>> little 'things to do' notebook and wrote something in it.
>>
>> We were later speculating that he'd written down 'fire Div 6' (or Div 4 -
>> whichever one it was that Ginny worked for), because shortly thereafter, it
>> was announced that Div 6 (or Div 4, whichever one it used to be) would be
>> replaced by the other one in running the BBN gateways. I have no idea if
>> there's any truth to that, but the change was made shortly afterwards!
>>
>>          Noel
>>
>> PS: A later version of the offending code still exists; here:
>>
>>    http://ana-3.lcs.mit.edu/~jnc/tech/gw/conf/sbr/route-1.mac
>>
>> if anyone is interested. Note that the update format there is _not_ the one
>> in IEN-109! :-)
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20240122/01f5643c/attachment.asc>