Lecture 17: Packet Switching

Flash and JavaScript are required for this feature.

Download the video from iTunes U or the Internet Archive.

Description: This lecture introduces communication networks, with MIT's network serving as an example. Packet-switched networks are discussed with examples of packet headers, traffic, and the sources of delay.

Instructor: Hari Balakrishnan

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

PROFESSOR: So my name is Hari Balakrishnan, and I'm going to take you through the rest of 6.02, doing the remaining lectures in the class. So far in 6.02, what we've looked at are ways in which we design a single communication link. So we know how to take two computers or two nodes and design what a link between them might look like. And this link might be an actual wired link. Or it might be a radio link. Or it might be an acoustic link.

There's some medium over which these two guys communicate. And the main ideas we've looked at have to do with coding, in particular, channel coding, which is a strategy to combat noise and errors that might show up on the channel. And then in order to match what we communicate to the characteristics of the channel-- for example, the ability of the channel to deal in sinusoids-- we studied modulation and de-modulation.

So those are the two main elements that we studied. And in both of these, we looked at both how you do this to achieve reliability-- because ultimately, we want to communicate information in a way that's reliable-- and do it efficiently. In particular with modulation, we look at a scheme to share a medium amongst multiple conversations, frequency division multiplexing, which is the topic of one of the tasks on this lab.

And with coding, we looked at ways in which you do this coding in a way that isn't just replicating every bit but involves some linear algebra operations that allows you to gain efficiency. So the rest of the class is really about taking for granted our ability to design communication links and putting them together and composing them to build networks.

So the basic problem is actually very, very easy. The problem is, you're given a set of nodes-- let's say computers-- and the problem you want to solve is to come up with a way by which you can allow any computer or any phone or any device on this network to communicate with any other device on the network. And that's the problem.

So you're given n nodes. And you want all-to-all communication. Now, this is a little different from the kind of-- there are other networks you could design. You could design a network where you're given n nodes and you have 1 to n communication. There's one transmitter, many, many receivers, and you want to design a network for that purpose.

What's an example of a network where you have one transmitter, many receivers, and you just want to build something that makes that work? Radio is one example. Television is another example. And those are good examples. In fact, for those kinds of one-to-many networks whether you have-- or k to n networks where you have k sources of information and n receivers and k is a lot smaller than n, it'll turn out that the basic frequency division approach makes sense. I mean, that's how radio stations or TV stations work.

Someone in the US-- the Federal Communications Commission has decided to allocate different chunks of frequency to different TV stations and different radio stations. And the assumption is they're always going to be using it. Turns out that assumption may or may not be true. But under the assumption that they're always going to be using it and you have many, many, many receivers, you just divide up frequencies and allow them each to transmit in their own frequencies.

And then you have a receiver that's capable of tuning to different frequencies. And you get the information or the channel that you want. We'll actually come back to that problem a little bit in the next two lectures. But for today, the design problem-- and going forward, the design problem you should have in mind is you want a network where you have all-to-all communication and you want to be able to support any application.

This is a big deal. We're not just designing a network to allow telephone calls to work. Or we're not just designing a network that allows you to do video conferencing. We're trying to design a network where any application can run on it-- in particular, applications that you might not have envisioned. This is the reason why the internet works really well is because when they designed the internet, they designed it under some set of assumptions. But they were really, really smart to design a network that made minimal assumptions about the application.

So it's a network that's good enough for almost any application, though it isn't perfectly optimal for any application. It's just good enough for everything. And that's a really good characteristic of a well-designed network is if it can work even for things you didn't even dream of. When they build the internet, they suddenly didn't dream that the web would exist. They didn't dream that people would be tweeting and telling people they're going to the bathroom or whatever they do on Twitter. I mean, they designed a network.

And it just kind of is amazing that all these applications can work. So the question is, what did they do correct? What did they do right? And what are things that-- what general lessons can we learn from it? And the general high level lessons you learn actually apply to any system you build. It'll turn out that whenever-- if you're confronted with a real world problem in an industry or research or whatever, very often you're trying to make decisions on what you need to be doing.

And it's very tempting to make decisions based on what you think it's going to be used for. But very often, what you end up eventually using it for is very different from what you thought in the beginning. So it's good to have applications in mind. But it's good not to embed too much about those applications in the design of network. So the high-level principle here is how you can do something that works well enough without making too many assumptions about what's running on top of it.

