keywordsNetEvents Ethernet Innovation Summit
Ethernet or Ethernot? Ethernet vs. competing technologies
Date: Fri, 06/14/2013 - 17:38
Bob Belleville at Ethernet Innovation Summit
Image credited to Net Events
The 1980s witnessed the birth of the Local Area Network, and a explosion of LAN technologies – DECnet. WangNet, AppleTalk, HYPERchannel, VG-AnyLAN, ARCNET and Token Ring to name a few. A decade later, Ethernet had seen off all these competitors. What was it about Ethernet –as technology and/or business model – that caused this? And what would today´s world look like is, say, Token Ring had triumphed?
Panellists: Bob Belleville, AppleTalk; Dan Pitt, Token Ring; John Shoch, Alloy Ventures; Pat Thaler, 10 Base-T
Shaired by Paul Saffo, Futurist, at Ethernet Innovation Summit, Mountain View, California
Okay. So our next panellists are all heading up, and you'll find your spot that -- and actually what would be good is if you -- this is good. So it's going to be Bob, Dan, John, Pat will be right next to me. Okay, so this -- John, good to see you, sir. So this panel is titled "Ethernet or Ethernot -- Ethernet and the competing technologies". Again, in the spirit of saving time for the actual panellists, I'm going to introduce everybody with just one word. So way off at the far end, Bob Belleville, AppleTalk, Then Dan's next. Dan standardised Token Ring. John Shoch, PARC. And I'm going to add a second word or two words, first virus. He'll never live that down. And last but not least, Pat Thaler, 10 Base-T; I got it right today.
So, let's dive in here. Bob, I actually would like to start with you. You spent time of course on Engelbart's Augment world, and then you came to PARC. How did your experience with Engelbart inform what you did afterwards?
The SRI experience was very formative for me, because I got to -- I joined Doug Engelbart's group in 1974, and at that point we had the network available just as a tool to use. We weren't developing at all. I remember very clearly some day and sitting there with an online conference with a guy at MIT sitting in [in the middle of PARC] with a video projector showing his slides and Doug talking about the system that we were talking about had nothing to do with the network or anything. That was already in 1974, so transparent when I got there that we didn't spend a lot of time thinking about it. And so that's a lot about how that came about.
Again, talking about the context out of which Ethernet emerged, when you think of the ALOHAnet and Doug Engelbart's Augment program of course was spun out, people like you who went on to do extraordinary feats. Just a quick show of hands -- who in this room worked at SRI or with Doug Engelbart? Come on, raise your hand, Bob, yes. So one, two, three -- did I see three or four? Good, okay. Yes, thank you. Dan. So Token Ring has been the subject of several jokes so far. Would you like to set the history correct around this?
Sure. Unfairly maligned. Let me dispel a myth right at the beginning.
That means you, Bob Metcalfe.
Giving Bob Metcalfe 10 years of nightmares was not our primary goal. We make such a big deal about competing technologies and Token Ring and Ethernet and Token Bus, that's because in those days the medium access control was different. Once we got to switch to Ethernet it became kind of irrelevant.
What I think was the primary accomplishment of that whole effort was two things: the frame format and the MAC service interface. It says we have a MAC layer, it'll attempt to do these things, there's no recovery at the MAC layer. That has sustained us to this day. That's really what Ethernet is right now, a frame format on a MAC service interface. The universally administered addresses I thought were brilliant.
I spent a lot of my time in three committees at IEEE 802 and I was responsible for the worldwide standardisation of local area network everything for IBM. 802.5 for the Token Ring, 802.2 for logical link control, 802.1 for overall architecture addressing and bridging.
IBM had contrary opinions on everything. But the reason wasn't to be abstruse. The reason was that our customers were the banks. And they absolutely required reliable, predictable delivery of bits and services and we could deliver that with Token Ring, whereas in those days you couldn't deliver it with CSMA CD and this cable strung around the C links.
So we had a legitimate business reason for wanting Token Ring against Ethernet, for wanting connection-oriented logic-only control instead of [connection list], and for wanting source routing bridging instead of spanning tree.
So I took a lot of arrows during those years. No-one was happy to see me walk into the room. But I will say this about the whole experience. We were arguing about really interesting technical matters, and really interesting business justifications. And except for a few individuals whose names I will not recite right now, there was really a large absence of personal animosity. And I became really good friends with my counterparts at Digital and the other companies. We went on to do some really great things together at FDDI and later in that, and of course we ended up in some of the same companies. But it was -- it's fun to go back and think about the things we were arguing about back then, that aren't the things we argue about any more.
Jump in, John.
So I cannot resist. That we are still discussing and rationalising this bullshit 40 years later. I am just back in time. Let me pick up on two comments.
The first one is importantly, and Radia mentioned it as well, about what it is we're celebrating today. And it is the 40th anniversary of the Ethernet memo, carrier sense multiple access, shared cable, collision detection and all the rest of it, which by the way, none of them are in the Ethernet today. Not one. And as I think Bob has said once, it's been a long time since the insurance companies heard a complaint about a collision between two packets; it just doesn't happen any more.
The key commonality to be Ethernet compatible today is really the addressing. And there's a long story about how 8-bit addressing in the experimental Ethernet and in POP and the problems we had there and why it evolved in later Ethernets and in XNS, is one of the most important stories here.
The exwire spec which people forget about was the internal second generation that was going to be done at Xerox. And I think, Bob, you and others had stuff to do with that. It had proposed a 32-bit address. And by the time we proposed the standard with DEC, to DEC and Intel, it had gone up to a 48-bit absolute identifier unique over all space and time. This is an unbelievably crazy and key idea to the success of the Ethernet 248th devices. Yogan, are you here? Raise your hand. [He's] here.
Is Yogan here? Where are you, Yogan?
Yogan's over here.
Get a mike to him.
[Dennis] who worked on it, and I think, Yogan, you've attributed some of it to Will Crowther?
Yogan, keep your hand up so they can get a mike to you.
For people who haven't read it, this is the one paper in all of networking -- I'll leave aside my own -- this is the best paper I didn't write, on 48-bit absolute addressing, and I wish I'd written this paper, that it endures as it does and it is really an important paper, an important cosmic idea which has allowed us to have generation after generation after generation of things that are called the Ethernet and yet can interoperate at a very efficient way because of this mind-stretching idea of every device will be born with an identifier that will last its lifetime. That's point number one.
Point number two, let me talk a little bit about my view, which is different --
Actually, hold that, let's give Yogan a chance to add some colour. Stand up. This is what happens when you get called on by friends.
All right. Well, it's a long time ago, but John is absolutely right. It's probably the most unique idea that came out of Xerox when we were working on Ethernet. And Will Crowther, a number of other people, are credited with the idea of saying you don't have relative host IDs, you should really have something that's absolute. And that was born with the experiences that people at Xerox had with POP in the first generation of Ethernet, and I and other people had with the development of TCP/IP at Stanford.
But it was such a bold idea, that I must say that when you're young you can have the hubris, because when we're working with DEC and Intel, the Intel engineers told us that there was no way in hell they could put an absolutely unique ID in every single chip that they would create. For Ethernet, and being young, we told them that they were Intel and they'd better figure out how to do it. And to their credit, they did. And that really is the most unique idea that every single node should be born with an independent address, and then you can map that address however you wish, to TCP/IP addresses or IPB sets or things of that nature.
So a number of people contributed to that effort. But it was a mind-stretching exercise where you could actually think about giving every node -- in those days, nobody thought there'd be 2 to the power of 48 nodes. And 48 bits was a lot of bits in those days. Now I know everyone thinks about 64 and 128, but it was quite a stretch.
We have another comment.
Yes, I just want to add something.
Say who you are.
I'm the same person who was up there earlier.
Yes, I know, but not everybody can see you from here. So Bill, say who you are.
I'm Bill Hawe. And Geoff Thompson and I were just talking about -- I think this is essential. Addressing is architecture and I totally agree with what you've said. But we should not lose sight of the type field, with the protocol identifier field, because that was a key enabler, because at the time, again this is circa 1979, circa '80: which is the single protocol you would want to run on the Ethernet? There isn't one. And that was a key enabler [miss]. So those two are essential to the longevity. Right now it's IP and so maybe doesn't matter as much. But at that time, if you didn't have the type field, you wouldn't have been able to bootstrap this.
Good, thanks, okay. So --
Geoff Thompson again. Just agreeing even more with Bill than he thinks, because even though much of Ethernet freight is IP, the type field has proved essential for many of the recent innovations in terms of VLAN technology that are provided for encapsulation. It's been the keystone of the long-term flexibility of Ethernet. And in terms of addressing, I happen to be on the committee which provides technical advice to the registration authority for selling addresses. The thing that we're concerned about is trying to make sure that the address space lasts 100 years. We're now 33 years into that, and so far we've done okay. But there are danger signals on the horizon, and that's because Ethernet devices have become so cheap that they're now just several sectors on a disk drive in a cloud somewhere. And that's taken the limits off the number that can be created. So we have real concerns about whether or not we can preserve the addressing scheme in the long term.
Right, a challenge we're dealing with right now is both addressing for virtual devices which -- 48 bits has been good for physical devices, at least as long as the physical devices are things like computers, but when you start having virtual devices you can consume an awful lot of addresses.
Then the other issue is the whole Internet of things, the smaller and smaller devices that are getting addresses. And so that's something we're coping with, and probably going to use -- start using the local address space more for some of these kinds of things.
I also wanted to respond to my friend Dan here. My line is that Ethernet, the original Ethernet had a deterministic physical layer with a probabilistic MAC layer. In other words, we relied on probability for the CSMA/CD algorithm, whereas Token Ring had a deterministic MAC layer but a probabilistic physical layer. If they lost a packet, they had to regenerate the token, and that took considerable time.
Then the other thing is that I put a comment in on the original ballot on the Token Ring standard that they didn't have their PLL specified well enough to ensure interoperability and they assured me they did, and didn't change anything, and then some years later dealt with the jitter accumulation problem.
You remember our beautiful hermaphroditic connector?
Yes, well, that was the other thing is they had a beautiful, ergonomic design on the connector, which was huge.
It was huge, but --
And the people complained that the --
RJ45 that you plug 10 Base-T in and twisted pair [standard width] is too big. But this was about this big. The thing is, they had a lovely shielded cable, much heavier duty, stiffer cable than we use for Ethernet. But on that they put this huge connector where they put the shield around in a U and the sides of it were open and the pairs were unbalanced with respect to those open sides. And so when they plugged it into a grounded wiring panel, it unbalanced the pairs.
So I think one of the things that Ethernet has done a great job of over the years, with a couple of little stumbles along the way that we fixed, but generally done a great job about, is a really solid, physical layer design. And so that when people bought new Ethernet physical layers and plugged them together, they worked.
When we did 10 Base-T and a lot of people gave us a lot of grief about making sure this was a bullet-proof physical layer, because there were people who felt that twisted pair was not Ethernet and moving to twisted pair was not Ethernet. And we were really careful. And we had our first plugfest where we brought everything together, about 10 or 15 different vendors plugging twisted pair implementations together for the first time. The only interoperability problem we had was that some of the devices had the wrong software loaded, so we had some upper layer issues with getting it to work at first. But there were no twisted pair interoperability issues, there were no issues with the spec we wrote and the ability of many companies to design implementations and bring them together and have them work.
That's I think really what Ethernet got right over the years, is the balance of innovation, people being able to do new things, and openness, a standard that really you could pick up that standard and design a device and somebody else could pick up that standard and design a device and they would work together.
So over time, basically as soon as we brought out 10 Base-T, we went to a star network with a repeater. You could only have two devices on the twisted pair, one on each end. And we went to a star network with a repeater, and that changed the paradigm from all the original networks, which were either buses or rings to the star network that Radia mentioned. Then we continued to argue about access method until the mid-90s, when that repeater turned into a bridge. At that point, the access algorithm, the details of it other than the CRC check and the frame integrity checks, went away, and really we were dealing with a star network, and people now relied on electronics to work. It wasn't the electronics that broke most often; it was the connector getting flaky or somebody making a user error like taking the terminator off. And so we found that the original idea of stars and rings that you couldn't rely on these electronic components in the centre of the network was incorrect, and we could, and we switched to it.
Now if we want more reliability we put in dual paths and have two paths through the network.
All I can say is I'm interested in hearing more about the hermaphroditic connector afterwards, because by coincidence this week, and I had what I thought was a bad Ethernet cable between the laser printer in my cottage and my home office, and I wasted about three hours trying to diagnose it, until I realised it was what in [today's radio] they refer to as a short between the ears, that my post-50-year-old eyes had run the wires and the RJ jack wrong, so I would vote for bigger connectors, as big as possible.
John, you were about to make a second point 10 minutes ago, and I want to --
No, it's been a good discussion. I would like to take a minute or two on Token Ring versus Ethernet. To put it in context, the wonderful story that I look at is about AC power and DC power. There's a great biography of Nikola Tesla, that many of you have probably read, and I recommend, that describes this.
Thomas Edison had developed a distribution system and power generation system based on direct current. Nikola Tesla had developed a set of ideas around alternating current. So there was a technical dimension to it, there was a business dimension to it, and there was a political and marketing dimension to it. So Tesla was backed by Westinghouse; Edison was backed by -- helped form GE and they battled over who would get the contracts for certain power stations and which was the better design technically, which one had the better business support. It devolved from a technical fight, which it should have been at one level, into a business and political fight, including Edison staging demonstrations where he would get a stray cat and electrocute it with alternating current to show that this was dangerous and there's no way that you should allow alternating current into your house, failing to point out that if you'd put the same current -- direct current, through the cat, the cat would die just as well. This was a very bitter struggle at a technical level; a personal level; a business level; a marketing level, which eventually Westinghouse and Tesla won. They got some big orders for some power plants, and then ultimately, GE to their credit shifted gears, dumped DC and got into the AC business and really succeeded at it.
So when we take that, and consider the Token Ring versus the Ethernet, there are technical issues, there are business issues, there are marketing issues, there are positioning issues. To this day I believe it is an absolutely fact that the Token Ring causes cancer, and the Ethernet cures cancer. This was the --
Vote in the audience for the proposition, raise your hand.
This was the level of debate. There was a lot of scurrilous bull scat that was spread around. There were technical differences of opinion about rings -- and there had been rings forever, by the way, Newhall and Farmer, guys at AT&T and others, and there had been bus networks. And it became in the standards, when we arrived at the standards body, having already produced actually the first -- I am regrettably an attendee at the very first meeting of the IEEE 802 committee, before there were any sub-committees, which was held at the Jack Tar Hotel in San Francisco in conjunction with [CopCon] -- a conference that many people don't remember -- and we had just about finished the Xerox/DEC/Intel joint effort, but we didn't quite have it ready for that first meeting. So when we later presented it, this produced what I view as a political backlash about whether Xerox, DEC and Intel were going to be able to have this unified front allowing other people and have a standard which would make life more difficult for a different IBM than we have today. That's fair.
The battle had many different dimensions to it, with arguments about determinism and error and reliability, most of which was BS. People would talk about determinism and we'd point out, if someone takes apart your Token Ring cable, and if someone takes apart your Ethernet cable, they're both going to fail. So let's talk about realistically, all of these are probabilistic systems. If you disconnect the Token Ring at the wrong moment and you lose the token, there is an arbitrary process to get the token back, and by the way, if you get a second failure with some minuscule probability you're going to have to go and generate the token again. We had these obscure arguments about angels dancing on the head of a pin, which we finally settled in the IEEE, or the people who succeeded me, because I couldn't stand it anymore -- as you can tell. They finally said, fine, you guys go off into a different sub-committee and go away, because your requirements are so crazy.
Now there's a particular meeting which you may not be aware of, so in the midst of all this, we were promoting Ethernet, we were getting good support from our partners and colleagues back in Intel and other companies coming on board. We were out working and recruiting people, and IBM were on the other side trying to figure out how to throw boulders on the tracks, and we got a call which -- I'm not certain but might have been from Bob Evans, to our senior management that said: we understand -- he was a senior guy at IBM. We understand you're talking to people about the Ethernet. Would you be willing to talk to IBM? We said, sure, we're happy to talk to IBM. This must have been in the time period -- I was back in Palo Alto from corporate, so this was somewhere between around '80 or '81.
It was the classic IBM delegation: six or eight guys, very smart guys, I believe it included Paul Green, Werner Bux from Switzerland, from Zürich, a bunch of really smart guys, very disciplined, very gracious, with a spokesman who had clearly been designated who had his list of questions. They had clearly done their homework. It was David Liddle and I against these guys. David unfortunately is not here, and I'm sure everybody has a different recollection of this meeting.
They came in, and the guy had his list. He was the staff guy who had obviously put together all the questions. It was like: well, we're trying to understand Ethernet. If you had this set of requirements, can Ethernet do that? Oh yeah, of course, Ethernet'll do that; no problem. Well, if you had this additional requirement, can Ethernet do that? Oh yeah, no problem. For this additional requirement, can it do this? Yeah, we're pretty sure, yeah, we might run this little test, mmm, there's a small pathological case. But yeah, we can probably do that. Well, if you had this requirement and this requirement and this requirement and this requirement and this requirement, can it do that? And it was like: you'd have to retrofit some devices and you can add on hardware, and you can add as much processing power, but no memory! Something insane. And we finally went: you got us. We don't think the Ethernet can do that. But who on earth has a requirement for a design that is that bad? And one of the IBM guys poked the other guy and said, see, I told you your design was crazy. I'm sitting there going: WTF! You know, what is with these guys?
So they were trying to solve some unusual, narrow, constrained, retro-fit, real-time, whatever, problem. I walked out of the meeting and I said, they're going to be a problem, you know, because they're IBM and they've got a lot of weight to throw around, and they have a point of view, but they are so confused and so screwed up. I said, although this is going to be hard, we are going to win this. I said, it's either they don't understand their customers' requirements; they're deliberately misrepresenting their customer requirements; they are focused on the wrong requirements; or they are incompetent. I concluded they were not incompetent, and just -- they were off trying to solve a different problem and we still had to fight it out, and I cannot tell you how many speeches I gave to customers about the probability that somebody will cut your cable, be it Ethernet or Token Ring, is higher than the probability that any of these other bad things will happen to you. Eventually, all I can say the final thing is, I dare anybody to go to [Fry's] and try to buy a Token Ring interface. I don't think [inaudible].
Last question. We're out of time but I can't let this pass because I've got -- I have a question for you, Dan, and a question for you, Bob. I'm going to start with you, Bob. When I look back, hey, for Christ's sake, this wasn't about people communicating information to other people. This all happened because people wanted to send data to a darned printer. At what point did -- and thank God you all did that very well, at what point did it start dawning on all of you that this wasn't about sending data to printers, that this was a much, much, much bigger deal. And what does that mean for the future? What are we getting wrong today about networking that's going to surprise us ahead?
I'll tell you two things about that.
Okay, haiku, fast.
Okay. So in 1990 when I started taking my son to colleges to visit to see which one he'd go to, and in the tours they would talk about they were getting one LAN connection per dorm room. Somebody used the phrase their goal was to have one per pillow, one for every student in the dorms. That's when I knew that this had really gone big.
Then as far as Ethernet curing cancer, when I had breast cancer and I was at the doctor's at Kaiser, and basically every one of my doctors had access to all of the information about what had been done so far and could talk to me knowledgeably about it, and the meetings could be so efficient and good, and they could see the X-rays and everything. That's really -- yes, it does cure cancer.
It does cure -- now, it shows we still have a future because it hadn't cured the common cold yet. But Bob, your observation on this?
I was actually preparing to talk about the fact that I built the --
We'll talk network principally to talk to a printer. The laser printer was very important to Apple's success, and we needed some way to share this very expensive piece of equipment. And that's the genesis of the Apple Talk network.
Steve was not a believer. He didn't even know what a network was when you talked to him, right?
Nobody at Apple particularly knew what a network was, or hardly anybody at Apple knew what a network was. But the thing that strikes me so much about the conversation that I've heard here so far is that we've been talking about a world that was dominated by the big research labs, the huge companies, the companies that actually had customers, like IBM, they had real live customers, who had things to actually do. Apple, when I went there, was making the computer for the rest of us. There wasn't a customer base to speak of. There were a bunch of Apple II guys floating around, and there were high school teachers that had Apple IIs, but the small personal computer was only just beginning.
The famous ad that Steve did in the Wall Street Journal or New York Times about "Welcome, IBM" was very serious. This was a matter that the rest of people we knew were going to want these computer things. And the biggest idea that people had about that was that they were going to store their recipes on them. We all knew that was different; it wasn't going to happen like that. But getting a lot of people involved, so the Apple Talk network I'm really impressed about, because it got the network into the hands of a lot of ordinary people who began to get a taste for this kind of a thing. Whatever they were doing with it: talking to a printer, talking to one another, sharing files, and all the things that could be done, the eventual development of email availability to the ordinary people, that was something that was in 1983 when the Apple Talk network was developed, was all new. And so this was the bringing in of a vast number of people which make all this stuff so interesting today, not the environment of the banks and not the environment of the people that have the university problem of putting one by every pillow, but the problem of everybody was going to want some piece of this at some point in time. That was what I was so proud of about the Apple Talk network, is I helped to accomplish that.
That's great. So Dan, very last question for you. We're way out of time, but the arc of your career is actually pretty extraordinary. You went from IBM through all this innovation and academics and now you're the Executive Director of the Open Networking Foundation. So you've really had -- continue to have an up-close view on how standards get set and evolve. Are you an optimist or a pessimist around the future of innovation since standards?
I think standards serve an important purpose. It's changing, as even networking's becoming more software-based and software standards are not the same as protocol standards. We're trying to change that culture.
But let me conclude with a limerick that I wrote in the period. This was in the late 80s. I'd been there throughout the 80s and we'd done Token Ring, we'd done Ethernet, we did Token Bus, we got the twisted pair, we got switched Ethernet, we're doing FDDI. And I wrote this limerick -- I looked around the room at IEEE 802 and I came up with this limerick.
Any nitwit with standards acuity
Soon learns of their self-perpetuity
The work was all done
Back in March '81
But these trips are a lifetime annuity
What a perfect way to finish this panel. Please, thank the panellists again.