1
00:00:00,012 --> 00:00:16,251
[music].
We're having massive scaling problems

2
00:00:16,251 --> 00:00:23,222
today.
Trying to join together the very

3
00:00:23,222 --> 00:00:32,921
information centric web model, with the
very host centric TCP/IP model.

4
00:00:32,921 --> 00:00:41,235
If you look at how the net has evolved it,
It started as a telephone system for

5
00:00:41,235 --> 00:00:46,554
computers.
The, the model was, computers wanted to

6
00:00:46,554 --> 00:00:54,182
exchange data people wanted their
computers to be able to exchange data.

7
00:00:54,182 --> 00:01:01,008
The model we had for communication for 140
years, years had been the phone system.

8
00:01:01,008 --> 00:01:06,306
So he said, okay, they want to have a
conversation, because communication is

9
00:01:06,306 --> 00:01:11,102
conversation over long distances.
And so, let's make protocols and

10
00:01:11,102 --> 00:01:15,826
infrastructure that allows computers to
have a conversation.

11
00:01:15,826 --> 00:01:19,942
First cut of that, things like the
ARPANET.

12
00:01:19,942 --> 00:01:27,321
Networks that would handle different
bandwidths they didn't require all of the

13
00:01:27,321 --> 00:01:32,125
global clock distribution of a tel,
telephony network.

14
00:01:32,125 --> 00:01:40,041
Instead, they substituted buffering and
one crucial thing coming out of Paul Baran

15
00:01:40,041 --> 00:01:47,612
was unlike the phone system where
communication was all about building a

16
00:01:47,612 --> 00:01:51,010
wire.
You know, hop by hop, link by link between

17
00:01:51,010 --> 00:01:56,477
the two endpoints, basically instructing
the switching system on how to make one

18
00:01:56,477 --> 00:01:59,493
long wire.
Paul said, don't do it that way.

19
00:01:59,493 --> 00:02:04,363
Just identify the endpoints and let the
network take care of getting the data

20
00:02:04,363 --> 00:02:06,078
there.
Okay, so, this is great.

21
00:02:06,078 --> 00:02:11,662
It is, just completely changed the world.
But the bulk of that change was, didn't

22
00:02:11,662 --> 00:02:17,003
happen in the 70s, and 80s, and early 90s
when the net was first growing out.

23
00:02:17,003 --> 00:02:22,637
It happened in the late 90s and the 2000s,
when the web took off, and it had nothing

24
00:02:22,637 --> 00:02:27,138
whatsoever to do with computers having a
conversation model.

25
00:02:27,138 --> 00:02:34,444
It had to do with people creating and
consuming content and it, the web sort of

26
00:02:34,444 --> 00:02:42,241
showed us for the first time what happens
if we leave behind this 18th century model

27
00:02:42,241 --> 00:02:49,925
of telephony and instead we start to look
at, not the wires, but the information in

28
00:02:49,925 --> 00:02:53,802
the wires.
And, and the web gave us this structure

29
00:02:53,802 --> 00:02:59,752
where you could name information, not the
process of getting it but the information

30
00:02:59,752 --> 00:03:03,120
itself.
Say I want this webpage, I want this

31
00:03:03,120 --> 00:03:08,916
YouTube video, I want this Amazon personal
page and you will get back a set of

32
00:03:08,916 --> 00:03:13,811
content, somet hing that represented that
name that you gave.

33
00:03:13,811 --> 00:03:19,845
What if we recast the way we think about
the low level infrastructure?

34
00:03:19,845 --> 00:03:26,091
Not, don't say the web is an overlay on
top of TCP/IP, which is the way it's

35
00:03:26,091 --> 00:03:30,439
implemented today.
But say, if 99% plus of what we do is

36
00:03:30,439 --> 00:03:36,535
web-like stuff, is there a model that lets
us do the same stuff at the packet level?

37
00:03:36,535 --> 00:03:41,401
Could we make it the basis of our
communication, rather than say it has to

38
00:03:41,401 --> 00:03:45,036
be an overlay?
See, you can create videos, you can put