There are two big themes. They're the same two themes that we studied before that we're going to keep coming back to. The first is efficiency. And the second is reliability. The same two themes we come back to over and over again. There's a third important theme about network design, which has to do with scalability. I mean, how can you make it work so this network can work for millions or billions of devices and billions of computers?

That's a topic we're not really going to talk about. I'll get to it in the last lecture. But 6.033 and 6.829 we'll talk about those issues. So let me start first with efficiency. If I tell you how to build a communication link that can communicate between any two devices or any two computers, it should be pretty straightforward to now design a network that allows all-to-all communication. Something out? That's a mouse. Great.

One way you can design this network is to simply take your communication link that we know how to build and do this. Just connect every pair of computers or every pair of nodes to each other. I'm probably missing a few of these. But this is a great network design because it's composed of bunch of links to build a network.

So why don't we do this? Or maybe we should do this. What? It's too expensive. Why is it too expensive? Sorry? You know, how many of you are in Professor [INAUDIBLE] recitation? Great. I understand he gives you guys money to answer or if he makes a mistake. I'm going to do the same thing. Whenever I make a mistake, Professor [INAUDIBLE] will give you some money.

[LAUGHTER]

So I actually-- I mean, don't hold me to this. But why don't you guys answer? This is pretty straightforward. How many links do you need? n [? choose ?] 2. It's about n squared, right? So n squared, depending on the context, it's either too big or too small. But it's about n2 to n squared lengths.

It turns out that's actually a pretty large number of links, because-- and the notes talk about some of the reasons why this is too expensive. But the other reason it's a problem is that it's one thing to design a network where every computer in this room can talk to each other. And conceivably, we might get tangled up in all these wires. But we could imagine laying wires between every pair of our computers and communicating.

But there are two reasons this is a big problem. I want to communicate with computers in California or China or wherever. And individual links going across the world and my computer to China and your computer to another computer in China just doesn't scale. It doesn't work very well. And the second problem, the reason why this issue matters is that not all communication links are wires.

In fact, right now, the most dominant mode by which people gain access to the internet, including right now in this room, is through radio, is through wireless. And this is a shared medium. So it's not like we can somehow put these wires together. We're going to have to share this communication medium. We're going to have to share this communication network. And somehow we have to come up with a strategy to do this efficiently.

There's a few different principles involved in how you design networks. But the main one is that we're going to construct a special computer called a switch. And a lot of what we're going to be doing has to do with what we do in the switch. The other part of what we're going to be doing is what we do in the computers itself.

So our network is going to be designed using a set of rules that are obeyed and implemented and followed by the computers. OK, a special set of rules that are implemented by these computers called switches and a special set of rules that are implemented by the end computers, by the devices on the network. And together, they're going to make our communication work.

So the high level plan is going to be that we take these computers and rather than put wires between every pair of them, we're going to connect them together into-- perhaps there's lots and lots of computers and many of them get connected to one of these boxes, which is a switch. And a switch may connect to other switches.

And some of these switches may have other computers attached to them. And then eventually you might get to other end computers. And when you build a network like this, a structure like this, this kind of a picture is called the network topology. A switch has one or more links attached to it. These links could be wires. They could be shared things like-- like this thing here is a switch.

It has no visible links, but it probably has one wire link connecting it via ethernet to the rest of the MIT campus. And out here lots of computers right now are connected to it. It gives the illusion that each of your computers has a separate link to the switch. And we look at how that illusion is maintained and done next time, next lecture.

But this is an example of a switch, probably the world's-- you know, this thing is made, I think, by Cisco. So they charge $600 or $800 for it. But really, you can buy it for $40. When you put the word "enterprise" next to anything you sell, you can mark up the price. But anyway, the world's cheapest switches are on Wi-Fi access points.

So you connect the stuff together into a topology. And the job of the switch is to look at messages that come in from these links and figure out what to do with those messages and make sure that together they coordinate to get messages to the destinations to which you wish to send those messages.

So here's a picture that I got today from MIT's ISNT, which is a picture of MIT'S network. So I just want to give you a sense for what this looks like for a campus like MIT. So the first thing to notice is that this is actually-- it's got some redundancy built in. You don't see it in the picture.

