Heidelberg Lecture: Vinton G. Cerf (ACM A.M. Turing Award 2004)

This talk will explore the motivations for and design of the Internet and the consequences of these designs. The Internet has become a major element of communications infrastructure since its original design in 1973 and its continued spread throughout the societies of our planet

Well, I can see already, I have to convince the computer that it's me, so one moment. (Laughter) There we are. First of all, you have no idea what this is like, I think. Well, some of you have been up here before. But for me this is very daunting. I’ve never had this many Nobel Prize winners and smart people in the audience at the same time in this scale. So I hope I do reasonably well. Stefan Hell did an absolutely spectacular lecture on optical microscopy last year at the Heidelberg Laureate Forum. So I’m feeling a certain amount of pressure. Let me start by saying, I’m going to try to cover some of the history of the internet, just to give you a sense for how it came about. And then some ideas about where it’s going in the future. Let’s start out by reminding you that there was a predecessor system called the ARPANET, the Defence Advanced Research Project Agency, which is part of our Department of Defence in the US, began to explore the possibilities of computer networking. And it had a very practical reason for doing it. It was funding a dozen computer science departments during the 1960s to do research in artificial intelligence and computer science. And everybody kept asking for the latest computing equipment every year. And they said, we can’t buy 12 new computers for 12 computer science departments every year. So we’re going to build a network and you’re going to have to share your resources. People were reluctant to do that initially, because they thought, well, if we have to share resources, the other people will see our work. And they’ll steal our software or steal our code or use up all the cycles. And Arpa said, just relax, we’re funding all of you. This is no longer a competitive issue. We want you to share your experiences and your expertise, so that we can accelerate the rate at which the research progresses. So they built the ARPANET, and it was successful. Then they realised, after the success of the ARPANET, that computers might be useful for command and control. Because if you could manage your resources better than an opponent, owing to the use of computers. You might actually be able to defeat a larger opponent with a smaller size group, because you were managing to extend their capability better. We call that a force multiplier. But, if that were going to be the case, then the computers would wind up having to be in aircraft and ships at sea and mobile vehicles, and, at that moment, only fixed installations had been built for the ARPANET. So that’s sort of the background for why the Defence Department, Arpa in particular, was interested in pursuing this. So this is all based on the concept of packet switching. And you’re all using it, whether you know that or not. But some people don’t fully appreciate how it works, and it’s actually very simple. If you know how postcards work, you know how the basic internet packets work as well. First of all, just like a postcard, they have no idea how they’re being carried. A postcard doesn’t know if it’s going over in an aeroplane, or a ship at sea, or on the back of a postman, or a bicycle. In the internet, packets don’t know how they’re being carried. They don’t know whether it’s an opticial fibre, or a satellite link, or a radio channel, or a hard wire Ethernet - and they don’t care. The design of the system was carefully done to make sure that these internet packets were unaware of how they were being transported. Also, like a postcard, the internet packets don’t know what’s written on them. So that’s turned out to be a very powerful tool. Because the meaning of the internet packets is only interpreted at the edges of the net, by the computers that are either sending or receiving them. What that means is that when you develop a new application, you only have to change the software at the edges of the net where the host computers are. You don’t have to change the network, because the network doesn’t care what the application is, which opens up a huge number of possibilities. When you want to invent a new application, you don’t have to change all of the network. Postcards don’t stay in order either. You put 2 postcards into the post box. And if they come out at all, they might come out in a different order. And, in fact, sometimes they don’t all come out. And so you have this disorderly, not reliable system of electronic postcards. And that’s basic packet switching. So you might wonder, how would anybody make anything useful out of that. And I hope I’ll show you how that can work. The original initial implementation of the ARPANET had 4 nodes. I was at UCLA at the time, as a graduate student like many of you are, and wrote the software to connect the Sigma 7 computer to the first packet switch of the ARPANET in about 1969. The Sigma 7 is in a museum now somewhere, and some people think I should be there too, but I’m here. So that’s the beginning - just the 4 node network. It rapidly grew over time. What you see on the left is what a packet switched looked like. IMP stood for interface message processor. We call them packet switches now or routers. This was the size of a refrigerator at the time. And you can tell that things have changed over the intervening 40 years or so. You can hold a router in your hand now, it’s about the size of a simple Ethernet connector. And, of course, it costs a lot less - these were $100,000 devices back in the day. So that’s how things have changed over a 40 year period. This, by the way, it a classic observation: usually anything that you do that’s new is big and expensive. And with experience, over time, if it continues to work, it gets less and less expensive and often a lot smaller. And so you see this trend from expensive equipment, that’s owned by institutions, to maybe just departments, and then eventually individuals who own these devices and carry them around. We were also concerned, of course, about mobile communication. And so we built a packet radio network in addition to the original ARPANET. This ran in the San Francisco Bay area. We had repeaters up in the mountain tops, and this particular non-descript van that was carrying the equipment inside, which I can show you here. If you see, these things over here and over here are packet radios. They’re about a cubic foot in size. They cost $50,000 each, back around 1975. And they were the sorts of things that you stick in your pockets now. But back then the equipment was not quite as dense. We were able to get something on the order 100 to 400 kilobits a second operating at 1710 to 1850 megahertz. And we were modulating this stuff at fairly high speeds. So one of the things that we tried to do in addition to transmitting just data around, we recognised that for command and control we’d need voice and video. And so back in the 1970s, we were experimenting with packetised voice and packetised video. I have to tell you that the voice experiments were kind of interesting, because a typical voice channel is 64,000 bits a second. You sample the voice stream at 8,000 times a second, taking 8 bits of information per sample. And we only had 50 kilobits were second available in the ARPANET back bone, and 100 kilobits in the packet radio net. So we decided, in order to get more voice channels in the system, we would compress the voice down to 1,800 bits per second. And in order to do that we modelled the voice track as a stack of 10 cylinders that would change their diameters as the voice, or speech, was being generated. And that little stack of cylinders was excited by a pitch reforming frequency. We sent the diameters of all of those model cylinders over to the other side. And that got the data rate down to 1,800 bits per second. Although you can imagine that the quality of the speech kind of reduced some, when you went from 64 kilobits down to 1,800. So anyone who spoke through this system sounded like a drunken Norwegian - and I hope I haven’t insulted any Norwegians in the audience. They were understandable but it was a very peculiar kind of sound. So the day came when I was, by this time, working in the Defence Department, and I had to demonstrate this system to some generals at the Pentagon. And I remember thinking, ok, how am I going to do this? And then I remembered that one of my colleagues, who was working on the packet voice, was Ingvar Lund from the Norwegian Defence Research Establishment. So we had Ingvar speak first through the ordinary voice switch system. And then we had him speak through our packet voice system, and it sounded exactly the same. We didn’t tell the generals that everybody would sound that way through this system. (Laughter) Well, as you can see on the right hand side, that we’ve gone from these big bulky pieces of equipment, that required a huge van to carry around, to things that we put in our pockets or even strap to our wrists. And once again, this trend of going from big and expensive to small portable, and often affordable by an individual, is still holding true. In addition, because we also wanted to deal with ships at sea, we decided that satellites would be the appropriate technology, because you could go long distances. So we put a standard satellite system, Intelsat IV-A - or used it, we leased some capacity on that network. And we had multiple ground stations, all contending for the same satellite channels, so it was kind of like an Ethernet in the sky. And that allowed us to experiment with wide area packet switching over a satellite channel. So we now had 3 different kinds of networks to deal with: packet radio, packet satellite and the ARPANET. And they all operated at different speeds, they had different error rates, they had different packet sizes. And yet, the problem that Bob Kahn and I had to solve was, how do we make all of those diverse networks appear to be one network, even though they were all very distinct. So just to give you a sense of the course of this effort: In 1969, the ARPANET begins construction. And then in ‘73/’74, after having about 3 or 4 years of experience with the ARPANET, Bob Kohn and I did the first design of the TCP protocol, which later became TCP/IP. And then during the 1975 to ’78 period, we went through multiple iterations of implementation, test and refining, and correcting of the protocols. And we found a number of mistakes that we had not anticipated. We had many different institutions working with us at the same time. And so, if someone tells you that, you know, the internet is purely an American invention - that’s incorrect. We had colleagues from everywhere: people in Europe, people in Asia, some in my lab at Stanford before I came to Arpa, and elsewhere. So there was a lot going on. And then, finally, after we settled on the versions that you’re mostly using today we began implementing those protocols and every operating system that we could find. So that in 1982, we could announce to everyone who was on all of the systems, that they would have to switch over to the new TCP protocols in order to stay in the programme. So on January 1st 1983, we turned the internet on and it has been running since 1983, although it wasn’t widely visible to anyone except the research community and the military. Now just to give you another important point about the design of the system: it’s layered. So the lowest layers are, you know, physical transport over optical fibre or radio links, and things like that. The internet protocol layer is the electronic post cards. And those are the things that are forwarded through the network, and go back and forth between the hosts. Above that layer are the protocols that make this a more disciplined environment. And, finally, protocols that implement applications. So this is a layered architecture. And it's roughly 5 layers, if you like: physical layer, the data links, the discipline, the bits and then, finally, the IP layer and transport and application. So the way it physically works is that the hosts at the edge of the net implement all of the layers of protocol, up to, and including, the application layer. But you’ll notice that the things in the middle of the net, that are responsible for switching internet packets, don’t know anything about transport layer protocols or application protocols. All they see are internet packets, those little electronic postcards. So their job is very simple. When they get a postcard, they look at it to see where it’s supposed to go. They look in a table which is generated by a routing protocol running in the background, and they just send it in whichever direction that table tells them to go. And so it’s a very simple concept. And the simplicity, I think, has helped make this a system which is not only scaled over time, but it’s persisted over a 30-plus-year period. So this is another picture of the layered protocol architecture. And what’s important is the little guy in the middle called the internet protocol. The thing which I want to emphasise in this picture is that, because the internet protocol layer doesn’t care how the underlying layers work. The assumption is, if you hand the underlying layers a packet, that they will somehow pass along that channel, and they go from router to router to router to the destination host. The consequence of that decision is that every time a new communication protocol came along, or a new transmission technology came along, we just swept it in to the internet. The internet didn’t care, didn’t notice that it was anything new, it’s just another way of carrying bits. By the same token, the absence of knowledge of the applications in the internet protocol meant that when somebody wanted to invent a new application, they didn’t have to go get permission from every internet service provider in the world. All they had to do was to go implement it at the edges of the net and proceed to send packets back and forth. So Larry and Sergey, when they started Google in their dorm room at Stanford University, did not have to negotiate with every internet service provider in the world. They just put the service up on the net and let people try it out. That’s why we’ve had such a cornucopia of applications coming out of the internet, despite the fact that there are literally hundreds of thousands of internet service providers all around the world. So in order to make the internet protocol layer more disciplined – remember it’s lossy, it loses things, it gets them out of order and everything else -, we put another layer of protocol on the top called TCP. And you can understand very easily how it works, if you imagine the problem of sending someone a book through a post office that only carries postcards. So imagine, what would you do? Well the first problem is you have to cut the pages up to get them to fit on the postcard. And then you’d notice that not all the postcards have page numbers on them because you cut the pages up. And you know they’re going to get out of order, and so you number every postcard 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. And you also know that some of the postcards are going to get lost. So you hang on to copies in case you have to retransmit them. And then you want to know, how do I know when to stop sending, how do I know when to throw away the copies you’ve kept. Because, you know, the guy on the other end has received them. And you get this brilliant idea: you have the guy at the other end send you a postcard saying, I’ve got everything up to, you know, postcard number 420. And then you realise, that postcard might get lost. So now you decide, well, I guess I’ll just look at my watch. And if I haven’t gotten any responses back from the other guy, I’m going to start sending copies until I DO get a postcard that says, I got everything up to number 420. So that’s the basic timeout retransmission recovery mechanism. You can filter things out, because you know which postcards you got. If a duplicate shows up, you can ignore that. Then the only other thing to worry about is the case where you have 1,000 page book, and you cut it up into 2,000 postcards. And you take them to the post office, and you give them to the post office all at once. And by a miracle the post office tries to deliver all of them at the same time on the same day. And, you know, they don’t fit in the post box at the destination, and some of them fall on the floor and the dog eats them or they get blown away by the wind. So you have an agreement with your friend that you won’t send more than 200 at a time. Until you get a postcard back saying, I got all of those, you can send some more. That’s called flow control. So now you know how the internet works, that’s all there is too it. Well, I left out a little bit. There’s this domain name system. You know, how when you type URLs and things like that, in the middle are domain names like www dot google dot com. There’s a whole hierarchical structure of servers that are scattered throughout the internet that your browser essentially applies to, or your email application, and says, I’m trying to send an email to someone at google.com. Or I’m trying to go to google.com to do a search. You can’t get there using the domain name. Your computer actually has to go and consult with the domain name service and say, what’s the numerical IP address of the destination? So domain name look-ups produce a numerical address, which the TCP/IP protocols use in order to send packets back and forth across the network. And so that turns out to be a very important part of the network as well. So you have the basic transport stuff. You have the internet packets. You have the TCP protocol to maintain things in order and to recover from failures. And you have the domain name system to figure out where things are supposed to go, but it’s easier to remember the domain name than it is the number. And finally you have the routing algorithms. And that’s basically the components of the internet that make it work. So in 1977, I’m now at the Defence Department running the programme - and I’ve been at it now since 1973 at that point. And I really, really wanted to be able to demonstrate that this stuff actually worked. We’d only done pairwise tests among the various nets. And to be honest with you, if you take 2 packet networks and you’re just trying to connect 2 of them together, you could probably build a box in between them and do some crazy thing, and it would make it work. But I wanted to show that a standardised box - which we called a gateway at the time, because we didn’t know they were supposed to be called routers - would work with multiple networks of different types. So we had the mobile packet radio network in the Bay area, with the van going up and down the Bayshore Freeway, radiating packets through the gateway into the ARPANET. By this time, the ARPANET had been extended by an internal synchronous satellite link all the way to Sweden and Norway. And then down to London by landline, where there was another gateway that connected the extended ARPANET, back across the packet satellite network over the Atlantic. Back to the ARPANET in the US into another gateway. And then all across the ARPANET to USC Information Sciences Institute in Los Angeles. Now, between the mobile packet radio van and Los Angeles it's about 400 miles. But if you follow the path of the packet, it’s gone 100,000 miles, because it’s gone up and down through synchronous satellite level twice, and then all across the Atlantic and the US as well. And it worked. And I remember jumping up and down saying, it works, it works - like it couldn’t possibly have worked. It's software and it’s a miracle when software works, so I was pretty excited about that. So this was the most important demonstration in the 1977 period. And, as I say, we standardised shortly thereafter. So another kind of time line, which I wanted to share, shows you some of the other participants in the growing internet programme. The ARPANET comes in ’69. The University of Hawaii did an ALOHANET system, based on shared radio channel in 1971. And they called it ALOHA because, basically, you transmitted whenever you wanted to. And if there was a collision and you didn’t hear a response, you assumed there was a collision and you retransmitted. And you were careful not to retransmit at a fixed time later, otherwise you’d have continuous collision. So, instead, what they did was to have a variable time out, so that if you had a collision with someone, the next time you each retried, it would be at a different time. And so ALOHA is a sort of a very hang-loose-kind of network. The packet satellite system was based on that same idea, using the synchronous satellite channel. A guy named Bob Metcalf visited the ALOHA facilitaty and decided that he could do the ALOHA system on a piece of coaxial cable. And he invented the Ethernet at Xerox Park in 1973, at 3 megabits a second - that was fairly impressive. And, of course, then we were going through all of our software development. We turned the internet on, on January 1st 1983. The National Science Foundation in the US decided, maybe this packet switching idea would be good to connect all of the universities in the US. So they built the NSFNET backbone to connect 3,000 universities around the United States, including some intermediate level networks. NASA and the Department of Energy also decided that they would adopt the TCP/IP protocols, replacing their High Energy Physics Network, HEPNET. It was for doing experiments with high energy physics. And so they replaced all of their networks with TCP/IP. And then, around 1989, I got permission to connect some commercial systems up to the government backbone. And in that year several commercial networks got started, UUNET, PSINET, and CERFNET. There’s a whole story behind CERFNET, and I won’t bother you with it right now. But I didn’t build it, they just borrowed my name and stuck it on it. They did ask permission. And I remember thinking if they mess it up, will I be embarrassed? And then I thought, wait a minute, people name their kids after other people, and if the kids don’t come out right, they don’t blame the people they named them after. (Laughter) So I said, go ahead. Go ahead and do it, it's ok. And it actually worked out alright. So this is what the internet looks like now. It’s this giant big ball of hundreds of thousands of networks. The reason that I wanted to show you this is that the colours represent just different networks. We call them autonomous systems, formally. But the thing is this is not a top-down system. And so the people, that run pieces of the internet, pick which hardware they want to use. They pick which software they want to use. They decide who they’re going to connect to and on what terms and conditions. And it just all comes together almost organically - which is what Bob Kahn and I hoped in the first place. We published our results in 1974 saying, if you can build something that works this way and find someone to connect to, it should work. And so what happened is the network grew in a very organic way. It only works because everybody is using the same protocols, even though their implementations might vary. So that’s how the internet has grown up until now. The World Wide Web is one of the most important applications of the network. And I want to distinguish between the 2, because some people get confused about that. The World Wide Web is what many of us use all the time. Tim Berners-Lee and Robert Cailliau at Cern built the first hypertext mark-up language and hypertext protocol implementation of browsers and servers at Cern, and nobody noticed, to be quite honest. However, 2 guys did notice. They were at the National Centre for Supercomputing Applications, Marc Andreessen and Eric Bina. They did what was called Mosaic, which was the first graphical user interface for a browser. It made the internet, or the World Wide Web, look like a magazine: It had formatted text, it had images; eventually it got video and audio and things like that. It was a very spectacular change in the interactions that people could have. And so a guy named Jim Clark, who had built Silicon Graphics in the Silicon Valley, saw this and brought Marc Andreessen and others from NCSA to the West Coast. They started Netscape Communications around 1994. They had their initial public offering in 1995, the stock went through the roof. It was the most spectacular IPO in history. And that started the Dot-Boom, which meant every venture capital company in the Valley and elsewhere, would throw money at anything that looked like it had something to do with the internet. It didn’t matter if they had a business model or anything else. There was a huge amount of money that went in. And a lot of companies failed around April of 2000, that was called the Dot-Bust. But what was interesting as I was tracking, you know, how big is the internet, and how much is it growing. And it was doubling every year for quite a long time - even through the Dot-Bust. Because people had real use for the underlying internet, even though a lot of companies failed because they didn’t really have a realistic business model. Just to point out to you about economics 101: Don’t spend any more money than you have, that’s point number 1. And the second one is: Don’t confuse capital for revenue. Revenue is continuous and capital runs out. And when you run out of capital and you don’t understand the difference, then you’re not surprised, or you are surprised that you’ve just gone bankrupt. So the system grew very, very rapidly in spite of the Dot-Bust. And, of course, all of you are using it today for many different purposes, including much of your scientific research. The internet itself, even though it was designed 40 years ago, is not static. It has continued to evolve in many ways, especially new protocols and new applications. Now I have to confess to you, that Bob Kahn and I did make at least one fairly major mistake – apart from little details in the protocol design. We were trying to figure out how many termination points that we’re going to need for this internet thing. And so, remember, it's 1973, and we’re writing our little design. And so we said, ok, how many networks will there be per country, because we were already thinking global. We’d just finished doing the ARPANET. And it was not cheap to build that, you know, on a nationwide scale. So we thought, well, maybe there’ll be 2 networks per country, because there’s sure to be some competition. And then we said, how many countries are there. We didn’t know, and there wasn’t any Google to ask. (Laughter) So we guessed at 128 because that’s a power of 2 and that’s a programmer's thinking. So 2 times 128 is 256, and that’s 8 bits. And then we said, how many computers will there be per network. And we thought, you know, let's go crazy, 16 million and that’s another 24 bits. So that’s 32 bits of address base that’s required. And we’re making this decision at a time when computers were great big expensive things. They were in air-conditioned rooms and they did not move around - so 16 million was pretty ambitious. And that actually worked ok. The 4.3 billion terminations of IP version 4, which is what you’re currently using mostly, lasted until 2011, and then we ran out. So, fortunately, the engineers, including me, started to get panicky around 1992, when we started seeing Ethernets all over everywhere. And, as I say, we developed the new version of protocol called IP version 6. And it has 128 bits of address space. I don’t have to tell you, you can do the math. You know, 3.4 times 10^38 addresses, which is the number that’s, you know, big enough for – even the Congress would appreciate that number. So we ended up – oh, by the way, some of you would wonder what happened to IP version 5? That was a protocol that was designed to do streaming video and audio. But it didn’t scale very well, so we abandoned that, and the next number was 6. So IP version 6 is the production version of the network. And that’s what you should be using. And if your ISP is not providing you with IPv6 servers, please pound on the table and say, give me a date certain when I can have IPv6 addresses. Because I need them for the internet of things, and the mobiles and everything else. So we were a bunch of Americans, and we only spoke English anyway. So all we had was ASCII characters for the domain names. But it was pointed out to us later, that there are some languages that can’t be expressed with ASCII characters. And we said, oh yeah, we forgot about that. So we added Unicode, which is what’s used in the World Wide Web in the domain names. So now you can have domain names in Russian and Cyrillic and Arabic and Hebrew and so on. The original generic top level domains were only 7, like .com, .net, .org, .edu, .mil, .gov and so on. But the Internet Corporation for Assigned Names and Numbers decided to open up the generic top level main space a couple of years ago. And they got 2,000 applications for new generic top level domains, things like .travel, .corporation and so on. Oh, and they charged $185,000 each, so $350 million came in upon opening up the top level domain space. There are additional things, which I don’t have time to go into much, except to say that there were security risks in the system, which had been designed in a very friendly environment, mostly engineers. We didn’t want to ruin everybody else’s stuff, and so we weren’t attacking anything. But once you released the internet into the global community, the bad guys are out there too. So we’ve been adding more mechanisms for defending against various forms of attack: against the domain name system and against the routing systems - those are the last 2 on the list. We’ve also been pushing 2 factor authentication. Especially at Google, where you have to have a device that will generate a cryptographic password, in addition to your user name and password. So even if somebody guesses your user name and password, they don’t have the little gadget that does the crypto password generation as well, and so they can’t penetrate the account. We’ve added transport layer security which encrypts the traffic on the TCP layer. And that inhibits the ability of somebody to snoop on what you’re sending through the network. And, of course, mobile smart phones and the internet of things have become part of the environment. Just a brief footnote on smart phones: The mobile phone was actually developed in 1973 by a guy named Marty Cooper working at Motorola. Bob Kohn and I didn’t know about that. But in 1983, Marty Cooper turned on the first mobile phone service. And, of course, his phone was about this big, it weighed 3½ pounds, and had a whip antenna on the top. And I called him up to ask some questions with one of his phones. And one question that I asked him was, how long does the battery last? And he said, 20 minutes - but its ok, you can’t hold the phone up longer than that anyway. (Laughter) They’ve gotten better since then. So we got launched at the same time. Mobil phones and the internet started, officially and formally, in 1983. But they really didn’t have anything to do with each other until 2007, when Steve Jobs came up with the iphone. And at this point now the phone is capable of interacting with the internet. And what’s interesting about this, of course, is that the 2 systems mutually reinforce their utility. The mobile phones apps use computer power on the internet. The internet is accessible from any mobile phone and any smart phone, and so the 2 making themselves more useful. And finally, of course, as time has gone on, people have started to use software instead of electromechanical devices for control, and that leads to the internet of things. Now, I will confess to you that in 1973, it did not occur to me that someone would want to attach their refrigerator to the internet, or a picture frame. I used to tell jokes that someday every light bulb will have its own internet address, ha, ha, ha. Except, now I can’t tell those jokes anymore. Philips makes one called Hue, which you control from your mobile, both the intensity and the colour of the bulb through the internet. So I did wonder, you know, what would you do with an internet-enabled refrigerator? And well, in America, the way we communicate in our families is to put paper and magnets up on the refrigerator door. So this improves things because now we can communicate with websites and blogs and email and things like that. But we also thought, what would happen if the refrigerator knew what it had inside? I mean, what if everything had a little RFID chip on it, and you could sense what was in the refrigerator. So when you’re out at work or off at school or something, the refrigerator is surfing the internet, looking for recipes that it could make with what it has inside. So when you come home you see the list of recipes on the display. That sounds pretty good, but a good engineer will always extrapolate to see what other things might happen. So you can imagine that you’re on vacation and you get an email. It’s from your refrigerator and it says that milk has been in there for 3 weeks, and it’s going to crawl out on its own if you don’t do something about it. Or maybe you’re shopping and your mobile goes off, it’s the refrigerator calling. And it says, don’t forget the marinara sauce, I have everything else I need for spaghetti dinner. I’m sorry to tell you that our Japanese friends have spoiled this idyllic vision of the future, because they invented an internet-enabled bathroom scale. And when you step on the scale it figures out which family member you are based on your weight. And it sends that information to the doctor and it becomes part of your medical record. Which is probably ok except for one thing: the refrigerator is on the same network. So, you know, when you come home and you see diet recipes coming up on the display. Or maybe it just refuses to open, because it knows you’re on a diet - it’s really bad. So in the lower right you see version 1 Google glass being modelled by Sergey Brin, the co-founder of Google. The reason I put this up is, of course, one thing: it’s an internet-enabled device. But what’s interesting about it is that it allows the computers to see what you see and hear what you hear. And that’s an interesting experiment. Because the possibility that the computer could understand what it was seeing and hearing, which again is pushing some of the limits of artificial intelligence, might mean that the computer could become part of the conversation. And so while you are having a dialogue with your colleagues and trying to argue over some particular design point or other speculation, you might be able to invoke the computer which would have context as a result. So it’s very much like Star Trek, you know, when Captain Kirk would say, computer. And you would hear Majel Roddenberry’s voice floating down from the ceiling. So this is actually an important experiment. And we’re in the middle of designing a new version, the Google glass. I left the guy in the middle for laughs though. This is an internet-enabled surfboard. I’ve not met this fellow. But I imagine him sitting on the water, waiting for the next wave, thinking, if I put a laptop in the surf board, I could be surfing the internet while I’m waiting for the next wave. (Laughter) So he put a laptop in the surfboard and he put a WiFi server back at the rescue shack, and now he sells this as a product. So what else is coming? Well, sensor networks are already with us. Some of you have them at home already: Sometimes it’s a security system, sometimes it’s heating, ventilation, and air conditioning. In my case I have an IPv6 self-organising radio network at home. Each room in the house has a sensor which also doubles as a little radio router. And every 5 minutes it's sampling temperature, humidity and light levels in the house and records that information through the network to a server down in my basement. I know, only a geek would do this. But the whole idea is, that at the end of the year, I now have good engineering information about how well the heating ventilation and air-conditioning works, so we can make adjustments instead of relying on anecdotal information. Now, one room in the house is the wine cellar. And there are 2,000 bottles of wine in there. So I care a great deal about keeping the temperature below 60 degrees Fahrenheit and the humidity up above 30 or 40%, to keep the corks from drying out. That room has been alarmed: if the temperature goes above 60 degrees Fahrenheit, I get an SMS on my mobile. And at one point, my wife Sigrid and I were away from the house, and I got the message saying, your wine is warming up. And nobody was there to reset the cooling system. So every 5 minutes for 3 days, I kept getting the message saying, your wine is getting warmer. So it got up to like 70 degrees or something which is not the end of the world, it’s not great. So I called the guys that made this system and I said, do you guys make remote actuators. And they said yes. So you know I’m thinking, I could remotely reset the cooler. And I said, do you do strong authentication? And they said yes. And I said, good, because there’s a 15-year-old next door and I don’t want him messing around with my heating and air conditioning system. So we installed that. And then I got to thinking, I can tell if somebody went in to the wine cellar because I can see that the light went off and on. But I don’t know what they did in there. So I thought, what can I do about that? And I said, aha, I put an RFID chip on each bottle, and then I will put an RFID detector in the wine cellar. So I can do a remote inventory, no matter where I am, to see if any bottles have left the cellar without my permission. So I’m boasting to one of my engineering friends about this brilliant design and he says, you have a bug. I said, what do you mean I have a bug? And he says, well, you could go into the wine cellar and drink the wine and leave the bottle. (Laughter) So now I have to put sensors in the cork. (Laughter) And as long as I’m going to do that I might as well sample the esters, which tell you whether or not the wine is ready to drink. So before you open the bottle you interrogate the cork. And if that’s the bottle that got up to 75 or 80 degrees, that’s the one you give to somebody that doesn’t know the difference. So this is actually, I mean, the future really is going to be heavy in sensor systems – all around, the buildings will be instrumented, the cars will be instrumented, manufacturing facilities. And even ourselves, our bodies, will be instrumented as well. And that will all be part of this vast quantity of information flowing around in the network. If we look over the next 20 years’ time - these are, of course, just guesses. But today we think there could be 10 to 15 billion devices that are capable of communicating on the net. They typically are not all on at once, necessarily, but there could be that many. And in 2036, 20 years from now, the numbers could reach a trillion. There will be on the order of maybe 8½ billion people in the world in 2036. And they might have anywhere from 100 to 110 devices, either on their persons, or at home, or in other places that they inhabit. So these numbers are not totally crazy. But they do certainly motivate the need to get to IPv6, because we need all that address space for all these devices. Here are some of the things that we’re experimenting with at Google. Our Verily Company, it’s experimenting with - it’s not manufacturing, but it’s experimenting with a contact lens which can sense the glucose level in the tears of your eyes. That’s related to the glucose level in your blood, although there’s a delay function associated with going from blood glucose to the tears of your eyes. The idea is that if you’re a type-1 diabetic and you’re tired of pricking your finger to take blood samples all the time, this is an alternative way of gathering the data. And since it’s a potentially continuous monitoring system, we can establish a baseline of what is normal for you. And then excursions away from the baseline can be detected very quickly. And so you can recover either by adding more insulin or eating something with sugar in it. So this idea of continuous monitoring, I think, is a very important theme, which you will see repeated over and over again. Continuous monitoring lets you see anomalies that you would not normally see if the sampling is too low a rate. If you think about the guys who never go to the doctor until they’re sick, really sick. And so the doctor’s model of you is you’re always sick. Because you never see the doctor when you’re healthy, you only see him when you’re sick. So this continuous monitoring could make a big difference. There are also Google self-driving cars. What you’re seeing here is model number 2. But I have a video showing you the first model, that we were testing with one of our blind employees, to see whether we could actually have the car drive our employee to work. So if I’ve done this right, I should be able to get the video to play. Nathaniel: Good morning Steve. Steve: Hey Nathaniel, how are you? Nathaniel: Doing just great. Nathaniel: Go ahead, Steve. Nathaniel: Here we go. Steve: Here we go. Steve: Look Ma, no hands. Nathaniel: No hands anywhere. Steve: No hands, no feet. Nathaniel: No hands, no feet, no nothing. Steve: I love it. Steve: So we’re here at the stop sign? Nathaniel: Yes, car is using the radars and laser to check and make sure there’s nothing coming either way. Steve: I find myself looking. Nathaniel: Old habits die hard. Steve: Hey, they don’t die. Anybody up for a taco? Nathaniel: Yeah, yeah, what do you want to do today Steve? Steve: I’m all for Taco Bell myself. Nathaniel: Alright, well let’s go get a taco at the drive-through. Steve: Now we’re turning into the parking lot? Nathaniel: Yeah. Steve: How neat. Nathaniel: There we go, now we kind of creep along here. Does anybody have any money? Steve: I’ve got money. Nathaniel: No, I’ve got my wallet right here. If you roll down your window and order a burrito. Yeah, push that. Waitress: How are you today? Steve: I’m doing very well, how are you today? Waitress: Good, thank you. Steve: This is some of the best driving I’ve ever done. Steve: 95% of my vision is gone, I’m well past legally blind. You lose your timing in life, everything takes you much longer. There are some places that you cannot go, there are some things that you really cannot do. Where this would change my life, is to give me the independence and the flexibility to go the places I both want to go and need to go when I need to do those things. Steve: You guys get out, I’ve got places now I have to go. Nathaniel: Bye now. (Laughter) Steve: And it's been nice. It's been really nice. You can imagine we’re pretty excited about all that, and hoping to keep at it. We have new models, as you can see, under development. There are other things that are happening, drones, for example, are everywhere. It sounds like we are still runing the video, doesn't it? Sorry about that. Oh no, it wants to take me all the way back to the beginning, I don't want to do that. Well, here we go, fast forward. (Laughter) There we are, drones - you all know about these, they’re all over the place. In the US it’s very exciting. The Federal Aviation Administration has been going a little crazy trying to figure out, what the rules are for what may become 27 million drones flying around in the US. I know Jeff Bezos wants to use the drones to deliver things for Amazon. I had dinner once with him. And I had this image of a cartoon that showed a drone hovering in front of somebody’s door. And sending a text message inside saying, I’m here with your delivery. And if you don’t open the door in the next 30 seconds I’m blowing it down. (Laughter) And Jeff laughed and I got nervous, that he might actually do that. I hope he doesn’t. So that’s another part of this internet of things. And then there’s project Loon, because it’s looney. These are balloons that Google has built, that are operating up to about 60,000 feet in the stratosphere. As they move up and down they’re blown in different directions, depending on the wind. And so we actually steer them by changing the altitude. The idea is that they are doing WiFi or LTE, long-term evolution radio communications, from the stratosphere. And the idea is that they circulate roughly given latitude. They look for tail winds to get to the next service point. And then they look for head winds to hover where they are. But they continue all the way around the world. We are in operation now in Sri Lanka. And we’ve been experimenting with this for about 4 years now. So the idea here is to provide access to internet in places that would be very difficult to bring fibre to – up in the Andes Mountains for example, or the Sahara desert, or the middle of the ocean for that matter. And finally, I thought I would show you the Boston Dynamics latest little robot. And this one is called Little Dog. That’s Big Dog behind him. Oh, we get the advertisements here - that's Google. That’s amazing, the stability of the head is incredible. Look at that, this is really impressive. There is a camera in the mouth that turns out. You don’t have to build these the way dogs are built. This is also pretty impressive, going upstairs is fairly straightforward for it. By the way there are 51 videos of these things on YouTube, in case you want to go look. Not just of the dog, but all the other robots these guys make. I have a little bit more that I want to show you. But what I am going to show you now is not a Google project. It’s a project that was started in the Jet Propulsion Laboratory in Pasadena. My colleagues and I began this work in 1998. I’ve been a visiting scientist there since that time. So this is the design and implementation of an interplanetary internet to support man, and robotic space exploration in the remainder of this 21st century. So we met right after the Pathfinder robot landed in 1997, successfully, on Mars. And this is after many, many attempts to get to Mars after the 1976 Viking Landers. And we got to speculating about this, because the communications to support the Pathfinder was a direct point-to-point link between Earth and Mars. Of course, that was a pretty limited kind of networking capability. We thought, what would happen if we had a richer networking environment, kind of like the internet? And we actually started out thinking that we could use the TCP/IP protocols - they worked on Earth, they ought to work on Mars. But when we started thinking about this, it didn’t work very well. Those protocols didn’t work very well between the planets. And it should be obvious to you, the speed of light is too slow. Between Earth and Mars, when we’re closest together, 3 ½ minutes one way delay. And when we’re farthest apart its 20 minutes one way, round trip time is 40 minutes. The TCP protocol was not designed to deal with a 40 minute round trip time for flow control. The flow control is really simple. When you run out of room you tell the other guy stop sending, I’ve run out of room. And if that’s only a few hundred milliseconds that’s great. But if it takes 20 minutes for that signal to get to the other guy, and he’s blasting stuff at you for 20 minutes full speed, the packets are falling on the ground and falling all over everywhere. So flow control didn’t work. Then there’s this other problem. The planets are rotating and we don’t know how to stop that. (Laughter) So if you’re talking to something on the surface and the planet rotates after a while, you have to wait till it comes back around again. Or if it’s an orbiter, it’s a problem. So by 2004, we had the 2 Rovers that were sent to Mars, Spirit and Opportunity. The original plan was to transmit data from the surface of Mars, the way we had with the Pathfinder. And the radios overheated, and everybody got all worried about that. And they were only rated at 28 kilobits a second. So the scientists were not too happy about that kind of data rate coming from the surface. And then we said we’re going to have to reduce the duty cycle, because we don’t want the radio to overheat and harm any of the other instruments or itself. So they were all upset. And one of the engineers at JPL said, well, there’s an expand radio on the Rover. And there’s also an expand radio on the Orbiters, which we had sent earlier to map the surface of Mars to figure out where the Rover should go. So we reprogrammed the Rovers and the Orbiters, so that when the Orbiter came overhead, the Rover would squirt data up to the Orbiter. And the Orbiter would hang on to the data and transmit it when it got to the right place in its orbit to reach the deep space network, which has big 70 metre dishes at 3 places on the surface of the Earth. That’s store and forward, and so we developed a whole suit of protocols, called the Bundle Protocol, to do that. The prototypes are actually running now, pulling all the data back from Mars. And when we dropped the Phoenix Lander on to the North Pole there wasn’t any configuration that had a direct path back to Earth. So we used the same set of protocols. And when the Mars Science Laboratory landed, we did it again. So all the data that’s coming back from Mars is going through the prototype, Bundle Protocols of the interplanetary system. We’ve uploaded those protocols on to the international space station. We’ve had the astronauts using the Bundle Protocols, the Interplanetary Protocols, to control Rovers on the surface of Earth in real time, because the distance is fairly small. They’re using the interplanetary protocols which work just fine over short delays, just like TCP does. But they also work over these long invariably connected systems. So what we’re hoping, frankly, over time is that as – oh we’ve standardised the protocols with the Consultative Committee for Space Data Systems. So now anyone can get access to them: They’re fully standardised. The protocols are available. The implementations are available on source boards for free for anyone who wants to download them and use them. In fact, there’s a German university that’s implemented these for android mobile phones as well. So what we’re hoping is that, as new missions get launched by the spacefaring countries of this planet, that they will adopt these protocols and use them for their missions. Or even, if they don’t use them for the scientific mission, if they could reprogram the spacecraft after they’ve finished their primary missions, they could become nodes in an interplanetary backbone. So we will literally grow the backbone over time as new missions get launched to the solar system. So that’s the up to the minute story on the interplanetary internet. And that is my last slide. So I’ll finish and thank you all very much for your time.

