Chatting with Ben Segal - Podcast Episode 9 - Early Battle of Network Protocols After STELLA Project


Episode 9 Early Battle of Network Protocols After STELLA Project


David: [00:00:00] What I find fascinating is how deep that effort to distribute the data through satellite was, how did it work out?

Ben: [00:00:06] Right. Wonderful. So we did not use Internet protocols, although, funnily enough...

David: [00:00:11] Which year is this?

Ben: [00:00:12] '78 to '83.

David: [00:00:15] OK.

Ben: [00:00:16] 1978, it started. The challenge was this. If you want to distribute data across a satellite link, obviously you need communication protocols. But all we got... Mervyn Hine, my boss, he made a deal with Eutelsat, the European satellite outfit, to get free time on a satellite channel most days for like an hour - it was a different time each day. That's all we got. He got some equipment from Marconi in England to actually beam towards the satellite, but for the rest we had no other support and we didn't have dedicated computers.

Ben: [00:00:59] We were five collaborating labs. It was CERN ... maybe six, CERN and five other labs. Nobody had a special computer. We didn't have a standard computer to use. We didn't have a standard programming language and we didn't have equipment to do the necessary time division multiplexing of this channel, we had nothing. So in the spirit of the time, we built our own hardware, we built our own software, which we could port using a new language called BCPL...

David: [00:01:27] Yeah.

Ben: [00:01:27] ...the only portable language we knew. And this was another ... this was our English collaborator who was the expert on that from Rutherford Lab...

David: [00:01:35] Which, if I'm not wrong, is a predecessor to C.

Ben: [00:01:37] Absolutely. In fact, Dennis Ritchie, er.. Ken Thompson, called it the B language.

David: [00:01:43] Right.

Ben: [00:01:44] Yeah. BCPL was invented by an Englishman called Martin Richards at Cambridge. Very elegant language. There was one exponent of it at CERN called Ian Willers, who'd graduated from the Computer Lab in Cambridge and came to CERN with knowledge of this. So he helped us with this. But so .. the idea was this: we would have a computer... each site got itself a computer, they were all different. We had a Norwegian computer. The Brits had a GEC, a General Electric, computer. The Germans had a little IBM computer, not a mainframe. The Italians had a PDP-11. And the Austrians, I forget what they had. The French... the French dropped out...

Ben: [00:02:31] So we needed software, the main software which would read the tape - the data was on mag tape - read the tape and transmit it logically.

David: [00:02:39] Yeah.

Ben: [00:02:40] Okay. And that software was written in BCPL. Then we needed a modem controller. We had the modem and we had the transmitter, we had a dish and we had to have a controller. And that controller we built from hardware ourselves, we had a very, very good hardware designer, and he built it in such a way that it would adapt to each computer so that we had a DMA channel...

David: [00:03:07] Yeah.

Ben: [00:03:07] ... and we had a PIO (programmed I/O) channel, and he would adapt it hardware-wise to each host computer hardware...

David: [00:03:15] Hardware.

Ben: [00:03:17] Hardware, OK?

David: [00:03:17] Right.

Ben: [00:03:18] And we had a fast serial channel to drive and it had to have timing gates on it. So because we'd invented the protocol, a time division multiplexing protocol. You each, you have six sites all using the same channel. So they have to multiplex and they have to tell each other... So everyone got a basic small time window dedicated to them. And then with a dialogue you could say "OK, I need a big transmission window" or "I want to receive now", or whatever. Right. So all this software was programmed in the mini-computer and gated by the controller, and the controller was a Motorola 6800 controlled device with special hardware, special time gating to handle the transmission. And because basically the mini-computer would do a DMA with big data and it would be held in the buffer of the controller until the time when the time was right for that particular thing to take the channel. The channel was, it was like an Ethernet without collisions possible.

Ben: [00:04:31] So all that was developed in a couple of years and I did the controller. I did the software for the little controller working very tightly with the hardware designer, a close friend of mine, and other people did ... Now we didn't use TCP/IP because .. it was actually available, just becoming available here, but we hadn't heard about it, although our Italian partners had heard about it. So they used .. in the second part of the project, by the way, when we got this to work, the big problem was an operational problem. The idea was: CERN would mount a tape, a round tape. The whole tape, read full speed, would be read in 10 minutes. So a mini-computer with the tape spinning would transmit this data in 10 minutes and all the other stations would receive it, acknowledging the receipt. It was like a TCP type protocol.

David: [00:05:27] Yeah.

Ben: [00:05:28] With the time division multiplexing underneath it so that people didn't get in each other's way on the satellite. So the problem was that in order to make this work properly, you had to have an operator at each site in real time mounting the tapes because there was no memory for buffering. No hard disks. Not enough for a whole tape anyway. So it used to usually fail because an operator wouldn't turn up at one site or another site. And so rarely would it really work. And during this, after like three years out of the five years, we realized that a better way to do this would be to have fixed disks on a bigger computer that would have the data on them. And we'd use sort of a batch system. And we would do it, we would use the satellite channel as basically an Internet channel. So in the second part of the project we actually did this, we demonstrated a Local Area Network in three sites using different networks with our Internet protocol connecting them. It wasn't the IP network of the Internet, but it was equivalent. The Italian guys designed it knowing about IP. So in fact, at the end of the project, which was really exciting, we had at CERN, we had .. I guess we had Ethernet at CERN, in England they had a Cambridge ring, which was an early LAN. Okay, a token ring .. an early token ring. In Italy.. Oh no, sorry, at CERN we had CERNET, our local home made network, and the Italians Ethernet. So we had data going across this thing, three different Local Area Networks linked by the satellite channel, and that worked. And that really was quite an advanced thing. So we learned a lot.