But really what's going on here is that we have these two routers here. In the context of the internet, these switches are also called routers. It's taken me 10 years to pronounce it router because where I was brought up, they pronounced it "rooter." And many people say that. But in the US, they say "router."

So anyway, these routers here, there are two backbone routers. And they're actually-- each of these guys, these other routers in these different buildings, are connected, actually, to both of these. So the idea here is that if one of those links were to fail or if one of these routers were to fail, the other guy would take over and handle this traffic.

Under normal conditions traffic is kind of balanced between these two different routers. So some of these computers-- some of these other routers are connected to one of them. Some of the other routers are connected to the other. And together they work to provide connectivity.

These backbone routers get connected to these things that are called external routers, which are routers that connect to various other networks and internet service providers that MIT uses. MIT is extremely well connected. The amount of bandwidth coming in and out, as you might have noticed doing, I don't know, bittorent or whatever the cool people do these days with networks, is phenomenal.

MIT commercially uses Sprint, which is an internet service provider, uses level three, which is probably the biggest internet service provider in the US. This thing called [INAUDIBLE] tech is-- I found is that-- so MIT now does telephony through the internet. So it's voice over IP as opposed to the old telephone system. So a lot of that voice traffic goes through that network service provider.

Other things here-- this NOX is-- I think it stands for the Northeast Crossroads or something like that. It connects to a network called the internet two, which is a network connecting many universities in the US. And it's a very, very high bandwidth network. And so if you were to communicate with, say, a Stanford or something like that, it wouldn't go over the public internet. It goes over a network that's essentially not commercially paid for but is a private network connecting different universities.

And it has a connection to Comcast. So many people who have Comcast in their homes in this area tend to have good-- or are supposed to, in theory, have good delay, low delay to MIT. Out here on this side, MIT is connected to other research and education networks. It has high connectivity to fermilab and to [INAUDIBLE], because I'm assuming there's a huge amount of data flowing because of things like the LFC experiments. They send terabytes or petabytes of data back and forth. So you need high bandwidth. So they have their own network connection to do that.

This NLR is something called the National Lambda Rail, which is another high speed network connecting a bunch of East Coast universities. And then out here on the edges, you have MIT connecting to other-- out here-- other internet service providers. This thing here is funny. It's called Big Ape, which is actually-- its called the Big Apple peering exchange.

It's this place in New York City where a lot of people-- a lot of companies and internet service providers have gotten together. And you can just connect to other networks. So MIT connects to, I think, 13 other networks on a non-payment basis. Whereas to internet service providers you have to pay money, you can peer with other networks essentially on a bilateral agreement. So I carry your traffic, you carry my traffic.

So it turns out that out in New York, there is this building where a lot of these different networks have gotten together. And MIT is one among those networks. So it has extremely good connectivity. But you can see that already MIT is a tiny campus. And already it's got such rich connectivity to the rest of the internet. I guess as far as college campuses go, it's a big campus.

But still, in the grand scale of the internet, it's a tiny thing. And you can already see that there's so much complexity and so many things going on inside the network. So the question is, how does this network get designed?

And the main idea that I want to get at today is this idea of packets and packet switching. So the design principle that's used in communication networks is this idea of packets and packet switching. There are some special rules-- simple, special rules that you have to follow to allow these switches to send messages back and forth. And in fact, these are fairly obvious rules.

But what's remarkable about them is how simple they are. And they can work. The main idea is that you take your message and you have to decide who it needs to be sent to. And you have to decide who it's coming from. So if I decide that I want to send a message to you in this network, my computer and your computer have to somehow have names associated with them. And in the context of packet switched networks, these names that we associate with-- ideally, these names should be associated with computers. But they turn out to be names that are associated with the link that you use from your computer to send these messages.

These names are called addresses. So very concretely, if I have a computer here, my computer may have a name. But this computer here has two or three different links coming out of it. If I connect this-- even this thing here or this ethernet link to the USB port here and I connect a cable to it, that's one link. The Wi-Fi on this is another link. If I turn the Bluetooth on and use that, it's a third link.

Each of those links has a different name. The name here is equivalent to an address. Each of these things is an address. So when I send a packet, I have to tell you my address. And similarly, if I want to send someone else, some other computer, a packet, I have to specify the address that I wish to send it to. So that's the first rule of packet switching. It's specify an address-- in particular, specify a destination address. And you specify a source address.

