Hello, and welcome back. I just wanted to give you sort of a sense of the actual physical experience of connecting and communicating and computing in the 60s and the 70s. The 70s was when I got my start and the lucky people got to use teletype, like was being used in that video, and other people used punch cards. You also heard the squealing sound of the data being converted into sound and back and forth. You know the key goal was there would be, if you were lucky, one computer within a 20-mile radius of where you were sitting so you could use a local phone call and you could be on all day and do things all day long and that was really exciting and a lot of fun. And this was sort of a common, if you were sort of, you know, today you have a $2,000 laptop, the fancy people had these teletypes right in their office because then they could conveniently sort of do computation, and not have to go somewhere to do that computation. So that's pretty exciting. So dial-up was kind of like the way the campus operated. But you could also do data transfer with leased lines. And the typical thing about leased lines is there the phone company that's going between two cities digs a hole and puts a cable in and has some number of copper wires in between those cities. This is back then, of course it's fiber optic now, but back then it was copper. And every time you would make a call between those two cities, it would have to find a free piece of wire and connect it up so that your call, the audio of your call, would go through that wire. And if you wanted to, you could pay them to lease one of those pieces of wire. It meant that people couldn't use that wire for phone calls. So you would sort of take it out of service. And if they had 500 wires between two cities and you leased one of them, then they had 499 wires. And so it was rather expensive. And really very importantly, the cost was based on distance, right? A mile, versus five miles, versus 20 miles, versus 100 miles, the cost would kind of go up linear based on distance. And so that's, that's a key thing that distance is important in these very limited-resource copper wires where you had to dedicate a wire either to a phone call or to data. And so, we ended up evolving, in the academic world what we called store and forward networking, with the sole purpose of compromising everything so that we would keep our cost that we paid for our phone lines to a minimum. We wanted to communicate in academia with people all around the country and all around the world, so we had to keep the cost low. And so we would lease a leased line, you know, so here would be us sitting with terminals in our offices and we would use dial-up to get connected and so this might be a few miles, like 1 to 2 miles, or 1 to 2 kilometers. And that's what you had to, you had to live near a computer or have an office near a computer and then you would use the local telephone network to dial in to do your work. And then there would be one connection out the back of that computer to another computer that would also have users on it, and then other computers with users on it, other computers with users on it. So this might, for example, be Michigan, this might be Stanford. Stanford would have a computer, Michigan would have a computer. The Stanford people would be connected to the Stanford computer. Stanford would have one little connection off its back end and to the rest of the world. So you sitting here want to talk to somebody sitting here, So this is how it worked. You're sort of always connected so your data would be inside, you know, you type an email into the computer and then you would say, send that out to my colleague at Stanford, and so the problem is everyone else was sending and so let's say for example that somebody sent a pretty big thing. Big purple circle is what they're sending. And then somebody next to you an office down sends a kind of medium-sized orange circle. And they're sitting there being stored in the local computer. And then you finally finish typing your email message and it's kind of a small green circle. And now, the problem is, you're in a line. The way this worked is the software would keep a queue or a line of those who were going to use the line, and then it would sort of start streaming this stuff out. And once it started, it just kept doing the same file, over and over and over. Now if it died, it would just start from the beginning again. And so, it takes some time for that thing to move across the network. And then when it moved across the network, the next message in line would start to be sent across the network. And it would use that link come on, finish up, there we go. Okay. It takes a while for these things to move across the link. And then finally, and this could be ten minutes later, finally it was your turn. And your stuff would work its way through the network, and get to the next computer. The problem is, once it's in that computer, you'd face the same problem, because if all these messages are going from Michigan, oops, forgot to hit the button thing, from Michigan to Stanford and they're all on the way, they got to go through all these links, because there wasn't a direct connection, because the direct connection to Stanford would be very expensive. And so we find ourselves in a situation where if you're stored, you sat on these computers. And if there was an outage of a network, or say this one, this might be hours. You might be sitting on this computer for hours, on their disk drive, right? Not even in their memory, you would be sitting on their disk drive for an hour, and then finally this would come back or maybe this computer was down. They would come back up and then the data would start flowing again. So it was haphazard. I keeping telling you, it was awesome, it was just slow, it was awesome but slow. So don't, don't, don't feel sorry for us, we loved it, we enjoyed it, it was great talking to colleagues all over the world. So we ended up with a network architecture that encouraged more hops, which means it encouraged more latency. It encouraged the likelihood of getting stuck behind something large as it worked its way through the network. So if, for example, we were going to send a message from East Lansing to, say, the East Coast somewhere, and we would have two connections maybe. We would have a connection between Michigan State University in East Lansing and Ann Arbor, and then we'd have a, the data would get stored and forwarded in Ann Arbor and then it would get further sent to Cleveland. And, if you think about it, the wire between Ann Arbor and Cleveland goes like this. Right? They probably buried wires under the ground. And if we could actually convince Toledo, the cost of the big wire versus the cost of the two shorter wires, the cost of the two shorter wires is almost exactly the cost of the big wire, because it's not really a big wire. And so if we can convince Toledo to join our little club, then we don't increase the cost of our communications because we're, it's about the same, right? The wire length is about the same. But we've got one more school for the same cost. And if you keep doing that, and you keep saying oh, well let's put a school here, and put a school here, and put a school here, in the middle of the lake, and put a school here, in the middle of a forest. The economics said that you could connect more schools with effectively fixed cost by shortening the distance every time you made a connection. And sometimes they would sort of make two connections. But the way it often worked was, from the perspective of this whole thing, is the data would sort of tend to go, you know, up to some central location and then kind of fan back out from the central location. And, and so these, it, there wasn't a lot of redundant links in this whole situation. So we find ourselves in a situation where we can save more money, saving money by just simply adding hops. So in this environment we had a lot of email. Back in those days we didn't have a lot of images. Computers, you know, barely could do upper and lower case sometimes. It was impressive when we finally got to upper/lower case, let alone images. And so for the longest time everything we did was very text-oriented. Sometimes we would send small files like programs to each other, but it was either text. And these days, those are tiny, it's almost like SMS, right? It's almost like the size of an SMS message was the size of a typical mail message back in those days. Images, we didn't have computers that could even display them and so it hardly mattered. So, you focused your life on this one computer within a 20-mile radius and it had this connection to like, a snake-like connection that sort of went over hill and dale and through somewhere and it finally got to Stanford or wherever your mail had to go. But again, it was awesome to be able to sit at a keyboard and talk to people all over the world, even though it took four hours. We didn't send as much email back then. And a number of networks came up. One of them that became sort of pretty widely used was a thing called Bitnet, and it was where everything kind of came back to Princeton was one of the main hubs of Bitnet. And it worked really well, and there was a way to say, oh, I need one more school, and we'd go find the ones that are closest and we'd make the connection. And so that's pretty much how the average academic saw networking. One common campus computer and sort of this weird, slow, store-and-forward networking that worked well enough. But during that exact same time, from the 1960s to the 1980s, the US Department of Defense was investing in a research network called ARPANET. And ARPANET was funded by the military, ARPA, Defense Advanced Research Projects Agency. And later in the lecture we'll meet Vint Cerf, who will tell the story much better that I can tell it, but I'll just tell you a short version right now. A lot of people wonder why the Department of Defense started this project and a lot of people say, oh it's because of fear of nuclear war. And the project was very long, and there were various motivations throughout the various phases of the effort. But, if, based on what I've been told and what I've read, I think it's safe to say that the primary motivation was to improve the use of their computing equipment that they were using for military purposes, make it easier to access them, make it so people didn't have to travel as much. It made it so that people could work from their office on many different computers. And also so that people could actually talk more effectively, so they could send email real fast, so that the email would move faster for military people. So the first thing is really kind of an end user focus to make them more useful to people and get people working together more effectively. That was the first kind of heavy motivation. The second motivation was, actually had to do with reliably, reliability and redundancy and resistance to partial failure. And that really wasn't so much about nuclear attack, that was more about battlefield attack. So the notion that once you start having all these links and you make them wireless, and you put them in trailers on a battlefield, and, you know, you've got a few hundred miles and the data's moving back and forth. Then we have to worry about, in a battlefield situation, one of those trailers might get hit. And how would you keep the network running if one of those trailers got hit? So, the notion that we have sort of a whole nation and we are worried about communications, I'm sure there was some worry about that, but it wasn't really the main reason. I mean, the exciting thing to me is the mean reason was a very people-centered reason, of people working more effectively. But this was a rather exclusive club, rather exclusive network, because it was only for the people who were either military, or funded to build it. So in 1969 there were four hosts on it. Again, that's research. And these were leased lines, the same ones we were all using to do our email, and they were expensive, very expensive. But because it was a large grant, they just paid it because the research was not about the money. The research was if you have these connections, what would be the best way to use them and how to deal with redundancies, and how to deal with multiple paths to the same place. All that stuff is interesting research questions that computer scientists spent many years conceiving of. And so by 1972, it looks like we got about 20. We got a couple of cross-country links and multiple connections, and this looks like a great testbed to see, you know, so all of a sudden this part goes down, how quickly can we reroute around the outage. And literally, these things these days reroute around outages in far less than a second, and so that's really impressive. Our current Internet owes its history to the research that was done in the 1960s and the 1970s. But what was fundamentally different between the store-and-forward networks of Bitnet and this ARPANET research network was the notion of packet switching. So the, it's a real simple concept. It just takes a little more complex software to solve. The store-and-forward network would start sending data across the link and then keep sending it until it was done. That was seen to be very efficient. You didn't want to like, you wanted to use it as fast as you can and then put the next one out, and put the next one out, and put the next one out. It was really simple and it dealt with outages in a simple manner by storing them all locally on the disk. But what if instead you made it so you broke every message Let me see if I can even draw this. I should probably make a slide about this. So, if there's a network here, and here's my computer and it's got a network connection, and it's got one really big message, broken into pieces. Many pieces. And it sends the pieces one at a time. If you show up with a really short message with only three pieces, all you have to do is wait for one piece to go and then your piece goes in and then you share for a while. Right. You share for a while and then yours have made it through because you only have three packets. This has like 1,000 packets. And then once your message is through, they resume sending this data in order. And so you were able to sneak and bypass the traffic jam that was this large amount of data. And so, that's the idea of packets. And packets are these chunks to say, what we're going to send is a piece, and then at the end of that we're going to maybe send a piece of a different message. It was allowing simultaneously multiple messages to be in flight at the same time. That's packet switching. And what happened then is we also ended up with these special-purpose computers called routers. They're still computers, but they weren't doing storing in the same way. They were just forwarding, they weren't store-and-forward, they were merely forwarding. So we'll get back to that in a second. So my favorite analogy to talk about how packets work is postcards. So let's say that I want to send a 30-character message to my friend Daphne at Stanford, but all I have is 10-character postcards. So, off I go. I break my message into three bits of 10 characters. I write each piece on a different postcard. I address with a from and a to address, from Chuck to Daphne, and then I give a sequence number so that when she gets the postcards she knows what order to put them back together. So I have to label each of these. And these are fixed width, fixed length. They, you know, it's like a packet, right? I'm breaking a long message that might be very long into nothing, so that each piece is a certain size so that we can all share it, right? And so then what I do is I send these, I put them all in my mailbox. And then I wait and this magical thing called the Post Office picks them up, puts them in buildings, people sort them. They end up on trucks, they end up on planes, on trains, on donkeys, by hand. And each of my postcards might take a different route. I mean one of my postcards, I'll show you on a map here, now one of my postcards, nope not that one, let's do that. One of my postcards, you know, goes from Michigan to Chicago to Kansas City to San Francisco. Another of my postcards goes from Michigan, to Chicago, to Dallas, to Denver, to Kansas City, to Chicago, to San Francisco. And my third postcard goes really crazy, it goes to Cleveland, then it goes to Atlanta, then it goes to Washington D.C. And then it goes to Chicago, and then it goes to Kansas City, and then it makes it to San Francisco. Now the fact that they took different paths and they might not even arrive in order, some might get past each other, they might get stuck somewhere. It doesn't matter, because each one of these has been labelled both with the from and the to destination. So each of these intermediate locations doesn't have to get it to the final destination, they just have to get it closer. They make choices and even if they make the wrong choice, it can be sort of dealt with one way or the other, okay? So, this is some big mystery, it's called the Post Office. It just takes these little cards with labels and moves them. It doesn't know if that's a YouTube video or if it's an email, it doesn't really care, it just has these little chunks to move around that have from and to addresses. And that's the essence of the network, the Internet, the cloud. That's why we draw this picture, you'll see like, ooh, it's a cloud, and that's because it's, don't worry about what's inside here, it's all super mysterious and don't worry about it, it just comes out. So after all that happens, Daphne, who happens to have the exact same mailbox as I do, kind of rare. We both have a mailbox that's copyright Creative Commons. That's what's cool about this mailbox. At some point later these things start appearing. She goes like, whoa, looks like Chuck is sending me a note. But because of his limitation of postcards he's only sent me one. I know who it's from and I know who it's to, and I know that's the first of some number of messages. And then the next day out comes another one, because that was the one that sort of, went the more southerly route. And she goes, well I'm missing something, I'll just sit and wait and see what happens. And then finally, many, many days later, the one that took the circuitous, cir-, most circuitous, most roundabout route comes and now Daphne can reassemble the messages because she has the sequences. So she simply puts them back together. 1, 2, 3, boom. So she puts them back together, she has it, she sort of throws the post cards away and she has the ultimate final message. That's packets. Packets are breaking a big message into small parts, labeling each one of them individually, and then throwing them into the shared network. And so this is what it looks like. The Post Office in this is called a gateway. Okay. Come on. Gateway. Okay. So, that's a gateway. So, here's Michigan, here's Stanford. Stanford has a gateway too, that's like their Post Office. In the middle is the Post Office box. Right? And the Post Office has intermediate locations. And it has trucks and locations. These are links and routers. And messages can take different paths. Right? And then they arrive and they're reassembled. And we have, like, the ability to hook from home, and stuff like that. So there's a local area network, LAN, and there's this sort of like Internet, the network of networks. It's like the Post Office. And it still breaks things into packets, they still come out as packets, and then Daphne has to reassemble them on her computer to create the message. So, it, so the research network ARPANET solved a lot of engineering problems, and that was sort of what they did. So here is an example problem to solve. Now, none of the mailbox, none of the routers, none of the post offices, know exactly where the thing is going. And they don't transport it to the final destination. All they do is they transport it to the future, to a further down destination. But what if they get it wrong? What if one, this is like Michigan, this is Chicago, this is Dallas. And what if Michigan thinks sending to Chicago is a good idea? Chicago thinks sending to Dallas is a good idea. And then Dallas thinks sending it to Michigan is a good idea. Well, then Michigan's going to get it again and send it back to Chicago. And so then what you end up with is this situation where your packet, your data, is in a loop, right? This wouldn't be good for the Post Office and it's not good for the Internet. So, you have to say, how do we solve this problem when something's wrong, right? It's, you, you wish it were perfect, but it's not. And so this is the kind of research question, as to how to solve this kind of problem, and we'll talk more about this in a bit when we get into a little more technical detail. But I just wanted to sort of say, that's the kind of research and engineering that took literally 20 years, and four different versions of it, of the ARPANET to get right. And so, by the end of the 1970s there was quite a sophisticated network. Like I said, they'd rewritten it four times. It had gotten to be very sophisticated, it had been a good investment. They had been careful about understanding how to improve it each time they rebuilt it. And so it was really a fine working piece of software, and the people who used it at these research universities and at the military, it was kind of like a futuristic world, right, you could send email and a second later it would appear, right. It was really quick and everything was nice and you could even have instant message-like interactions where it went right then. And the problem was that this is a small group of people. This is maybe, looks like 60 or so. That was all the computers on the entire Internet, right? I mean now we have our cell phones and we have billions of them, right? But this is like 60. And so a real question is how did this go from 60 computers of a very narrow group to a much larger group. And the answer to that question is at Urbana-Champaign, Illinois. And so, at the same time that, this kind of goes back to Bletchley Park, right, where the computers were part of science. Throughout the 50s and 60s and 70s scientists, much like the military, were realizing computers were mighty useful to advance scientific research. And so the National Science Foundation would fund universities to buy computers, and they'd say give me ten million dollars to buy a computer. And another university would be like, give me ten million dollars to buy a computer. And then three years later the first university says, my computer is obsolete, I need another ten million dollars. Now the research questions were good research questions. And they were important to society. But the National Science Foundation got tired of giving ten million dollars to every, everybody who. Wait, hang on a sec, let me... As a matter of fact, I was part of this because I used to be a high-performance computer guy. This is a Convex C3800 supercomputer. I would be about this tall on this supercomputer, this is a lovely and very expensive model that I was given after, afterwards, and I wouldn't throw it away because this was from, like, 1987. And basically I wanted one of these terribly badly. Each one of these is about two million dollars, so this is like two, four, six, eight, ten million dollars. And I so badly wanted this, and I thought that I deserved a ten-million-dollar toy, and I could do such great research. But unfortunately everybody else wanted the exact same thing. And they were important, too. So the National Science Foundation said to themselves hey, this isn't going to work very well if I can't find my pen. You know, we're not going to be able to, we're going to make a network. How about we put a few of these things in, and then make a network and connect them together. Of course it's never as simple as that. So now we're going to meet Larry Smarr, at the National Center for Supercomputing Applications, N-C-S-A, at the University of Illinois Urbana-Champaign. And Larry was the director of NCSA and one of the many people, but one of the most instrumental people, in creating the national network that we now think of as the Internet, and getting it moving it from being a research project to being a project that we all, both academics and regular people, that we all can make really good use of. And so let's take a look at Larry Smarr.
