Let's go ahead and get started, you guys.
OK, so before we begin, I just want
a brief note about the quiz.
So you should get the quiz back tomorrow in recitation.
The mean and median on the quiz were 69 out of 100,
so look for it tomorrow.
And there should be solutions post it also tomorrow.
Does anybody or member with standard deviation
was on the quiz?
OK, thanks.
OK, so the topic for today, we're
going to continue talking about networking.
And just to recap where we left off last time,
I wanted to review a few of the best effort network properties.
So you remember at the end of lecture
last time we talked about this notion of a best effort
network.
And we said that these packet switch
networks like the Internet are typically best effort, which
means that there are certain things in particular
that they don't guarantee.
So one property of best effort networks
is that they're subject to delays.
So these are delays due to the propagation of messages
down our wire, the time it takes for the messages
to propagate along the pipe.
Remember we talked about that analogy last time?
Time to transmit the message, so transmission time
is sort of the amount of time it takes
proportional to the length of the message
and the bit rate of the link.
And then, there is additional delays
that are introduced by these properties
that we talked about at the end of the lecture
last time such as queuing.
So the fact that remember we said that these networks are
congested and the load is somewhat unpredictable.
And because the load of the network is unpredictable,
that necessarily means that there
are going to be queues in between the links
on our network.
And then finally, additional sorts
of delay that we talked about, but also
can be an issue as the processing delay.
So this is the delay incurred by sort
of the overhead of processing messages between switches,
for example, in our network.
OK, so other interesting properties of best effort
networks, they incur some loss.
OK, so there are going to be messages
that are corrupted as they are transmitted down these links.
There are going to be losses that are caused by congestions.
Remember we talked about how one of the only responses,
oftentimes the best response to congestion
is simply to drop packets to reduce overload.
And there are sometimes going to be failures
that are going to be switches within the network that
will sometimes simply cease to function.
And of course you're going to lose
the data when that happens.
And there can be reordering of packets.
So you didn't talk much about this.
But it's fairly sort of obvious idea
that suppose an application has two different messages, right?
Well if you think about the way that those messages may
be routed along different paths through the network.
And we'll talk about this more when we talk about how
routing works next time.
But because they can be routed along different paths,
there's no guarantee that the messages, because message one
was sent before message two, that message one actually
arrives before message two at whatever
endpoint you're sending to.
And finally, there can be duplication.
And duplication is often a side effect of techniques
that we'll again talk about next time for dealing
with this issue of loss.
So if you have lost packets, somewhere in the network
you may want to try and retransmit those packets.
And because you're retransmitting things,
you're sending things multiple times.
There can be places in the network
where you actually see two copies of a message.
So these best effort networks have a number
of sort of properties that make using them somewhat complex.
And what we're going to talk about over the next two
or three lectures basically are ways
of mitigating the complexity of these best effort networks,
of making the interface that these best effort
networks provide to applications a little bit
more usable in the sense that we're going to try and find
ways to reduce the effects of things
like loss and reordering are to make it so that applications
don't necessarily need to be aware of those things.
So in order to start getting at sort
of dealing with complexity, we're
going to talk today about this notion of layering.
So -- So when we talked generically about systems
earlier in the class, we said that a standard way that
we're going to deal with complexity is by introducing
modularity.
And the specific kind of modularity
that is widely used within networks is layering.
And that's what we're going to talk about most of the time
today.
The other way that we typically deal with,
another common way of dealing with complexity
with the networks is by using protocols.
And a protocol is really just a set
of rules for how two machines on the network
do communicate with each other.
So, for example, a protocol might
say that if I want to tell you about,
if I want to send a message to you that I will put
this certain bit of information at the beginning of it,
I'll put some address information at the beginning
of that message.
And the message will be no more than a certain number of bytes
long.
And I'll put that message on the wire,
and then part of the protocol is also
that you will send an acknowledgment back
to me that tells me that you in fact got the message.
So these protocols are very well defined
sets of rules about how communication
is supposed to happen.
These protocols are going to help
us to deal with complexity because they
are going to tell us what we expect to have
happen within the network.
And when things don't follow the protocols,
then that's going to be an indication
that something went wrong, and that we should therefore
try and recover from it.
So, for example, if we lose a packet,
the protocol is going to allow us
to detect that a packet was lost and request
that that be retransmitted.
We'll talk much more about protocols next time,
but it's sort of worth bearing in mind
that almost at any time, two things
are communicating within a network that are
using one of these protocols.
And a protocol is just a set of rules.
OK so I want to just quickly give you
this list of five questions.
We're going to come back to this list of five questions
a little bit later.
But these are sort of five key questions
that we need to sort of figure out
how we're going to actually resolve in networks.
And the first question is, how do we multiplex conversations
on a network?
When we talked about this last time,
we have these two different alternatives, time division
multiplexing, which we said was used in telephone networks.
And we talked about packet switching
as a way in which we can have multiple people sharing
a network.
But there is a bunch of other questions
that we haven't really answered yet.
And this is what we're going to get
at over the next few lectures.
So how do we transmit bits on a link?
How do we actually, given a wire,
how do we actually modulate that wire in the right way
to transmit the message that we want to transmit down it?
How do we forward packets via switches?
So we sort of said that there are these switches,
and that along any communication path,
there may be sort of multiple communication hops
that have to be taken through multiple switches.
But we haven't yet talked about what is actually
going on inside those switches.
So we are going to look in particular at what's
going on inside switches in the Internet
and see how that works.
Then there's this question about,
how do we actually make communication reliable?
So we said that one of the limitations of a best effort
networks is that, well, it introduces loss,
and it can reorder packets.
Applications oftentimes don't want
to have their packets reordered or dropped, right,
because they're trying to actually exchange information
with each other.
So we'd like to understand what kinds of techniques
we can use that can systematically
allow us to avoid, or to make communication reliable.
And then, finally, how do we manage congestion?
So we said that one of the fundamental problems
with these packet switch networks
is that the amount of load may be
unpredictable in the network.
So the question that we need to ask, then, is, OK,
how are we going to manage this congestion?
What are we going to do in response to congestion in order
to sort of minimize the effect that it has
on the applications that are trying to run on the network.
OK, so we'll come back to these questions in a minute,
and as we talk about what the layers of the network stack
are, we'll sort of see how these different questions
fit in to these different parts of the network stack.
But what I want to do now is really
turn to this issue of layering.
OK, so in order to understand a little bit about why there
might be wires within a network, or a
why there might be layers within a network, excuse me,
let's look at a very simple kind of a network.
So suppose we have some client, a client, C, OK,
who has a number of different connections
to the outside world available to it.
And, it can connect each of those connections
go, say, for example, to some switch which
may in turn connect to another switch which may in
turn connect to some N host S, server S, that the client is
trying to communicate with, OK?
So, suppose C is trying to send a message to S.
Let's think a little bit about how this might actually work.
So we have the application, which is perhaps running on C.
And, it might try and send a message
by calling some routine send S message.
OK, so it says send to endpoint S this message that I have.
So let's think about how we might actually
go about implementing this.
So one way that you might have the application send
a message to S is that you might have
this sort of the application might understand everything
about what the whole network topology looks like, right?
So, it might understand, know about all the different links
that are available to it, and with each one
of these different links, it may understand what the topology
of devices that are out there.
So if I have a connection to the Internet, that
would mean that I have to understand all of the machines
that are connected to me via the Internet,
right, so I have this list of a million hosts,
and [UNINTELLIGIBLE] every client, and I sort of just
scan down this list of a million machines
that I can connect to until I find S.
And then I send a message out over the next link
or something, right?
So this sounds very complicated because it
forces the application to understand
the sort of entire functionality of the network underneath it,
how the network is connected, and how
the nodes talk to each other.
So that doesn't seem like a very good idea.
Right, instead we'd like to application simply
to be able to just send its message out.
And we would like some lower layer service
to take care of the details of figuring out
where to send the message next.
So, in networks, we talk about that sort of service
that runs underneath the application, that's
in charge of figuring out what the next sort of connection,
the next top to use within the network,
we call that the network layer, OK?
So, I'm going to abbreviate as NET.
And so, what the network layer, for example, suppose
this client had three connections available to it.
It has a modem connection.
It has a WiFi connection.
And maybe it has an Ethernet connection.
What the network layer is going to do
is it's going to look at this name, S,
that the client has specified.
And it's going to try and decide which one of these links
is the next link to use in order to forward the message on to S.
OK, so it's just going to make a decision
from amongst the available connections.
So, it's going to basically pick the next link, OK?
And if this is the Internet, you're
going to have these switches or these routers that
may have links to a bunch of other networks.
And so in the Internet, the network layer
runs actually on all of the routers within the Internet,
and is making these decisions about how
to forward packet after packet.
So we'll see again in the next lecture and in recitation
how the Internet actually does packet forwarding.
But so we said there is this network layer.
But we have this thing that's picking the next link to send
the message out over, right?
But we don't necessarily want that thing
to have to understand the details of how you actually
communicate over each of the available physical connections,
right?
So suppose that the only thing that was here
was this network layer.
And the network layer had to understand
how to communicate over Ethernet and WiFi and the modem.
Right, well then the network layer
is going to be very complicated because, of course, sending
messages out over a wireless radio
is very different than sending messages out over an Ethernet.
So what we have is one layer that
sits underneath the network layer, which we typically
call the link layer.
And the link layer is responsible for managing
the physical connection for the transmission of data
from a long just one of these wires.
It's the thing that actually moves bits
from C to whatever the next top within the network is, OK?
So, these are these two layers.
You notice now, I've left this hole here.
You might be wondering what goes into that hole.
So what we said is so the network layer
is responsible for picking the links.
But remember that what we talked about so far in this best
effort network abstraction is sort of affairs
all these problems, decent sort of with delays, reordering,
duplication, and so on.
And it might be that neither of these layers
really is responsible for dealing with those problems.
What we said is, what we want, to be
able to provide an abstraction for applications
where some of these problems with the best effort networks
are hidden from the network.
OK, so typically networks introduce
a third layer, which in this class
we call the end-to-end layer that's
in charge of addressing these kinds of issues.
The end-to-end layer may seem a little bit fuzzy, the details
of it when we talk about it because the end-to-end layer
can do lots of different things for different applications.
OK, so some applications may be concerned about,
for example, the possibility of messages being lost, right,
whereas other applications may not
be as concerned about messages being lost,
but may be very concerned about delay.
And we'll see as we talk to the class
that delay and loss trade off with each other which
makes sense.
If I lose a message and I have to retransmit it,
that's going to increase the delay on the network.
But, so it's possible to sort of trade these things off
for each other.
So the end-to-end layer is the thing
that's responsible for trying to make application environment
sort of more pleasant for the application.
And that can mean dealing with trying to eliminate loss
or trying to minimize delay, for example.
We'll talk about different kinds of end-to-end layers
in just a few lectures.
OK, so these are kind of the three.
So we're going to decompose our network into these three
layers.
And in order to sort illustrate this to you a little better,
what I want to do is just walk you
through a simple example of how the letters might
look in the Internet with a simple web application.
And I'm going to use some of that terminology
from the Internet here, and we're
going to return to some of this terminology, introduced
its older more carefully in recitation.
But I'll try and explain it as much as we go.
So suppose we have a laptop, say my laptop here,
that wants to connect to a Web server, MIT.edu.
And, the way that the Web works is it
uses a protocol called HTTP, which
is used for making requests for specific webpages,
and for returning the results of those webpages.
So these are typically called requests and responses
in the HTTP specification.
Now, if you look at, so this is sort of from the user's
perspective; the application is a browser
that knows about the http protocol,
or a Web server that knows about the HTTP protocol.
And it's running on these two remote machines.
Underneath each of these things, of course,
there is a set of layers.
And each of these things has layers underneath it.
And these layers correspond to these three things
we just talked about, the end-to-end layer, the network
layer, and the link layer.
So one thing you may notice here is
that the link layer is different between these two things.
So the laptop is perhaps communicating over WiFi,
and the Web server is communicating
over the Ethernet.
But otherwise these two things have the same;
their Ethernet layer and their network layer are TCP and IP.
So, TCP is going to be in charge of basically providing
this reliable abstraction for us.
We're not going to talk about it anymore
today, except to say that, that it
makes communication reliable.
We'll see how it does that later.
What IP is responsible for is choosing the sort of next top
to make along each connection of the way, each connection
within the Internet.
So, IP is the protocol that runs the Internet.
And, you may have seen IP addresses.
So, IP addresses are the sort of names
for the endpoints in the Internet,
and takes an IP address and basically
gives you this next link that you
should use in order to transmit a message out over it.
OK, so suppose that the browser generates
a request for some page.
What it's going to do is it's going to call
send on the end-to-end layer.
OK, so I've just written this as E to E send to make it clear
that this is a send request to the ETE layer.
And it's going to pass some message.
In this case, the message is simply
going to be the contents of this request.
And it's going to specify the underlying
protocol that it should use as well as the destination
address.
So this address is one of these Internet addresses and IP
address followed by this colon 80.
So, what colon 80 does is it identifies
what's called a port number.
And it identifies the application
we're running on the remote server
that we want to communicate with.
So, typically Web servers run on port.
Now, you say they run on port number 80.
That just means that the TCP layer on the other side
knows how to communicate, knows that the Web
server on the other end is connected on this port number
80.
So it gives us a way to communicate,
to identify applications that are running on the remote host.
So now what happens is this request is going to be,
the TCP layer is going to take this request, which
I've shown in blue, and it's going
to attach what are called headers and trailers to it.
So these headers and trailers are the information
that TCP needs, the TCP layer on the other side
is going to need in order to deliver this message
to the application.
So in particular, this thing is going
to contain this port number that we already mentioned.
So this is going to be used on the other end in order
to send the message to the Web server.
It's also going to have a sequence number, which
as we will see later, we're going
to use in order to, for example, reporter in order
to detect reordered messages or detect lost messages.
OK, so the TCP layer now is just going to repeat the same thing.
It's just going to take this packet,
and it's going to call some request, say,
NetSend [SP?] on the IP layer that sits underneath it.
And again, it's going to specify the set of data
that it built up, which we called a segment.
So that's what SEG is, which was the purple and the blue blocks.
And it's going to pass that on to the IP header
using this NetSend message to the IP layer.
And it's going to tell the IP layer what IP address it
wants to send this message to.
Now, the IP layer is going to take this message,
and it's going to put the header on it.
So IP doesn't use a trailer, although it could,
in principle, use a trailer.
And this IP header is going to sort of just
contain the IP address of the next hop,
or of the destination.
OK, now the IP layer is going to do exactly what we said.
The IP layer is our network layer
so it's going to do exactly what we said it does before.
It's going to look at all the available links
that it has to it, and it's going to send this message out
over one of those links that it believes
is the correct next top in forwarding.
So it's going to call link send.
It's going to pass this packet on,
and it's going to specify the name of the link
that it wants to use.
And it may have to specify some address information,
for example, what I've shown here is just [cool?] in one
just to say whatever machine is one the wireless network
at wireless address number one.
So you guys saw sort of a similar addressing scheme being
used in Ethernet last time.
You can sort of think of that the same here.
So what happens now is of course the same process.
The link layer attaches its header and trailer.
So, I've called WH and WT for WiFi header and WiFi trailer.
And now at this point we called this thing a frame.
And this frame is now ready to be delivered out
sort of along the next top of the network.
So suppose that the network layer identified
one particular switch as the next destination
of this packet.
It's going to send this out over the network to the WiFi
interface of this switch.
The switch is going to receive this message.
What it's going to do is it's going
to take the WiFi header and the WiFi trailer,
and it's going to peel them off of the message,
and it's going to pass the message with just the network
header, no more WiFi header on it up to the IP layer.
Now the IP layer now has an exact copy
of the sort of message including the IP header from the laptop.
And, so what the IP header layer will do
is look at its IP header labeled NH here,
and it'll decide what the next appropriate hop to use, to send
this message out, it is.
So it's going to then pick the next link
to send a message out over and, say, in this case,
it decides to send the message over an Ethernet connection.
The Ethernet connection is going to receive the message.
It's going to attach its header and its trailer to it.
And then it's going to send it out to the next link, OK?
So this process just repeats.
The message gets sent to the Ethernet link
on the other side.
The Ethernet link forwards the message onto the IP layer.
The IP layer decodes the message,
decides what the next link to use is.
In this case, it decides again to use an Ethernet link.
And it sends the message out over the Ethernet.
Finally we get to MIT.edu.
And once we get to MIT.edu, we just
start forwarding this message up the layers, OK?
So, we do what are called up-calls from the lower layers
to the higher layers, notifying them
that a message has arrived.
So, the Ethernet layer peels its headers off, sends them up
to the IP layer.
The IP layer peels its headers off,
sends them up to the TCP layer.
Then remember, we said the TCP layer,
so the TCP layer has a port number that's
associated with it.
The port number is used to identify the application that
should receive this message.
So, the TCP layer pulls out the port
and sends it up to the web server, which finally
receives our request, OK?
Now the Web server does whatever it does.
It chews on this request for a while,
and say, for example, generates a webpage,
generates some HTML that it's going
to send back to the client.
And now this process just repeats all over again.
The MIT.edu sends a message back down
to TCP identifying the client as the endpoint
that it wants the message to reach, OK?
So this is sort of the basic way in which we use layering.
What I want to do is now kind of step back and look at,
I sort of presented this as a very quick example.
But what I want to do is step back
and look at some of the sort of rules
that we are following as we use these layers,
and to sort of talk about why we have
sort of constructivist thing in the exact way
that we have constructed it.
So the first rule that we are following here
is called encapsulation.
So what encapsulation is, is it's simply
this way in which you notice that when we send messages out,
each layer associated its own header
and trailer with those messages that were sent out.
And it didn't modify anything about any
of this sort of data that wasn't associated with the header
and trailer for that layer, OK?
So, encapsulation says that each layer
may add or remove depending on whether we're
sending a message down or sending a message up.
Its own headers are trailers.
OK, but that layer doesn't touch, doesn't look at or use
the payload from higher layers.
OK, so the link layer doesn't look at anything
that the end to end layer sends it.
It simply treats this as a block of data
that it has to transmit, and it doesn't understand anything
about what the contents of that block of data are.
It doesn't assume anything about the contents
of that block of data.
Similarly, the network layer doesn't assume anything
about the contents of the data that's
received from end to end layer.
And similarly, the end to end layer
doesn't assume anything about the format or the layout
of the data that's received from the application layer, OK,
or from the application.
So what this layering abstraction buys
us is that it allows these things to sort
of coexist without any understanding of what
the other layers do.
So in particular, it means that we can, for example, change
something about the format of the data
that the network layer sends.
And we continue to use the same link layer.
OK, so I can send it out over an Ethernet that's
not data that's been sort of packaged up by IP, right?
It doesn't necessarily have to be an IP packet
to send it out over Ethernet.
And so, this sort of separation between the layers
is going to be really critical for allowing
us to sort of maintain and develop
new networking code over time.
And it also means that the people
who provide the sort of companies that build and sell
software and hardware that works at these different layers
don't really have to assume very much
about what the other layers are going to provide, right?
So if I'm making an Ethernet card,
I don't have to understand anything about exactly what,
I hopefully won't have to understand anything
about exactly what's sort of going on up at the higher
levels of the network stack.
You have to be a little bit careful, though,
because of course the individual layers
do have some protocol that there is some sort of API
that they're using to interface with each other.
So, API is an application programming interface.
You have some set of routines that they call on each other.
So for example, I showed in this example
up here that the networking layer
is calling this link send message
on the link layer below it.
So the link layer has to provide this link send interface.
And similarly, there's a comparable interface
when the link layer receives a message that uses to send up
to the network layer.
OK, but basically what this means
is that we can develop the software that
runs at the different layers in isolation
without having to worry too much about what's
going on at the layers above or below us.
OK, so --
Let's return back to our set of questions
now and talk a little bit about how these questions map
onto our three layers.
OK, so our first question is, so we
said question one is, we've sort of already addressed that.
But question two is, well, how do we transmit bits on a link?
OK, so clearly that's going to be handled by layer two,
OK, or by the link layer, sorry.
And, so the link layer is the thing
that's going to be in charge of actually pushing
the bits onto the link.
And none of the other layers need to know about this.
Question three, OK, how do we forward packets via switches?
Well, it seems that it's pretty clearly what's
happening at the network layer.
OK, so the network layer is the thing
that's deciding sort of which packet,
what the next link that we should use is within a switch.
OK, and now questions four and five
are these questions about this kind of our best network
properties.
How do we achieve reliable communication?
How we manage congestion?
These are things that were going to worry about at the end
to end layer.
OK, so just to sort of illustrate a little bit more
about sort of how the commercial, and how
these things are separated in sort of a commercial world,
I thought I'd just show you the slide that sort of illustrates
that there are lots of different vendors, both hardware
and software, that run at each one of these different layers.
So, for example, at the end to end layer,
first there are clearly a bunch of applications
that run up there.
And each of those applications perhaps
has some different sort of set of requirements
about how data is delivered.
And those applications, typically
the sort of things like the TCP protocol
are provided by, say, the operating system vendor.
So Microsoft Windows provides an implementation of TCP;
similarly Mac OS and Linux also provide this.
At the network layer now we have sort
of this huge variety of people who are building these network
switches.
And these network switches are the things
that have sort of coded into them
the rules for how you should forward messages around
on the Internet.
And so these are these companies like Cisco and Alcatel,
in sort of these big companies that hear mentioned in the news
all the time.
And then finally at the sort of lowest layer,
there are these sorts of link layer things.
And again, there are a number of link layer technologies
like WiFi and Ethernet.
And those link layer technologies
are different than the technologies that
are used to actually decide which
hop we should next use in order to transmit data around
in the Internet.
OK, so if there's a big diversity of applications.
And part of this diversity of applications
is enabled by this separation of the layers
because Microsoft Windows doesn't really
have to know anything about how the network layer works.
It simply passes sort of messages
on for the network to transmit.
OK, so and the point is that the vendors
are generally different at each of these different layers.
OK, so given this sort of high-level overview
of layering, what we're now going
to do throughout the next few lectures
is to pay some attention to how each of the different layers
works.
So we're going to start off talking
about this class about the link layer.
And then we'll move on to the network
and ends to end layers in later lectures.
OK, so we've sort of seen some of the things that
touched on some of the things the link layer
needs to provide at a high level.
But let's make a list and talk about what these things are.
So the first thing clearly that the link layer does
is manage the sort of transmission of bits
along this physical wire.
OK, so there's going to be some digital to analog
to digital conversion that happens
in sort of as a part of using any one of these links, OK?
And this is going to be one of the main functions of the link
layer is it's going to decide how
this sort of digital to analog to digital conversion
is done, OK?
Another thing to link layer does is framing.
And so, framing, well you remember
we talked about at the link layer,
we sometimes call for messages that are transmitted around,
we call these things frames.
Framing is simply separating the frames,
is deciding how we should separate the frames that
are on the wire.
So it says, how does the software
that's running at the link layer decide that one frame has ended
and another frame has begun?
That's what framing is about.
And we'll talk about these two issues briefly today.
The other kinds of things that happen at the link
layer we're not going to talk about as much about today.
One of them is channel access.
And so this is how somebody who wants
to send a message actually is able to physically use
the wire or the air that it's transmitting out
of without interfering or something on top of something
else who's transmitting at the same time.
So you guys have read the Ethernet paper,
and you saw one way in which that's done
and Ethernet, which is basically by listening for a carrier,
right, which is called carrier sense,
and only when the channel is not used,
there's not a carrier on the wire,
does somebody try and send.
And then you use this notion of collision detection
and Ethernet in order to actually sort of detect
whether or not you are able to successfully transmit
your message.
So these are the kinds of things you worry about
in channel access.
Last time with the phone network,
we talked about time division multiplexing
as another way in which you can sort of share access
to a physical wire.
You can carve it up into a bunch of little units of time
and assign each sender one unit of time.
OK, so now the last link layer issue
which sometimes is done in the link layer
is error detection and correction.
And I don't want to talk at all about really
how error detection or correction works except
to say that some link layer is included in some link layers
don't include it.
The idea here is suppose we are transmitting a message out
over a wire.
Of course, there's some probability
that that message will become corrupted
or garbled it is being transmitted, either because it
interferes with somebody else who is transmitting
at the same time, or as the message propagates,
it decays somewhat and we can't decode it anymore.
So sometimes link layers include a facility
for doing this error detection and correction.
And error detection and correction
is one of these things that can sometimes
be included at the link layer, and is very often included
at the end to end layer.
And so, as you read, the reason I mention this
as being a part of the link layer
is that as you read the end arguments paper for recitation
next time, you should sort of think
about how the end-to-end argument relates
to whether error detection and correction should
be within the link layer or should
be within the end to end layer.
OK, so let's talk about these sort of two issues
that I said we'll address briefly here.
So the first issue I want to talk about
is how the conversion from digital
to analog to conversion works.
So -- So the way to think about, suppose that we have some
sender which has some sequence of bits, say, one, zero, one,
zero that they want to send out over the radio channel.
So if you think about what this is
going to look like in terms of an analog signal,
they are of course are many different ways you
could represent it.
But a simple way to represent it might
be to say that this is a digital line,
and we'll make the line high when we are transmitting a one,
and we'll make the line low when we're transmitting a zero, OK?
So we would send this message out
as high followed by low followed by high followed by low.
So this would be one, zero, one, zero.
OK, you might ask the question, OK,
how do we decide when to sort of push the next bit out
on to the wire?
Well, typically the way we do it is
we have some clock signal that tells us
when the next bit should be, we should
start sending the next bit on the wire.
So we might have some protocol that says something like,
every time there is a rising edge in the clock signal,
we'll start transmitting the next bit.
So, what does that mean?
So a rising edge --
OK, so suppose this is our clock and this is our data.
And what I've just shown here is that every time a clock signal
goes high, we start sending in new bit.
OK, so every time we go from low to high in the clock signal,
we start putting a new bit on the wire.
So, now it's going to happen is oftentimes
the way the network connections are
connected is what's a so-called serial connection.
So we have one wire that's transmitting the data.
And we don't have a separate wire
that includes the clock signal.
We just sort of transmit the data out over the wire.
So if you were to look at this data
as it comes down the serial connection,
at the receiver, what it would look like is something that
was sort of, it's not going to look exactly
like these nice square pulse was that we have here.
It's going to have decayed somewhat.
So it might look something like is
each of these nice square waves might have sort of become
a somewhat decayed version of their former selves, OK?
And now the question we have is, OK,
how are we going to decode this, right?
So we don't have access to the original clock
signal that was used.
But we may know what frequency, would
rate this data was encoded at.
So we may be able to generate a comparable clock signal.
So suppose we generate a clock signal that's
about the same frequency, and then try and use
that to decode the message, say, by looking again
at the rising edges.
If we're not careful, we're going
to get something that's wrong.
So in this case, I transmitted one, zero, one, zero,
but now I'm decoding something that's
shifted from that somewhat.
So I'm decoding zero, one, zero, one.
So, I've sort of become offset because the two clock
signals aren't actually identical, right?
Even though they're at the same frequency,
they are not specifically lined up with each other in time.
So we say that those signals are out of phase.
So one signal is essentially a time shifted
version of the other signal.
OK, and this time shifting leads to these kinds of problems
where we don't properly decode the message because we're not
sampling the channel at the right point in time.
We're not looking at the channel to see
whether it's high or low.
OK, so how are we going to fix this?
It turns out that there's sort of a simple and elegant way
that's often used to fix this.
And it's what's called a phase lock loop or a PLL.
So a phase lock loop, a very simple way
that you can implement a phase lock loop is as follows.
So the idea here is that what we want
to do is we want to figure out, we want and make it
so that the receiver has essentially a lined up version
of the transmitters clock.
So we need to figure out how much we
need to shift the receiver's clock in order
to make it line up with the transmitter's clock.
And once we do that, then hopefully we will properly
decode the message instead of being shifted
when we decode the message.
So the idea with a phase lock loop is kind of as follows.
Suppose we have our signal like this.
A simple way to implement a phase lock loop
is to take this signal and to sample it
not once per clock, but some multiple number of times
per clock period, OK?
We call this oversampling.
We might, say for example, do eight times
oversampling on this.
OK, so what that means is if we were perfectly lined up
in time on this oversampled signal,
and we were encoding a one as a high, and a zero as a low,
then what we would see if we were perfectly lined up
is alternating sequences of eight zeroes and eight ones,
right?
So, if instead we start decoding this
and we see something that's not quite that,
suppose we see three ones followed by eight
zeroes followed by five ones.
OK, so we decode two bits worth of information off the wire,
and we see that it's sort of shifted in this way.
OK, that suggests that I need to shift the signal
to the left some amount.
OK, and so this is exactly what the phase lock loop does
is it observed the signal as it's coming in,
and it computes an amount that we
need to shift the signal in one direction or the other.
OK, so if you wanted to make a sort of schematic for how
a phase lock loop works, we have our sender and the receiver.
The idea is simply as follows.
You have some data at the sender,
and a clock at the sender.
Those go into some encoder box.
They are transmitted out over a line
to the receiver, which has a decoder box.
OK, but the decoder box needs a clock signal
that's been lined up with the sender's clock signal, OK?
So we're going to do is use our phase lock loop to do that.
So the phase lock loop is going to take
in the incoming signal as well as the unaligned clock
from the local machine.
And it's going to input into the decoder an aligned clock
signal.
OK, so basically what's going to happen
is this PLL is going to be able to reconstruct the clock
signal from the sender.
Of course, it takes a little bit of time for the PLL
to reconstruct the clock signal.
So usually what we do is every message that we transmit over
the link, we have some sort of set of synchronization bits
at the beginning of it that we use in order
to allow the phase lock loop to lock in
to the phase of the signals being transmitted.
And that preamble doesn't carry any data bytes.
It's simply sort of overhead that's
on every packet to guarantee that the sender and receiver's
clock synchronize with each other.
So there is one last little detail
associated with phase lock loops that you guys may have noticed.
So the issue is that the signal that I've
shown being transmitted here is a one, zero, one, zero, one,
zero signal, right?
But if you think about the way that this phase lock
loop works, what the phase lock loop does
is it looks for these transition points in the signal, right?
So it looks for points where the signal changes
from a one to a zero, right?
So suppose that instead of transmitting one, zero,
I transmitted zero, zero, zero, zero, zero, zero, zero, right?
Then the problem I'm going to have is I'm
just going to have a very long sequence of zeroes
even if I do this eight times over sampling.
I'm still just going to have a long sequence of zeroes,
and I'm not going to know how much I need
to shift the signal, right?
I'm going to have no way of computing
how much I need to shift the signal.
So it turns out there's a very simple and kind of elegant
solution to this called Manchester encoding.
And the idea with Manchester encoding is as follows.
It says will transmit a zero as a transition
from a low to high, and we'll transmit a one
as a transition from a high to a low.
OK, so now if I transmit a signal like one,
zero, one, if I transmit the signal: zero, zero, zero,
it simply looks like this.
So, zero is a transition from a low to high
followed by another transition from a low to a high.
OK, so now this is zero, zero, zero, zero, right?
And if I transmit the signal, zero, one, zero,
this is a transition from a low to a high followed
by a transition from a high to a low followed
by a transition from a low to a high, OK?
So now we have a way that we can guarantee that every bit as it
least one transition in it.
And that's going to allow our phase lock
loop to look into the face of the signal that's
being transmitted.
Of course, the cost of this is that we've now
doubled the number, sort of, we've
doubled, every bit as a transition in it, right?
So we sort of have the number of bits that we can send over
the channel because instead of a one
being simply a low, or a one simply being a high and a zero
being a low, now everything is both a high and a low.
So we have the amount of data that we
can send on the channel.
But we've sort of gotten this wind
that now we can have the phase lock loop actually work.
And so turns out Manchester encoding is actually
commonly used.
There are other encoding schemes that you
can use that are sort of less wasteful of channel bandwidth,
but operate on the same principle,
trying to introduce extra transitions when possible.
So this basically wraps up our discussion of the link layer.
What we're going to talk about next time,
are going to start talking about how the network layer works.
And we're going to basically talk about
how Internet routing actually functions,
and how these routers actually decide which
link they should use to transmit the next message around
in the network.
So, that's it for this time, and we'll see you on Wednesday.