Now, the idea is once I specify the addresses and I construct a message, my message has some bits in it. Maybe it's a file. Maybe it's a piece of video or whatever. I add something to that message, which I call the header. The header has a bunch of fields in it specifying something about what should be done with the message.

But the only two important things here-- there's three or four things that you need. But the non-negotiable part that you need is a part of this address-- part of this header should specify the destination address. There's other parts of it that specify the source address, as well.

The basic structure is very simple. I send a message in which I specify a destination address. And the job-- and my job is done as the source for the time being. I send it to some switch. I'm connected to a bunch of switches. My computer picks a switch to send it to. The switch it picks is typically the switch that that link is connected to.

So if I am connected right now through ethernet and Wi-Fi, there's some rule on my computer that decides whether to use ethernet or Wi-Fi. And let's say it decides to use Wi-Fi. It sends this thing, this message, with this destination address to that access point. And that's the first switch it goes to.

And then it becomes the switch's job to figure out how to get this message to the actual destination. This combination of a header that includes the destination address and some number of bits that corresponds to the message, this entire bag of bits is called a packet. For something technically to be considered a packet, it needs to have an address on it. Or it needs to have something that's equivalent to an address on it that then allows the rest of the network to decide how to send that packet onward.

This is a lot like the way the post office works. When you deliver-- you write your letter. You write who it's from. And you write who it's to. You put it in the mailbox. Your job is done. And maybe at some later point, if it's registered post, you get an acknowledgment that the other guy received the message.

Packet switch networks are very much like that. They just work a little bit faster. Now, why is this idea good? Now, the reason this idea is good is that it's extremely robust at dealing with failures, at least in theory, because it becomes the job of the switches and the network to talk to each other and run some sort of algorithm between each other that allows them to always construct and maintain some information that allows them to always, no matter what the failures are, as long as there is some path that takes you from here to there in the network, regardless of failure, as long as the underlying topology allows you at least one path to get between one place to another, the switches figure that out.

And if you want to make a network more reliable, you add more switches and more links. And you figure out how to make it reliable. The end points and nothing else have to really bother with that problem. And you can take portions of the network that are unreliable and add some redundancy to it, add more pads to it, and run some other algorithm that allows the switches to figure out how to divert, how to route packets, or how to move these messages across.

And this idea is a brilliant idea. It looks completely obvious in retrospect, like all brilliant ideas. But it's actually quite recent. I think they celebrated its 50th anniversary quite recently. In 1959, Paul Baran, who was at the RAND Corporation at the time, wrote one or two-- you know, it's not often you can call a paper seminal. This is seminal. This is really important.

It just changed the way communication worked. His paper is called on distributed communications, introduction to-- the first one was "Introduction to Distributed Communication Networks," where he looked at various ways you could design these network topologies and completely theoretically argued that this design would allow you to build a network that could withstand various kinds of failures-- in particular, even adversarial failures caused by enemy attacks.

And the second part of the story with these messages that are in packets is he said that if I want to communicate a large amount of data, what you should do is break it up into smaller pieces. So you take a message-- if you have a big file to transfer, don't put it in one big packet. But instead, you break it up into smaller pieces and send each piece into the network.

So a big file gets broken up into many packets. Each packet becomes an independent, atomic unit of delivery. Packets could be sent along very different paths, in principle, between any point in the network and any other point in the network. And at the other end, packets could arrive along different paths. And as long as there's some working path, it's the job of the network to figure out how to get those packets through. That's the basic idea.

So the first one is this idea of using an address on messages. The second one is the idea of breaking it up into packets. And in particular, these packets could all take arbitrary paths. The sources and the destinations don't determine the path. The switches determine the paths that you have to use, using some algorithms that we're going to be studying.

So is the idea clear? Does everybody understand kind of what a packet switched network is? The textbook-- the notes also talk about other ways of doing it. The other big way of doing it, which predates this, was what was done in the Bell Telephone network. It's called circuit switching. It's a different idea. I'm not going to talk about in lecture. You can read about it. It's important stuff to read about, but mostly cultural at this point, because almost every network is packet switched today.

So any questions about this idea? It's pretty simple. OK. So here's an example of the world's simplest packet header. This is the 6.02 reference design. So for the labs and everything else, this is the packet header we're going to be using. It has just four fields-- a destination address, which specifies where the packets should be sent.

