Keynote: Vinton G. Cerf

Thank you very much. First question. Thank you. I turned it on. I'm okay. Am I audible? Good. Okay. Whether I say anything useful, that's a different question. You know, it makes me nervous when everybody claps when you get up because it makes you feel like you should just sit down because it won't get any better than that. That and and considering uh this old fart in a three-piece suit showing up, uh you must be wondering, do I have anything useful to say? And I don't know the answer to that, but I don't think you're armed with Rotten Tomatoes. At least I hope not. Um, what I'd like to try to do in about 45 minutes is uh try to persuade you that the internet that you're using today deserves some serious um, let's say evolution and it's not too late. The original design was done if you go back far enough around 1973 with Bob and I wrote first uh, first papers on the subject. Uh, it's evolved substantially in terms of implementation architecturally. It's still pretty much the way it was before. And I feel like we missed a bunch of opportunities uh to say nothing of the fact that as the net has evolved and propagated, we've discovered a lot of uh serious uh problems related to security, for example. So, I'm going to take you back for a little bit into history and then go from there. This is the predecessor to the internet. It was the Arpanet. It only had four nodes to begin with. I was a programmer at UCLA and wrote the software to connect a Sigma 7 machine to uh the first Arpanet imp that was installed at UCLA. Um the Sigma 7's in a um a museum now and some people think I should be there too, but uh if you fast forward uh past the uh installation of TCP IP in January of 83 and so on, you see an internet that looks kind of sort of like this. This was generated automatically by looking at the BGP routing tables and then uh using a different color for each autonomous system to try to show what the connectivity was. I show this partly to show that it get it got a lot bigger. But the most important thing is that it's a grand collaboration because there's no central authority for the internet. It's it's built out of pieces of networks that people decided they wanted to interconnect because it was useful. And I think that uh notion of collaborative interconnection is just as important today as it was uh in the early days of the uh design. The number of hosts on the machine has gone up over time. It's well past 750 million now. The actual numbers are who knows, but the estimates are based on machines that have domain names and fixed IP addresses. That doesn't count things that are episodically connected like laptops or desktops or mobiles or uh netbooks or other kinds of things. And it also doesn't count the machines that are hiding behind firewalls that we can't see because they're uh enterprise systems. So probably there are more like a billion a billion and a half maybe more devices that are connected at one time or another on the net and certainly on the order of two billion users which is still kind of small considering that there's almost 7 billion people in the world. So as the Google chief internet evangelist I feel like I have about 80% of the world that converts. So I have a long ways to go before we get there. The other thing that's interesting of course is the existence of mobiles. they've penetrated dramatically into the telecom environment and some fraction of them maybe 15 or 20% are internet enabled and with time I think more and more of them will be so they play also an important role in this landscape of the internet uh the users are uh distributed approximately this way and for those of us in North America it's a little stunning to realize that there are more Chinese on the net than there are Americans even though in the very early days of internet we had very large uh population relatively speaking. So uh the numbers of course in Asia will just get bigger as the penetration rates go up. Uh so they will be in the in the billions I assume before the end of this decade. One of the things I wanted to draw your attention to is what Bob Khan had in mind when the internet was first thought of. We were we were thinking in terms of military requirements for command and control, the use of computers to manage military resources and to make to take advantage of computing power in order to uh overcome a larger opponent with better control of your resources. So these notions um that Bob u had begun developing even before uh we started the project. He was uh thinking of this when he went to the advanced research projects agency in late 1972. Uh and you see uh I'm letting you read these. I don't need to repeat them. But you can see in this list things that are are quite familiar today. The notion of distinct networks that interconnect uh independently. Uh best efforts communication. Uh black boxes which we used to call gateways until Cisco explained to us they should be called routers. Um and there was no global control. It was very distributed in order to avoid a central uh weakness. We also needed global addressing because the networks that we were interconnecting didn't know that they were not the only network in the world. And so there was no and we had a rule that said don't change any of the networks. Just let them run and carry packets uh enclosed in their packet formats whatever they were. We need ways to recover from lost packets because some of the networks were inherently lossy. They were radio-based. When Ethernet came along, it had its own uh characteristics. Satellite communication had longer delays uh than terrestrial. So there were a lot of variations in uh the parameter space and we needed to accommodate uh for all of those things. We had different operating systems. Uh we didn't have Linux, we didn't have Unix at the time uh when this got started. Uh so there were uh a large number of different operating systems that had to be adapted uh to use the internet protocols. Um one thing that I think I've learned in the last several decades is that it was important that we didn't have a particular application in mind for the internet. We hoped that it would be useful for a wide variety of purposes. And the reason that turned out to be important is that we didn't build any assumptions into the net or into its protocols or its architecture that assumed a particular set of applications that had to be supported. The utility of that is that people many of you have figured out new applications to use this best efforts communication system for uh and so it's been able to adapt uh to new technology and new applications without too much difficulty. The layered structure we inherited or the notion we inherited from the original arponet design. Uh and it has proved to be quite useful because it segregates uh functionality and when you make changes in implementation within one layer as long as the interfaces stay very uh much uh constant. Uh you can make all kinds of different implementation choices inside without affecting the layers above and below. One thing I really love is that the IP packets not only don't know how they're being carried, but they don't know what they're carrying. All it is is a bag of bits and they're only asked to deliver something from point A to point B with some probability greater than zero. That's all that we asked of it of an internet packet and everything else, you know, sits on top of that. Uh I'm also rather proud of the fact that when we designed the internet uh addressing structure, we did not use a countrybased system. Part of the rationale for that was that the military never could not know ahead of time where it might be in operation and it didn't make any sense in a in a military uh situation to have to go get permission from some country that you were attacking in order to get address space to run. So we said we you know this is going to have to be purely topologically based and have nothing to do with national boundaries. Okay. uh openness and you I'm sure are uh strong uh proponents and understanders of that openness has really been important uh in this internet story. Uh the open source material uh and Linux and other systems like Chrome and Android are I think important open access is important being able to get to the network being able to get to anywhere on the network. uh the open standards where literally anyone with a good idea has an opportunity to inject that idea into uh the uh architecture. Um I do remember though around the late 1980s uh when it was all government sponsored uh I thought that at some point we needed to make a commercial engine uh out of the internet because I couldn't figure out why the government would pay for every individual's access to the internet. So I thought commercialization was important. Some of my colleagues thought that was a dumb idea because after all it was their toy. I mean this was their sandbox. Why would you want these commercial greedy people to become part of the equation but that's why the internet grew was because there was a commercial engine underneath it. And of course broadband is a big deal and here especially in Australia uh tip of the hat to uh the broadband plan uh which I understand is underway. So IPv6 you all know that we're almost out of E4 address space. I'm a little embarrassed about that because I was the guy that decided 32 bits was enough for the internet experiment. My only defense is that that choice was made in 1977 and uh I thought it was an experiment. Uh the problem is the experime the the experiment didn't end and so here we are. Uh so if you're not doing V6, you should be. uh domain names are coming uh have arrived actually with non-Latin characters and that's an important addition domain name system security is another addition also very important RPKI in order to do a better job of protecting from people who um are uh squatting uh on or hijacking address space uh in the backbone routing structure is another addition which is underway and of course we're seeing sensor nets and smart uh appliances the smart grid in the US and and I'm are in similar things in Japan and Europe and mobile devices are all part of uh this growing uh architecture. Um I think that you're likely to hear an announcement that Ayanna has exhausted its address base very soon. U and as soon as the uh we're down to five8s then all one each of those one each of the the last five will go to each of the regional internet registries. I'm pretty sure we'll hear about that very soon. Um, we also need to work very hard to get IPv6 up and running and it's the the time for just talking about it is over. We just have to get busy and implement it and demonstrate it. So on it's actually 6 811 now instead of 6611 for a kind of an uh world IPv6 day. Google is going to be very active in that and I hope some of you will participate as well. These are some examples of the internationalized domain names that have been approved by ICAN. Here's some more. Um, one, I'm sorry. Lincoln one. Four squares. Four square. Oh, yes. That one is one that I didn't have the uh character set for. Uh, this a good example. Let's see. That's uh Sinhala. I didn't happen to have Sinhala on my machine. So, you can you can blame Apple for that. I had I don't know about cleaning down. We got to work on that. Um all right. So we have security problems. You live with them every day. Here's a list of things that we should be worried about and we are worried about. Uh I think the thing which I'm most disturbed by uh is that some of these problems are not just technical. They're our behaviors. We pick bad passwords. Some people still pick password as their passwords. Um, others pick words that are easily broken with dictionary attacks and things like that. I am a very big proponent these days of two-factor authentication with cryptographically generated passwords that only last for a short period of time. Google has adopted that internally and I think we're also hoping to make that available uh publicly to people who want more security in their uh access to uh to our services. uh social engineering is still a very common way of getting penetrating uh systems. Fishing and farming, we hope we'll be able to reduce some of that using DNS SEC. Um address poaching, all of these things. But uh the bottom line here is that the worst things that happen in the net have very little to do with deliberate security uh penetration. It has a lot to do with dumb mistakes that we all make. And some of the worst are, you know, things like configuration errors. It's hard to figure out that something is misconfigured. I mean, if if there's a parameter out of out of scope, that's easy. But if there's some constellation of values that would cause half the net to disappear into a black hole, sometimes it isn't obvious that that's what you just did. And I remember we had a little event at Google where as we crawl the net and index all the websites, our software looks for malware. And if it thinks there's malware on the site, it makes a little mark uh in a table. And uh when you anyone else happens to go to uh Google search and find a site that has one of these malware marks on it, we and they try to go there by clicking on the link, we pop up an interstitial page saying maybe you shouldn't go there. We think there's malware that would harm your computer. So the guys that were doing that were manually doing some editing of this thing and somebody stuck a slash in at the wrong place and it caused every site on the internet to be marked as having malware. So, so we've discovered that fairly quickly because people were saying everything is infected. Uh, so the most the most spectacular mistakes I think are the ones that we do to ourselves. You all appreciate that the security problems uh in the system come about in part from operating systems that are easily penetrated. One hopes that the openness of the Linux environment or Android or Chrome or some of these other operating systems will contribute to eliminating a a lot of the potential weaknesses in those systems. Uh but the biggest hole I think right now for security is in the browser space because the browsers uh in the past weren't really um threatened much when you think about what they did. they would go and download the homepage and interpret it. And most of what they were interpreting was formatting information from HTML and also imagery and maybe at some point uh some streaming uh elements. But now of course we download JavaScript or Java or Python or some other highle language and then run the program uh in an interpreter inside the browser. And for some browsers uh unable to figure out that they're doing anything bad will run those programs and lodge uh Trojan horses or other kinds of things into the operating system partly because the browser is operating at too high a level of privilege within that operating system setting. So uh we have work to do I think to improve the framework in which we allow web-based uh applications to run. Of course, there are lots of other things that can cause uh a serious problems. All the botnetss that are used to generate spam or denial of service attacks are really a consequence of the penetration of a lot of operating systems by way of driveby downloads. So, uh here uh I think we all have a kind of collective responsibility to think our way through better operating systems and browsers and the like that will uh reduce if not eliminate a lot of those problems. Privacy is a big issue too and some of it is just the result of u users choices. They just put information up on the net that u uh they don't seem to recognize might be um damaging later on. Uh but also there are people who don't bother configuring things properly and the consequence of that or they can't figure out how I mean to be fair some of the user interfaces to configurations are not so simple. Um, but there's also policy issues here. It's not all technology that causes privacy to be a problem. Sometimes a business like a telephone company will naturally accumulate information like what numbers did you call, when did you call, how long were you on the line? Uh, and all that gets accumulated for billing purposes, but it also in is potentially quite uh private. And so most businesses theoretically treat that information as private and they'll protect it. But if they choose not to, then your privacy is uh harmed and it's not because of technology. It's because of a decision made by a company that's accumulated the information. So companies like Google and others who have information that could be considered private have a responsibility to protect that information and to not share it or to or not to abuse it. There are also uh some what we call them invasive devices. We walk around with mobiles today. They have cameras in them. We've all become uh you know reporters in a very funny sense. We take pictures, we upload them into the net, we do videos, we can do sound recordings uh and in the millions in the hundreds of millions u they upload these to YouTube and other uh storage sites that are made accessible. We do GPS tracking. All of these things are for our convenience, but at the same time, they have potential uh privacy implications and I think we're living in a world where it's going to be increasingly difficult to protect privacy. If you're interested in that, Scott McNeely, the uh uh former head of Sun Microsystems, was quoted almost a decade ago, I think, is saying, "There isn't any privacy. Get over it." And I'm not sure that I hope he's not exactly right, but I have to say that we live in a world where that's difficult. I want to shift gears for just a second and mention clouds because I feel as if we are at the state in the cloud world now where we were in the internet world around 1973. What do I mean by that? Well, we have many different cloud implementations for different sources whether it's Amazon or uh Google or uh Microsoft or IBM and so on. They aren't built the same way. They don't have all the same functionality. Uh in our case, we have multiple data centers. They all have to be interconnected to each other. Uh they're very attractive because of the dynamics, the ability to share resources. Uh, one nice thing is that we do replicate data in the Google case so that even if a data center goes away, it's possible to get access to your information because we replicated it uh deliberately in order to uh to protect it. Or you may be working uh with others on documents that you're interacting uh over like a spreadsheet or or a document text document and you could simultaneously be doing video or audio conferencing. So all these things are very attractive but each of the clouds for the moment is independent of each other cloud just like the networks of the past were independent of each other. And I've often thought well gee what if you had data in cloud A and you decided that it would be beneficial to either replicate or move the data into cloud B. Probably not a good idea to have to download all of that into your laptop and then push it back to the other cloud. For one thing, there might be too much data to do that in a convenient way. How do I get cloud A and cloud B to talk to each other? What if it turns out that the data that's in cloud A has some access control associated with it that's important to me? I need to replicate the metadata in cloud B that will give me the same access control that I had in cloud A. This is presuming that I have semantics that are comparable in the two clouds. We don't have any standards for describing any of that. uh we don't have any way of telling cloud A and cloud B to cooperate with each other in the conduct of a common computation which might involve data sharing. Uh none of the um vocabulary which is uh grown up around the internet for this uh remote uh peer-to-peer interaction has been developed for clouds yet. And so if you're looking for a dissertation topic uh this is one of them. this this ex exploration of how to get clouds to interact with each other. But there are other research problems that haven't been solved. And in this part of the talk, what I'd like to do is to persuade you that not only do we have unfinished work before us, but that it's possible to do that even though this internet has been around for quite a long time. Security we've already talked about and plainly there's lots of work to be done there. some serious work in operating system uh design uh including the within the Linux context I think is called for we don't have very good um formulas if if those of you who have studied traditional telecommunications will know about this guy heirlong who figured out that a typical telephone call was 3 minutes in a bell-shaped curve not counting teenagers and uh actually that's a that's a cheap throwaway it turns out that today's teenagers don't talk to each other they text they don't want to talk to each other because it's too tense, you know, you don't know what to say next and the conversation falls apart and it's embarrassing. So, they don't like to talk to each other on the phone. They just send text messages back and forth. But anyway, Heirlong was able to measure the behavior of people on the telephone system because there's only one thing you could do, make a phone call. Well, in the internet, we don't have that luxury. What happens is that tomorrow somebody will invent yet another way to use the internet. It'll have different statistics at the edges of the net uh than uh than we had before. So there are no airong formulas to help us plan the um scale uh scaling and implementation of the internet at the edge. In the core, it's a different story. When you're aggregating large amounts of flow, the law of large numbers actually helps you. But at the edges of the net, the dynamic range of behavior is still extreme. Uh and of course, we have all these screaming and delying matches about quality of service, whether we need it or not, or just add more capacity. That debate is going to go on for a long time. distributed algorithms which is something that we'll be talking about in one of the many conferences is another place where uh a lot of effort is still needed to take advantage of clouds that can support concurrent computations in ways that we couldn't do with a simple ordinary single processor. Um I'm not going to go through every single one of these but the place where I really get upset is in mobility generally multihoming multiath routing and broadcast. uh I made an absolutely awful mistake. I mean I don't mean to take all the blame. I had colleagues who were participating in the design of the internet but but uh really this was uh in the split uh in 77 1977 in the split between TCP and IP that split was made in order to provide for real-time delivery of data that didn't all have to get there. So speech, radar tracking, all the kinds of things where uh freshness was more important than getting everything there in sequence. Whereas TCP was working really hard to make sure that you could retransmit, get rid of duplicates, and do all those other things. So here's the problem. When we made the split, I thought it was very clever to create what we called a pseudo header and bind the TCP connections closely to the IP addresses of the underlying IP layer because we'd save header space and you know we didn't have to invent yet another address space for the TCP layer. That turned out to be a mistake. And the reason it's a mistake, if you haven't already uh figured that out, is that it bound the higher level protocols and applications to the IP address of the machine that happened to be connected to the net at the time. Now, you could we could be forgiven, I guess, considering that when that decision was made around 1977, most machines didn't get up and move around. And they were, you know, this the size of two or three rooms and, you know, they required air conditioning and everything else and, you know, cables all over everywhere. But as we have moved to the point where our computing goes with us, then our access to the internet has changed and our IP address access moves with us or does not move with us. It changes as we move around as it did with the mobile telephone network. Those telephone numbers are no longer what they used to be. They used to be things that said exactly where you were in this physically switched network. Today they're just a label and there are some underlying routing uh identifiers that uh figure out how to rebind your telephone number to the underlying routing system as you roam from one uh service provider to another. So we could do that in the internet architecture. We could segregate the address space for TCP layer and up from the address space of IP. Then the problem will be how to cope with the guy that says, "Hi, uh, I'm in a new IP address now, but I'm the same guy you were talking to before." Of course, that's, you know, obviously a kind of a penetration attack. So, you'd have to invent some sort of handshaking, probably with a cryptographic element to it in order to prove that you're the same guy that used to be on a different IP address, but you're on this TCP connection or FTP or what have you. But I think that it's worth exploring those sorts of things. The IETF has some groups looking at shims and other sorts of techniques that would allow this sort of uh rebinding of the higher level uh applications to different IP addresses that would solve the multihoming problem too. If you have multiple ISPs that deliver different IP addresses to you, you could use any of them because you'd be binding streams together at a higher layer than than just the IP address. In the multipath routing case, uh the way routing typically works in the net, you pick a path and you use it until it doesn't work anymore. Uh it would be nice if there were multiple paths that you could push packets on all of them in order to get a higher capacity from uh edge to edge, but we don't do that. And finally, the thing that really drives me crazy, we take broadcast radio capability and we turn it into a point-to-point link. I mean, think about Wi-Fi and other things. We actually could make use of the fact that a broadcast could be received by multiple parties. That's what satellite television is about. That's what cable television is about. It's not just about video. I don't mean to narrowly focus this. It's really about being able to deliver the same thing to a large number of receivers at the same time. It's a very inexpensive way of delivering large amounts of data if everybody wants the same thing. Not everybody wants the same thing, but some people, some large number of people may want the same thing, like the latest software update for for uh for Linux or possibly a video or some other piece of of information or program of some kind. So I I imagine having uh satellite services that are raining internet packets down on 100 million receivers so that to do very efficient delivery of things that are popular and if you miss a couple of packets you you know holler and you get a uniccast update in order to recover from that. So I again once again I see no problem actually implementing something like that. There are satellites in the sky that have a big footprint. they could easily be uh generating or at least relaying internet packets as opposed to what they do today. And I'm surprised that this hasn't already emerged uh as a business. Um we talked a little bit about authentication and I would say that we have some distance to go to do a better job of authenticating everybody. We need standards and we need things that are internationally recognized as strong authenticators for uh for parties that are uh transacting on the network. Uh multi-core processors are an interesting problem space because Moors law broke a few years ago. We aren't increasing the clock speed anymore every 18 months. Instead, we're increasing the number of cores that are on each chip. And that's all fine. and you still get the same large increase in the number of compute cycles that are available. The problem is you have to use them in parallel better than you can before. I'm not going to take any more time on that because I'm going to talk about that in another one of the uh small conferences. Um and I'm going to skip over delay and disruption tolerance and pick it up when we talk about the interplanetary internet which I'll try to finish up with. Um this other thing on the right hand side governance of the internet is a gigantic quagmire. the folks who live here in Australia are living a piece of that right now where there's Well, that's interesting. Does that Does that mean I should stop now? That's pretty impressive. Um, anyway, folks here in Australia are living in one piece of this uh debate. Uh it's been proposed that somehow the internet gets censored uh in order to protect people from things that they shouldn't see. And you know, my reaction to this is that doesn't sound like it's a very effective thing to do, especially if you're trying to hack DNS servers and things of that sort. I think we all appreciate that there are things that we might agree on a societal basis, on an international basis that we would want to remove from the net. The best we can do is to remove it when we find it. We can't stop people from putting it up ahead of time. Uh but I I really think that this debate is going to go on forever. Uh as we see the system increasingly penetrant in every aspect of our lives, then societal issues are going to become uh more and more paramount in the debates. And I hope that we can preserve the openness and freedom of the internet which has allowed so much permissionless innovation uh that allows people like you and me to try new ideas out. We've talked about mobile and we skip over that. Performance is another huge problem space uh and it gets harder and harder as the net gets bigger to figure out exactly what went wrong. I know when if you if you're trying to do something on the net and it isn't happening in a reasonable amount of time, you sort of wonder, well, what broke? And if you have any knowledge like you do of how all the different things that could possibly go wrong are in the chain, uh, I want a WTF button that I can push that that that sort of says, "Okay, let me see if I can figure out why you're not getting the service you expected." Uh, we really do have to find ways of not only measuring but also articulating and identifying or exposing uh, performance problems in the net. And I think it's really hard uh to do that. So there's some good design work waiting to happen. And with regard to addressing setting aside the V4 and the V6 uh transfer transition, uh it's reasonable to ask questions about what other things should be identifiable or addressable in the net and it's not obvious why we should uh stop thinking about addressing at the you know interface to a computer. What about just a digital object that has been created with a, you know, maybe it was a spreadsheet or a word document or something else. Why couldn't it have an identifier? And of course, you could say, well, what's wrong with the URL? And one answer is it depends on the domain name system. And well, what's wrong with the domain name system? Well, that is not necessarily uh long-term. There's no guarantee that a domain name will continue to be resolvable. So one might start asking well is there some other scheme I can use to identify objects in the internet that would have a longer lifetime that doesn't have the same potential brittleleness of uh of a domain name that is currently used in the URLs. We could talk about URNs as an alternative uh in the uh in the web structure as a way to do that. Um I'm going to skip over policy right now because I'm more interested in first of all not running out of time and second uh getting to a couple more technical points. Uh something that we do every day is the creation of complex objects. We use application software to build spreadsheets to build complex word documents to build presentations and a variety of other things. and the uh files that of bits that those applications create are only as useful as our ability to apply the application to those files. So, one of the things that I'm becoming increasingly worried about is that uh we invest a huge amount of effort in creating these digital objects and then if someday the application software doesn't work anymore or isn't available that all the investment in the digital objects will evaporate. We'll just have a pile of rotten bits. So, I've been calling this the bit rot problem and it's more complicated than it looks. the the typical uh analogy or metaphor I have in my head is that it's the year 3000 and I'm running Windows 3000, let's say, and I do a Google search and I turn up a 1997 PowerPoint file in my Google search. The question is, does Windows 3000 know how to interpret a thousand-y old PowerPoint file? And the answer is probably no. Uh and that's not a gratuitous dig at at uh Microsoft. I think even if we had open source, it's not 100% clear that the open- source functionality would be preserved for a thousand years so we can read these old digital objects. So I worry about this for a couple of reasons. First of all, um if if the if someone decides not to to maintain any any longer a particular application that you were dependent on and if maybe the operating system that that worked down becomes obsolete, uh then you're sort of out of luck because you can't run the application anymore. uh open source kind of helps because we might be able to keep running those applications. But what if they're proprietary applications that we've become accustomed to using and we've made uh investments in creating objects using those applications and the company goes out of business. What happens to the intellectual property that went into that proprietary software? So as an example of the sort of thing that would be interesting would be to find a way to let a cloud-based operation absorb uh this kind of application and make it accessible to everybody. Obviously there's all kinds of intellectual property issues associated with that. Maybe you even have to preserve not only the application but the operating system version that it ran on and once again there will be more intellectual property issues. So in a way what you're doing with Linux is helpful because you've created an environment where that itself may not be as much of a problem. But I am worried that we are not thinking our way through preserving of our digital stuff and 10 20 30 years from now or even 100 years from now people may wonder about the early 21st century because all of our stuff won't be interpretable anymore. So we we we will all just be a big pile of rotten bits as far as they're concerned. So I don't know how to solve that problem except to chip away at some of the specifics. Now I've been everyone has heard the term internet of things and I'm expecting to see an increasingly large number of devices on the net. I love the guy that made this internet enabled surfboard. He's uh he's in the Netherlands. I haven't met him, but I have this picture of him sitting on the water thinking, you know, if I had a laptop and my surfboard, I could be surfing the internet while I'm waiting to Good man. So, and I mentioned earlier that sensor nets are likely to be on the system. This is a little uh eye chart. Uh it's a it's a diagram of an IPv6 wireless sensor network I have running in the house. It's a commercial product from Arch Rock, which I guess was just acquired by Cisco, and it samples temperature, humidity, and light levels every 5 minutes in the house, and it records that in the server down in the basement. Uh, the wine celler is very important room in the house. I have to keep it below 60° Fahrenheit, and if it goes beyond that temperature, uh, I get an SMS on my mobile telling me, you know, your wine is warming up. Uh, that actually happened. And after I was away for several days and I I kept getting messages every 5 minutes saying, you know, you're in trouble. So I asked the Arch guys if they made remote actuators that I could go in and install. Uh they said yes, that's a project they need to do. And but I can also tell whether anybody's gone into the wine celler. Uh if the lights go on, they'll that'll be recorded, but I don't know what they did in there. So, uh, in particular, I I thought, well, maybe I should put RFID chips on the bottles. And then, you know, I could I could, uh, you know, tell if anything leaves the wine celler without my permission. But one of my friends was debugging the design for me, and he said, "Well, you know, you can go into the wine celler and drink the wine and leave the bottle." So, now we're going to have to put uh uh sensors in the cork. Um, and if you're going to go to that trouble, we might as well be sampling the esters to figure out whether the wine is ready to drink. Before you open the bottle, you interrogate the cork. And you know, if that's the bottle that got up to 90° at some point, that's the wine you give to somebody who doesn't know the difference. So, something practical about that. So, so the sensor nets are going to be everywhere. All this smart grid stuff is is taking off and we're going to see more. will be gathering data. You know, the buildings will know more about us and the environment and everything else. We'll be swimming in a sea of information. Of course, we all have to make sense of all that. The smart grid in the US is is moving along in that domain, too. I'm running a little over, but I'm going to finish up with this interplanetary internet stuff. Now, the last time I mentioned this, some people thought, okay, he's off his chump. Uh, and is he expecting to communicate with aliens? Uh, or or should I be worried about alien porn? And and the problem is we can't even figure out, you know, did you see the ovapositor on that thing? So, so this is actually a serious piece of engineering. Any of you who um who get a kick out of taking what sounds like a crazy idea and actually making something work as an engineering project, I think we'll appreciate this. Uh my colleagues at the Jet Propulsion Lab and I got together in 1998. We said, "Look, the networking of space right now is point-to-point radio links, and that's not a very rich network. Can't we do better? Can't we create a networking environment that will allow us to have multiple spacecraft communicating with things on the ground, things are moving, maybe sensor networks that are sprayed across the landscape?" And we said, can't we use TCPIP to do that? And of course, the answer was works okay on Earth, works okay on Mars, doesn't work okay between them. Then there's a little problem. The speed of light is too slow. And the the distance between Earth and Mars varies from 35 million to 235 million miles. That's a variation of 3 and a half minutes to 20 minutes one way. Can you imagine writing a browser program? You know, you click on your mouse and it's 40 minutes before the first bit comes back. And I know you've got networks with those problems here. But but that's that's not that's not because of speed of light delay. So, and then there's this other problem, celestial motion. You know, the planets are rotating. We haven't figured out how to stop that. So, when you're talking to something on the surface and it rotates, you can't talk to it till it comes back around again. So, there's delay and there's disruption. And we concluded uh this is a great shot from the rovers. We concluded that we were going to have to build systems that that had in in them in the architecture and in the protocols delay and interception knowledge. So, we did that. We developed a set of protocols we call GTN type protocols. They've not only been implemented, but we put them on the space station. We put them up on board uh the epoxy spacecraft that just rendevoused with the Harley 2 comet. Uh we're uh experimenting with some prototype implementations on android. uh and we're hoping to persuade the consultative committee on space data systems which is all the space fairing nations to adopt the use of these delay and disruption tolerant networking protocols in order to make standard a rich communication networking environment for space exploration both manned and robotic. So what we're hoping frankly is over a period of decades that we'll literally grow an interplanetary backbone because once uh a particular spacecraft has completed its primary mission, it can be repurposed to become part of a node of an interplanetary network. So we're actually what is it telling me to do here? Possible dinner, right? Um we're hoping that we will actually grow an interplanetary backbone over time. I won't see the end of it, but it's been a lot of fun to see the beginning. Okay, we're going to do Q&A, but I need to warn you ahead of time that I'm hearing impaired. So, when you get a microphone to ask the question, you're going to need to hold this little gadget with you. It is an FM transmitter and a microphone. And I am Hang on. My hearing aids just turned off. I am the guy that came to talk and wouldn't listen. See you. Ready? Hello. Hello. Testing. Oh, wait a minute. I got to turn the power on. This is where I run out of batteries. Okay. Testing. Yes. Okay. So, if if you will hang on to this thing while you ask the question, that will help a lot. Okay. If you if you have any questions, if you don't have any questions, that's fine, too. Hands up and we'll uh we'll come to you with Mike. Okay. Running. Running. Okay. Now, make sure you return that little FM transmitter. It cost about $850. So, so about the bit rot problem at the moment, you know, there's a lot of data from say 2,000 years ago that we no longer have because it rotted physically. So is it likely that the same situ situation will happen with the bit rock problem that we will lose lots of data but that's going to be okay because we'll keep some well actually I have first of all I have to say that um we are less in in at risk because of the media than we are because of the formats. The reason for that is that it should be possible to move bits from one medium to another. So I'm I'm more sanguin about that part of the problem. Although I completely accept when somebody shows you a DVD and and asks how long is that going to last or how long will the reader of the DVD last and uh you know you don't quite know the answer to that and when the librarian comes and shows you uh a vellum manuscript that's a thousand years old that's still readable you sort of cringe and think boy we have some work to do. Um, I am more worried right now about being able to preserve our ability to interpret the bits than anything else. Okay, next question. I just wanted to ask you talking about the TCP IP binding problem. It's an issue that we've seen come up, especially with, as you said, you know, mobiles, there's quite a lot of us that network engineers that know about it, etc. What's actually happening on a research level for that? Because I haven't really heard anything that's been going on globally to try to address that. Is there a concerted effort? Yes, there is. In fact, there's an IETF, at least more than possibly more than one IETF um uh working group looking at this problem in particular breaking IP uh V6 address space up into two 64-bit pieces uh and introducing possibly a shim layer. I don't maybe some of you know the remember the acronym for the working group. I've just gone out of my head, but you should uh you should be able to find that in the IETF working groups and I'd recommend that you have a look there because there's real progress being made. Wow, this is really hard, isn't it? It's part of the um health plan for the folks who are um so one of the things that has been recently in the news is Jim Gettys about buffer bloat and how it's affecting TCP congestion control. Um what are your thoughts on that? I'm sorry. I missed one word. I'm sorry. I missed one word at the very beginning that it was something that was affecting the congestion. Um buffer bloat is affecting um TPC congestion control. The upload buffer. Oh, buffer. Oh, this is the buffer bloat. Oh god. Yes. Jim Gettys. Um I Jim is Jim is in the process of writing a couple of uh specific articles about this. It's a huge problem. Um I don't know how many how many people know about buffer bloat that Yeah. So I my I don't need to tell you what it is. My reaction right now is that uh the only way we're going to fix this problem is to get people who make the devices that have these large scale buffers in them to artificially reduce their size. That's the only way we'll get rid of the problem is feedback loop. It it's it takes too long to discover that there's a problem because we allow everything to fill up the buffers. So my reaction to this is that um because memory got cheap, people stuck buffers in because they thought that's would would help. And in fact, at some point it doesn't. I hope that uh Gettys and others are able to persuade people that they really need to um uh re-engineer systems to not have more memory than is absolutely necessary. Yeah. One funny thing appropo of buffer bloat. Where I'm sorry, where's the question coming? Oh, there you are. Thank you. Okay. Uh, one one uh interesting observation app propo of buffer bloat was uh there was actually advice given to all the conference attendees from the Australian networks here that because we're so far away in the undersea cable to increase the size of our buffers uh to make things work better. Um so I I was sort of amused by that. Well, you know this is how how many bad things have happened and somebody said I was only trying to help. Right. We're okay. Keep you running. Come on. We have time for a couple more here. I'm not going to the gym this week. So when you are not presenting, what do you get to hack on? Okay, so that's a good question. I'm one of well the um interplanetary stuff is one of my hobby horses. Uh the rest of the time uh I'm running around trying to not so much to write any software which I haven't done in a while. It's to try to persuade people that they should want to be writing software to do various things which is part of the story here. Um part of my time uh I get to spend uh on university campuses in particular trying to help not only graduate students but their uh professors recognize that there are some serious hard problems that deserves an attack that everyone would benefit from if they were solved. And so I spend more of my time being an an evangelist to me. What else would you expect with that title? I didn't ask for that title, by the way. When they asked me what title I wanted, I said, "How about Archduke?" But you you notice I didn't end up with that title. And the reason first they said it didn't fit with the uh you know, the nomenclature, but the more important part was that the previous arch duke was Ferdinand and he was assassinated in 1914 and it started World War I. So that might not be a good title to have. Next question. Um, with the IAN and the domain name system and the fact that they're now basically making it so you can do anything as the domain name, isn't that going to cause more complication? I mean, the entire point of the domain name system is to make it simpler that you don't have to remember a TCP IP address and now all of a sudden we're going to have anything as a domain name. Isn't that going to add complication to the system? Well, uh, it may certainly give too many choices, but I let's be honest, it's hard to believe that you could, uh, remember today every possible, uh, domain name, even forgetting the non-Latin ones. uh the more important observation which is going to sound very self-serving I think is that search is a really great way to find things and and but what's important is that having searched and found having a domain name or something which is fixed that you can return to is absolutely essential otherwise email and other things wouldn't work uh so I think we have to rely on our computers to remember the specific fix for us. I'm I'm not sure how many people still try to guess domain names and type them in. Maybe they do and it doesn't work and then they search. So, my guess is that's really where we're going to end up is searching and and remembering. I think we have time for one more. Yeah, one more. In your opinion, do you think Google would look favorably on any Google Luna X-P prize team competing that might use the interplanetary internet protocol to communicate back here? So uh my honest answer is that I've been trying to persuade the guys that are funding that to provide a free uh interplanetary protocol bundle protocol implementation just and not require anybody to use it but make it available freely. I would love that. Uh so I'm not quite I don't think that there would be any special favors but I think it would help if we just got over that problem and made it available to everybody. Okay, that's all the time we got. Thank you so much. Thank you. Please welcome Dr. Vinton G. Surf. Thank you. Thanks guys. That's great. in recognition. You know, you would not be clapping if you knew that my next stop is the Barasa Valley and McLaren Veil. The my the real reason for coming to Australia to recognize Vince's contribution. Uh we have this bowl made of Queensland macadamia wood. Thank you very much. Thank you very much. Oh, now that's beautiful. This is great. Thank you. Thank you very much. Okay, you've got somebody else coming up right now. Thank you, Vint. Here comes just one little reminder before we head off. Morning tea will be available outside uh now. Thank you. Before we head off to that, I was a little bit disappointed yesterday that we only made it to the top trend in Twitter by about 1:00 p.m. I would have expected us to be there at least by about 11:00. So, let's see if we can do a little bit better today for all those social freaks out there. Are we already there? Are we wonderful? Okay, guys. Thank you. Thank you, Dr. Vin. Right. Yeah. Thank you. God, what a process this is. Shim 6 the uh I'm sorry. Was Shim 6 the the working group that you were making for the um uh mobile I was looking up uh let me get my glasses on here I won't be able to see. Wow. 06 type. Sorry. Oh yes. Okay. Shim 6 is one of them. That's one of them. Yes sir. Yes. Right. I You're right. Hang on. Let me turn this off. You got there. It's gone. Is it? And I need to take this [Music] off. There we go. Yeah, I saw I like that. taking photos of the UFI. Yeah. You know how I do events, right? And I'm always told, "Oh yeah, yeah, the internet will be fine. Not white. It'll need this kind of thing." And they go, "Oh, it'll be fine." I want sort of, you know, this is how it's done. Don't give me Yeah. Uh, no. camera seems to move on. Yeah, I'm just Yes, I believe. Can I just [Music] Okay. Yeah. Which way? Did it just turn off That's my background. So now I'm in the [Music] Okay, I'm all set. One more cast. Miss on the right. Next. No. Yeah. This was evaporating. So, I'm going to plug in and this is where the next I have the No, it's not. That's not normally. It's a bad way of getting it to work as booting it up. As long as it works with Yeah. I've heard I've heard these rooms now from what I understand making sure that everything that they're doing from I usually just got so much junk. Oh, really? You can hear [Music] your fancy little. Do you have an idea? Right. Exactly. Yes. Hello. What are some of our I've got 10. Yeah. little thing in the room. quite a bit resolution 1024. Well, I had one of the guys say there was someone driving very Excellent. Excellent. Did you know this? That's too much. I'll try and do it. That's what you're saying. It's okay. Thank you. The funny thing though is the WP access point. Does this work? Yep. I You spend more time. He spent more time. Yeah, probably need to start at couple inches and then double the font size. Yeah, it's still going to run off. Yeah. Um, turn off transparency. Okay. That's cool. everything including the problem. I'm wondering Last year was 111. Okay. Let me see because I say you are doing very nice. Well, Yeah, I We open What's a lot of Why would you? Yeah. All right. But anything more interesting outside How many? It makes such a difference, too. Oh, that's excellent. That's mad. I was wondering how you got such a good photo. Oh, and the skill. It's all skill. Do you want something? Check check check. You bend down too much. Who needs Sorry. Check, check, check. Is this Will this do? I suspect. Okay, this is going to be a pain. So, I'll just hold it. Why? Or do I need to speak? Okay, I can do that. Yeah, just have to make it uh speak a little bit louder and that should work. Awesome. You can turn it off again if you like. Yep. Okay. Oh yeah, that's right. Thank you very much. mess around with it too much. Yeah, that's okay. You can't mess around with it worse than I do. You want to do a walk outside later in lunch with a big lens? Yes. Is this one on? [Music] Cool. Okay. Um, we'll start off in a minute or two. So, welcome to the CISDmin mini. If you were expecting a different mini comp, you need to leave now. Um, first up, a couple of announcements. Uh, first off, if you have a mobile phone, can you please put it on mute or turn it off so as to not disturb everyone else if you're not on call? Now's a really good excuse to turn it off. We are ordering you to turn off your mobile phone. Please note anyone's manager. Okay. Um, secondly, our latest schedule is this online one here. Um the there are some slight changes from the printed schedule. The main change from the printed schedule, the sambber talk, which was going to be this afternoon, it's now this morning. Um as the other thing is at 14:45, we have a 10-minute gap. We have about 5 minutes in there. If you have a very short lightning talk you want to squeeze in, please come up and discuss with myself or you. Um, and that's probably about it and we'll just lead on to the first talk. All right. This is Dev Dash talking about DevOps. Right. Can I just borrow the cable? Thanks. Okay. Work. Thanks. Here we go. Lovely. All right.