*** ERRATUM: The STELLA Internet actually bridged:

(1) a Cambridge Ring between CERN and the Rutherford Lab


(2) a CERNET segment between CERN and CNUCE-Pisa (BS) ***

David: [00:07:18] Especially because you have huge latency if you go through a satellite, and that's how you know if you've really designed a protocol well.

Ben: [00:07:25] 250 milliseconds, yes.

David: [00:07:27] Yeah.

Ben: [00:07:27] So the actual TCP-level protocol was a windowed protocol with big windows to take care of it, which we all designed ourselves. So a big learning .. So in five years it seems to me, using this portable language as well, it was quite amazing.

Ben: [00:07:45] So anyway, so coming back from that was the time to get a new job. People had, you know, they knew this was going on, this project. But it was treated you know, it was run by the old Director. It was his hobby. We had these people, these spoiled people like me who didn't have to run services - they just do the exciting developments - and there was quite a bit of jealousy at times. But anyway, coming back into the mainline, then I had found Les Robertson as a boss, and very soon we decided we needed proper networking - RPC wasn't enough. We were going to find it. And so the choice came down to TCP/IP or Xerox Network Systems (XNS). So I took a look at both of these and XNS was more elegant, very nice, but not properly developed. And you couldn't get implementations of it, whereas TCP/IP - which seemed a bit messy coming from the ARPAnet, you know, was it military or was it not, etc. - implementations were coming all over for everything. And so we chose that very quickly. And then we ran into the problem that, at that time there was huge debate, controversy and conflict around the choice of computer communication protocols. So it turns out TCP/IP, OK, is American, and was being developed in universities, bottom-up and not at all sort of official, but very dynamically being developed dynamically. And the "official" future protocols were the ISO protocols. Seven layers, all that sort of stuff, and they were being developed top-down and they didn't seem to be arriving. And you couldn't get implementations. You could spend a lot of money. You could get a partial implementation on one solution. It wasn't practical, but politically, we were seriously criticized for pushing ahead with this. And however, at the price of signing a document that Les and I had to sign saying we promised never to use these protocols outside CERN, we were allowed to go ahead. And I was even named the official coordinator of these protocols at CERN. And so we were left to do our stuff with very little help or cooperation from the main networking people - more or less harassment, criticisms that we were using connectionless protocols in the IP layer. There was a lot of "religion" - you had to be "connection-oriented" to be taken seriously and so on. Oh yeah. I mean X.25...

David: [00:10:30] Right. I mean that makes no sense... now...

Ben: [00:10:34] And even then it made no sense.

David: [00:10:36] What do you get? You only get the downside from it.

Ben: [00:10:40] You get the downside. And it's not scalable.

David: [00:10:41] Exactly right.

Ben: [00:10:42] So anyway, it was on the level of religion and politics. And the main networking group had all the money, they had the budget for leasing lines all over the place and running proprietary protocols on them. And we were sort of looked down on, but they let us get on with it. And we finished up, yes, we connected all the important machines at CERN. I used to handle the licenses when we had to pay. I would have the licenses and go around, give out the licenses mostly for the VAX-VMS machines and so on. And we had software that we found on each major implementation, and sometimes from universities. On the IBM, we started off with software from the University of Wisconsin and soon IBM came up with their own.

Ben: [00:11:28] Funnily enough, the kicker in the story is this: IBM, who I always felt didn’t want to share, they switched quite early on and decided that TCP/IP was a good thing, before CERN did. And IBM started to encourage their big customers to use TCP/IP and CERN was part of something called, I forget the name of it, but IBM had a certain class of European customer, the very very big centres. Like Bologna, and CERN and so on, running the biggest mainframes, and CERN offered, sorry IBM offered, to pay for TCP/IP lines to the US if people would adopt it. I mean, this was before CERN had done it. So that was the final kicker that made the politicians in CERN switch and admit that after all the ISO protocols were not going to come, and that what we had been messing around with since '84 for five years was a good thing after all, it was working. And that took off very quickly in CERN, very, very quickly. So Tim, then, was sitting inventing the Web, HTTP in particular, and he could see all this happening. And I taught him socket programming. Because what came with the Internet protocols in the software implementations, came an API, called sockets, which all these other products didn't have - standard sockets. No, how do you interface with them? If you had X.25 or so on, how do you interface with them? Well, each of them would have its own method, all the usual stuff. But you couldn't just write a little test program and connect it to our test program on another machine with a different operating system. But with TCP/IP you could. If there was a socket library for a decent runtime library, you could do it and you could do it between VMS, the IBM... And so this .. I was also running around teaching and preaching all this. To me, it was so obviously necessary. And that's why the other stuff never, they never planned the implementation all the way up to the application level. They didn't do that. So they couldn't succeed.

David: [00:13:52] Yeah.

Other news