It has something called the hop limit, which I will talk about in a couple of lectures from now as to why we need it. It has a source address, mainly because when I receive a message-- when this computer receives a message from someone, it often wants to send a message back in response. And having the source address allows it to send a message back to the person who sent the message. It's just for two way communication.

And it has a length. And the reason for having the length is convenience. You kind of know once the header is done, how many bits do you need? Or how big is the actual data corresponding to the packet? It's also called the payload. How big is the payload in the packet?

Now, real world packet header is a little more complicated. Just for concreteness, this is what IP version 6, which is the version of IP everybody's trying to move to, the internet protocol, looks like. It has the destination and source addresses. It has the hop limit. It has the length. And it's got a few other things that we're not going to worry about. They have to do with allowing switches to prioritize certain kinds of packets so that-- I guess things like if you were doing Skype or voice telephony, you might want to schedule those packets differently in the switch so you get low delay.

Or if you were-- maybe the CEO's packets get higher priority, whatever. You could come up with policies on deciding how you switch these-- how you schedule these packets. So that's the main idea in packet switching.

For the rest of today, I actually want to talk about two performance metrics that people use to evaluate how well a packet switching network is doing in terms of how properties that users care about. And I want to also explain to you why this idea works-- like, this idea that nodes just send data. All these nodes are sharing a communication medium-- I'm sorry. Sharing resources in the switch.

So this node can send packets. This node can send packets. This node can send packets. And the switch must have a plan in mind to-- let's say that all these packets are going to some destination and have to go on this link. This switch must have a plan in mind for deciding how to take all these packets that are coming in and sending them along this link.

I mean, for example, what happens if packets come too fast for the switch to handle? The speed of these links when they all simultaneously send packets could be bigger than the speed of the link going this way. What does the switch do with that? Does it just drop the packets? Does it hold onto them for some time? What does it actually do?

And I want to do this first with a very simple picture that tries to get at why this idea really, really actually works. This idea that makes packet switching work has a fancy name. It's called statistical multiplexing. So let me explain what that means.

Let's take it with a very simple picture. So let's say that you have a switch with one link coming out of it. And let's say that the speed of this link-- I need to get into some metrics here. So links are measured in terms of how quickly-- how quickly is the wrong word. In terms of the rate at which they can send data.

And there's another metric, which is the delay of the link. So I'll get to both of these more carefully in a bit. But the important thing right now I want to keep in mind is the rate of the link. This is the rate at which it can send bits per second. It's a measure of throughput. So it's typically measured in bits per second.

So let me actually imagine that the rate of this link is one megabyte per second, which is 10 to the 6, which is a million bytes per second, or about 10 million bits per second. Let's imagine a simple network that looks like this. Let's imagine that all these links are also coming in at 1 megabyte per second.

If somebody came and told you, here's the design of my network. I have a switch. It's connected to three computers, each of which can-- is connected with a link whose maximum speed is one megabyte per second. And this switch is going to connect to something else downstream, maybe another switch, and it goes somewhere else. And the speed of this link is one megabyte per second. Is this a good network design?

How would you go about assessing that question? Is this good or bad? How would you know? Yes?

AUDIENCE: [INAUDIBLE]

PROFESSOR: Right. So let me ask this before we answer this question. Let's say this was 10 megabytes per second. Is this a good network design? It is. You're paying too much, though, because I mean, really, this link is too fast for the amount of load that is coming in. But yeah, you know, it's a reasonable network design.

But the real question is, if it's one here, is it a good network design? And the answer, as the gentleman here pointed out, is it really depends on how much traffic or how many packets per second or bits per second these different computers are going to be sending. Let's say that they all actually send-- when they send traffic, they send at one megabyte per second. And when they don't send traffic, they're quiet.

How would you determine whether this is a good network design, whether this works or not? Like, in practice, on average, how often can each of these guys be sending before you determine that this is probably not-- this network isn't going to work. Yeah.

AUDIENCE: [INAUDIBLE].

PROFESSOR: Right. And they may or may not be equal. Ideally, what you'd like is just to make sure that over some window of time, they sent slower than the rate at which this link can ship packets. Now, the reason why packet switching works is that when you build a network like this and you scan it out to bigger numbers, it turns out to be extremely unlikely that everybody using the network exercises the network at exactly the same time.

