So, before we begin, I just want to make
sure you guys all remember about the quiz on Friday.
So the quiz is going to be in Walker at 2 pm.
Everybody goes to Walker.
The quiz is open book.
You can bring your own notes.
You can bring a class notes, bring the readings from class;
you can bring your calculator.
But please don't bring any computers, phones, PDAs,
things like that.
So make sure you have all your stuff printed out
before you show up if you've been taking notes on a laptop.
OK, so what we're going to do today is just quickly,
well, we're going to do an introduction to networking.
But quickly I just want to finish
the topic of caching that we began,
that sort of introduced at the very end of the lecture
last time.
So, if you guys remember, we were
talking about our pipeline WebServer system that
consisted of these three stages: a networking stage connected up
to our HTML stage connected up to our disk stage.
OK, and we did a little performance
analysis of the system.
We looked at what the cost of each of these stages
is, what sort of throughput of each one of these stages is.
We said that as long as we split this networking module up
into ten submodules, we can get the throughput of this thing
to be about 100 requests per second.
We said the latency of this was 1 ms.
So that means it can process a thousand requests per second.
We said the latency of the disk was 10 ms.
So that means it can also process
100 requests per second.
And we said, remember, that when we are looking at a pipeline,
the sort of throughput of the entire pipeline
is going to be bottlenecked by the slowest
stage in the system.
And so if we look at this, we see
that these two stages are both running
at 100 requests per second.
But we have a very simple way of making this first network stage
be able to process more requests per second,
right, because we simply can replicate
the number of threads that are sending
data out over the network.
So, for example, if we went from ten nodes here to 100 nodes,
we could increase the throughput of this stage
to 1,000 requests per second, which
means that now the bottleneck stage that we have is simply
the disk stage.
So the question is, is there something
we can do to increase the throughput of the disk stage?
If you think about it, at first it
may seem like, well, there's probably
no way that we can do anything because the disk takes 10 ms,
you know, every page takes 10 ms to read in.
So what are we going to do about that?
And there's a very sort of standard answer
to that that you guys have all seen before,
and that answer is caching.
OK so the simple idea is that we're
going to take this IO stage, or this disk stage,
with this disk that runs at 10 ms.
What I've shown here is a very simple piece
of pseudo code that might correspond
to what this sort of read or the get
page ID function for this IO stage does.
It simply calls some read function
that reads page ID off the disk and then returns the page.
If we add a cache to this system,
suppose we have an in memory cache
that can retrieve a page in 0.1 ms.
In that case, the way that we can
use that cache is just before every time we go to the disk,
we can check and see if the page that we're trying to load
is in the cache.
And then only if it's not in the cache
do we need to actually go to the disks.
And we get a miss on the cache.
We go check the disk to see if the page is available.
So we can extend the code in a very simple way
to take advantage of this.
We simply say, we look up in the cache first,
and then if the page is null or empty or whatever,
we can't find it in the cache, then we go ahead and look it up
on the disk.
And then we add that result to the cache.
So there's a couple of little details
that we need to work through.
But let's first look at what the performance of this system
is going to be, or how this is going
to impact the performance of what we've been doing.
So if we come over here, if we think
about what the cost of accessing a page on this system would be,
well, we're always going to have to check the cache, right?
That's the first thing we do.
So I'm going to write C for cost of accessing the cache, where
cost is in this case going to be expressed
in something like the number of milliseconds
to do a lookup in the cache, and then plus the cost
of looking it up on the disk.
But we only have to look up on the disk some of the time,
right, so there is some probability
of getting a miss times the cost of that miss.
OK, so in this case, we said the cost of going to the cache
was 0.1 ms.
The cost of going to the disk is 10 ms.
OK, and now what we're left is to figure out
what the probability of this miss is.
So if you think about a system for a little bit,
you might say, well, OK, what does the system look like?
What's the probability that we are actually going to get a hit
or miss?
And if what the applications are doing
is simply generating random requests
for random pages, which might be one model of how
the application behaves, then it doesn't
seem like cache is going to buy us
very much, right, because the cache is
going to be a small fraction of the total size of the disk.
It might be in RAM, so we might have 100 MB of cache,
and we might have 10 GB of disk, right?
So that means there is a factor of 100 difference
between these two things.
So if the page requests are random,
the probability that something is going to be in the cache
is going to be very low.
It's going to be only, say, 1%.
But it turns out that almost all applications
have an interesting property which is commonly referred
to as locality of reference.
What this means is that if you look at which pages a program
is likely to access over time, be
these pages of data or parts of a program,
typically a page that has been accessed recently
is very likely to be accessed again.
So a simple example might be that if you
look at the files that are being used in a computer system,
usually there is a small set of files
that a user is working with at any given point in time.
You're running certain programs; you're
editing certain documents.
And there's a huge array of other programs
and files and documents that are on the system
that you aren't accessing.
And when those active files are being accessed,
there's a much higher probability
of getting a hit of looking at those active files
then there is of going to any one of the other files.
So even when the difference between these things
is, say, a factor of 100, in the case of a Web server,
it might be very likely that we would
have 90% maybe of the pages that have been accessed
are already in the cache.
So in that case, sorry, this probability should be 0.9, 90%.
OK, so suppose that the probability, sorry,
the probability of a hit is 90%.
The probability of a miss is then 10%.
OK, so if you look at now what this sort of formula
evaluates to, we see it's 0.1 plus ten times 0.1.
So, it's 1.1 milliseconds on average,
assuming that we get a 90% hit rate on our cache.
OK, so if you now come back to this diagram, that
means that the throughput of the box is one over 1.1,
remember, because throughput is just one over latency
when we have sort of just this one module, which
means that now we can process something like,
so this is something like, sorry,
this should be one over latency.
But this is in milliseconds.
So this is 0.1, one, sorry, the number of seconds is 0.0011,
right?
So, one over 0.0011 is about 900.
OK, so we can get about 900 requests per second
that we can process instead of just 100.
This is approximately equal.
OK, so what we've managed to do is
increase the throughput at this stage
by about a factor of nine.
I mean, now you can see that sort of all three
of these stages are close to about 1,000 requests a second.
We have increased the performance of the system
pretty dramatically by introducing the cache.
And you have to remember that this cache is only
going to be a good idea when we are
sure that we have this locality of reference property.
OK, so if the Web server is going to a random page,
if the Web server is sort of asked
to fetch a random page on every request,
the cache is not going to be a good choice.
But most of the time Web servers to have this locality property.
So the last little detail that we
need to talk about when we talk about caches,
is the sort of question about how we deal with page eviction.
So in this diagram here, when we call add to the cache,
if the cache is already full of results,
we have to pick something to replace, right?
So we need what's called a page removal or page replacement
policy.
OK, so you guys presumably have seen different page removal
or page replacement properties in 6.004 before.
I'll just talk about two very quickly:
a FIFO policy and a LRU policy.
OK, so what FIFO means is First In First Out.
So it says the thing to throw out
is the first thing that we loaded into the cache.
OK, so if I access a set of pages,
suppose I have a three element cache
and I access a set of pages, one, two, three, two, one,
four, what I'm going to do is I'm going to load this.
I'm going to access these three pages.
Page 1 will be the first one that's in my cache.
So when I try and load page 4, I'm going to evict page 1.
OK, that's what's going to happen in a FIFO system
because one was the first one that was loaded.
But a least recently used approach
says instead of evicting the first thing that
was put into the cache, we want to evict the last thing that
was read from the cache.
So in this case, if I do one, two, three, two, one, and then
I get four, the last thing that was read was three,
and that's what I'll evict from the cache.
So, if you think about the intuition behind these two
policies, you sort of realized that this FIFO approach
has a problem, which is that it's
sort of contrary to this notion of locality of reference,
right, because it doesn't capture anything
about how frequently a data item is accessed
or when it was last accessed.
It throws the sort of first access thing out of the cache
even if that first access thing is read all the time.
LRU sort of captures the intuition which we want,
which is that something that's been accessed recently
is likely to be accessed again.
And something that hasn't been accessed very recently
is less likely to be accessed again.
So it sort of captures our intuitive idea
that we want locality of reference.
So the text talks much more carefully
about these different page removal policies.
But anytime you see anybody talk about a cache,
you should sort of immediately think to ask the question,
well, what's the page removal policy that's being used?
OK, so that basically does it for our discussion of caching
and of performance that we started last time.
And what we're going to do now is
move on to the topic of networking, OK?
So -- So a computer network, you guys should all be familiar
of what the idea of a computer network is.
It's some sort of a connection that connects
multiple computers together.
So why are we interested in studying a computer network?
What is it that's relevant about a computer network
for the purposes of this class?
And there's really sort of two primary reasons.
The first one is that computer networks are commonly
used as components of systems.
OK, so anytime we are building a big computer system,
it's very likely it's going to involve a computer network.
So it's going to be important for us
to understand what the properties of computer networks
are, and how computer networks affect the design of our system
if you want to use them effectively in our systems.
And computer networks have a number
of uses in the computer systems.
They do things like allow us to overcome geographic limits.
So what you guys are all familiar with the ability
of the Internet to allow you to check
the score of some sporting game that's
happening on the other side of the country,
or to be able to send an e-mail to your parents back home.
So obviously, being able to sort of transmit data
over long distances is clearly a good thing
for many kinds of systems.
They also allow us to access remote data.
And this is related to the other thing, to the other one.
But if you have data that's not on your computer
that you want to get a hold of, you
may want to contact your bank and ask them
for your bank balance.
And then finally they can be used
to physically separate a client and a server.
So we talked about the last few lectures,
we spent a while talking about the fact
that we can use things like threads and address spaces
in order to provide a sort of enforced modularity
between modules running on the same computer.
But there are lots of situations in which we
want to actually physically separate the client
and the server, right?
Your bank doesn't really want you
to be running your copy of Quicken on their server,
right, because this notion of enforced modularity we talked
about isn't a perfect separation between the client
and the server, whereas putting these things on really
separate machines that are only connected by this network that
is controlled by this piece of hardware that's this network
card that sort of talks with the network, that's a good reason
may be to separate these things from each other.
And then finally, the second major reason
why we want to study networks is simply
that they themselves are an interesting computer
system, OK?
So we talked in the first lecture
about some of the interesting sort of properties
that big computer systems have.
Well, there's not many computer systems
that are bigger than the Internet, right?
It's a perfect example of the giant complex interesting
system with all sorts of complicated behaviors.
And we'll talk about some of those complicated behaviors
today as we overview networks.
So the goal of our discussion of networking in some sense
is going to be to develop a set of tools that
allow us to have universal communication between a number
of different clients.
OK.
So what do I mean by that?
Suppose I have some collection of machines,
which I'll just draw as little boxes that
are scattered around.
And they are connected together.
What we want to do is to connect these guys together, OK?
And the network system that we are going to design
is going to be the interconnect that allows these
got to talk to each other.
And what we want this network to be
able to provide at a very high level
is the ability to do any-to-any communication.
OK, so if this is A and this is D,
we want to A to be able to send a message to D or anybody
else who's in this network.
And that should be true for any of the pairs that we can find.
And so, in some sense, what we're
going to do over the course of the next couple of weeks
is sort of see how we design this cloud that
sits in between all these different computers.
If you like, you can sort of think of this cloud.
Often times, the Internet is represented as a cloud.
It's just some black box that you sort of send messages
into with an address.
And on the other side, the message
pops out at the other end.
So, we're going to dive into this cloud
and see what happens inside of it.
So, in order to start to understand
some of the challenges of building this cloud,
we are going to start looking top down.
We're going to look at the biggest issues
that we have to deal with, and then we're
going to break up those issues into some smaller pieces.
So - - OK, so what are the issues
that sort is immediately pop out when you first
start thinking about the properties of a network?
Well, so there's some technological issues which
have to do with things like the physical medium over which
you're transmitting messages, or the properties of the links
over which you're transmitting them,
the rates at which you can send data, the lost rate,
the percentage of messages that get lost by the link
as it's transmitted.
So those are the kinds of things we
mean by technological concerns.
And so one kind of technological concern is this,
is sort of the different kinds of technology
that we might use for transmission.
And we saw this notion of D technology over DT before.
It's just this idea that technology,
just like the technology in your computer system
has been evolving dramatically over time.
The technology of networks has been evolving dramatically.
And we're going to sort of study some
of the range of different technologies
that we have to deal with.
There also are a set of limits, technological, physical,
fundamental limits that are associated with networks.
So, these are things like the speed of light, OK?
We simply can't send messages faster than the speed of light,
right?
These are messages that are being transmitted [down wire?].
And they propagate at some speed.
And that's going to be fundamentally a bottleneck
in the design of a computer system.
If I have to send a message from here
to California, that message isn't going
to get there any sooner than the amount of time
it takes for light to travel across the country.
And the amount of time that it takes
to transmit a message across the country
is nontrivial in computer time.
It might be a couple hundred milliseconds.
And that's a long time as we saw before it
when we have a processor that connects one
billion instructions a second.
OK, so the other interesting issue
that's going to come out about networks
is that networks are a shared infrastructure, OK?
What that means is that there are multiple users who are
simultaneously using a network.
You guys, of course, all know this from using the Internet.
And all the networks that we study in this class
are basically a shared infrastructure.
And we'll talk in a minute about why
the networks are fundamentally almost always going
to be sort of shared.
They're going to have to transmit
data for multiple different users at the same time.
And that's going to present a number of challenges
about how we ensure that the network is fair,
that everybody gets to send their data
when they want to send data, how we sort of
allow multiple people to access the same physical wire
at the same point in time.
OK, so what I want to do is I'll talk about these two things
now in order.
I'm going to start off by talking about technology.
So -- So the first interesting technological problem,
which I've already mentioned is that these networks are
extremely diverse.
They are heterogeneous.
OK, networking technology has evolved a great deal
in the past 20 years or 30 years since networks first
started being designed.
And that means there is a huge sort of range of devices
that we might have to transmit data over.
So let me show you what I mean.
This is just a graph showing the rate of transmission,
the sort of number of bits per second
that you can send over different networking protocols.
And the thing to take away from this first
is to note that on the Y axis here,
this is an exponential scale.
So the technology at the very bottom,
things like early telephone modems,
could maybe send data at 10 kb per second,
whereas these sort of high-end router class devices that
are running the Internet or sort of very fast desktop Ethernet
kinds of connections that are coming out today
can send more like, say, in this case we
have 10 Tb a second, right, so one times ten to the tenth.
So we are talking about a factor of ten to the seventh or ten
to the eighth difference in performance
in terms of the number of bits that these different kinds
of devices can actually transmit.
So, that's pretty dramatic.
And that's going to make it difficult to design computer
systems.
OK, and these kinds of variations
occur not only at the sort of number
of bits that we can send per second,
but also in terms of the propagation delay of the links,
OK?
So if I have a local area network that's
connecting two computers in my office together,
I may be able to transmit a message from one computer
to the other in an order of microseconds, OK?
But as we said before, to send a message
all the way across the country might take 200 ms.
To send a message across the Pacific Ocean
by way of the satellite around the United States
might take a second.
To send a message to Mars might take
tens of seconds or a minute.
OK, so there's this huge range in terms of transmission times
that some of these different links have.
So, fundamentally these two things, bit rate
and propagation delay are going to tell us
how long we would expect it to take for a message to travel
from one place to the other.
So for example, the amount of time,
so we can think of a communication link,
if you like, as being a piece of pipe, which has some width that
is the bit rate.
OK, so the width of the pipe is the number of bits
that I can cram down this thing.
So, a wider pipe I can shove more data down it.
But no matter how much data I can shove down it per second,
there still is some link to this pipe, right?
And that's the sort of separation between the sender
and receiver.
And that's bottlenecked, as we said before,
by the speed of light.
And that's going to affect how long it
takes for a message to get from, say, one endpoint to the other.
So if you think about the total time
to transmit a message from one guy to the other,
it's going to be the amount of time
it takes to pack the bits into the beginning of the pipe,
right, and then the amount of time
that it takes for all those bits to come out the other end.
So it's going to be some combination of the propagation
delay plus the transmission delay.
The propagation delay is just going
to be equal to length divided by, say, for example,
the speed of light.
And we're going to need to add to that the transmission
delay, which is simply going to be the number of bits
we have to send divided by the bit rate, the number of bits
per second.
OK, and so this is the time to send along one link.
OK, so it's worth remembering that this time to send
equation, this is only to send along a single link.
If we have to send more data, if there are multiple people,
for example, who are waiting to get access to a link,
that may increase the delay that it takes to send a message.
Or if we have to relay a message over multiple hops
and there are some intermediate node in between each of those
hops, then that sort of processing
at each intermediate node may take some additional time
as well.
OK, so if we look at a graph of some
of the properties of networks, it's
interesting to sort of look at the rate of change
of these different technologies.
So this is just showing what Moore's Law is.
So we saw this before.
Processor speed doubles every 18 months
according to Moore's Law.
If you look at the size of the Internet, so the number
of things that we have to connect together,
well, that's been doubling every 13 months.
So this has this sort of exponential behavior
that Moore's Law has as well.
So we are talking about sort of the number of things
that we have to connect together is just
growing at this massive rate.
And that's a real challenge for designing
the kinds of protocols that we are going to need
to use in these networks.
The other thing that we see that's been going up
at the same rate or even faster is the amount of traffic that's
being sent over the Internet.
So more and more people are sending data.
And again, this affects the sort of,
this is the challenge for designing protocols
that are able to scale up and up and up to these greater
and greater rates.
The largest link capacity in the past few years
has actually started to go up as fast as double once every seven
months.
So this is the size of the largest pipe that's
on the Internet, say, connecting lots of these big service
providers on the Internet together.
And this is just been getting larger and larger and larger
as well.
And so that's, again, means in order
to exploit all this additional link capacity,
we need faster computers.
And the rate of change of technology
is just extremely high.
Interestingly enough, of course, as we
said before, the speed of light never changes.
So this is a fundamental constraint
that we're always going to have to deal with when
we are building these things.
That is also the case that if you look at,
there's another number that you can look at.
And in the context of the Internet,
this number is, this is bits per second per dollar.
OK, so what does that mean?
This is the amount of money that it
costs to, for example, send one bit per second
over the Internet.
And this number just has not been scaling up very fast.
If you look at this, it's a factor
of ten cheaper today than it was in 1980
to send the same amount of data per second out
over the Internet.
So, why is that?
That seems strange, right?
I mean, if you look at the fundamental technology,
the technology itself has gotten much faster.
If you look at the Ethernet network
that you might have in your home or your office,
this thing has gotten, in 1980 you
might have had one megabit a second
that you could transmit over this Ethernet.
You can now, for $100 go to Best Buy and buy
something that can transmit a gigabit a second
over an Ethernet.
OK, so we are talking about a huge scale up in technology
in terms of the performance of the networks.
The issue here is that there is a human cost that's
associated with sending data out over the Internet.
And if I want to send data from here to California,
there's a physical wire that that data has to transfer over,
right?
And somebody owns that wire.
And it cost somebody a lot of money
to cut the holes in the ground where that wire runs
and to knock holes through buildings
and to get rights from all the cities
that that wire runs through to dig holes in their roads,
right?
So, there is some very large human cost
associated with setting up these sort of very wide area
internets.
And you see the same kind of thing
not just in wire but in wireless technology
with wireless companies paying huge amounts of money
for access to the rights to use a particular part
of the wireless spectrum.
So this is these bits per second per dollar
is growing slowly, OK, and the reason for that is human costs.
OK, and what this argues for, what
this suggests that we are going to need
to do when we are building these internets
or building these large networks is
to share these network links.
So, if every time we added a new host to the network,
we had to run a wire that connected it
to every other host in the network.
Obviously, that would be hugely expensive,
so we want to avoid that.
And so, we are going to end up because
of these costs of physically running the wires having
to share network connections.
And that brings us to sort of the next topic
that I want to talk about, which is this topic of sharing.
OK, so just that everybody is clear,
this notion of having pair-wise links,
a connection from every host every other host
is just not practical.
So suppose I have them set of nodes like this,
if I want to connect all of them together
by their own set of independent wires,
I don't know if I got all of them there,
but then the cost is going to be, if I have N hosts,
the cost is going to be N squared wires.
OK, and that is just too expensive, right?
If you have a million hosts, you're
going to have a trillion wires.
So we don't want to be building anything that has
a trillion components in it.
It's going to be really, really expensive to deploy.
So what we end up doing is multiplexing.
OK, so what do I mean by that?
I mean this notion of sharing links.
So let's look at a very simplified
kind of an architecture for something like the Internet.
So suppose I have two hosts, two nodes, two computers, A and B
that I want to be able to communicate over
a network to some other pair of nodes, C and D.
OK, well in a multiplex network, what we're going to do
is we're going to have a set of these boxes that
are going to connect these nodes together.
So I just sort of shown one possible network topology.
But with these boxes are, they are sometimes called switches.
And they are the connection points
that are scattered in various locations
around the Internet that transfer data
from one location to the other.
So in your home, you may well have what's sometimes
called a wireless router.
That's the thing that transfers data from the air
onto a wire network.
You may have a box from your cable company
that transfers data from your home out over the cable.
And then the cable company itself
has a box that transfers data to some other service
provider, which may be transfers data across the country, which
transfers data into the home of whoever you're trying to send,
or the business of whoever you're
trying to send a message to.
So you have this set of what we are calling switches here
that connect all these various hosts together.
And these hosts clearly, there are connections here
that are sharing data.
So if I look at this link here, if both A and B are trying
to send data to C, clearly there's
going to be some data for both A and B traveling on this wire.
And so, what we end up with is, sorry, so there
is a set of issues that are brought up by the fact
that we are sharing this data, and that we have
this kind of switched infrastructure
which we are running data around in.
So the first issue that we need to talk
about that obviously comes up is this notion of routing.
OK, so when you see a graph like this
and you ask the question, well, OK,
how does A get its data to C?
We have to pick some route which A
is going to take along this path,
through this network in order to get to C.
And, there are a couple of different alternatives, right?
So, any time you're sending a message,
there has to be something that plans out how that route is
going to be transmitted.
And commonly what happens is that each one
of these intermediate points along the network
has some table which says how to get to every other location
within the network.
And we'll talk about how those tables work,
how these tables that talk about where to forward your messages
to work.
But when a node has multiple sort of possible locations
where it can send data out to, typically that node
is called a router.
OK, so if you hear the term router,
just think of it as one of these switch things that
gets to make a decision about where some kind of traffic
is going to be sent to.
OK, so now what we need to do in order
to think a little bit more about how these switches work
is to resolve the issue of how we multiplex traffic
over one of these links.
So we said there may be traffic for both A and B
running on this link going into D.
Well, so how are we going to interleave the traffic
from A and B in order to make this work?
And there are two techniques.
We call this technique for interleaving data,
we call it switching or multiplexing.
And we're going to talk about two techniques for switching.
We're going to talk about circuit switching.
And we'll talk about packet switching.
So circuit switching is pretty easy
to understand at an intuitive level.
The idea with the circuit switch is
that we want to set up some reserved channel that
is the communication channel between two endpoints,
say for example, A and C.
So, a simple way if you want to think about circuit switching
is to think about the way that phone networks used to work.
So you may have seen these old movies where the operator would
plug wires into a switchboard.
What an operator is doing there is establishing
a physical circuit, a physical wire that connects
two endpoints together.
OK, so that's circuit switching.
Each operator has a bunch of lines coming in
and a bunch of lines coming out.
Somebody connects to the operator
and says I want to talk to line A.
And the operator establishes the physical connection.
So, of course we don't use that technology
for doing circuit switching anymore,
but this notion of circuit switching
is still used in the telephone system.
And the way that a common digital telephone system
might work is as follows.
So the idea is that suppose I have some set of nodes A, B,
and C, all of which want to send their data out over some line.
So they are connecting up to some switch.
And they want us their data out over this switch,
out over this wire that is on the other side of this switch.
OK, so what this kind of switching that we are going
to talk about does, which is commonly called TDM for Time
Division Multiplexing --
is to give each one of these nodes,
A, B, and C, a little unit of time
in which only its traffic is being transmitted on this wire.
So if you think of this wire as having
one additional piece of information
put on at each unit of time, and this is the wire stretching out
away from the host so that this is sort of time
is going this way as the signal propagates down the wire.
And if you were to look at all the different messages that
are on the wire, what you see is sort of a repeating pattern
of time intervals.
And each of these time intervals would be carved up
into a number of slots.
OK, and each slot is allocated to exactly one of these nodes.
And each node gets the same slot and each one
of these larger intervals.
OK, so you'd see a pattern like A's traffic, B's traffic,
C's traffic, and so on.
And then in the next interval we would
have A's traffic, B's traffic, and C's traffic again.
So there would be this repeating pattern
where each node is associated to the same slot in every one
of these intervals, OK?
And we call the data that, say, for example, A
puts into a slot a frame.
The frame is sort of the set of data
that is allocated to a node.
And, so this is basically the way
that circuit switching works.
And it's almost exactly the way that the phone network
works now.
So a phone network carves up the wire
into a bunch of these little slots where
each conversation is allocated one of these sort of frames
in each interval.
So in a typical phone network, a frame might be eight bits.
And there might be these intervals.
There might be 8,000 of them per second.
OK, so we have 8,000 intervals per second.
OK, and so what that means is that if each frame is eight
bits and there is 8,000 intervals,
each sender can send 64,000 bits per second.
And, it turns out that 64,000 bits per second
is about enough to be able to encode voice
at a sort of acceptable level for people.
So we can talk about the capacity of this channel
by basically looking at the number of frames
that are in one interval.
So if we say there are N max frames in one interval,
then that specifies the number of conversations
that we can simultaneously maintain on this wire.
OK, so the behavior of one of these circuit-switched systems
is as follows: everybody who's having a conversation
has bandwidth allocated to them, and has a frame allocated
to them in every interval.
So, up to N max conversations can be held simultaneously
and there's no problem.
But as soon as we get to the N max
plus first guy tries to initiate a call,
the network will simply refuse to accept that connection
because there's no slot available for this guy
to do his communication.
And the last little detail about how these circuit switches work
is how do we actually establish a connection
in the first place?
And we need some protocol for actually resorting
to a slot for a particular connection
between a pair of endpoints.
And so typically what you will do
is reserve some frame or set of frames
to carry information that's used to configure the connection
between the endpoints.
So, A can request that an interval be assigned
to its connection between C, and then it
will be by communicating during a special frame.
OK, so that's circuit switching.
But, circuit switching has a problem.
And we're going to need to introduce this notion of packet
switching to deal with it.
OK, so the reason that circuit switching has a problem
is as follows: because although circuit switching works
great for voice where every conversation is essentially
a continuous stream of audio that can always be encoded
at about 64 kb per second, Internet traffic just
doesn't work like that, right?
People who are communicating on the Internet
can have very variable demands for the amount of traffic
that they want to send.
And even taken as an aggregate, taking all the people who
are, say, for example at the community of MIT over time,
there still is a lot of variation
in the network demand.
So this is just a plot over the course of the day with samples
taken every five minutes of the amount of traffic
that was being sent out of one of MIT's labs.
OK, and so you don't need to worry too much about what
these different lines show.
But the point is that there are these periodic spikes.
And these spikes represent spikes of traffic
demand a different machines on the network.
So you can see that at any given point in time, there
can be anywhere from, at its lowest,
these numbers are about 40 Mb per second to numbers as high
as 100 Mb a second.
So there's a lot of variation in the demand at MIT's network.
Here's another way of looking at the same traffic.
This is an interesting graph.
This is showing the amount of traffic
that different protocols use.
This is a real graph by the way.
This is showing the amount of traffic
that is transmitted over MIT's network for different types
of protocols.
And what you see here is that it's really pretty amazing.
You see that Kazaa, this file trading network,
is using up a vast majority of the traffic that we send out
of MIT.
But besides that, there's another interesting point
which is that noticed during the months of October and November,
the two leftmost lines here, we are
sending a lot more traffic than during the month of December.
So, if you were at MIT and are trying
to plan how much traffic you expected to be transmitted
during a month, this makes it hard
because there was a 50% drop in the amount of traffic
from one month on this Kazaa network.
So we need to introduce this notion of packet
switching to deal with this problem of unpredictable rates.
OK, so in many kinds of data networks,
it's simply not possible to predict
exactly how much traffic you're going to need
to send at any point in time.
And so the idea is to use something
called asynchronous multiplexing instead of time division
multiplexing.
And the idea is as follows.
Suppose we have our three nodes, A, B, and C all transmitting
data through some switch out over a wire
just like we did before.
If you look at the traffic that's
being transmitted on this wire, what you'll see
is that it's not necessarily going
to have the same regular pattern that we had before.
The idea is that any node is allowed
to try and start talking on this wire any time that it wants.
It's asynchronous.
It's not timed.
There's no regular slots when nodes are required to transmit.
So this might be traffic for A.
This might be traffic for A.
This might be traffic for B, A, A, and C.
OK, so what this suggests, and noticed
that these packages of data that are being transmitted
are of different sizes.
Typically these are called packets.
And that's what this is packet switching
because we are sending the full packages of information that
are of a variable size as opposed to these fixed size
frames that we were transmitting before.
And notice that there is no requirement that A transmitted
any specific time.
A is allowed to try and transmit as much as it wants.
But this does introduce a complexity
because it makes it hard to plan for the capacity
of the network.
So suppose that each of A, B, and C
have a 1 Mb per second link, and suppose that this link is also
1 Mb per second.
Now, clearly if A, B, and C are rarely sending any traffic,
then everybody may be able to get
all its data onto the network.
But if A, B, and C all decide that they
want to send at the same time at 1 Mb per second,
then there's going to be a problem because they're
going to be trying to send more data over this link them
the link has capacity for.
And so what that immediately suggests
is that in these boxes, in these packet switch networks,
there is some kind of a queue.
OK, so we're doing queuing within the network.
But it also, so you might ask the question,
why don't network designers design these packet switch
networks so that you never have a link that's
connecting multiple endpoints together
that doesn't have sufficient capacity to transmit all
of the information from all of the endpoints that may
be transmitting data over it?
But if you think about this for a second,
that's going to be a really bad idea.
So suppose we are on the Internet.
And suppose that I am designing simple website.
I want to set up a website for students of 6.033.
If I needed to make sure that that website had
sufficient bandwidth that could support connections
from everybody who is on the Internet
just in case everybody who's on the Internet decided to access
that website at exactly the same time,
I would be in big trouble, right,
because I would have to have hundreds of terabits
of bandwidth available to me in order
to be able to support that.
So clearly I'm not going to do that.
Instead, what I'm going to do as a network designer is simply
try and ensure that most of the time my network has
enough bandwidth available for the users
were going to be accessing it.
But some of the time, there may not be.
I may sort of under-provision the network, may not
provide enough resources.
And so during those times when the network has
more data that's trying to be sent over it than it
could possibly send, we call those congestion times.
And when a network is subject to long periods of congestion,
these queues that are sitting in the network may fill up.
So these queues are some fixed size.
They are stored typically in RAM on a device,
and they can over-fill.
And when they over-fill, we have to do something about it.
OK, so this problem of congestion in networks
leads to all sorts of kind of interesting trade-offs
in the design of these packet switch networks.
And typically the bottom line is basically,
and we'll talk about this in much more detail,
but the bottom line is typically these packet
switch networks have to be able to drop data some of the time.
If a queue over-fills, the network
has no choice but to refuse to transmit data for somebody.
But because these packet switch networks are composed
of multiple routers along the way,
it may be that the data is actually dropped deep
in the network by some router not when I first try and send
the data, but five hops down the line the data may be dropped.
And so these kinds of things complicate
the design of these systems.
Queuing means there's variable delay.
OK, and congestion means there may be data that's lost.
And to deal with lost, we may have to retransmit packets.
And so this gets the sort of fundamental notion
that's going to come up in the design of these packet switch
networks, and that's that the extraction
that these packet switch networks provides
is so-called best effort networking.
And that means at the lowest level,
these networks don't guarantee that the data
that you send over them will actually be delivered.
All they say is the network is sort
of promising that it will try hard to get
the data to be delivered.
But you as a user, the applications that
are using this run network interface
need to understand that this variable delay,
they need to understand that there's
congestion that can happen which means
that packets can be dropped.
Congestion also means that typically packets
may be retransmitted.
And so that means that all of your data
may not arrive at the other end.
And so this is the best effort network abstraction,
and we're going to talk about these kinds of best effort
network abstractions exclusively for the next several weeks
as opposed to these circuit switch networks.
And what we're going to do is we're
going to see how we can build up a set of software that
runs on top of these best effort networks that allows us
to provide things like, for example,
some reasonable guarantee of reliable delivery, that data
won't be lost as data is transmitted over the network.
So we will see how we build up layers
on top of this best effort network
stack that allow us to provide certain guarantees to the user.
So that's it for today, and tomorrow we will talk about,
starting Monday we will talk about the link layer
interface for these things.
Don't forget about the exam.