39
00:03:45,036 --> 00:03:50,162
them on your own website and you have to
pray that they never get popular.

40
00:03:50,162 --> 00:03:55,110
Because, if they get popular, your ISP is
almost immediately going to shut you down,

41
00:03:55,110 --> 00:03:58,112
because your link will be completely
saturated.

42
00:03:58,112 --> 00:04:01,117
You know, what we used to call a Slashdot
effect.

43
00:04:01,117 --> 00:04:04,424
That's intrinsic to the conversational
model, right?

44
00:04:04,424 --> 00:04:08,191
We don't do broadcast TV by making phone
calls to a TV station.

45
00:04:08,191 --> 00:04:14,361
If you want to put media distribution over
TCP/IP you have to figure out some way to

46
00:04:14,361 --> 00:04:19,881
lie to the network so that YouTube.com,
which TCP thinks is a location is

47
00:04:19,881 --> 00:04:24,765
identified by an IP address.
You gotta make sure that it's not a

48
00:04:24,765 --> 00:04:28,866
location, that it's spread across the
entire planet.

49
00:04:28,866 --> 00:04:37,566
So while we spent most of the 90s growing
the Internet and having the protocols work

50
00:04:37,566 --> 00:04:41,984
for us.
Now, if you look at YouTube, Google,

51
00:04:41,984 --> 00:04:49,144
Amazon, Facebook, Twitter, all of these
very heavily-used services.

52
00:04:49,144 --> 00:04:55,574
That manifest themselves to the net as an
IP address, looks like a single location.

53
00:04:55,574 --> 00:05:01,744
But if they're a single location with
hundreds of millions of users, the traffic

54
00:05:01,744 --> 00:05:06,552
in a conversational model always scales
like the popularity.

55
00:05:06,552 --> 00:05:12,320
It scales like the number of consumers and
you're doing Twitter update or a video

56
00:05:12,320 --> 00:05:16,487
that wants to be seen by millions.
You, you can't deploy it in a

57
00:05:16,487 --> 00:05:20,517
conversational model and we spend all our
time fooling the net.

58
00:05:20,517 --> 00:05:25,259
Information that's sort of qualitatively
the same as all naming or identity

59
00:05:25,259 --> 00:05:29,674
information, but it's spread randomly
across the whole damn packet.

60
00:05:29,674 --> 00:05:34,992
So we've got source and destination
addresses that can eventually, we think of

61
00:05:34,992 --> 00:05:39,595
as layer three, so it's up at front to be
used as by the network layer.

62
00:05:39,595 --> 00:05:44,559
Then we've got ports that are a layer
four, and so, they're a little deeper in,

63
00:05:44,559 --> 00:05:49,295
because they're supposed to be used by the
end node [foreign] to a particular

64
00:05:49,295 --> 00:05:52,849
application.
Then, inside of that, we've got sequence

65
00:05:52,849 --> 00:05:57,874
numbers which are being used when you get
to the application for it to reassemble

66
00:05:57,874 --> 00:06:01,519
the larger unit.
And, inside of that, we've got URLs, which

67
00:06:01,519 --> 00:06:06,483
are used by a entire level part of the
application than on transport part of the

68
00:06:06,483 --> 00:06:09,916
application.
You've just got all of this information.

69
00:06:09,916 --> 00:06:14,353
It's all fundamentally name information.
It's, what do these bits mean?

70
00:06:14,353 --> 00:06:19,788
Well, if you pull together the source
addresses, the ports, the sequence

71
00:06:19,788 --> 00:06:25,484
numbers, the URLs, the all give you
context for the information, they're all

72
00:06:25,484 --> 00:06:30,105
the name of the information.
What if, rather than having, you know,

73
00:06:30,105 --> 00:06:35,069
Amazons load balancer, which is trying to
figure out, alright, which of my 50,000

74
00:06:35,069 --> 00:06:39,049
unused machines is currently handling this
customers request.

75
00:06:39,049 --> 00:06:43,963
So I, I have to look at the addresses, I
have to look at the ports, I have to look