I mean, a bunch of people might have their computer on. But if you think about how it's used, you click on a link and you get a bunch of stuff showing up. And then you click on-- you read it for some time. You click on a link and something else shows up.

Or if you're watching a video stream, video is compressed. So if the scene changes very often, you end up using a lot more of the-- in terms of the bitrate. But then every once in a while, it's one of these old Russian movies where nothing's changing for 10 minutes. And it's very heavily compressed.

And then you get to Schwarzenegger and it's blowing your bandwidth limit. So I mean, it's kind of like that. Traffic is bursty. So when traffic arrives in bursts and the users are not all highly correlated with each other-- I mean, from time to time, you do get these correlations. These are called flash crowds. Presumably this happened last night. Everybody is hitting refresh on the New York Times website.

And presumably what's happening there, of course, is that these websites really know what they're doing. So they've actually provisioned with the expectation that starting from 8:00 PM, everybody is sitting there glued. Nothing's changing, but everybody's hitting reload.

And they've designed this network-- they've provisioned their network to allow for people to get the answers they want or the results they want to see. So here's some pictures. So what I did was I took-- I sniffed on the traffic in this room. So here's the kind of stuff that you see.

So this is the traffic in this room during lecture. Now, this is actually not this semester. But I would assume that it's fairly typical. I should also say this was during-- well, I don't want to say. The x-axis in these pictures is time. The y-axis is the number of bytes that was sent.

So you can see that what I've done on top is I've broken time into 10 millisecond windows. So initially on top, it's every 10 milliseconds I just count the total number of bits-- actually, total number of bytes that was sent. Now, you can't read the scale on the y-axis on top. But on the top curve, it goes up to 200,000 bytes in a small 10 millisecond window.

Then the curve down here does the same thing. But I've picked 100 millisecond window. Now you can see that what has happened when you've picked a bigger window of time? Has it become smoother or less smoother? What can you say about it? It's become a little smoother. But surely there still are these peaks. The bursts do become smoother. But they don't completely disappear.

And what's remarkable about network traffic is that these bursts never completely disappear, but they do get a little smoother as you aggregate over more time. Over 100 millisecond windows, that's what it looks like. Over one second window, it looks smoother. But you can actually see that from time to time, there are these big bursts that take up a lot of the-- that end up over any window of time that you expand out, there's still some probability with which you'll see a big burst of traffic showing up in that window.

That's kind of a nice and noteworthy characteristic of kind of real world data traffic. In fact, even when you go to 10 second windows, it says, look, I'm looking at 10 seconds at a time. You get stuff that looks like this.

MIT runs a website you can get access to using your web certificates. It's called mrtg.mit.edu. You can actually go to this website and you can see, for different switches, including ones in your dorm or wherever you're living if you live on campus, you can actually look at the statistics from your router. They do this on a per switch level. It's kind of interesting to see when people use this network and when they don't.

I think an interesting characteristic of MIT's networks is it turns out if you look at some of the dawn network traffic, it peaks at between 1:00 and 3:00 or 1:00 and 4:00 in the morning, which is probably good, because honestly, I think MIT should negotiate preferential pricing with ISPs, because no one else is using those ISP networks at that time.

So it would be actually-- it turns out I learned that the Amazon Kindle kind of does that. When you do your newspaper subscriptions, they actually send it through wireless networks, through this commercial 3G and 4G wireless networks. And I believe that what they do is they send it to you in the middle of the night when not many people other than at MIT are using those networks.

So you could take advantage of some of these time varying properties [INAUDIBLE] doing it. So why did I tell you this story? The same thing-- I showed you these time windows. The same thing applies when you bring many, many users together. The odds that we all are going to click on some link at exactly the same time and all of us cause a burst of traffic to happen exactly at the same time is extremely small.

Now, it can happen if there's an adversary in the network. If there are bad guys-- and how many of you have heard of denial of service attacks? Yeah, DDoS, Distributed Denial of Service attacks. I understand if you know Russian you get an edge in doing it. So these things are launched because they commandeer a whole bunch of machines and they coordinate an attack. They destroy the assumptions that make statistical multiplexing work because the normal assumption is people are not exercising the network at the same time. So you're not attacking some website or whatever at the same time.