Ich sehe schon, ich muss erst den Computer davon überzeugen, dass ich es bin - einen Moment, bitte. (Gelächter) Alles klar. Zunächst einmal - Sie haben wahrscheinlich keine Ahnung, wie das ist. Gut, einige von Ihnen waren schon hier oben. Aber für mich ist das sehr einschüchternd. Ich hatte noch nie ein Publikum, das aus so vielen Nobelpreisträgern und gescheiten Leuten gleichzeitig bestand. Ich hoffe, dass ich das einigermaßen gut hinkriege. Stefan Hell hielt im letzten Jahr am Heidelberg Laureate Forum einen wirklich spektakulären Vortrag über optische Mikroskopie. Ich fühle mich also ganz schön unter Druck gesetzt. Zu Beginn werde ich versuchen, etwas aus der Geschichte des Internets zu erzählen, damit Sie eine Vorstellung davon bekommen, wie es entstanden ist. Und dann mache ich mir ein paar Gedanken darüber, wie es sich in der Zukunft weiterentwickelt. Ich möchte Sie erst einmal daran erinnern, dass es ein Vorgängersystem namens ARPANET gab. Die Defence Advanced Research Project Agency (Behörde für Forschungsprojekte, die Verteidigungszwecken dienen), die zu unserem Verteidigungsministerium in den USA gehört, begann damit, die Möglichkeiten der Computer-Vernetzung zu erforschen. Und dafür hatte sie einen handfesten Grund. Sie finanzierte in den Sechzigerjahren ein Dutzend Computer-Wissenschaftsabteilungen, die auf den Gebieten künstliche Intelligenz und Computerwissenschaft forschen sollten. Und alle verlangten alljährlich die modernste Computerausstattung. Da sagte die Behörde: Wir können nicht jedes Jahr für zwölf Wissenschaftsabteilungen 12 neue Computer kaufen. Wir bauen ein Netzwerk auf, und ihr müsst euch eure Ressourcen teilen. Darauf ging man zunächst nur zögernd ein, da man dachte: Wenn wir unsere Ressourcen teilen müssen, können die anderen unsere Arbeit sehen. Und sie stehlen unsere Software oder unseren Code, oder sie verbrauchen alle Zyklen. Und die ARPA sagte: "Nur die Ruhe, wir finanzieren euch alle; es geht hier nicht um Wettbewerb. Wir möchten, dass ihr eure Erfahrungen und euer Fachwissen untereinander austauscht, um den Forschungsfortschritt zu beschleunigen." So entstand das ARPANET, und es war erfolgreich. Nach dem Erfolg des ARPANET merkte man, dass sich Computer möglicherweise auch zur militärischen Führung eigneten. Wenn man nämlich mithilfe von Computern seine Ressourcen besser einsetzt als der Gegner, ist man vielleicht in der Lage, einen größeren Gegner mit einer kleineren Truppe zu schlagen, da man so deren Fähigkeiten besser erweitert. Wir nennen das einen Kraftmultiplikator. Aber dafür müssten sich die Computer in Flugzeugen, in Schiffen auf hoher See und in Fahrzeugen befinden. Zu jenem Zeitpunkt aber waren für ARPANET nur ortsfeste Anlagen gebaut worden. Das ist also der Hintergrund, warum das Verteidigungsministerium, und vor allem ARPA, daran interessiert war, dieser Sache nachzugehen. Alles beruht auf dem Konzept der Paketvermittlung. Sie nutzen es alle, ob Sie das wissen oder nicht. Einige verstehen nicht ganz, wie das funktioniert; dabei ist es wirklich sehr einfach. Wenn Sie wissen, wie Postkarten verschickt werden, dann wissen Sie auch, wie die Internetpakete im Wesentlichen funktionieren. Zunächst einmal haben sie - wie eine Postkarte - keine Ahnung davon, wie sie transportiert werden. Eine Postkarte weiß nicht, ob sie in einem Flugzeug, in einem Schiff auf hoher See, auf dem Rücken eines Postboten oder mit dem Fahrrad unterwegs ist. Und die Internetpakete wissen auch nicht, wie sie transportiert werden. Sie wissen nicht, ob es eine Glasfaser, eine Satellitenverbindung, ein Funkkanal oder ein Ethernet-Kabel ist – und es ist ihnen auch egal. Das System wurde sorgfältig daraufhin ausgelegt, dass diese Internetpakete nie wissen, wie sie transportiert werden. Wie eine Postkarte wissen auch die Internetpakte nicht, was auf ihnen geschrieben ist. Das erwies sich als ein äußerst leistungsstarkes Instrument, weil die Bedeutung der Internetpakete nur an den Enden des Netzes interpretiert wird, durch die Computer, die sie senden oder empfangen. Das bedeutet: Wenn man eine neue Anwendung entwickelt, muss man nur die Software an den Enden des Netzes ändern, wo sich die Host-Computer befinden. Man muss nicht das Netzwerk ändern, da die Anwendung dem Netzwerk gleichgültig ist. Das eröffnet eine Vielzahl von Möglichkeiten. Wenn man eine neue Anwendung erfinden möchte, muss man nicht das ganze Netzwerk ändern. Postkarten behalten auch ihre Reihenfolge nicht bei. Sie stecken zwei Postkarten in den Briefkasten, und die kommen möglicherweise in einer anderen Reihenfolge heraus. Manchmal kommen sie auch überhaupt nicht heraus. Damit hat man dieses ungeordnete, unzuverlässige System elektronischer Postkarten. Das ist im Wesentlichen die Paketvermittlung. Sie fragen sich vielleicht, wie irgendjemand daraus etwas Nützliches machen kann. Und ich werde Ihnen hoffentlich zeigen, wie das funktionieren kann. Die ursprüngliche, erste Installation des ARPANET hatte 4 Knoten. Ich war damals an der UCLA als Student - wie viele von Ihnen. Um 1969 schrieb ich die Software zur Verbindung des Computers Sigma 7 mit dem ersten über das ARPANET verschickten Paket. Der Sigma 7 ist jetzt irgendwo in einem Museum. Manche glauben, da gehöre ich auch hin, (Gelächter) aber ich bin hier. Das war also der Anfang - das Netzwerk mit nur 4 Knoten. Es wurde im Lauf der Zeit rasch größer. Links sehen Sie, wie eine Paketvermittlung aussah. IMP stand für „Interface Message Processor", heute nennen wir sie Packet-Switches oder Router. Das hatte damals die Größe eines Kühlschranks. Und Sie erkennen, dass sich die Dinge in den dazwischenliegenden etwa 40 Jahren geändert haben. Heute können Sie einen Router in der Hand halten; er hat etwa die Größe eines einfachen Ethernet-Steckers. Und natürlich kostet er weniger - damals kosteten die Geräte 100.000 Dollar. So haben sich die Dinge geändert - in 40 Jahren. Das sieht man übrigens immer wieder: Normalerweise ist alles, was neu entwickelt wird, groß und teuer. Und die Erfahrung zeigt: Wenn es sich bewährt, wird es immer billiger und oft viel kleiner. Sie sehen also die Entwicklung von teuren Geräten, die zunächst Institutionen, vielleicht Ministerien vorbehalten sind – und am Ende haben alle solche Geräte und tragen sie mit sich herum. Wir waren natürlich auch mit mobiler Kommunikation befasst. Deshalb errichteten wir neben dem ursprünglichen ARPANET ein Paketfunknetz, das um die Bucht von San Francisco betrieben wurde. Wir hatten Repeater oben auf den Berggipfeln, und dieser unscheinbare Lastwagen transportierte in seinem Inneren die Ausrüstung, die ich Ihnen hier zeige. Diese Dinge hier und da, das sind Paketfunkgeräte - sie sind etwa so groß. Das sind Dinge von der Art, wie man sie heute in die Tasche steckt. Doch damals war die Ausrüstung noch nicht ganz so kompakt. Wir erreichten etwa 100 bis 400 Kilobit pro Sekunde bei 1710 bis 1850 Megahertz. Und wir modulierten das bei ziemlich hohen Geschwindigkeiten. Wir wollten aber nicht nur Daten herumschicken, da wir erkannten, dass wir für militärische Führungszwecke Ton- und Bildübertragung brauchten. Und so experimentierten wir in den Siebzigerjahren mit paketiertem Audio und Video. Die Tonexperimente waren ziemlich interessant, da ein typischer Sprachkanal etwa 64.000 Bits pro Sekunde überträgt. Man sampelt den Ton bei 8.000-mal pro Sekunde und nimmt 8 Datenbits pro Sample. Im Backbone des ARPANET standen uns nur 50 Kilobit zur Verfügung, im Paketfunknetz 100 Kilobit. Um mehr Sprachkanäle in das System zu bringen, beschlossen wir, den Ton bis auf 1.800 Bits pro Sekunde zu komprimieren. Hierzu gestalteten wir die Tonspur als Stapel von 10 Zylindern, deren Durchmesser sich veränderte, wenn der Ton bzw. die Sprache erzeugt wurde. Dieser kleine Zylinderstapel wurde durch eine die Tonhöhe ändernde Frequenz angeregt. Wir schickten die Durchmesser all dieser Modellzylinder zur anderen Seite hinüber. Damit senkten wir die Datenübertragungsrate auf 1.800 Bits pro Sekunde. Sie können sich allerdings vorstellen, dass die Tonqualität ziemlich darunter leidet, wenn man von 64 Kilobit auf 1.800 Bit zurückgeht. Jeder, der durch das System sprach, klang wie ein betrunkener Norweger – und ich hoffe, ich habe jetzt keine Norweger im Publikum beleidigt. Es war zu verstehen, aber der Sound war schon sehr speziell. Schließlich war es so weit: Als ich damals im Verteidigungsministerium arbeitete, sollte ich dieses System ein paar Generälen im Pentagon vorstellen. Ich weiß noch, wie ich dachte: Wie mache ich das? Und dann fiel mir ein, dass einer meiner Kollegen, die am Paketton arbeiteten, Ingvar Lund vom norwegischen Institut für Verteidigungsforschung war. Wir ließen Ingvar zuerst durch das normale Tonübertragungssystem sprechen. Dann ließen wir ihn durch unser Pakettonsystem sprechen, und es hörte sich ganz genauso an. Wir verrieten den Generälen nicht, dass durch dieses System jeder so klingen würde. (Gelächter) Wie Sie rechts sehen können, sind aus diesen großen, unhandlichen Geräten, die man in einem großen Lastwagen transportieren musste, Dinge geworden, die wir in unsere Tasche stecken oder uns sogar ums Handgelenkt binden. Nochmal: Diese Entwicklung von groß und teuer zu klein, tragbar und häufig für den Einzelnen erschwinglich gibt es nach wie vor. Wir wollten außerdem mit Schiffen auf hoher See in Verbindung treten und kamen zu dem Schluss, dass hierfür Satelliten die geeignete Technik waren, da man damit große Entfernungen überbrücken kann. Wir verwendeten ein Standard-Satellitensystem, Intelsat IV-A; wir mieteten Kapazitäten in diesem Netzwerk. Und wir hatten mehrere Bodenstationen, die alle um dieselben Satellitenkanäle stritten. Es war so etwas wie ein Ethernet im Himmel. So konnten wir mit großräumiger Paketvermittlung über einen Satellitenkanal experimentieren. Damit hatten wir 3 verschiedene Netzwerke: Paketfunk, Paketsatellit und das ARPANET. Sie arbeiteten alle mit unterschiedlichen Geschwindigkeiten, hatten unterschiedliche Fehlerquoten und unterschiedliche Paketgrößen. Bob Kahn und ich hatten das Problem zu lösen, wie wir all diese verschiedenen Netzwerke als ein Netzwerk erscheinen lassen konnten, auch wenn sie sich alle deutlich voneinander unterschieden. Damit Sie sich eine Vorstellung davon machen, welche Aufgabe vor uns lag: Im Jahr 1969 beginnt der Aufbau des ARPANET. Und dann, in den Jahren 1973/74, nach 3 oder 4 Jahren Erfahrung mit dem ARPANET, fertigten Bob Kahn und ich den ersten Entwurf des TCP-Protokolls, aus dem später TCP/IP wurde. Danach, in der Zeit von 1975 bis 1978, waren wir damit beschäftigt, die Protokolle immer wieder neu zu installieren, zu testen, zu verfeinern und zu korrigieren. Wir fanden zahlreiche Fehler, die wir nicht erwartet hatten. Gleichzeitig arbeiteten viele verschiedene Institutionen mit uns zusammen. Wenn also jemand behauptet, das Internet sei eine rein amerikanische Erfindung, dann stimmt das nicht. Wir hatten überall Kollegen: in Europa, in Asien, einige in meinem Stanforder Labor, bevor ich zur ARPA kam, und anderswo. Es tat sich also sehr viel. Nachdem wir uns schließlich auf die Versionen festgelegt hatten, die Sie heute meistens verwenden – Sie nutzen, grob gesagt, das Internet-Design des Jahres 1978 -, begannen wir damit, diese Protokolle auf jedem Betriebssystem zu installieren, das wir finden konnten. Und im Jahr 1982 konnten wir ankündigen, dass jeder, der diese Systeme nutzte, zu den neuen TCP-Protokollen zu wechseln hatte, um im Programm zu bleiben. Am 1. Januar 1983 schalteten wir das Internet ein. Es ist seit 1983 in Betrieb, obwohl es nur für die Forschungsgemeinde und das Militär erkennbar war. Das Internet hat noch eine weitere bedeutende Eigenschaft: Es ist geschichtet. Die niedrigsten Schichten sind der physische Transport über Glasfaser oder Funkverbindungen und ähnliche Dinge. Dann die Schicht des Internet-Protokolls - das sind die elektronischen Postkarten – jene Dinge, die über das Netzwerk verschickt werden und zwischen den Hosts hin- und herwandern. Über dieser Schicht sind die Protokolle, die für eine stärker disziplinierte Umgebung sorgen. Und schließlich Protokolle, die Anwendungen installieren. Das ist also eine mehrschichtige Architektur. Es sind im Wesentlichen 5 Schichten, wenn Sie so wollen: die physische Schicht, die Disziplin, die Bits und schließlich die IP-Schicht sowie Transport und Anwendung. Physisch funktioniert es so, dass die Hosts an den Enden des Netzes alle Protokollschichten bis hin zur Anwendungsschicht implementieren. Aber Sie stellen fest, dass die Dinge in der Mitte des Netzes, die für die Übermittlung der Internetpakete zuständig sind, nichts über Protokolle der Transportschicht oder Anwendungsprotokolle wissen. Alles, was sie sehen, sind Internetpakete, diese kleinen elektronischen Postkarten. Ihre Aufgabe ist also sehr einfach. Wenn sie eine Postkarte erhalten, sehen sie nach, wohin sie gehen soll. Sie sehen in eine Tabelle, die durch ein im Hintergrund laufendes Routing-Protokoll erzeugt wird, und schicken das Paket in die Richtung, die ihnen die Tabelle vorgibt. Das ist ein ganz einfaches Konzept. Und diese Einfachheit, denke ich, hat dafür gesorgt, dass das System nicht nur im Lauf der Zeit skaliert wurde, sondern schon seit mehr als 30 Jahren Bestand hat. Hier sehen Sie noch ein Bild der geschichteten Protokoll-Architektur. Wichtig ist der kleine Kerl in der Mitte namens Internet-Protokoll. Was ich mit diesem Bild herausstellen möchte: Da sich die Schicht des Internet-Protokolls nicht darum kümmert, wie die darunter liegenden Schichten funktionieren, wird angenommen, dass die darunter liegenden Schichten, wenn man ihnen ein Paket aushändigt, irgendwie an diesem Kanal entlangwandern, von Router zu Router zu Router und zum Ziel-Host. Die Folge dieser Entscheidung war: Jedes Mal, wenn ein neues Kommunikationsprotokoll oder eine neue Übertragungstechnik auftauchte, schoben wir sie einfach ins Internet. Dem Internet war das gleichgültig, es merkte nicht einmal, dass es etwas Neues gab. Es war nur eine weitere Art, Bits zu transportieren. Dass das Internet-Protokoll nichts von den Anwendungen weiß, bedeutete gleichzeitig, dass jemand, der eine neue Anwendung erfinden wollte, keine Erlaubnis von jedem Internet-Service-Provider der Welt benötigte. Sie mussten die Anwendung nur an den Enden des Netzes implementieren und dann Pakete hin- und herschicken. Als Larry und Sergey in ihrem Schlafsaal an der Stanford University Google starteten, mussten sie also nicht mit jedem Internet-Service-Provider der Welt verhandeln. Sie stellten den Dienst einfach ins Netz, und die Leute konnten ihn ausprobieren. Deshalb kommt aus dem Internet eine derartige Fülle von Anwendungen, obwohl es weltweit buchstäblich hunderttausende von Internet-Service-Providern gibt. Um das Internet-Protokoll stärker zu disziplinieren - Sie erinnern sich: es ist verlustbehaftet, es verliert Dinge, verändert deren Reihenfolge und was sonst noch alles -, legten wir eine weitere Protokollschicht namens TCP oben drauf. Sie können leicht verstehen, wie das funktioniert, wenn Sie sich das Problem vorstellen, über ein Postamt, das nur Postkarten transportiert, ein Buch zu versenden. Was würden Sie tun? Das erste Problem besteht darin, dass Sie die Seiten des Buchs zuschneiden müssen, damit sie auf die Postkarte passen. Dann stellen Sie fest, dass nicht alle Postkarten Seitenzahlen haben - Sie haben ja die Seiten zugeschnitten. Sie werden also durcheinander geraten, weshalb Sie jede Postkarte nummerieren - 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Sie wissen auch, dass einige Postkarten verloren gehen werden. Sie behalten also Kopien für den Fall, dass Sie sie erneut übersenden müssen. Und dann wollen Sie wissen: Woher weiß ich, wann ich die Übertragung beenden und die Kopien wegwerfen kann, weil der Empfänger am anderen Ende alles erhalten hat? Und Sie haben eine brillante Idee: Sie lassen sich vom Empfänger am anderen Ende eine Postkarte schicken, auf der steht: Ich habe alles, sagen wir, bis zur Postkarte 420 erhalten. Dann fällt Ihnen ein, dass auch diese Postkarte verloren gehen könnte. Und jetzt beschließen Sie: Na gut, ich denke, ich schaue einfach auf meine Uhr. Wenn ich keine Antwort vom Empfänger bekomme, sende ich so lange Kopien, bis ich TATSÄCHLICH eine Postkarte erhalte, auf der steht: Ich habe alles bis Nummer 420 erhalten. Das ist im Wesentlichen der „Timeout Retransmission Recovery“-Mechanismus. Sie können aussortieren, weil Sie wissen, welche Postkarten Sie erhalten haben. Wenn ein Duplikat auftaucht, können Sie es ignorieren. Das Einzige, worum Sie sich dann noch Sorgen machen müssen, ist, wenn Sie ein Buch mit 1.000 Seiten haben, das Sie in 2.000 Postkarten zerschneiden. Die bringen Sie zur Post und geben alle gleichzeitig auf. Und es geschieht ein Wunder: Das Postamt versucht, alle am selben Tag gleichzeitig zuzustellen. Am Ziel passen aber nicht alle in den Briefkasten – ein paar fallen auf den Boden und werden vom Hund gefressen, oder der Wind weht sie weg. Sie vereinbaren also mit Ihrem Freund, dass Sie nicht mehr als 200 gleichzeitig senden. Sie können erst dann mehr versenden, wenn Sie eine Postkarte erhalten, auf der steht: "Ich habe diese 200 bekommen, du kannst wieder was schicken." - Das nennt man Flusskontrolle. Jetzt wissen Sie, wie das Internet funktioniert, das ist alles. Na gut, ich habe etwas ausgelassen: es gibt dieses System der Domainnamen. Wenn Sie eine URL eintippen, ist in der Mitte ein Domainname, etwa www. google. com. Es gibt eine hierarchische Struktur von über das ganze Internet verstreuten Servern, an die sich Ihr Browser oder Ihre E-Mail-Anwendung wendet und sagt: Ich versuche, jemandem unter google.com eine E-Mail zuzusenden. Oder: Ich versuche, google.com aufzurufen und eine Suche durchzuführen. Mit dem Domainnamen kommen Sie dort nicht hin. Ihr Computer muss sich mit dem Domain-Name-Service in Verbindung setzen und nach der numerischen IP-Adresse des Ziels fragen. Das Nachschlagen eines Domainnamens produziert eine numerische Adresse, die von den TCP/IP-Protokollen zum Hin- und Herschicken von Paketen im Netzwerk verwendet wird. Wie sich zeigt, ist das ebenfalls ein sehr wichtiger Teil des Netzwerks. Es gibt also den Transport als Grundlage. Es gibt die Internetpakete. Es gibt das TCP-Protokoll, damit die Dinge nicht durcheinander geraten und nach Ausfällen wiederhergestellt werden. Es gibt das System der Domainnamen, um herauszufinden, wo etwas hingehen soll – der Domainname ist leichter zu merken als die Nummer. Und schließlich gibt es die Routing-Algorithmen. Das sind im Wesentlichen die Bestandteile des Internets, die dafür sorgen, dass es funktioniert. Wir schreiben das Jahr 1977 - ich bin im Verteidigungsministerium und betreibe das Programm, und zwar seit 1973. Und ich will unbedingt zeigen können, dass diese Sache tatsächlich funktioniert. Bis jetzt hatten wir nur paarweise Tests zwischen den verschiedenen Netzen durchgeführt. Und um ehrlich zu sein: Wenn man 2 Paketnetze nimmt - wenn man nur versucht, 2 von ihnen miteinander zu verbinden, kann man wahrscheinlich auch eine Schachtel zwischen sie stellen und ein paar verrückte Sachen machen, um dafür zu sorgen, dass es funktioniert Ich wollte aber zeigen, dass eine standardisierte Schachtel - die wir zu jener Zeit Gateway nannten, da wir nicht wussten, dass sie einmal Router genannt werden sollte - mit vielen Netzwerken unterschiedlicher Art funktionieren würde. Wir hatten also dieses mobile Paketfunknetz in der Gegend der Bucht von San Francisco, mit dem Lastwagen, der auf dem Bayshore Freeway hin- und herfuhr, und strahlten über das Gateway Pakete ins ARPANET aus. Zu jener Zeit war das ARPANET durch eine interne synchrone Satellitenverbindung bereits bis nach Schweden und Norwegen erweitert worden. Dann ging es über eine Festnetzleitung nach London, wo ein anderes Gateway über das Paketsatellitennetz eine Verbindung über den Atlantik mit dem erweiterten ARPANET herstellte, zurück ins ARPANET in den USA, in ein anderes Gateway, und dann über das ARPANET zum USC Information Sciences Institute in Los Angeles. Zwischen dem Lastwagen mit dem mobilen Paketfunk und Los Angeles liegen etwa 400 Meilen. Wenn man aber den Weg des Pakets verfolgt, hat es 100.000 Meilen zurückgelegt, denn es ist zwischen synchronen Satelliten zweimal hin- und her- und dann über den Atlantik in die USA gewandert. Und es hat funktioniert. Ich weiß noch, wie ich auf- und abgesprungen bin und gerufen habe: Es klappt, es klappt – als ob es möglich gewesen wäre, dass es nicht funktioniert hätte. Es ist Software, und wenn Software funktioniert, ist das ein Wunder. Ich war also ziemlich begeistert. Das war die bedeutendste Veranschaulichung in der Zeit um 1977. Wie ich schon sagte, haben wir kurz danach standardisiert. Einer anderen Zeittafel, die ich Ihnen zeigen wollte, sind die Namen der anderen Teilnehmer am wachsenden Internetprogramm zu entnehmen. Das ARPANET kommt im Jahr 1969. Die University of Hawaii errichtete im Jahr 1971 das auf einem gemeinsam genutzten Funkkanal basierende ALOHANET. Sie nannten es ALOHA, weil man zu jeder beliebigen Zeit etwas übertragen konnte. Wenn es eine Kollision gab und man keine Antwort hörte, vermutete man eine Kollision und übertrug die Sendung erneut. Dabei achtete man darauf, die erneute Übertragung nicht zu einer bestimmten späteren Zeit vorzunehmen, da es sonst zu einer permanenten Kollision kam. Stattdessen gab es eine variable Auszeit – hatte man also mit jemandem eine Kollision, würden die nächsten Versuche zu verschiedenen Zeiten stattfinden. Damit ist ALOHA so etwas wie ein sehr locker verbundenes Netzwerk. Das Paketsatelliten-System mit der Nutzung des synchronen Satellitenkanals beruhte auf derselben Idee. Als eines Tages jemand namens Bob Metcalf die ALOHA-Einrichtung besuchte, kam er zu dem Schluss, dass er das ALOHA-System mit einem Stück Koaxialkabel machen konnte. Dann machten wir alle unsere Software-Entwicklungen durch. Am 1. Januar 1983 schalteten wir das Internet ein. Die National Science Foundation in den USA kam zu dem Schluss, dass mit dieser Idee der Paketvermittlung alle amerikanischen Universitäten miteinander verbunden werden konnten. Sie errichtete den Backbone NSFNET zur Verbindung von 3.000 Universitäten in den Vereinigten Staaten, einschließlich einiger Netzwerke auf mittlerer Ebene. Die NASA und das Energieministerium entschlossen sich ebenfalls zur Übernahme der TCP/IP-Protokolle als Ersatz für ihr High Energy Physics Network, HEPNET. Es diente der Durchführung von Experimenten im Bereich der Hochenergiephysik. Sie ersetzten alle ihre Netzwerke durch TCP/IP. Etwa im Jahr 1989 erhielt ich dann die Erlaubnis, einige kommerzielle Systeme an den staatlichen Backbone anzuschließen. Dieses Jahr war der Beginn für einige kommerzielle Netzwerke wie UUNET, PSINET und CERFNET. Hinter CERFNET verbirgt sich eine lange Geschichte, mit der ich Sie jetzt verschonen will. Ich habe es nicht aufgebaut - sie haben sich nur meinen Namen ausgeliehen und ihn draufgeklebt. Sie haben mich natürlich um Erlaubnis gebeten. Ich weiß noch, wie ich dachte: "Wenn es den Bach runtergeht, wird es mir schaden?" Und dann dachte ich: gibt man die Schuld nicht denen, nach denen man sie genannt hat." (Gelächter) Ich sagte also: "Na gut, macht es, es ist in Ordnung." Und es klappte gut. So sieht das Internet heute aus. Es ist dieser gigantische Ball aus hunderttausenden von Netzwerken. Ich zeige Ihnen das deshalb, weil die Farben für verschiedene Netzwerke stehen. Offiziell nennen wir sie autonome Systeme. Aber die Sache ist die: Das ist kein hierarchisches System. Wer am Internet mitmacht, sucht sich die Hardware aus, die er nutzen möchte. Er sucht sich die Software aus, die er nutzen möchte. Er entscheidet, mit wem er sich zu welchen Bedingungen verbindet. Das alles wächst fast organisch zusammen - was Bob Kahn und ich von Anfang an gehofft hatten. Wir veröffentlichten unsere Ergebnisse im Jahr 1974 und erklärten: Wenn man etwas aufbauen kann, das so funktioniert und jemanden findet, mit dem man sich verbinden kann, dann sollte es funktionieren. Das Netzwerk wuchs dann auf sehr organische Art und Weise. Es funktioniert nur, weil alle dieselben Protokolle nutzen, auch wenn sie unterschiedliche Anwendungen haben. So also ist das Internet bis heute gewachsen. Das World Wide Web ist eine der wichtigsten Anwendungen des Netzwerks. Ich lege Wert darauf, diese beiden Begriffe zu unterscheiden - manche Menschen bringen das durcheinander. Das World Wide Web ist das, was viele von uns die ganze Zeit nutzen. Tim Berners-Lee und Robert Cailliau entwickelten die erste Hypertext Markup Language am CERN, wo sie auch das Hypertext-Protokoll in den dortigen Browsern und Servern installierten - was niemand mitbekam, um ehrlich zu sein. Zwei Männer allerdings bekamen es mit. Sie arbeiteten am National Centre for Supercomputing Applications - Marc Andreessen und Eric Bina. Dort entwickelten sie etwas namens Mosaic, die erste grafische Benutzeroberfläche für einen Browser. Damit gaben sie dem Internet bzw. dem World Wide Web das Aussehen einer Zeitschrift: Es gab formatierten Text, es gab Bilder, und schließlich kamen Video und Audio dazu. Das war eine denkbar spektakuläre Veränderung der zwischen Menschen möglichen Interaktionen. Ein Mann namens Jim Clark, der Silicon Graphics im Silicon Valley aufgebaut hatte, sah das und brachte Marc Andreessen und andere vom NCSA an die Westküste. Um das Jahr 1994 hoben sie Netscape Communications aus der Taufe. Die Aktie schoss durch die Decke. Es war der spektakulärste Börsengang der Geschichte. Und es war der Beginn der Dotcom-Blase. Jedes Venture Capital-Unternehmen im Valley und anderswo pumpte Geld in alles, was so aussah, als hätte es irgendetwas mit dem Internet zu tun. Es spielte keine Rolle, ob es ein Geschäftsmodell oder dergleichen gab. Eine riesige Menge Geld wurde da hineingesteckt. Und viele Unternehmen gingen im April 2000, als die Blase platzte, pleite. Doch das Interessante an der Geschichte ist, wie groß das Internet ist und wie stark es wächst. Für eine ziemlich lange Zeit verdoppelte es sich in jedem Jahr, selbst nachdem die Blase geplatzt war. Denn die Menschen hatten einen echten Nutzen aus dem zugrundeliegenden Internet, auch wenn zahlreiche Unternehmen gescheitert waren, weil sie kein realistisches Geschäftsmodell hatten. Nebenbei: Zu Beginn eines wirtschaftswissenschaftlichen Studiums lernt man Folgendes: Geben Sie nicht mehr Geld aus als Sie haben, das ist das Erste. Und das Zweite ist: Verwechseln Sie nicht Kapital mit Umsatz. Umsatz ist stetig, Kapital geht zur Neige. Wenn Ihnen das Kapital ausgeht und Sie den Unterschied nicht verstehen, dann überrascht es Sie nicht, vielmehr dann sind Sie überrascht, dass Sie gerade pleite gegangen sind. Das System wuchs also sehr, sehr schnell, obwohl die Dotcom-Blase geplatzt war. Und natürlich nutzt es heute jeder von Ihnen für viele verschiedene Zwecke, auch für einen Großteil Ihrer wissenschaftlichen Forschung. Das Internet selbst ist nicht statisch, auch wenn es vor 40 Jahren entwickelt wurde. Es hat sich auf vielfache Weise weiterentwickelt, vor allem mit neuen Protokollen und neuen Anwendungen. Jetzt muss ich Ihnen gestehen, dass Bob Kahn und ich mindestens einen ziemlich großen Fehler begangen haben – abgesehen von Kleinigkeiten im Protokolldesign. Wir versuchten herauszufinden, wie viele Endstellen wir für dieses Internet brauchen würden. Sie erinnern sich, es ist das Jahr 1973 und schreiben unser kleines Design. Und wir fragten uns: Wie viele Netzwerke wird es pro Land geben? Schon damals dachten wir global. Wir waren gerade mit dem ARPANET fertig geworden, und es war nicht billig, dieses Netz landesweit zu errichten. Wir dachten: Vielleicht werden es 2 Netzwerke pro Land, denn es wird bestimmt etwas Wettbewerb geben. Und dann fragten wir uns: Wie viele Länder gibt es eigentlich? Das wussten wir nicht, und Google konnten wir auch noch nicht fragen. (Gelächter) Unsere Vermutung war 128, denn das ist eine Zweierpotenz. So denken Programmierer eben. Zweimal 128 ergibt 256, und das sind acht Bit. Dann fragten wir uns: Wie viele Computer wird es pro Netzwerk geben? Und wir dachten: Lass uns groß denken, 16 Millionen - das sind weitere 24 Bit. Man braucht also eine Adressenbasis von 32 Bit. Diese Entscheidung trafen wir zu einer Zeit, als Computer richtig groß und teuer waren. Sie befanden sich in klimatisierten Räumen und bewegten sich nicht - 16 Millionen war also ziemlich ambitioniert. Und es klappte tatsächlich ganz gut. Die 4,3 Milliarden Endstellen des IP Version 4, das Sie derzeit zum größten Teil nutzen, reichten bis 2011, dann gingen sie uns aus. Glücklicherweise gerieten die Ingenieure, auch ich, bereits 1992 in Panik, als wir plötzlich überall Ethernets sahen. Und wir entwickelten die neue Version des Protokolls namens IP Version 6. Es hat einen Adressraum von 128 Bit. Ich muss Ihnen das nicht sagen, Sie können es sich selber ausrechnen. Wir kamen also – übrigens, einige von Ihnen fragen sich vielleicht: Was war eigentlich mit IP Version 5? Das war ein für das Streamen von Video und Audio entwickeltes Protokoll. Es war aber nicht gut skalierbar, weshalb wir es aufgaben und gleich mit Nummer 6 weitermachten. IP Version 6 ist also die Produktivversion des Netzwerks. Die sollten Sie nutzen. Und wenn Ihnen Ihr Service Provider keine IPv6-Server zur Verfügung stellt, dann hauen Sie bitte auf den Tisch und bestehen auf einen konkreten Termin, zu dem Sie IPv6-Adressen bekommen. Die brauchen Sie nämlich für das Internet der Dinge und für die Mobilgeräte und so weiter. Wir waren übrigens ein Haufen Amerikaner und sprachen natürlich nur Englisch. Deshalb hatten wir für die Domainnamen nur ASCII-Zeichen. Später wurden wir darauf hingewiesen, dass es ein paar Sprachen gibt, die sich mit ASCII-Zeichen nicht wiedergeben lassen. Und wir sagten: Ach ja, daran haben wir nicht gedacht. Wir fügten also Unicode hinzu, was im World Wide Web für die Domainnamen verwendet wird. Jetzt gibt es Domainnamen auf Russisch und Kyrillisch, Arabisch und Hebräisch und so weiter. Ursprünglich gab es nur 7 generische Top-Level-Domains wie .com, .net, .org, .edu, .mil, .gov und so weiter. Doch vor ein paar Jahren beschloss die Zentralstelle für die Vergabe von Internet-Namen und -Adressen, den Hauptraum für generische Top-Level-Domains zu öffnen. Sie erhielt 2.000 Anträge auf neue generische Top-Level-Domains wie .travel, .corporation und so weiter. Und sie verlangte jeweils 185.000 Dollar. Die Öffnung des Raums für Top-Level-Domains brachte also 350 Millionen Dollar ein. Es gäbe noch mehr, worauf ich aber aus Zeitgründen nicht eingehen kann, außer Ihnen zu sagen, dass es im System Sicherheitsrisiken gab. Das System war in einer sehr freundlichen, hauptsächlich aus Technikern bestehenden Umgebung entwickelt worden. Wir wollten die Sachen der anderen nicht kaputtmachen, weshalb wir auch nichts angriffen. Doch als das Internet für die weltweite Gemeinschaft freigegeben wurde, waren die bösen Jungs auch schon da. Wir fügten also weitere Mechanismen zur Verteidigung gegen verschiedene Angriffsformen hinzu, die sich gegen das Domainnamensystem und gegen das Routing-System richteten. Das sind die beiden letzten Punkte auf der Liste. Wir trieben außerdem die Zwei-Faktor-Authentifizierung voran, vor allem bei Google, wo man ein Gerät braucht, das zusätzlich zu Benutzernamen und Passwort ein kryptographisches Passwort erzeugt. Selbst wenn also jemand Ihren Benutzernamen und Ihr Passwort herausfindet, hat er nicht das kleine Gerät, das für die Erzeugung des Krypto-Passworts zuständig ist, weshalb er das Konto nicht knacken kann. Wir fügten Transport Layer Security hinzu; hierdurch wird der Traffic auf der TCP-Schicht verschlüsselt. Damit lässt sich das, was Sie über das Netzwerk versenden, nicht mehr ausspionieren. Und natürlich wurden mobile Smartphones und das Internet der Dinge zu Bestandteilen der Umgebung. Eine kurze Anmerkung zu Smartphones: Das Handy wurde im Jahr 1973 entwickelt, von einem Herrn namens Marty Cooper, der bei Motorola arbeitete. Bob Kahn und ich hatten davon keine Ahnung. Doch im Jahr 1983 schaltete Marty Cooper den ersten Mobilfunkdienst frei. Sein Telefon war etwa so groß, es wog eineinhalb Kilo und hatte oben eine Peitschenantenne. Ich rief ihn an und stellte ihm ein paar Fragen - mit einem seiner Telefone. Eine Frage war: Wie lange hält der Akku? Und er sagte: "20 Minuten - aber das ist in Ordnung, länger können Sie das Telefon sowieso nicht halten." (Gelächter) Seither wurden sie stark verbessert. Wir starteten also zur selben Zeit. Mobiltelefone und das Internet starteten, offiziell und formell, im Jahr 1983. Bis 2007 hatten sie aber nicht wirklich etwas miteinander zu tun. Dann kam Steve Jobs mit dem iPhone daher. Und jetzt ist das Handy in der Lage, mit dem Internet zusammenzuarbeiten. Das Interessante daran ist, dass die beiden Systeme ihre Nützlichkeit gegenseitig verstärken. Die Handy-Apps nutzen Computerleistung im Internet. Das Internet ist über jedes Handy, über jedes Smartphone zugänglich. Die beiden machen sich also selbst nützlicher. Schließlich haben die Menschen nach und nach damit begonnen, Software anstelle elektromechanischer Steuerungsgeräte zu verwenden. Das führt zum Internet der Dinge. Ich gebe es offen zu: Im Jahr 1973 wäre es mir nicht in den Sinn gekommen, dass jemand den Wunsch hegen könnte, seinen Kühlschrank an das Internet anzuschließen, oder einen Bilderrahmen. Ich sagte damals zum Spaß, dass eines Tages jede Glühbirne ihre eigene Internetadresse haben würde, hahaha. Heute kann ich diese Witze nicht mehr erzählen. Von Philips gibt es jetzt eine namens Hue, die Sie von Ihrem Handy aus steuern können – die Intensität und die Farbe der Birne, über das Internet. Ich fragte mich allerdings: Was würde man mit einem internetfähigen Kühlschrank anstellen? Nun, in Amerika kommunizieren wir in unseren Familien dadurch, dass wir Papier und Magnete an der Kühlschranktür anbringen. Das ist besser geworden; jetzt können wir mit Webseiten und Blogs und E-Mail und dergleichen kommunizieren. Wir fragten uns aber auch: Was würde passieren, wenn der Kühlschrank wissen würde, was sich in ihm befindet? Wenn überall ein kleiner RFID-Chip angebracht wäre und man erkennen könnte, was im Kühlschrank ist. Wenn Sie bei der Arbeit sind oder in der Schule oder sonst wo, surft also der Kühlschrank im Internet und sucht nach Rezepten, die er mit seinem Inhalt kochen könnte. Wenn Sie dann nach Hause kommen, sehen Sie auf dem Display die Liste der Rezepte. Das klingt schon ziemlich gut, aber ein guter Ingenieur denkt immer weiter und überlegt, was man sonst noch alles machen könnte. Stellen Sie sich also vor, Sie sind im Urlaub und bekommen eine E-Mail. Sie ist von Ihrem Kühlschrank. Er schreibt, dass die Milch, die schon seit 3 Wochen drin ist, bald von alleine davonkriecht, wenn Sie nichts dagegen unternehmen. Oder vielleicht sind Sie beim Einkaufen und Ihr Handy klingelt. Ihr Kühlschrank ist dran und sagt: "Denk an die Marinara-Soße; sonst habe ich alles, was ich für das Spaghetti-Diner brauche." Ich muss Ihnen leider mitteilen, dass unsere japanischen Freunde diese idyllische Vision von der Zukunft etwas angekratzt haben. Sie haben nämlich eine internetfähige Badezimmerwaage entwickelt. Wenn Sie auf diese Waage steigen, erkennt sie anhand Ihres Gewichts, welches Familienmitglied Sie sind. Die Daten übermittelt sie dann Ihrem Arzt, wo sie in Ihre Krankenakte kommen. Dagegen ist wohl nichts zu sagen, abgesehen von einem Umstand: Der Kühlschrank ist im selben Netzwerk. (Gelächter) Dann kommen Sie nach Hause und sehen Diätrezepte auf dem Display. Oder vielleicht lässt er sich gar nicht öffnen, da er weiß, dass Sie auf Diät sind - das wäre dann richtig schlimm. Unten rechts sehen Sie Version 1 des von Sergey Brin, einem Mitgründer von Google, entwickelten Google Glass. Dafür, warum ich das hier zeige, gibt es einen Grund. Es ist natürlich ein internetfähiges Gerät, aber das Interessante daran ist: Es ermöglicht den Computern, zu sehen, was Sie sehen, und zu hören, was Sie hören. Das ist ein interessantes Experiment. Wenn es nämlich möglich ist, dass der Computer versteht, was er sieht und hört - was wiederum einige der Grenzen für künstliche Intelligenz verschiebt -, könnte das bedeuten, dass der Computer am Gespräch teilnimmt. Während Sie also mit Ihren Kollegen sprechen und über eine bestimmte Konstruktion oder sonst etwas diskutieren, würden Sie den Computer aufrufen können, der Ihnen daraufhin Kontext liefert. Das ist dann ganz so wie bei „Raumschiff Enterprise“ - Sie wissen schon, wenn Captain Kirk sagt: "Computer!" Und man hört die Stimme von Majel Roddenberry aus der Decke kommen. Das ist tatsächlich ein bedeutendes Experiment, und wir sind gerade dabei, eine neue Version des Google Glass zu entwickeln. Den Jungen in der Mitte habe ich mir bis zum Schluss aufgehoben. Das ist ein internetfähiges Surfbrett. Den Jungen kenne ich nicht. Aber ich stelle mir vor, wie er im Wasser auf die nächste Welle wartet und denkt: Er baute also einen Laptop in das Surfbrett ein und einen WLAN-Server hinten in die Rettungshütte. und das verkauft er jetzt als Produkt. Was kommt sonst noch auf uns zu? Sensornetzwerke gibt es bereits. Einige von Ihnen haben sie schon zu Hause: Manchmal ist es ein Sicherheitssystem, manchmal ist es eine Heizungs-, Lüftungs- und Klimaanlage. Ich für meinen Teil habe ein selbstorganisierendes IPv6-Funknetz zu Hause. Jedes Zimmer im Haus hat einen Sensor, der auch als kleiner Funkrouter dient. Alle 5 Minuten erfasst die Anlage Temperatur, Luftfeuchtigkeit und Helligkeit im Haus und speichert diese Daten über das Netzwerk in einem Server in meinem Keller. Ich weiß, so etwas macht nur ein Freak. Aber dahinter steckt folgender Gedanke: Am Jahresende habe ich aussagekräftige technische Daten darüber, wie gut die Heizungs-, Lüftungs- und Klimaanlage funktioniert. Wir können also sinnvolle Anpassungen vornehmen, anstatt uns auf Hörensagen zu verlassen. Ein Raum im Haus ist der Weinkeller, in dem sich 2.000 Flaschen Wein befinden. Ich gebe mir große Mühe, die Temperatur nicht über 16 Grad Celsius ansteigen und die Luftfeuchtigkeit nicht unter 30 % oder 40 % sinken zu lassen, damit die Korken nicht austrocknen. Dieser Raum hat eine Alarmanlage: Steigt die Temperatur über 16 Grad Celsius, bekomme ich auf meinem Handy eine SMS. Einmal waren meine Frau Sigrid und ich unterwegs, als ich eine Nachricht bekam: Dein Wein wird warm. Und niemand war da, um das Kühlsystem zurückzusetzen. Es waren dann ungefähr 21 Grad - das ist nicht tragisch, aber toll ist es auch nicht. Ich rief dann die Hersteller des Systems an und fragte: Macht ihr auch Fernauslöser? Sie sagten: Ja. Ich dachte, dann könnte ich den Kühler per Fernbedienung zurücksetzen. Und ich fragte: Gibt es eine starke Authentifizierung? Sie sagten: Ja. Ich sagte: Gut. Nebenan ist nämlich ein Fünfzehnjähriger, und ich möchte nicht, dass er mit meiner Heizungs- und Klimaanlage herumspielt. Also installierten wir das. Und dann dachte ich mir: Ich merke, wenn jemand im Weinkeller war, weil ich sehen kann, dass das Licht an- und ausging. Aber ich weiß nicht, was er darin gemacht hat. Also dachte ich mir: Was kann ich dagegen tun? Und die Antwort war: Aha, ich bringe an jeder Flasche einen RFID-Chip an, und in den Weinkeller kommt ein RFID-Detektor. Ich kann also, egal, wo ich bin, eine Ferninventur durchführen und feststellen, ob eine Flasche den Keller ohne meine Erlaubnis verlassen hat. Als ich bei einem meiner Ingenieurskollegen mit dieser brillanten Konstruktion angab, sagte er: Da gibt es allerdings einen Fehler. Ich sagte: Was meinst du damit? Und er sagte: Nun, man könnte in den Weinkeller gehen, den Wein austrinken und die Flasche da lassen. (Gelächter) Jetzt muss ich Sensoren in die Korken stecken. (Gelächter) Und wenn ich schon dabei bin, kann auch gleich die Ester erfassen, die mir verraten, ob der Wein trinkreif ist. Bevor man die Flasche öffnet, befragt man also den Korken. Und wenn das die Flasche ist, die 23 oder 26 Grad warm geworden ist, verschenkt man sie an jemanden, dem das nicht auffällt. Ich will damit sagen, dass die Zukunft den Sensorsystemen gehört - überall. Die Gebäude werden mit Instrumenten versehen, die Autos, die Fertigungsanlagen. Und sogar wir, unsere Körper, werden mit Instrumenten versehen. Und das wird alles Teil dieser gigantischen Datenmenge, die im Netz herumfließt. Wenn wir uns die nächsten 20 Jahre ansehen - das sind natürlich nur Vermutungen. Aber heute glauben wir, dass es 10 bis 15 Milliarden Geräte geben könnte, die in der Lage sind, im Netz zu kommunizieren. Sie sind normalerweise nicht unbedingt alle gleichzeitig eingeschaltet, aber so viele könnten es sein. Und im Jahr 2036, in etwa 20 Jahren, könnte die Zahl eine Billion erreichen. Im Jahr 2036 werden etwa 8,5 Milliarden Menschen auf der Erde leben. Und Sie könnten 100 bis 110 Geräte haben - am Körper, zu Hause oder wo immer sie wohnen. Diese Zahlen sind also nicht total verrückt. Aber sie machen es ganz bestimmt erforderlich, zu IPv6 zu wechseln, denn wir brauchen den ganzen Adressraum für all diese Geräte. Hier sehen Sie ein paar Dinge, mit denen wir bei Google experimentieren. Unser Unternehmen Verily - es produziert nichts, aber es experimentiert mit einer Kontaktlinse, die den Glukosegehalt in Ihrer Tränenflüssigkeit erfassen kann. Der hängt mit dem Glukosegehalt in Ihrem Blut zusammen – auch wenn es eine Verzögerung gibt, bis die Glukose aus dem Blut in Ihre Tränenflüssigkeit wandert. Dahinter steckt folgender Gedanke: Wenn Sie ein Typ-1-Diabetiker sind und keine Lust mehr haben, ständig in Ihren Finger zu stechen, um Blutproben zu nehmen, ist das eine andere Möglichkeit, diese Daten zu erfassen. Und da es ein System mit der Möglichkeit fortlaufender Überwachung ist, können wir einen Grundwert bestimmen, der für Sie normal ist. Abweichungen vom Grundwert können dann sehr schnell entdeckt werden. Sie können sich dann wieder erholen, indem Sie entweder mehr Insulin nehmen oder etwas Zuckerhaltiges essen. Diese Idee der fortlaufenden Überwachung ist, so denke ich, ein sehr wichtiges Thema, dem wir immer wieder begegnen. Die fortlaufende Überwachung ermöglicht die Feststellung von Anomalien, die normalerweise unentdeckt bleiben, wenn die Erfassungsrate zu niedrig ist. Denken Sie nur an die Leute, die erst dann zum Arzt gehen, wenn sie krank sind - wirklich krank. In der Vorstellung des Arztes sind Sie dann jemand, der ständig krank ist, da Sie nie zum Arzt gehen, wenn Sie gesund sind - Sie gehen erst dann, wenn Sie krank sind. Diese fortlaufende Überwachung könnte also große Auswirkungen haben. Von Google gibt es auch selbstfahrende Autos. Was Sie hier sehen, ist das Modell Nummer 2. Ich habe aber ein Video mit dem ersten Modell, das wir mit einem unserer blinden Mitarbeiter getestet haben, um festzustellen, ob das Auto unseren Mitarbeiter tatsächlich zur Arbeit bringen könnte. Wenn ich das richtig gemacht habe, sollte sich das Video abspielen lassen. Nathaniel: Guten Morgen, Steve. Steve: Hallo Nathaniel, wie geht's dir? Nathaniel: Mir geht's gut. Gehen wir's an, Steve. Nathaniel: Alles klar. Steve: Alles klar. Steve: Schau mal - freihändig. Nathaniel: Freihändig. Keine Hände. Steve: Keine Hände, keine Füße. Nathaniel: Keine Hände, keine Füße, nichts. Steve: Das gefällt mir. Steve: Hier ist das Halteschild. Nathaniel: Ja. Das Auto nutzt Radar und Laser, um sicherzugehen, dass alles frei ist. Steve: Ich ertappe mich dabei, wie ich umschaue. Nathaniel: Alte Gewohnheiten wird man nicht so schnell los. Steve: Man wird sie nicht los. Ist jemandem nach einem Taco? Nathaniel: Ja, ja, alles, wonach dir heute der Sinn steht, Steve. Steve: Ich würde gern zu Taco Bell fahren. Nathaniel: Also gut, holen wir uns ein Taco vom Drive-Through. Steve: Jetzt biegen wir auf den Parkplatz ab? Nathaniel: Ja. Steve: Toll. Nathaniel: Jetzt schleichen wir ein bisschen dahin. Hat jemand Geld dabei? Steve: Ja, ich. Nathaniel: Nein, nein, ich hab' meinen Geldbeutel hier. Lass dein Fenster runter und bestell' einen Burrito. Ja, da musst du drücken. Kellnerin: Wie geht's Ihnen heute? Steve: Mir geht's sehr gut, und Ihnen? Kellnerin: Danke, gut. Steve: Das ist eine der besten Fahrten, die ich jemals gemacht habe. Ich habe 95 % meiner Sehkraft verloren. Ich bin deutlich über dem, was nach dem Gesetz blind ist. Man kann die Zeit nicht mehr richtig einteilen - für alles braucht man viel länger. Es gibt Orte, wo man nicht hin kann. Es gibt Dinge, die man beim besten Willen nicht tun kann. Das hier würde mein Leben insofern verändern, dass es mir die Unabhängigkeit und die Flexibilität geben würde, an Orte zu kommen, wo ich hin möchte oder hin muss, um meine Sachen zu machen. Steve Mahan – Nutzer des selbstfahrenden Autos Nr. 0000000001 Produziert in Zusammenarbeit mit Morgan Hill Police Department, Santa Clara Valley Blind Centre San Jose, Kalifornien. Steve: Jetzt raus mit euch, ich muss noch wohin. Schön war’s. Nathaniel: Tschüss. (Gelächter) Steve: Es war schön. Es war wirklich schön. Sie können sich vorstellen, dass uns das richtig begeistert, und wir hoffen, dass wir dranbleiben können. Wie Sie sehen, entwickeln wir neue Modelle. Es passiert noch mehr: Drohnen, zum Beispiel, sind überall. Es hört sich so an, als würde das Video immer noch laufen, nicht wahr? Entschuldigung. Oh nein, ich soll wieder ganz zurück zum Anfang, das will ich nicht. Alles klar, schneller Vorlauf. (Gelächter) Jetzt hab ich's. Drohnen - Sie haben alle davon gehört, sie sind überall. In den USA ist das sehr spannend. Die Luftfahrt-Bundesbehörde versucht verzweifelt herauszufinden, welche Regeln für 27 Millionen Drohnen gelten, die in den USA herumfliegen könnten. Ich weiß, dass Jeff Bezos die Drohnen zum Ausliefern von Waren für Amazon nutzen will. Ich habe mal mit ihm zu Abend gegessen, und ich hatte diese Vorstellung von einer Drohne, die vor einer Haustür schwebt. Sie schickt eine SMS ins Haus: "Ich bin hier mit Ihrer Lieferung. Wenn Sie die Tür in den nächsten 30 Sekunden nicht öffnen, sprenge ich sie auf." (Gelächter) Jeff lachte und ich machte mir Sorgen, dass er das tatsächlich tun würde. Ich hoffe, er lässt es bleiben. Das gehört auch zum Internet der Dinge. Und dann gibt es das Projekt Loon - weil's verrückt ist. Es sind von Google hergestellte Ballone, die bis zu 18 Kilometer hoch in der Stratosphäre arbeiten. Wenn sie sich nach oben und unten bewegen, werden sie abhängig vom Wind in verschiedene Richtungen geweht. Wir steuern sie, indem wir die Höhe ändern. Dahinter steckt der Gedanke, dass sie aus der Stratosphäre per Funk über WLAN oder LTE kommunizieren könnten. Dahinter steckt die Idee, sie mit einem gewissen Spielraum zirkulieren zu lassen. Sie suchen Rückenwind, um zum nächsten Servicepoint zu gelangen. Und dann suchen sie Gegenwind, um auf der Stelle zu schweben. Doch sie setzen ihren Weg um die ganze Welt fort. Derzeit sind sie in Sri Lanka. Damit experimentieren wir jetzt seit etwa 4 Jahren. Dahinter steckt die Idee, das Internet an Orte zu bringen, die für Glasfaser sehr schwer zugänglich sind – zum Beispiel in den Anden, in der Sahara oder auch mitten im Ozean. Schließlich möchte ich Ihnen noch den neuesten kleinen Roboter von Boston Dynamics zeigen. Der hier heißt Little Dog. Hinter ihm ist Big Dog. Hier haben wir Werbung - typisch Google. Das ist verblüffend, der Kopf ist unglaublich stabil. Sehen Sie sich das an, das ist wirklich beeindruckend. Im Maul ist eine Kamera. Man muss sie nicht so bauen, wie Hunde gebaut sind. Das ist auch ziemlich beeindruckend: Treppensteigen ist für ihn kein Problem. Es gibt übrigens von diesen Dingen 51 Videos auf YouTube, falls Sie sich das ansehen möchten. Nicht nur vom Hund, auch von allen anderen Robotern, die dort gebaut werden. Ich möchte Ihnen noch etwas zeigen. Was ich Ihnen jetzt zeige, ist aber kein Google-Projekt. Das Projekt begann im Jet Propulsion Laboratory in Pasadena. Meine Kollegen und ich begannen mit dieser Arbeit im Jahr 1998. Seitdem bin ich dort Gastwissenschaftler. Es handelt sich um die Entwicklung und Implementierung eines interplanetaren Internets zur Unterstützung der Erforschung des Weltraums durch Menschen und Roboter im Rest dieses 21. Jahrhunderts. Wir trafen uns, nachdem der Roboter Pathfinder 1997 erfolgreich auf dem Mars gelandet war, und zwar nach sehr vielen Versuchen, wieder auf dem Mars zu landen, nachdem die Viking-Sonden 1976 dort landeten. Wir mussten darüber viel nachdenken, weil die Kommunikation zur Unterstützung des Pathfinder eine direkte Punkt-zu-Punkt-Verbindung zwischen Erde und Mars war. Das war natürlich eine sehr beschränkte Art von Netzwerkfähigkeit. Wir dachten: Was würde geschehen, wenn wir eine reichhaltigere, internetähnliche Netzwerkumgebung hätten? Zu Beginn dachten wir, wir könnten die TCP/IP-Protokolle verwenden - sie funktionieren auf der Erde, dann sollten sie auch auf dem Mars funktionieren. Aber bei genauerem Nachdenken kamen wir darauf, dass das doch nicht so gut funktionieren würde. Zwischen den Planeten funktionierten diese Protokolle nicht besonders gut. Für Sie dürfte das offensichtlich sein: Lichtgeschwindigkeit ist zu langsam. Zwischen Erde und Mars beträgt die Verzögerung bei größter Annäherung 3,5 Minuten Verzögerung für eine Strecke. Ist die Entfernung am größten, sind es 20 Minuten für eine Strecke, hin und zurück 40 Minuten. Das TCP-Protokoll wurde nicht dafür entwickelt, mit einer Laufzeit von 40 Minuten für die Flusskontrolle umzugehen. Die Flusskontrolle ist wirklich einfach. Wenn Sie keinen Platz mehr haben, sagen Sie dem anderen: Halte die Übertragung an, ich habe keinen Platz mehr. Wenn das nur wenige hundert Millisekunden dauert, dann passt das. Aber wenn es 20 Minuten dauert, bis das Signal beim anderen eintrifft und er Ihnen 20 Minuten lang bei höchster Geschwindigkeit Material entgegenschleudert, dann fallen die Pakete auf den Boden, sie fallen überall hin. Die Flusskontrolle funktionierte also nicht. Dann gibt es noch ein Problem. Die Planeten drehen sich, und wir wissen nicht, wie man das anhält. (Gelächter) Wenn man also mit etwas auf der Oberfläche spricht und der Planet dreht sich weg, dann muss man warten, bis er zurückkommt. Oder, wenn es ein Orbiter ist, wird es schwierig. Bis 2004 wurden 2 Rover auf den Mars geschickt, Spirit und Opportunity. Der ursprüngliche Plan war, Daten von der Marsoberfläche zu übermitteln, wie es mit Pathfinder gemacht worden war. Die Funkgeräte überhitzten, und jeder machte sich deshalb große Sorgen. Und sie waren nur für 28 Kilobit pro Sekunde ausgelegt. Die Wissenschaftler waren mit dieser von der Oberfläche eintreffenden Datenrate nicht besonders glücklich. Wir sagten uns, dass wir den Arbeitszyklus verkürzen müssen, denn wir wollten nicht, dass das Funkgerät überhitzt und andere Instrumente oder sich selbst schädigt. Alle waren aufgeregt. Und einer der Techniker am JPL sagte: Der Rover hat übrigens nachgerüsteten Funk. Die Sonden, die wir zuvor losgeschickt hatten, um die Marsoberfläche nach geeigneten Landeplätzen für den Rover abzusuchen, haben ebenfalls nachgerüsteten Funk. Wir programmierten die Rover und die Sonden um - wenn die Sonde über ihm auftauchen würde, würde der Rover-Daten nach oben zum Orbiter schicken. Die Sonde würde die Daten behalten und erst dann übermitteln, wenn sie den richtigen Platz auf ihrer Umlaufbahn erreicht hätte, von dem aus sie das Weltraumnetzwerk erreichen konnte, das sich mit 70 Meter großen Schüsseln an drei Stellen der Erdoberfläche befindet. Das nennt man Speichern und Weiterleiten. Hierfür entwickelten wir eine ganze Suite von Protokollen namens Bundle-Protokolle. Die Prototypen laufen jetzt und holen sich all die Daten vom Mars. Und als die Sonde Phoenix am Nordpol aufsetzte, gab es keine Konfiguration, die einen direkten Weg zurück zur Erde hatte. Wir verwendeten also den gleichen Satz von Protokollen. Und als das Mars Science Laboratory landete, wiederholten wir das. Alle Daten, die vom Mars kommen, laufen durch dieselben Prototyp-Bundle-Protokolle des interplanetaren Systems. Wir haben diese Protokolle zur internationalen Raumstation hochgeladen. Wir ließen die Astronauten die Rover mithilfe der Bundle-Protokolle, der interplanetaren Protokolle, in Echtzeit auf der Erdoberfläche steuern, denn die Entfernung ist ziemlich kurz. Sie nutzen die interplanetaren Protokolle, die mit kurzen Verzögerungen gut funktionieren, wie TCP auch. Sie funktionieren aber auch über diese langen, fest miteinander verbundenen Systemen. Was wir uns offen gesagt für die nächste Zeit erhoffen – die Protokolle haben wir übrigens beim Consultative Committee for Space Data Systems standardisiert. Jetzt hat also jeder darauf Zugriff: Sie sind vollständig standardisiert. Die Protokolle sind verfügbar. Die Implementationen sind auf Source Boards für jedermann kostenlos zugänglich, der sie herunterladen und nutzen möchte. Eine deutsche Universität hat die Protokolle sogar für Android-Handys implementiert. Wir hoffen, dass die Raumfahrtnationen dieses Planeten, wenn sie neue Einsätze starten, diese Protokolle übernehmen und sie für ihre Missionen nutzen. Oder wenn sie sie nicht für die wissenschaftliche Mission verwenden, könnten sie das Raumschiff nach dem Abschluss der ursprünglichen Mission umprogrammieren und dann Knoten in einem interplanetaren Backbone werden. So können wir den Backbone im Lauf der Zeit buchstäblich anwachsen lassen, wenn neue Missionen zum Sonnensystem gestartet werden. Das sind die neuesten Nachrichten über das interplanetare Internet. Und das ist mein letztes Bild. Damit beende ich den Vortrag und bedanke mich sehr für Ihre Aufmerksamkeit.