>>>
The Greyglers is a group of approximately 200 Googlers, a little less than that, most
of us of a certain age. And this is our first big public event.
So thanks very much for coming. Just wanted to give you a really fast overview
of our primary goals. They are to raise awareness of age diversity
at Google and in our user base, to help attract experienced talent to Google, and to help
make Google culture and Google products and services welcome to people of all ages.
Anyone who can relate to our mission is welcome to join.
You don't have to have gray hair, or even gray roots, like some of us.
[ Laughter ] >>> And today we're running a one-time special.
There's a goto address on the screen if you'd like to join.
It's goto/join-Greyglers. The first 50 people who join will get one
of these way-cool tee shirts. So don't forget to do that.
So we are honored that Vint is a Greygler, and he's also our executive advisor.
Speaking of the main attraction, Vint will be taking questions via Dory at the end of
his talk. So if you have questions, please be sure to
go and submit them. The address is up on the screen.
It's goto/Vinttalk -- one word -- hyphen questions. >>> Hi.
As a Greygler, I can remember what things were like -- as a Greygler, I can remember
what things were like before the Internet existed.
Everybody had a lot of free time on their hands.
[ Laughter ] >>> And no one had any information at their
fingertips. But Vint Cerf has done a lot to make that
change. With Bob Kahn, he invented the TCP/IP protocols
and the basic architecture that allow computers all over the world to link together and communicate.
And he spent most of his career providing leadership to develop the technology into
the Internet that we all know and love today. Because of his contributions, he is frequently
called one of the fathers of the Internet. And he has received quite a few awards of
recognition from lofty organizations. He received the Turing Award from the ACM.
He received the National Medal of Technology from President Clinton.
And, in a show of bipartisanship, he received the Medal of Freedom from President George
Bush. He's also --
[ Laughter ] >>> He's also been designated one of the most
intriguing people of the year 1994 by "People Magazine."
[ Laughter ] >>> So his talents span a broad spectrum.
He's been an advisor of many boards and organizations. He's received many, many awards, at least
two of which include the word "legend" in their title.
And he serves Google as our chief Internet evangelist.
So today he's going to share with us some of his insights into how the whole Internet
evolved and how we could have done it better if we had only had known these things in advance.
So with no further ado, here's Vint. [ Applause ]
>>Vint Cerf: You know, I always get nervous when people clap before you say anything.
It makes me want to just sit down, because it won't get any better than that.
[ Laughter ] >>Vint Cerf: I -- really, I'm stunned at this
overwhelming turnout. I do recognize, however, that theorem 208
might apply. It says, if you feed them, they will come.
I know there's food out there. So that's part of it.
The other thing I'm very conscious of. You probably have no idea how daunting it
is for me to confront a bunch of really smart Googlers.
I don't know how many of you know about the talking dog, some guy finds a dog that can
talk and he takes it around to various places. And everybody's all excited about the fact
that this dog can talk. It doesn't matter what the dog says.
It's just the fact that he can talk is amazing. I feel like the talking dinosaur.
I've been around since the Jurassic Period. I hope I have something of interest to say.
Two things. First of all, if you get bored, I won't be
offended if you leave. And probably some of your folks around here
will appreciate it if somebody went away because of the density.
And then second, when we get into Q&A, I really invite people to raise issues, to challenge
things I might have said. The fact that you're around for a long time
does not necessarily give you vision. In fact, in some respects, if you've been
around for a long time, you can't necessarily either predict the future or see what's coming.
There is -- I forget who said this, but he said, you know, if an old and distinguished
scientist tells you you can do that, the chances are pretty good that you can.
But if that same individual says you can't do that, there's a good chance he's wrong.
So I may be wrong about some of the things I'm going to say.
And I invite some interaction about that. Let me start out by just reminding you that
the thing that you're working with started out in a predecessor program called ARPANET
with four nodes, just four computers and four routers or, actually, packet switches.
I used to be at UCLA as a graduate student. And had the responsibility for writing the
software to connect a Sigma 7 computer to the first router that was installed at UCLA
in September of 1969. The Sigma is in a museum somewhere.
And some people think I should be there along with it.
[ Laughter. ] >>Vint Cerf: If you fast forward a few years,
you see an Internet that looks like this. This was generated automatically by looking
at the global routing tables and assigning a different color to each autonomous system
and showing something about the connectivity. This is Bill Cheswick, formerly of AT&T Labs,
generated this. And I'm sure if we looked at the 2010 version,
it would be very much like this, maybe bigger and more colorful, but still very complex.
One of the things that it's important, I think, for you to take away from this picture is
that it does represent a very large number of autonomous systems, each one of them operated
independently. This system is not centrally controlled.
It is something that is collaborative. It's something that people voluntarily interconnect
in order to gain benefit. And so even if we argue about whether Metcalfe's
Law should be N squared or N log N, the reason this works -- yes.
>>> (inaudible) this is based on -- >>Vint Cerf: No.
The colors, the colors represent different autonomous systems.
>>> The colors maybe. >>Vint Cerf: And, of course, the connectivity
is clearly I.P. But that's an A.S. -- each color is a different
A.S. Okay.
Are we square on that? See, it's okay to interact.
[ Laughter ] >>Vint Cerf: Somebody throw the -- all right.
[ Laughter ] >>Vint Cerf: All right.
So that's -- the point here is that it is voluntarily a collaboration of global proportions.
This doesn't happen unless a lot of people want it to happen.
So an important other takeaway is even though Bob Kahn and I did do the original design
work, this wouldn't have happened if, literally, millions of people didn't decide they wanted
it to happen. Here's just kind of a picture of how quickly
the number of machines on the network has grown over time.
It started out in -- with the four nodes that I mentioned on the ARPANET.
When the network was first -- Internet was first released, it was January of 1983, there
were 400 computers on the network in January of '83.
And it was a hard problem to get everybody to switch over from the older NCP protocols
to the TCP/IP protocols. And I don't want to waste your time telling
you how we did that. But it was coercive.
It was not cooperative. It was one of those I'm turning your funding
off if you don't switch over to TCP/IP. Fortunately, I was at DARPA at the time and
could actually say that. Today you can't do that.
That's harder. The number of machines on the net now that
are publicly visible is approaching 750 million. The number of machines on the Net, in fact,
is much larger than that. We're an example, because there are lots of
machines behind firewalls that people can't see through the public DNS.
The number of users now is estimated by Internet world stats at 1.8 billion.
Again, that's an estimate. The other thing which has been going on that
we are all very much participant in is the mobiles that have shown up in the telecom
environment. Extremely rapid innovation and penetration.
A lot of those mobiles are Internet-enabled. And, of course, we care a lot about that because
we've offered Android as an operating system, and we are wanting very much to offer and
let others offer applications that take advantage of mobile access to the network.
If we look at where the Internet is right now, or where the users are, it's actually
a fairly stunning revelation that North America is only third on the list now.
It used to be at the top, because this is where the first penetration occurred.
We're still the highest percentage penetrated. But as you can see, Asia represents the largest
single grouping. And of the 764 million people on the Net in
Asia, about half of them are in mainland China. So the largest grouping of users on the Internet
today is in China. Now, we all recognize that there have been
interactions between Google and China and there's policy questions.
But it is an inescapable fact that the largest population of users on the Net today is in
China. And that will continue to grow, because their
percentage penetration, Asian penetration, is only 20%.
So you understand when it gets to 75 or 76%, the number will be dramatically bigger.
We care a lot about these kinds of statistics because it tells us where our products and
services have to go, where they have to serve, what kinds of users, cultures, languages,
scripts, and everything else we have to be prepared to deal with.
These are just another way of displaying the same kind of information.
So I'll kind of skip through all of that. You'll notice at the bottom here that the
average penetration around the world is slightly over 26%.
As the chief Internet evangelist at Google, I have the feeling I have three-quarters of
the world to convert still. There's a lot of work to be done to get Internet
in place. Mobiles are actually helping a lot in some
respects, because their economics is so attractive. When Bob Kahn started this -- I want to emphasize,
it was Bob Kahn that started the project. He was at the Defense Advanced Research Projects
Agency. I was still at Stanford.
And he had some simple ideas about what he wanted to accomplish in the interconnection
of networks. Each network would have to stand on its own.
There wouldn't be any changes permitted to the networks that were part of the original
Internet in order to make them part of the Internet.
Which led to the need for gateways in between. Because the networks had no way of referring
to any other nets. Their addressing structure thought they were
the only network in the world. Later on, we'll see a similar situation coming
up with clouds. This is all best efforts communication.
And in a sense, that was really important. We made no guarantees at all.
If you could get a packet from point A to point B with some probability greater than
zero, that's all we were asking of the underlying system.
There would be these black boxes, which we called gateways at the time, because we didn't
know they were supposed to be called routers, and we assumed they would be able to send
objects, packets, through each of the networks that interconnected and that the Internet
packets would be encapsulated inside those packets of each individual network.
That turned out to be a very important tactic, because it allowed arbitrarily large numbers
of different kinds of packet networks to be part of the system, because we were simply
encapsulating and decapsulating the Internet packets that went end to end.
And, finally, there's no global control at the operational level.
That was important from the military point of view, because we didn't want a central
place that could be attacked and the network disabled.
So there's global addressing was needed, because the networks didn't have a way of referring
to other nets. Gateways were forwarding packets.
There were algorithms to recover from lost packets.
We didn't assume everything was reliable. And some of the initial networks that were
involved were actually quite unreliable. Packet radio was a mobile system.
Ethernet was not necessarily a reliable transmission scheme.
We provided pipelining so that there could be a stream of packets flowing from end to
end, which is where those of you doing TCP stuff know about Windows, about how many packets
can be outstanding before you have to stop and wait.
There were some end-to-end check zones. We assumed things would be reassembled.
We knew we needed host flow control, although we'll see that we didn't do as good a job
then as we could probably do now. And then interfacing to a variety of operating
systems and other things. There were some other secondary concerns like
efficiency, performance, and, by the way, security, although, in fact, we didn't focus
very heavily at all on security, and we might look back on that and regret it.
But I have to say that if we had tried to focus heavily on security in these early days,
we might never have even gotten anything built that we could test.
We honestly did not know whether this system would actually work.
One of the nice things about the Net is that we didn't make any assumptions about applications.
And, you know, the old expression, if you don't know where you're going, any road will
take you there, if you don't know what application you're running, any packet will take you there.
And in a very funny way, the Internet has survived and thrived because of the fact that
it wasn't designed to do any particular thing. A lot of the historical networks, like the
telephone, telegraph net, the television broadcast networks, the cable networks, were purpose-designed.
And that purpose design limited what they could do.
The Internet didn't have that limitation. And as the capacity of the Net has grown,
as the economics of electronics has dropped, it's been possible to make the packet-switched
net do a lot more than it did when we were working, you know, with 50 kilobit backbones.
I mean, the word 50 kilobit and backbone in the same sentence sounds, excuse me?
That's a dialup modem today. The other thing that's interesting is, the
Internet layer, the Internet packets, have no idea what they're carrying.
They don't know how they're being carried. They don't care if it goes over a satellite
link, an optical fiber, or submarine cable. Only the edge devices that can interpret the
contents of the packets understand what it means.
There is no national indicator in the I.P. address space.
That was a deliberate decision on my part. Remember, I'm doing this at the Defense Department
or for the Defense Department. I wanted not to have any binding of the networks
to any particular geographical location. Now, we all understand that the domain name
system has a very specific potential binding, because we have, you know, country codes,
like .DE, .FR. And a lot of us have worked hard to make it
possible to associate locale with I.P. addresses because we're interested in geographic --
applications that have some knowledge of geographic location.
But when the design was done, I didn't want to have any such binding, because I didn't
want any national authority to interfere with the military's ability to deploy a network
wherever it needed to go. I didn't want some third party to say, "I'm
sorry, you can't have address space because we think you're an aggressor or an enemy."
So I didn't want that to be a problem. And, finally, our performance targets, again,
were best efforts. Now, there are some changes going on in the
Net. And we're involved in some of them very intimately.
IPv6 is one. And I'll show you a chart that motivates why
we need to have a different I.P. address space than the IPv4.
Some of the people in this room -- I saw Lorenzo here.
I don't know if Eric is here. But you have some -- a group of people here
at Google that have single-handedly pushed us to implement IPv6.
The reason that's so important is that the IPv4 address space only has 32 bits.
It's 4.3 billion terminations. I made the decision in 1977 that the address
space could be 32 bits and it would be enough. I thought we were doing an experiment.
[ Laughter ] >>Vint Cerf: I thought, you know, that we
didn't know if this thing was going to work, and surely 4.3 billion terminations is enough
for an experiment. I mean, even the Defense Department probably
couldn't use that many termination points. So I thought what would happen is if we demonstrated
this capability, then we would in fact do a production engineering job of it.
Well, the experiment never ended. Here it is 2010, we're running out of address
space, we need larger address space. We actually argued 32 bits, 128 bits, and
variable length. The variable-length guys lost, because the
programmers said it's going to chew up a bunch of computer cycles to find the fields and
the packets, and so they didn't want to do that, so that was out the door.
And finally, because nobody could make up their minds and I'm sitting there in the Defense
Department trying to get this program to move ahead, we haven't built anything, I said,
it's 32 bits. That's it.
Let's go do something. Here we are.
My fault. [ Laughter ]
>>Vint Cerf: On the other hand, you know, if I had stood up and said we need 128 bits
of address space because this is going to be the world's backbone in 25 or 30 years,
they'd look at me and say, "Boy, are you out of --" internationalized domain names.
Remember I showed you all the distribution of users in the Internet?
There are more users who don't use Latin character sets than there are people who use Latin character
sets. So internationalized domain names are a way
of writing domain names in scripts other than Latin characters.
So Cyrillic and Chinese and Hebrew and Arabic and so on are all scripts that are now available
for IDNs. And they're being introduced now by the Internet
Corporation for Assigned Names and Numbers. The domain name system, as I'm sure you are
all very well aware, has got a bunch of vulnerabilities in it.
One aspect of that is that it's possible to poison the cache of a DNS resolver.
It's possible to, in fact, invade the name servers.
And so getting digital signatures that you can use to confirm the binding of a domain
name and address is actually an important and useful step.
It doesn't solve all problems. But it's an important one.
That's starting to happen now. The root zone will be, in fact, signed sometime
during the summer this year. And then, finally, the routing system has
the awkward problem that it's possible to lie about what you're connected to.
And if you want to avoid having -- introducing lies into the routing tables, one way to do
that is to have tables that show which entities, which autonomous systems are allowed to announce
what connectivity they have. If it turns out that you received a routing
update which isn't confirmed by a digitally signed entry in a table that should be publicly
available, you might discard that particular update and maybe even raise a red flag and
say somebody is trying to spoof the system into directing traffic where it doesn't belong.
There are sensored networks that are coming up and being connected to the net.
I'm give you an example. The smart grid is an activity that we are
very much involved with because we have a power meter program.
I'm personally involved in this in a variety of ways because the smart grid interoperability
panel has a governing board and I'm on that, and the whole point here is to try to find
ways of letting electricity-consuming devices be more cooperative in the event you're reaching
a peak load. One of the ways is to go through the Internet.
So they will be, increasingly, on the network. And, finally, mobiles, as you all know.
We have a bunch of problems -- I'm not going to catalogue all the problems.
I'm not going to talk you through all of them. Because you know most of them.
The thing I want to emphasize here is that as soon as you turn a system like this over
to the general public, you have to deal with the general public.
You have to deal with the motivations of the general public.
And not everyone in the general public necessarily has everyone else's best interests in mind.
And so one of the facts of life is that the network began with a fairly homogeneous, uniform
collection of academic types, research types, engineer types, who more or less shared a
common view of what it was they were trying to accomplish, and they more or less trusted
each other to do the right thing. We are now faced with the consequences of
commercialization. And spread of the Net to the general public.
Now, I was a big proponent in 1988 of commercializing the Internet.
And I know my colleagues, many of them, anyway, thought I was crazy.
Why would you let the general public, you know, this great unwashed, into our wonderful,
you know, sandbox? And the honest answer to that is that I didn't
think it would ever be available to the general public if we didn't build a commercial engine
underneath it to support it. And so I was very much in favor of trying
to find commercial businesses models that would allow the Internet to grow, because
the general public and industry wanted to be on it.
So, indeed, that's what happened. I'm not trying to claim any credit.
Just for having been much -- an advocate of that particular thing happening.
So the point I also want to make here is that in spite of all the vulnerabilities and everything
else -- and these are not just technical vulnerabilities -- you know, bad passwords, social engineering,
and things of that sort -- some of the worst things that happen to the Internet are mistakes
that we make. You know, half the Net falls off the Net,
or YouTube disappears because somebody in Pakistan creates a black hole that everyone
routes to, not just the routers that are in Pakistan.
It's amazing how we can screw things up without even trying.
And so one of the big problems with design of systems like this is how to make them more
resilient and more conscious of errors in configuration.
This is probably one of the hardest problems that I can think of.
It's figuring out that a configuration is wrong.
It's easy if some part of that configuration has a parameter value which is outside of
a valid range. That's the easy case.
The hard case is some ensemble of configuration parameters that turn out to add up to bad
things. Figuring out that that's the case, at least
in my experience, is very, very difficult. So that's a problem worthy of serious thought
and consideration. There are other serious security weaknesses
in the system. We have operating systems that are much too
willing to be invaded, in effect, to allow their resources to be attacked or coerced.
Browsers which are very naive about software that they download or that -- the Web pages
they download and then interpret. That's why we released Chrome, because we
think we did a better job of building sandboxes for the interpretation of downloaded Web pages.
But we are still far from having what I consider to be a completely secure environment.
We never will. But we can probably improve beyond where we
are now. We don't have very good access control practices.
I talked about improper configurations. A lot of the botnets that cause trouble, that
generate spam, do denial of service attacks and everything else are a direct consequence
of laptops and PCs and increasingly now mobiles that have been coerced and invaded and become
tools of the botnet herders. So even trying to detect and go after botnets
is -- is going after the symptom. The real issue is that we allow these resources
to be coerced by people who don't own them and have no business using the cycles.
And, of course, there are all kinds of parties, including organized crime and state-sponsored
agencies, that want to exploit these vulnerabilities in the network for their own advantage.
There are lots of privacy problems. And, again, they cover the gamut.
And I want to get -- because it's already 20 minutes into this thing, I want to get
beyond the list of problems and get to the things that we really need to do.
I do want to mention cloud collaboration. That is to say, interactions between clouds.
This is important to us because we are committed to data liberation.
We're committed to letting people get data out of the cloud.
The question is, how do they get it out? First of all, where do they put it?
And second, if they want to move it to another cloud, how do they do that?
And without going into terribly long diatribe here, I believe that cloud interaction in
2010 is about where we were with networking in 1973.
We had networks. They were proprietary.
You could make all the IBM machines interact with each other, the Digital machines interact
with each other using DECnet. But we did not have much interaction between
networks of different manufacturers. Internet was intended as a nonproprietary
solution to that problem. Today we have proprietary clouds.
In fact, most of the clouds have no idea that other clouds exist.
The best they can see is another cloud possibly because it looks like a Web server somewhere.
But clouds have properties. And the different clouds that are built have
different properties. Some of you just go back into history for
a moment, will remember a protocol called TELNET.
TELNET had a very interesting property. It had a thing called a network virtual terminal.
This was a thing that never existed. The problem was that the computers at the
time had a whole variety of different terminals, and they all had different encoding schemes
and different conventions for what new line is and so on.
So the guys doing the ARPANET said why don't we invent a thing which doesn't really exist
but we'll call it a network virtual terminal. It has a set of properties.
We will map our terminals on a given host into that network virtual terminal behavior.
And what we would like to do is to say, for everyone who's out on the Net, as long as
you can handle the network virtual terminal, then you can interact with any terminal on
-- any host in the ARPANET. Maybe we need a network virtual cloud.
We need something that all clouds can pretend to be.
It won't exercise every functional capability of every cloud, but it might exercise sufficient
commonality that we can move data back and forth.
Maybe we're capable of actually getting processes to run in two clouds that are interacting
with each other concurrently. What about data that's in a cloud and it's
access-controlled and we want to move it to another cloud?
What metadata do we have to move to the other cloud and how will it be interpreted and will
that access control continue to be observed? These are all questions that don't yet have
answers or maybe, in some cases, too many different answers, because we have so many
different options, you know, SOAP and UDDP and all -- UDDI and so on from the Web world,
and a variety of other options. So we don't have any agreed standards on letting
clouds interact with each other. So I think there's a rich area for research
and development there. So here are the kinds of problems that we
did not solve and have not solved adequately in the Net.
One of security at all levels in the architecture. There's no one place in the Net where you
can guarantee all the security you need. We don't actually have a very good understanding
of the statistical nature of the network. In fact, it's very hard, I think, to characterize
the Internet or even pieces of it in a statistical way, because unlike the telephone system,
the dynamic range of demand on the Net is extremely broad.
You could be clicking a mouse for a little while, sending almost no data at all, and
the next thing you know, it's a 150-megabit file transfer.
Unlike the telephone system, where no matter how much you talk, you can only consume 64
kilobits per second on average, not counting compression.
So erelong formulas for the Net that will help you design pieces are hard to come by.
There are lots of debates about whether there should be quality of service mechanisms in
the network. Right now all we have is best efforts.
And there are valid arguments that sometimes you want more than best efforts.
The problem is, you can't rely on everybody wanting to or being capable of offering more
than that. So the question is, how do you build that
in so that multiple networks can somehow participate in anything other than best effort?
I mentioned Internationalized Domain Names. Distributed algorithms.
I don't think that we have done a very, very good job in the R & D community of developing
distributed algorithms. There are some.
The routing algorithms are an example. Their stability is sometimes in question.
We do a lot of distributed computation, but it's more like parallel stuff; right?
When we do a search, it's, you know, one engine is running the search algorithm.
We don't have a lot of stuff going on in parallel except for the fact that we can do our searches
by splitting the data up into a large number of different places and letting everybody
run in parallel. There aren't very many examples of distributed
algorithms that work well. Some of ours are wonderful.
Presence, which showed up originally in chat kinds of things, could be quite rich in its
character. It's not just whether you're online or not
online, but where are you online or what are you doing online.
These are all kinds of variations in Presence that we can exploit.
We've done a rotten job of dealing with mobility. If there's anything that I think we really
messed up, it's that. The problem that happened is that the example
of mobile in the original Internet design was the packet radio network.
This was a mobile network that was operating here in the San Francisco Bay Area.
We had some radio store and forward repeaters up in the mountaintops and we had mobile devices
down on the Bayshore freeway or driving around Palo Alto and Mountain View and so on.
The network itself took care of dealing with the mobility of the devices below the Internet
Protocol layer. It's not too different from what happens with
mobiles today, because what happens in a mobile today is that the binding of the telephone
number happens below the level of the phone number.
The consequence of that is that I thought, wrongly, that we had dealt with the mobile
problem. I didn't take into account that a device,
a host on the network, might actually move physically from one place to another.
Because at the time, they were big computer centers that didn't get up and move around.
Well, now they're in your pocket or maybe they're even a chip that you've got inserted
in your arm or it's in the dog. So the problem here is that I failed to recognize
that we might actually have nodes whose I.P. addresses had to change depending on where
they were accessing the network. If we had -- I'll give you an example of possible
kinds of solutions. Multihoming, we did a terrible job of multihoming.
Because every port on the computer had a different I.P. address.
It wasn't as if we had an address of the device and then, you know, spokes pointing out.
Every one of them had a different I.P. address. That means that if you are getting service
from two different ISPs, it's not exactly clear that you can set up a TCP/IP connection
with packets flowing along both of those in order to assemble them together as one stream.
Broadcast is another rant. We did a terrible job of dealing with broadcast
media. In fact, we turned broadcast media into point-to-point
links. Think about 802.11, for example.
So I would love to see some serious effort put into, for example, a satellite system
that could rain I.P. packets down on 100 million receivers at the same time.
For information that everybody wants, that has a large number of interested recipients,
broadcast is really good stuff. And we don't do that.
We're busy, you know, with these point-to-point TCP connections.
We do that with YouTube, we do that with a lot of other applications.
And I imagine if we were trying to pump out a large number of software updates, it would
be really nice if everybody would say, okay, at 8:00, we're all going to listen for the
next update of the -- of that software, and then I only have to transmit it once.
Okay. Some people would have to say, hey, I missed
a couple of packets. Please send them to me on a unicast basis.
But the bulk of the delivery could be done very, very efficiently.
So I want to keep going here. Another huge issue is identity, authentication,
and authorization. Those are all three different things.
We don't do a very good job of authenticating the components of the network.
We don't know whether a router over there is really one that we should be talking to
or not. There isn't any built-in, inherent ability
in the Net to authenticate various sources and syncs.
And if I were doing this over again, I would have wanted to put in tools for strong authentication.
This doesn't mean that I believe that anonymity is a bad thing or that it should be banned
or anything like that. I think anonymity is important.
But there are times when you really need to know what it is that you're interacting with
at various layers in the protocol. So if we're having a simple little chat, I
may not care exactly who you are. But if you say, "I want to borrow $50,000,"
I care a lot more about who you are and whether you can pay me back and how do I find you
again. So authenticity and identification turn out
to be really important. And I would submit to you that for Google's
own range of applications, that investing in good-quality identity and authentication
is really important, because that's the only way we will convince people that it's okay
to use the cloud, that we have a strong way of identifying the users, and that we have
a good way of preventing people from getting access to information that they shouldn't
have access to. So we need these kinds of technologies to
convince our users that it's safe to use the cloud and that we know how to protect their
information from others. Well, okay.
So multicore processors. This is another little headache.
Moore's Law is broken. The clock speed is not going up at the rate
that it used to. Now our problem is how do I use a larger number
of cores running at a fixed clock speed. I think a lot of algorithms don't know how
to take advantage of that. So this is another rich place for us to evolve
our applications. I'll come back to delay and disruption tolerance.
Let me just say that in the mobile world, one of the big problems is that you don't
have guaranteed solid connectivity or reliable connectivity.
Frequently, it's interrupted. Frequently, there's packet loss.
And most of the algorithms in the Internet are not as good as they could be and should
be in order to overcome those problems. Governance is a nontechnical problem space.
Now, if you and I think that technical decisions are hard, imagine what it takes to make political
decisions associated with who's in charge of what.
These don't necessarily have quantitative metrics.
And so you wind up having to argue, coerce, cajole, you know, demand and all these other
things in order to come to some kind of agreements. Sometimes they're international in character.
Sometimes they're national in scope. Sometimes they might be corporate.
But governance questions are policy-related questions, and they're very, very hard to
deal with. There's a bunch of them here.
I won't go into any further detail there. Finally, mobile operation again.
What I would love to see, frankly, is some ability to let a device move around from one
termination point to another in I.P. terms and still maintain its connectivity to the
higher-level protocols. There are some applications or protocols for
that purpose that are being looked at in the Internet Engineering Task Force.
This was a mistake that I made, a really bad one, that I didn't recognize at the time.
When we split I.P. from TCP, I thought it was very clever to use the I.P. address as
part of the end-point connection identifier. So TCP was bound very, very strongly to IP.
And I was patting myself on the back, thinking, "Look, I saved all these bits.
I didn't have to have another set of identifiers at the TCP or UDP layer."
And I thought, boy, I was really smart, it was very efficient, blah, blah, blah.
Turns out to have been a bad mistake. It screwed up multihoming, it screwed up mobility
where I.P. addresses were changing. Now, this leads to a different kind of a problem.
Think about it for a moment, that you're moving around and getting different I.P. addresses.
And so at some point, you have an end-point identifier distinct from the I.P. address,
and you've established, let's say, a TCP connection using those end-point identifiers.
Now you move to a different I.P. location, and you say to the other guy, hi, it's me
again. I'm just at a different I.P. address.
Well, that looks like a hijack, doesn't it? So the real question is, how do you reauthenticate
so the guy on the other end says, well, I know you said it's you, but, you know, can
you take this encrypted challenge and send it back to me properly encrypted in my public
key, blah, blah, blah. You need to have mechanisms that reestablish
authentic trust between the two parties if you're going to allow this kind of dynamics
to happen. We don't do a very good job of routing in
general. But more importantly, in the mobile world,
if topologies are changing, getting an routing algorithm that works, when the topology keeps
changing -- it's not just a question of it's a fixed topology and links are up and down;
this is a topology which is varying -- that gets to be a really hard problem.
And it hasn't been well solved in my view. We don't even have the idea of persistent
connections. I can open up a connection and things are
running, and I lose connectivity. And when I come back again, I would like to
reestablish the session that I had. We don't have a session layer in the formal
sense in the Internet architecture. And that, too, might be a useful development.
And then, finally, in the mobile world, there is a great deal of interest in being able
to self-organize. You throw a bunch of nodes down and they're
wandering around and they discover each other. This is all wonderful until you start worrying
about the possibility that one of them isn't supposed to be there because it's the bad
guy. And if you have a self-organizing network,
the bad guy might look like a good guy because you didn't know the difference.
So he's part of your environment and all of a sudden you have a problem.
So figuring out who are the good guys and the bad guys in a self-organizing network
are -- that's a particularly interesting problem. In the military world, this is called the
overrun problem. I have a whole bunch of nodes, they were all
okay. Then the bad guys overran the good guys and
the bad guys got ahold of their devices and said, hi, we're still good guys.
And, of course, they're not, but they're taking advantage of your assets to defeat you.
So figuring out how to make that all work in a way that is reliable and trustworthy
is tricky. Performance.
Well, the original Internet design was best efforts.
And here I'm going to invoke Greg Chesson. He is back there.
Wave your hand. You doesn't have any hair, either.
You don't have your tee shirt on, though. So Greg --
>>> That's the -- Greglers. >>Vint Cerf: You get two points for that.
Very good. So Greg is, like a lot of our senior management,
intensely concerned with performance, particularly inside the data centers.
And so what I want to observe to you is that for a long time, performance on the Internet
was not as -- was not viewed as critical as just getting it to work at all.
And so now we're at the point where this thing has been around for a long time and every
one of us and our customers and users are relying on this thing working reliably and
quickly. One of the things I want to emphasize to you
is that I am not an I.P. bigot. I'm not a TCP bigot.
Just because I happen to have been involved in designing and building that stuff does
not mean that it is the place to stop. It means it might be the end of the beginning.
But the important thing is here that none of you should be afraid to say, maybe we should
do something different. That's not irreligious.
Or heretical. I know I'm the Internet evangelist.
But, you know, I feel like the Pope and the heretic.
Right? The real answer here is that you should not
be afraid to think differently, to branch out into new areas, to think about things
that may not even be compatible. When people think about what might come next,
they think, oh, how in the hell are we ever going to deploy this in the existing Internet?
And I would remind you that before the Internet, there was this big network called the telephone
network. And you could have said, how in the heck would
you ever deploy the Internet? We already have a global network.
It's called the telephone net. You'd never be able to do this.
Well, it did take a few decades. But it happened.
And there's no reason why it couldn't happen again with good ideas that work better.
So I want to somehow, if I can empower you to not be afraid to think differently.
And Greg I know already is fully capable of doing that, because he's got ideas inside
our data center that work better than the conventional TCP mechanisms.
We have -- this is not an entirely internal meeting.
We have some folks from outside. So we're not going to go into any details
about that, unless Greg chooses to. But the point I want to make is that this
guy is fearless. He's looking at, you know, 80 gigabits a second
worth of traffic going in two different directions to figure out what the heck is going on inside
the TCP. And he's done a brilliant job of making this
work a lot better. Now, there is another area of real interest
here. Addresses in the Internet are bound mostly
to edge devices. And Bob Kahn and I have had this long-standing
debate about what should have an address. Why should we stop at the box?
Could we talk about the things that are inside the box?
What about logical addresses of objects that are inside the box?
Should the routing tables be able to route not to a box, but to something inside that
might move around? Well, I don't have an answer to you.
But I can tell you that thinking about addressing other than just termination at a box may turn
out to be a very rich way of dealing with some of the cloud issues that we face, because
the data in the cloud is what has to move around.
So this means, by the way, that the domain name system may not necessarily be the sole
means of binding an identifier to an I.P. address.
And this is another example of don't be afraid to think differently.
So instead of using DNS, it may very well be that some other label which has a different
meaning than the DNS might be useful and might be worthwhile implementing in addition to
or even instead of the DNS. So the DNS isn't necessarily fixed in the
universe of Internet architecture. I'm going to skip over policy considerations
in the interest of time here. I do want to bring up a couple of other major
problems, though, for us at Google. Intellectual property treatment is troublesome,
because the history has been rooted in hard copy of things.
In fact, if you read the copyright law, it talks about the fixing of a work in a physical
manifestation. So it's a CD, or it's a tape, or it's a hard
drive, or it's a memory stick, or a book, or a magazine.
And when we start dealing with digital information, we have to cope with the fact that, A, it's
easy to replicate, and, B, it's easy to distribute. And the notion of controlling copies as the
means of recovering value from intellectual property collides with this ease of distribution
and copying. In fact, if you think about the way the Web
works in particular, what does a router do? The first thing it does is go out and copy
whatever the home page is on the Web site. It's a giant copying engine.
No wonder the people who think of intellectual property protection as controlling copies
are a little unnerved by this, you know, global spread of this giant copying machine.
It's, you know, sort of Xerox written large. So the problem here is that the current rules
are rooted in the wrong kind of concepts. And we really need to rethink how people can
recover value from intellectual property in addition to or instead of simply controlling
copies. Now, I don't have a magic answer for you here.
I mean, the usual easy one is, well, just encrypt everything and then sell people the
keys. Yeah, that's all fine, unless somebody buys
one key and puts it up on the Net. And then everybody has a copy to it, and so
much for that. I would point out, however, even in that scenario,
that somebody who puts the key up is -- morally, -- has morally created a copyright violation
of the same order of magnitude as making copies of music CDs or making copies of books and
distributing them. The problem, of course, might be finding that
person in order to somehow inhibit that sort of behavior.
The semantic Web is something that Tim Berners-Lee I know has been working on very hard.
In fact, it came up in the CIO meetings that we hosted here yesterday.
This problem is that there is a lot of unstructured information on the Web right now.
But there's also a lot of structured information, except that we can't see it, because it isn't
expressed in a form that the crawler can detect it.
So when we have a lot of structured data, it's kind of like dark matter in the universe.
We know it's there but we can't quite detect it.
So there's dark information in the Internet. And finding a way to make it more visible
so that our crawlers can find it and our users can discover it is a nontrivial exercise.
We have to find ways of labeling content that's consistent across a large number of different
bins full of information. This is a hard thing.
It's the data dictionary collision problem for people who speak databases.
The other two things on this slide have to do with my recurring nightmare that our digital
history will be lost in not very many years. So let me give you the long-term example.
It's the year 3000. And you've just done a Google search.
And you find a 1997 PowerPoint file. That's even -- let's pretend you're using
Windows 3000, just for the sake of argument. [ Laughter ]
>>Vint Cerf: The question is, does Windows 3000 know how to interpret a 1,000-year-old
PowerPoint file. And the chances are pretty good that it can't.
The question is even if we were using open source software, it isn't necessarily clear
that the versions of the open source software that we might be dealing with in the year
3000 know how to interpret files that are 1,000 years old.
The reason I'm so exercised about this is not the thousand-year problem.
It's the next year or the third or fourth or fifth-year problem.
I'm already seeing image formats that are noninterprettable by current-day software.
I see this happen a lot between the Macs and the PCs.
I do a presentation on a Mac and then show it on a PC, and a big thing comes up saying
"We don't know how to interpret this thing." So it's a big blank in the slide.
So I am worried that our descendents 100 years from now or maybe even our kids 20 years from
now won't actually have any idea what the beginning of the 21st century was like, because
none of the digital objects that we have created and stored away are interpretable.
So the question is how to solve that problem. This is hard, because it's not just a question
of hanging on to the application software. If somebody says, "I'm not going to support
that software anymore," and it runs on that version of an operating system, is there any
way that we can hang on to not only the application, but the operating system it ran on and maybe
the emulation of the hardware that the operating system ran on that ran the application that
knew how to interpret the complex bits? The question is, what rules reasonably apply
to, let's say, not coerce, but encourage people to make sure that objects that were created
in earlier forms are still interpretable? And this gets all mixed up in motivations,
in business ethics, in business practices, and in intellectual property management.
So if we don't do something about this in a conscious way, we will end up with a lot
of rotten bits that won't be interpretable. And that can't be the right outcome.
I am particularly personally embarrassed about this because when I work with librarians and,
you know, we walk in with our fancy CDs and DVDs and everything else, they say, "How will
these last?" I'm not sure I actually have a good answer
to that. And then they kind of walk out with a 1,000-year-old
vellum manuscript which is magnificently illuminated and if you happen to read Greek or Latin,
you can still read it. And they hold this up and say, talk to me
again about these digital formats and how long you think they're going to last?
I want to shrink down and walk out the door. This is serious.
And it's serious for us at Google. Because we are offering to people to put their
stuff in our clouds. And we're offering to allow them to get it
back. And the question is, when they get it back,
in what form will it be delivered to them? And will they be able to interpret it?
Okay. I'm going to do just a couple more slides
and then I want to do some Q&A. This picture many of you have already seen.
It's my way of saying, there's some weird stuff on the Internet that I didn't expect
to be there, you know, like picture frames and refrigerators.
It was the farthest thing from my mind. The Internet-enabled surfboard is my favorite
one. Some guy in The Netherlands -- I haven't met
him -- I just have this picture, he's sitting on the water, waiting for the next wave, thing,
if I had a laptop on my surfboard, I could be surfing the Internet while I'm waiting.
He put a Wi-Fi service in the rescue shack and he surfs the Net while waiting for the
next wave. If you're interested in that, that's the product
for you. I mentioned earlier that there are sensored
networks showing up on the Net. Some of them are being driven by smart grid
ideas, some are driven by being more thoughtful about dealing with efficient use of energy.
I have a sensored network at home. And I'm proud to say it's a commercial thing.
It's not me with a soldering gun. It's from Arch Rock.
It's running IPv6. It's sampling temperature, humidity, and light
levels in all the rooms of the house every five minutes.
And there is a server that's accumulating that stuff.
Now, one of the rooms in the house is the wine cellar.
And it's very important that the wine not get up above 60 degrees Fahrenheit and the
humidity not drop below about 50%. That particular room is alarmed so that if
the temperature is -- exceeds 60 degrees, I get an SMS on my mobile.
And it happened when I went to the -- a laboratory -- Argon National Laboratory.
Just as I was walking in the door for a three-day visit, my mobile goes off.
It's the wine cellar calling. "You've just breached the 60 Fahrenheit barrier."
So every five minutes, I kept getting reminded my wine was warming up.
Unfortunately, my wife was away on some trip, so she couldn't go and reset the cooler.
So I called the guys at Arch Rock, and I said, "Do you make actuators so I could do some
remote actuation?" They said, "Yes, that's a little project for
the weekend." I did think, though, that I could infer some
things about what was going on when I wasn't at home.
For example, if somebody goes into the wine cellar and turns on the lights, I might be
able to detect that. Of course, I don't know what they did in there.
So the next step is to put RFID chips on all the bottles.
[ Laughter. ] >>Vint Cerf: That way, I can do a rapid inventory
to see if any bottles have left the wine cellar without my permission.
Somebody did debug this for me, though. He pointed out, you could go into the wine
cellar and drink the wine and leave the bottle. [ Laughter. ]
>>Vint Cerf: Clearly, I have some work to do to debug the architecture.
So we're going to have sensored networks everyone. The data is going to be flowing to us.
That's simply going to be another part of our Internet universe, huge amounts of information
either flowing to consumption places or devices just talking back and forth to each other.
Okay. So last thing I want to do is quickly mention
the Interplanetary Internet. I know many of you have heard me talk about
this. I'm very excited about it.
It's not a Google project. We're not planning to take over the solar
system as part of our business model, at least not as far as I've been told.
But I am interested in the problem of being able to give richer communication for manned
and robotic space exploration. Some of this is driven by our visits to Mars
with the Rovers and others -- since 1976, actually, we've been sending equipment to
Mars. And most of the communication with the spacecraft
have been with point-to-point links. One of the things that my colleagues at the
Jet Propulsion Lab and NASA have been wanting is a richer networking environment so that
we can support much more complex missions with many different devices, lots of different
orbiters, things on the ground that are moving around, sensored networks that are self-organizing.
So this is just a view of Google Mars, which is a beautiful piece of work.
What you might know is that when the Rovers landed several years ago on Mars, the original
plan was to transmit data direct to Earth. And the radios overheated.
And so they decided that they'd have to reduce the duty cycle to keep the radios from damaging
themselves. And that reduced the data return, which is
already rather limited at 28 kilobits a second. Now, remember, these things are 35 million
to 235 million miles away. At the speed of light, it takes three and
a half minutes for a signal to go from Earth to Mars when we're closest together and 20
minutes when we're farthest apart. So my colleagues and I were thinking, okay,
why don't we use Internet protocols. It works here.
It ought to work there. And that's true.
But it doesn't work very well in between. Imagine TCP with flow control with a 40-minute
round-trip time. Then there's the other problem of celestial
motion. The planets are rotating, and we haven't figured
out how to stop that, either. [ Laughter. ]
>>Vint Cerf: The problem is, there's a thing on the surface of Mars, and it rotates around,
and you can't talk to it until it comes back around again.
And the same thing happens with orbiters. The Jet Propulsion Lab guy said, "We have
orbiters around Mars already. They were used to map the surface of Mars
to decide where the Rover should land." They reprogrammed the Rovers and the satellites
to do store-and-forward relay back to Earth at 128 kilobits a second using a different
radio. So store-and-forward is the way all the data
has been coming back from Mars. When the Phoenix lander arrived, in May of
2008, it was going to the North Pole. It didn't have any director or path.
So they deliberately did store-and-forward. So my colleagues and I thought, well, why
don't we just use TCP. But it doesn't work.
So we had to invent a whole new suite of protocols that we call Delay and Disruption Tolerant
Networking Protocols. Those not only have been made to work at interplanetary
distances using the Epoxy spacecraft, which is not on its way to rendezvous with a comet
and will be using the new DTN protocols, but it also has been applied to military tactical
communications. The Defense Advance Research Agency that funded
the original interplanetary work and the original Internet work has adapted these Delay and
Disruption Tolerant Protocols to Tactical Com, which is a highly hostile environment.
So what we're hoping, frankly, is that the standards that we have been developing for
interplanetary communication will be adopted by all the countries around the world.
If they do, then everybody's spacecraft could potentially interwork, which means when they
have completed their initial missions, they might well be repurposed to be part of an
interplanetary backbone. Over the course of the next several decades,
assuming the standardization is adopted, we may actually see an interplanetary backbone
emerge out of the space exploration that goes on.
Okay. So I really overshot my time.
But let me stop here and invite questions. I know we've got some Dory things.
And in any event, thanks a whole bunch for letting me take up an hour of your time.
[ Applause ] >>> Let me read the first question on the
Dory. We have a lot of our distributed offices VCed
in, including the West Coast, plus Boulder, plus New York.
So let's just get to one of those, at least. Comcast recently had a court victory in their
effort to own the Internet and control traffic on it.
Murdoch has similar ambitions. And I suspect that the military will make
a similar claim. Can a free and open Internet be effectively
defended? >>Vint Cerf: Wait a minute.
I was too busy stabbing myself in the gut here.
Wow. Okay.
So I don't think that Comcast quite had the victory that's characterized here.
What they basically said was, when the FCC told us that we should cease and desist interfering
with BitTorrent, that the FCC didn't have a basis for making that demand.
Now, you need to have a little context. A few years ago, Internet was considered a
telecommunications service and it was regulated in what's called Title II of the Telecom Act,
as amended in 1996. In its infinite wisdom, FCC, upon hearing
debates between the telcos and the cable companies on the differences in their regulation, said,
"I hear you. We realize that you are regulated differently,
but you're both offering Internet service. We are going to move Internet service into
what's called Title I of the Telecom Act." This is essentially applications.
It's an information service. And it was treated as a vertically integrated
service, so there was no notion of telecommunications. There was no notion of common carriage anymore,
because it was treated as this unitary thing. Well, within Title I, the court ruled that
the FCC did not have any authority deriving from that title that would allow them to tell
Comcast to cease and desist. Now, I want to defend Comcast just a little
bit here. What they had -- what was happening to them
is that they have an asymmetric network; right? You can't push data into the cable system
as quickly as you can pull it out. So they're faced with a problem with people
doing BitTorrent, because some people who are running multiple TCP connections to do
the BitTorrent application are consuming much more bandwidth than everybody else.
So they're kind of freezing everybody out. So Comcast is saying, well, we have to do
something to make it more fair for everyone to get access to the limited resources that
we can make available. And their way of doing the network management
was, let me say, not very ept. They --
[ Laughter ] >>Vint Cerf: -- chose to do deep-packet inspections,
see which guys were doing the BitTorrent protocol and then generate fake reset messages to both
people, leaving them both thinking the other guy hung up.
That was a particularly crude way of trying to do network management.
In subsequent conversations with them, I urged them to consider an alternative, which was
to look at the bandwidth that was being consumed by these parties in a, you know, nonprotocol-centric
way and simply limit the amount of bandwidth that anybody could get if the system had gone
into congestion. And that, as I understand it, is what they
have chosen to do. So the court case basically says to the FCC
that Title I may not be a very good way of preserving fairness and choice for users.
What do we want? At Google, what we want is every user has
the ability to go anyplace on the Internet and run any applications that he or she wants
to. We understand that it's not right for a user
to get more resource than they are paying for.
We understand that people have to do some network management to deal with, you know,
potential denial of service attacks, to deal with fair allocation of the resources.
But we don't want them to abuse their access to and control over a broadband conduit that
gets the consumer into Internet services. In particular, for example, if you're a cable
company that's offering television as a service and you're being paid for that, and you're
also offering Internet, broadband Internet service, and you're being paid for that, we
wouldn't want YouTube, for example, to be somehow interfered with over the Internet
part of the channel in order to favor the other application that that company offers.
Now, I'm not picking on Comcast or any other cable company.
I'm just saying that we are looking for fair and equitable access for users and for suppliers
of service on those underlying broadband facilities. The likely outcome of this particular situation
is that the FCC will choose to reclassify Internet service as a Title II kind of service.
Some of you who know anything about this could conceivably levitate skyward, because there
are a huge number of things in Title II that are all about telephony, all about universal
service and taxation and tariffing and all this stuff.
The FCC has the ability to forbear from applying some of the possible controls, remedies, and
regulations in Title II. They always have the freedom not to do something.
And so if anything does happen to reclassify Internet as Title II, my hope and expectation
is that only a small number of the terms and conditions of Title II would apply to the
Internet service. One of the things I'm very attracted to is
common carriage. Common carriage basically says you have to
apply the same rules to everybody, all customers are served under the same terms and conditions.
There is no favoritism. And I think that's important for our business.
Okay. Next Dory question.
I don't know how to -- >>> How about if we --
>>Vint Cerf: There we go. Why don't I read it.
That way, I'll pay attention. That's terrible, isn't it?
How would the Internet be different if there had been native support early on for user
identification and for content signing and for encryption?
This turned out to be hard to be retrofit. Yeah, it has been hard.
I actually think it would have been very helpful and powerful not only to have users able to
authenticate themselves, but have devices able to say, yes, I'm getting control from
somebody I recognize. I will accept the exchange or demand for information.
I wish that we had done that. The problem is, the technology to do it wasn't
available at the time that the Internet standards were being finalized in 1978.
Public key crypto was invented in 1977 by Whit Diffie and Marty Hellman at Stanford.
And I knew all about what they were doing. But it was an idea at the time.
It wasn't -- RSA hadn't been implemented yet. So by the time those things matured, the Internet
had raced on into, you know, such a deployment that we couldn't force those things in.
If we were doing it over again, I would have wanted to have the advantage of that.
Okay. How long did the government want to keep TCP/IP
a secret technology? Zero milliseconds.
[ Laughter ] >>Vint Cerf: Never.
And I have to tell you, I'm really proud of this.
Bob and I, Bob Kahn and I, deliberately set about to make TCP/IP visible to the public,
to anyone in the world. We visibly wanted it to be unconstrained,
fully accessible, fully documented from the get-go.
And the reason is very simple. Our rationale was that if -- this was ever
going to be an international standard, if it was ever going to be adopted by the proprietary
community, there had to be zero barriers, no excuses.
You can't say, well, we couldn't get the documentation, or, no, we didn't have access to a reference
implementation. Our conclusion was, make this so available
that there are no excuses for not adopting it.
And we didn't put any patent constraints on it.
We didn't do anything other than to make it fully and widely available.
And I think that openness served us well, because, ultimately, it did get adopted as
an international standard. What's the one thing you wish you had been
-- No -- oh, wish had been properly separated into two or more things from the beginning.
Well, the one thing I did mention was this separation of identifier at the end points
from the I.P. addresses. I really wish I had done that.
By the way, we can still do that. There is absolutely nothing stopping us from
implementing protocols that have that property. And, in fact, one of the things that is interesting
about the Internet is that you can keep changing it.
You can keep adding new capabilities. And I hope that we actually get there someday
so that we have this flexibility that we don't have today.
How do I get this little thing to scroll down? There we go.
Okay. What's -- Let's see.
Something to think about at the end of the discussion: If the Internet's original design
had been different in the ways we've discussed, how would its evolution have been different?
Boy, that's a DNA question, isn't it, as opposed to a DNS question.
[ Laughter ] >>Vint Cerf: I know.
Bad -- minus 2. Well, I think probably, if we had done some
of the things I suggested, we would have had strong authentication available to make the
system a little more secure. We would have had better mobility, multihoming,
ability to use multiple routes to push data across the Net faster, taking advantage of
multiple paths at the same time. I think we might have had a good shot at making
the network more resistant to various forms of attack, because we had put in authentication
in places where it could usefully be applied. And, again, I want to remind you that it's
not impossible to put some of those things in again.
There's an activity in the National Science Foundation called FIND, Future Internet Design.
And there are ideas that are being pursued with support from NSF, some of which touch
on the ideas I've talked about. Some are even more elaborate than that.
And there's nothing stopping us from trying some of those ideas out, either in the existing
Internet or, in fact, in something which is independent.
So my sense right now is that we are not constrained to live the history of the network.
We have the freedom and flexibility to change that if we want to.
Let's see. What choices would you have made if you'd
known that the Internet would eventually be used for commercial purposes?
I don't think I would have made different choices, to be honest with you, since I was
a big proponent of trying to turn various parts of the network into commercially useful
things. I was very happy to see Cisco and Proteon
and others make commercial routers. Because the way we made routers before that
was to take a computer and a graduate student and wrap the graduate student around the router.
[ Laughter ] >>Vint Cerf: And we were running out of graduate
students. So seeing commercially available routers was
great. And finally came Internet services that were
commercially available. And that didn't happen until we broke a policy
logjam in 1988. I asked permission from the federal government
to allow me to connect the commercial MCI mail system to the Internet in 1988.
Up until that time, 15 years of the Internet program, nobody was allowed to put commercial
bits on the government-sponsored backbone. So I was really happy when they said, yes,
you can do that. Within a year, we had gotten the MCI mail
system connected. All the other e-mail providers said, wait
a minute, those MCI guys shouldn't have that privilege alone.
So they jumped on, telemail, and Ontime, and CompuServe, and so on.
An odd side effect, they hadn't been able to talk to each other before, because they
were closed e-mail systems, but they could all talk to the Internet.
In consequence, they could talk to another through the Internet.
That was a surprise for everybody. Holy cow, I just got a message from some guy
on a different e-mail system. How did that happen?
The side effect of having allowed the commercial use of the government-sponsored backbone is
that commercial providers of service didn't have to build their own backbone.
So that meant they had a relatively low barrier for offering commercial service that could
use the government-sponsored backbones for a time.
It didn't take very long. That was 1989 when we saw the first commercial
Internet services come along. By 1995, just a few years later, the National
Science Foundation shut down the NSFNET because it didn't need it anymore.
It could buy, the universities could buy commercial service more cheaply than they could get it
from a specially operated network. Sorry?
Yes. >>> I asked this question a few weeks ago
at TGIF, and I got completely shot down. But --
>>Vint Cerf: Can you use the microphone? You'll be on record, by the way, so you should
be aware of that. >>> But basically, I was just wondering what
your thoughts were on where the Internet will be in the future maybe ten, 50 years down
the road, and what our relationship with the technology will be then.
I won't hold you to it. >>Vint Cerf: That's a nice, simply-asked question
with a really easy answer; right? The short answer is, beats the hell out of
me. I wish I was eight years old so I could actually
wait around to see the answer. Honestly, I think two things.
First of all, mobility, high bandwidth. The network will disappear.
You won't see it. It will just be part of the environment in
the same way that we don't think very much about electrical power.
We just plug into the wall and expect it to be there.
We will expect networking to be part of the environment.
It will always be available. All of the devices that we use will be networkable.
And the thing that I think is the most exciting possibility is the possibility that the network
will be able to interface to our neural systems. Now, before you think I've gone all Ray Kurzweil
on you. I'm not quite there.
But I will -- I need to finish with this comment, even though there are other questions, because
it's already way over time. But I love to tell the story, many of you
have heard this before, but I'll tell it anyway. My wife was born with normal hearing, but
she lost her hearing when she was three. She had spinal meningitis.
So she was deaf for 50 years. Then she got a cochlear implant.
Now, this is a device that interfaces to the inner ear, the cochlea.
It has electrodes that touch the auditory nerve.
The speech processor that she wears takes in sound, does a Fourier transform to figure
out what frequencies are present, then generates electrical impulses in the inner ear to fake
the brain out into thinking that the inner ear is working.
Now, the implication of that is that we understand enough about sensorineural processes to imitate
them electronically. Now, I had been thinking, why not program
-- reprogram the speech processor so that it can do TCP/IP?
[ Laughter ] >>Vint Cerf: And now -- I'm not trying to
get TCP/IP stuck in her brain. We aren't there yet.
But what I am interested in is the possibility that she could ask a question, speak out loud,
the microphones that normally are hearing sound to help her hear could pick up what
she says. We could digitize that, packetize that, send
it as voice-over-IP to a speech-understanding processor.
Guess what? We make some of those; right?
So she could ask a question. The answer would come back through the Internet,
go into the speech processor and go straight up into her auditory nerve electronically
and then, you know, the brain interprets that as sound.
So we could Internet-enable my wife. That's pretty amazing.
[ Laughter ] >>Vint Cerf: So there -- I think, honestly,
that our ability to network ourselves in the sensory sense is quite likely.
Whether we ever get cognitive interaction is a whole other story.
And it's one which is at the moment still science fiction.
But sensory, neural and sensory motor possibilities are very strong.
And, finally, something that you all know about, augmented reality.
When we think about things like my wife's cochlear implant, this is remediating a problem
that she had. Otherwise, she can't hear.
But there's no reason why we can't extend the range of people's ability to sense the
environment. Why can't we see x-rays?
Why can't we hear at the frequencies that dogs can?
There's no reason why we can't augment our abilities.
So I think if we're looking 30, 40, 50 years into the future, we will see a lot of augmentation
of our abilities, some of them sensory motor, some sensory neural.
Whether we ever get to the point where we have cognitive interactions with computers,
I don't know. But I think it's very possible that we might
have conversations with computers that are richer than the ones that we have today, which
are mostly command and control. I think if you saw the TED lecture where the
guy was wearing a projector and had a television camera, he had a headset and a microphone,
and instead of carrying a mobile around, he carried a piece of paper.
That was his display screen. And he projected stuff onto the paper, or
in one case he projected stuff on his hand. It was the telephone dialing pad.
And he dialed by just, you know, poking on his hand.
And, of course, what was going on is that there was a video receiver that was watching
the gesture and interpreting it. This is the first time I have thought about
and seen a computer-based system that was participating in the same sensory environment
that I am. It's observing what I'm observing.
It's seeing gestures and interpreting them. So that kind of -- It was a really moving
example of what happens when you let a computer participate with you in the real world.
If we see anything arrive out of that in 20 or 30 years' time, I bet it's going to be
because we've got common, shared experiences with our computers.
Okay. That's really all the time we've got.
But thanks, again, for letting me be here this afternoon.
[ Applause ]