But if you coordinate an attack, then you make that assumption not hold, causing congestion to happen, causing traffic to exceed what your network link can support. But under normal, non-adversarial conditions, the assumption is that people are randomly gaining access to the network, which means that you can actually get away with the design of a network that looks like this as long as you study statistics like the average amount of traffic.

Like, on average, the guy is not going to be sending more than-- this node is not going to be sending more than a certain amount of traffic when measured over some period of time. What happens when people send traffic in a burst? What happens when, from time to time, in fact, you see these bursts of traffic, right? You look at this picture here. You do it over a one second window or a 100 millisecond window and you see these big peaks of traffic.

Lots of bytes at 100 millisecond window. What that really means is that this switch here is going to be getting traffic from different users that probably exceeds-- you know, is perhaps the sum of all of the input links. So it's a large amount of traffic. If you have a design like this, something's got to give, because you're getting water or packets coming in at one megabyte per second times three. And you've got a link that can only send one megabyte per second.

So what can you do? What can the switch do?

AUDIENCE: [INAUDIBLE]

PROFESSOR: The easiest thing it can do is just drop it. Just say, you know what? Just drop it. You laugh, but I'm telling you, sometimes dropping it and letting the end point deal with it is a better strategy than holding onto it and simply keeping it in line. It's like, you've got to be careful, right?

I like the idea of storing it. But for how long do you store it? How much do you store? For example, if I look at that burst of traffic here and I have a network like this and I look at this big burst of traffic here, over a 10 second window, I'm seeing traffic that's probably, in this example, perhaps 10 or 100 times bigger than the average.

The average is sitting down somewhere. And maybe this is 10 times the average. The peak to average ratio might be 10 to 1 or 20 to 1. So how much should you store inside the switch? If you were designing a network and I told you, well, all right, good idea. Why don't you store the packets. You're going to put these packets into a data structure called a queue, right?

Packets come in. Packets go out. Packets go out whenever the link is able to send packets. You keep shipping packets out. In the meantime, traffic's coming faster than you can handle. You're going to put stuff in a queue. How much? Do you want to keep everything? If you did, you'd be like Disney World, because they have these lines that go forever, and nothing's moving and everybody just piles on the end of the line.

This is a tough question. We're going to answer this question somewhat. There's no single, easy answer to this question. But the rule of thumb that I'm going to have you keep in mind now is you're probably going to keep between 10 milliseconds and 100 milliseconds worth of traffic. I'll get to why later. For now, it's some small amount of time worth-- amount of traffic.

The reason why you need this queue is to absorb a burst of traffic that you're not able to immediately send. But the important principle in a packet switch network is, you need a queue, but they're a necessary evil, because the only thing that the queue is doing for you is absorbing the burst. But the only thing-- the bad thing that it's doing for you is adding delay.

Just because you have a queue, the network ain't going to move faster. The network's moving-- the link's moving at the same speed whether you have a queue or not. The only thing the queue is doing is it absorbs a burst so that whenever the network link is able to send packets, you can ship packets from the queue and you don't want to drop too many packets.

Now, if you're lucky, the size of the queue is enough to absorb all of the burst. And then the traffic eases and you get to send the rest. But if you're unlucky, the queue overflows and you drop some packets. And then the endpoints have to somehow deal with it.

So what are the things we've looked at? Packet switch networks as defined by a header, which includes the destination address. The way the network works is that the sources just ship a packet with the header that includes the destination address. The switches somehow are going to figure out how to ship-- how to get those packets to the destination.

The reason why this stuff works is because of the statistical multiplexing. And finally, the reason we need a queue in a packet switch network is to absorb these bursts. So what I want to do in the remaining six or seven minutes is to tell you about the other metric by which we're going to evaluate our networks.

The first metric I introduced already is the rate of a link. When you have links of different rates, you can also define the rate for an actual communication. When a source sends a packet to a destination, you can measure the rate at which bits are arriving at the destination. That's the throughput of the data transfer of the bit rate.

The other metric we're going to care a lot about is called the delay. The fancy term for delay is latency. I really don't know why they have two terms. But you know, from time to time, people use the word delay or latency.

And by the way, I'm going to try hard to use the word rate here or bitrate or throughput. Often you see the word bandwidth, like oh, my bandwidth is 10 megabits per second. And that's actually fine to use, except it's confusing in a real communication system because we're going to-- we've already used the word bandwidth to refer to a frequency. And so we've already said the bandwidth is defined in terms of, say, Hertz or something like that.

