[music]. We're having massive scaling problems
today. Trying to join together the very
information centric web model, with the very host centric TCP/IP model.
If you look at how the net has evolved it, It started as a telephone system for
computers. The, the model was, computers wanted to
exchange data people wanted their computers to be able to exchange data.
The model we had for communication for 140 years, years had been the phone system.
So he said, okay, they want to have a conversation, because communication is
conversation over long distances. And so, let's make protocols and
infrastructure that allows computers to have a conversation.
First cut of that, things like the ARPANET.
Networks that would handle different bandwidths they didn't require all of the
global clock distribution of a tel, telephony network.
Instead, they substituted buffering and one crucial thing coming out of Paul Baran
was unlike the phone system where communication was all about building a
wire. You know, hop by hop, link by link between
the two endpoints, basically instructing the switching system on how to make one
long wire. Paul said, don't do it that way.
Just identify the endpoints and let the network take care of getting the data
there. Okay, so, this is great.
It is, just completely changed the world. But the bulk of that change was, didn't
happen in the 70s, and 80s, and early 90s when the net was first growing out.
It happened in the late 90s and the 2000s, when the web took off, and it had nothing
whatsoever to do with computers having a conversation model.
It had to do with people creating and consuming content and it, the web sort of
showed us for the first time what happens if we leave behind this 18th century model
of telephony and instead we start to look at, not the wires, but the information in
the wires. And, and the web gave us this structure
where you could name information, not the process of getting it but the information
itself. Say I want this webpage, I want this
YouTube video, I want this Amazon personal page and you will get back a set of
content, somet hing that represented that name that you gave.
What if we recast the way we think about the low level infrastructure?
Not, don't say the web is an overlay on top of TCP/IP, which is the way it's
implemented today. But say, if 99% plus of what we do is
web-like stuff, is there a model that lets us do the same stuff at the packet level?
Could we make it the basis of our communication, rather than say it has to
be an overlay? See, you can create videos, you can put
them on your own website and you have to pray that they never get popular.
Because, if they get popular, your ISP is almost immediately going to shut you down,
because your link will be completely saturated.
You know, what we used to call a Slashdot effect.
That's intrinsic to the conversational model, right?
We don't do broadcast TV by making phone calls to a TV station.
If you want to put media distribution over TCP/IP you have to figure out some way to
lie to the network so that YouTube.com, which TCP thinks is a location is
identified by an IP address. You gotta make sure that it's not a
location, that it's spread across the entire planet.
So while we spent most of the 90s growing the Internet and having the protocols work
for us. Now, if you look at YouTube, Google,
Amazon, Facebook, Twitter, all of these very heavily-used services.
That manifest themselves to the net as an IP address, looks like a single location.
But if they're a single location with hundreds of millions of users, the traffic
in a conversational model always scales like the popularity.
It scales like the number of consumers and you're doing Twitter update or a video
that wants to be seen by millions. You, you can't deploy it in a
conversational model and we spend all our time fooling the net.
Information that's sort of qualitatively the same as all naming or identity
information, but it's spread randomly across the whole damn packet.
So we've got source and destination addresses that can eventually, we think of
as layer three, so it's up at front to be used as by the network layer.
Then we've got ports that are a layer four, and so, they're a little deeper in,
because they're supposed to be used by the end node [foreign] to a particular
application. Then, inside of that, we've got sequence
numbers which are being used when you get to the application for it to reassemble
the larger unit. And, inside of that, we've got URLs, which
are used by a entire level part of the application than on transport part of the
application. You've just got all of this information.
It's all fundamentally name information. It's, what do these bits mean?
Well, if you pull together the source addresses, the ports, the sequence
numbers, the URLs, the all give you context for the information, they're all
the name of the information. What if, rather than having, you know,
Amazons load balancer, which is trying to figure out, alright, which of my 50,000
unused machines is currently handling this customers request.
So I, I have to look at the addresses, I have to look at the ports, I have to look
at the sequence numbers, I have to look at the cookies, in order to dispatch this
sucker, to where it's going. What if I say packets have a name on the
front and all of that information just gets collected to the name.
And at any point in the network you look at as much of that name as you need to
look at to do your job. If just the front part will work, because
all you're doing is gross level stirring, just look at the front.
If you need to look at more of it, it, we don't have layers, what we have is a
center-structured information. There's, we know that we're going to be
looking at different parts of it for different reasons, so we put topologically
sensitive information like Amazon.com, stick that at the front cause you can use
that to make scalable writing tables. But when it gets there, we don't want to
say there's a transport protocol and, you know, various layers.
Just say, yeah, there's a job that I'm doing when I get to Amazon.com and it
requires me to look at this much. If you don't care where you're getting the
data, if all that matters to you is what the data is, not where it comes from.
Then all of this memory that has to be in the network as buffering in order to, to
manage the multiplexion of the network. Suddenly that becomes a viable source of
data. You know, the way it happens today is
you're watching a YouTube video, that means the bits leave some server at
YouTube. They go into the downstream gateway's
memory. They get pulled out of that memory, put
into a wire, go into the next hop gateway's memory, and they're going,
bouncing memory to memory through all these interconnecting wires till they get
to you. If the two of us are watching the same
video, then, the immediate upstream gateway gets one copy of the video going
to me, and another separate copy of exactly the same video going to you.
They both went through that gateway's memory.
It, because of this conversational extraction we're putting on because the
gateway doesn't know that we're consuming the same content, what it sees is two
different conversations. It can't look in its memory, and say, oh,
I've got that, I can give it to you. You have to fetch a new copy and you have
to fetch it all the way from YouTube. I mean, that's what giving us the abysmal
scaling is the, the, having the load scale like the popularity is strictly a function
of, the data can only originate at one place.
And if you just cared about the data, just start going towards that place.
And as soon as you run into the data, okay, now you've got a copy, you're done
with your distribution. [music]