76
00:06:43,963 --> 00:06:49,111
at the sequence numbers, I have to look at
the cookies, in order to dispatch this

77
00:06:49,111 --> 00:06:53,555
sucker, to where it's going.
What if I say packets have a name on the

78
00:06:53,555 --> 00:06:57,628
front and all of that information just
gets collected to the name.

79
00:06:57,628 --> 00:07:02,148
And at any point in the network you look
at as much of that name as you need to

80
00:07:02,148 --> 00:07:05,912
look at to do your job.
If just the front part will work, because

81
00:07:05,912 --> 00:07:09,784
all you're doing is gross level stirring,
just look at the front.

82
00:07:09,784 --> 00:07:14,350
If you need to look at more of it, it, we
don't have layers, what we have is a

83
00:07:14,350 --> 00:07:19,128
center-structured information.
There's, we know that we're going to be

84
00:07:19,128 --> 00:07:24,354
looking at different parts of it for
different reasons, so we put topologically

85
00:07:24,354 --> 00:07:29,892
sensitive information like Amazon.com,
stick that at the front cause you can use

86
00:07:29,892 --> 00:07:34,938
that to make scalable writing tables.
But when it gets there, we don't want to

87
00:07:34,938 --> 00:07:38,979
say there's a transport protocol and, you
know, various layers.

88
00:07:38,979 --> 00:07:43,560
Just say, yeah, there's a job that I'm
doing when I get to Amazon.com and it

89
00:07:43,560 --> 00:07:49,743
requires me to look at this much.
If you don't care where you're getting the

90
00:07:49,743 --> 00:07:57,128
data, if all that matters to you is what
the data is, not where it comes from.

91
00:07:57,128 --> 00:08:04,024
Then all of this memory that has to be in
the network as buffering in order to, to

92
00:08:04,024 --> 00:08:10,192
manage the multiplexion of the network.
Suddenly that becomes a viable source of

93
00:08:10,192 --> 00:08:12,877
data.
You know, the way it happens today is

94
00:08:12,877 --> 00:08:17,513
you're watching a YouTube video, that
means the bits leave some server at

95
00:08:17,513 --> 00:08:20,520
YouTube.
They go into the downstream gateway's

96
00:08:20,520 --> 00:08:23,706
memory.
They get pulled out of that memory, put

97
00:08:23,706 --> 00:08:28,462
into a wire, go into the next hop
gateway's memory, and they're going,

98
00:08:28,462 --> 00:08:34,284
bouncing memory to memory through all
these interconnecting wires till they get

99
00:08:34,284 --> 00:08:37,432
to you.
If the two of us are watching the same

100
00:08:37,432 --> 00:08:42,936
video, then, the immediate upstream
gateway gets one copy of the video going

101
00:08:42,936 --> 00:08:48,126
to me, and another separate copy of
exactly the same video going to you.

102
00:08:48,126 --> 00:08:51,915
They both went through that gateway's
memory.

103
00:08:51,915 --> 00:08:57,937
It, because of this conversational
extraction we're putting on because the

104
00:08:57,937 --> 00:09:04,141
gateway doesn't know that we're consuming
the same content, what it sees is two

105
00:09:04,141 --> 00:09:09,561
different conversations.
It can't look in its memory, and say, oh,

106
00:09:09,561 --> 00:09:15,446
I've got that, I can give it to you.
You have to fetch a new copy and you have

107
00:09:15,446 --> 00:09:21,141
to fetch it all the way from YouTube.
I mean, that's what giving us the abysmal

108
00:09:21,141 --> 00:09:27,105
scaling is the, the, having the load scale
like the popularity is strictly a function

109
00:09:27,105 --> 00:09:30,349
of, the data can only originate at one
place.

110
00:09:30,349 --> 00:09:34,897
And if you just cared about the data, just
start going towards that place.

111
00:09:34,897 --> 00:09:49,101
And as soon as you run into the data,
okay, now you've got a copy, you're done

112
00:09:49,101 --> 00:10:00,865
with your distribution.
[music]