And it's just a little confusing to also use bandwidth for rate. So we're going to try to use words like bitrate and throughput to refer to bits per second. So delay is measured in seconds or milliseconds or microseconds. And what we want is you have a source that sends a packet or set of packets-- let's say a single packet to a receiver going through a network of switches.

And I want to ask-- if I send a packet at some point in time, let's say at time 0, when does that package reach the receiver? That's the delay for a single packet. So I just want to explain to you how to calculate this or how to measure this. So let's say that the packet has a size of L bits.

So what does the answer depend on? Let's take an even simpler example. Let's say that I have a sender. I have a receiver. I have one link between them. No switches. And the packet has size L bits. I send a packet at time 0. When does the last bit of the packet show up at the receiver? Yes?

AUDIENCE: [INAUDIBLE]

PROFESSOR: Good. So I need to define this thing here. Let's say that the bitrate of this link is c bits per second. So I have l bits and I have a link that can send packets at c bits per second. Therefore, something here should be l divided by c second. That is from the moment I start shipping these bits, from the time delay between when the first bit arrives-- first bit arrives at the receiver and the last bit arrives at the receiver, that time distance or time difference is c divided by l-- sorry, l divided by c seconds.

Because I ship these bits. These bits go back to back over the link. If I look at when the first bit arrives and I look at when the last bit arrives, that time difference is the spacing-- the time difference between any two bits showing up at the receiver is 1 over c, seconds, because if the link can send c bits per second, any two bits are separated apart by 1 over c seconds.

Therefore, from the time at which the first bit arrives to the time at which the last bit arrives, that distance is l over c. That difference is l over c seconds. This l over c has a name associated with it. This is called the transmission delay.

Now let's say I want to send just one bit. I have to now-- I send a bit at some point in time. And that bit shows up some point in the future, because it can't show up immediately. If it did, we'd probably have to change the laws of physics because speed of light is no longer valid as a finite limit.

So what is the time between when I send the first bit and when the first bit shows up here? What does that depend on? Like, let's think I want to communicate to the moon. I send one bit of information. I put it out onto the-- or even one sample. I put it out on the radio or whatever. How long before it gets to the moon?

AUDIENCE: [INAUDIBLE]

PROFESSOR: Depends on what? Does it depend on the rate at which I can communicate? No. What does it depend on?

AUDIENCE: [INAUDIBLE].

PROFESSOR: Sorry? You guys said it. What is it?

AUDIENCE: [INAUDIBLE].

PROFESSOR: Speed, and the speed of what?

AUDIENCE: [INAUDIBLE].

PROFESSOR: It's the speed of light in that medium, or speed of whatever the signal you use is. If it's acoustic, then it's the speed of sound over the medium. So it depends on the distance and it depends on a speed at which a signal can propagate through that communication medium-- for example, the speed of light. So the distance is b and the speed of the communication medium is, let's say, v.

That thing is called the propagation delay. So let me organize this properly so I'm not confusing everybody with these different terms. So so far we've hit two sources of delay. The first source of delay, which I said second, is the propagation delay. This is the time it takes for the first bit to get to the other side. It depends on the speed at which a signal propagates through the medium and the distance between sender and receiver.

So sound travels at one foot per millisecond, I think, roughly something like that. So if I'm doing acoustic, that dictates the propagation delay. The second delay is the transmission delay, which depends on this l over c. The third delay is whatever processing delays there are. That, for example, is when a switch gets a packet, it has to look at the packet's header, figure out the destination, do something to that.

There's some competition time that the switches have to work with. That delay is called the processing delay. This is purely some sort of computing delay. And it's usually very, very small. And the fourth delay is the queuing delay, because it could be that you get these packets in and they have to sit behind in a queue. And that imposes a delay in communication. So that's called the queuing delay.

And it's usually a very variable source of delay. On many networks, these other delays are constant-- not always, but generally constant. The transmission delay may or may not be constant. But usually these are more constant. The queuing delay is not a constant delay. And the actual delays that you experience when you click on a link, there's lots of reasons why the website is slow. But these are a principle, dominant factor in many, many cases.

So we'll pick up on this next week after the quiz two stuff. You deal with quiz two and p set 6. And we'll continue with multi-hop networks.