WEBVTT 1 00:00:00.120 --> 00:00:02.120 Right now. You know you're probably listening to this over 2 00:00:02.160 --> 00:00:05.400 a Wi Fi connection or maybe a cellular network. You 3 00:00:05.480 --> 00:00:09.839 hit play on your device and the audio just immediately 4 00:00:09.919 --> 00:00:11.519 started streaming right into your ears. 5 00:00:11.679 --> 00:00:13.400 Right. It feels completely seamless. 6 00:00:13.480 --> 00:00:16.039 Yeah, honestly, it feels like magic. I mean, we navigate 7 00:00:16.079 --> 00:00:21.760 our entire digital lives assuming there's just this I don't know, this, 8 00:00:21.879 --> 00:00:26.719 one single invisible, tightly pulled wire connecting our phones directly 9 00:00:26.760 --> 00:00:28.839 to whatever server holds the deep dive we want to 10 00:00:28.839 --> 00:00:29.160 listen to. 11 00:00:29.320 --> 00:00:32.920 We really have grown completely accustomed to that illusion, haven't we, 12 00:00:33.039 --> 00:00:36.880 That illusion of a direct, unobstructed connection. But we rarely 13 00:00:36.920 --> 00:00:41.039 stop to actually consider the sheer volume of well mechanical 14 00:00:41.039 --> 00:00:43.439 and logical hurdles that data has to clear just to 15 00:00:43.479 --> 00:00:43.960 reach us. 16 00:00:44.119 --> 00:00:48.119 Exactly. So today we are cracking open the Internet's invisible plumbing. 17 00:00:48.320 --> 00:00:50.359 We're going to figure out how this astonishing ballet of 18 00:00:50.399 --> 00:00:51.600 engineering actually. 19 00:00:51.240 --> 00:00:53.159 Works, which is quite the task. 20 00:00:52.960 --> 00:00:55.719 Yeah, it is. And to guide us, we're using a 21 00:00:55.840 --> 00:00:59.399 foundational text in the field. It's called computer networks as 22 00:00:59.479 --> 00:01:03.600 Systems of Approach. We are specifically pulling our insights from 23 00:01:03.600 --> 00:01:06.599 the sixth edition by Larry Peterson and Bruce Davey along 24 00:01:06.599 --> 00:01:09.519 with as part is really cool the forwards provided by 25 00:01:09.560 --> 00:01:11.079 Internet pioneer David D. Clark. 26 00:01:11.359 --> 00:01:14.640 Yeah, and the methodology of this particular text is really 27 00:01:14.680 --> 00:01:17.319 what makes it so valuable for our mission today. We 28 00:01:17.400 --> 00:01:20.560 are not We're not going to drag you through an 29 00:01:20.599 --> 00:01:25.760 exhaustive audio textbook of dry protocols and endless acronyms K goodness, right. 30 00:01:25.920 --> 00:01:28.159 Our goal is to decode the why of the Internet. 31 00:01:28.319 --> 00:01:31.200 We're looking at how all these individual components fit together 32 00:01:31.280 --> 00:01:35.120 to solve the really monumental problem of global connectivity, which 33 00:01:35.120 --> 00:01:35.840 means we kind. 34 00:01:35.680 --> 00:01:37.200 Of need to hop into a time machine for just 35 00:01:37.200 --> 00:01:39.560 a minute, because the first edition of this source material 36 00:01:39.599 --> 00:01:42.120 was actually published back in nineteen ninety six, and the 37 00:01:42.159 --> 00:01:45.000 contrast between the network landscape of nineteen ninety six and 38 00:01:45.040 --> 00:01:48.280 today is just staggering. Oh. Absolutely. Back then, you had 39 00:01:48.920 --> 00:01:52.560 fifty six K dial up modems literally screeching at you. 40 00:01:53.000 --> 00:01:56.280 Alta Vista was the brand new hot search engine, and 41 00:01:56.319 --> 00:01:59.799 the concept of the cloud was I mean literal distant 42 00:01:59.799 --> 00:02:03.400 hate on the horizon. Gigbit Wi Fi and four k's 43 00:02:03.439 --> 00:02:07.040 streaming video on a phone that was pure science fiction. 44 00:02:07.000 --> 00:02:09.439 It really was. And in his forward, David D. 45 00:02:09.520 --> 00:02:12.879 Clark highlights this really crucial shift in our perception since 46 00:02:12.919 --> 00:02:16.159 those early days, particularly regarding that concept of the cloud. 47 00:02:16.240 --> 00:02:17.599 Well, right, the fluffy cloud. 48 00:02:17.400 --> 00:02:18.159 Yeah, exactly. 49 00:02:18.240 --> 00:02:20.719 People hear that word today and they picture something soft, 50 00:02:20.800 --> 00:02:24.120 fluffy ethereal just kind of floating above us. But the 51 00:02:24.159 --> 00:02:27.800 physical reality is entirely different totally. The cloud is actually 52 00:02:27.840 --> 00:02:30.199 a massive data center, right, like the size of a 53 00:02:30.240 --> 00:02:35.400 football field. It is heavy industrial infrastructure, filled with cold steel, 54 00:02:35.800 --> 00:02:39.879 massive cooling fans, and just rows of servers sucking down 55 00:02:40.039 --> 00:02:41.199 megawatts of power. 56 00:02:41.280 --> 00:02:43.319 Which is such a great mental image for you to 57 00:02:43.319 --> 00:02:45.280 hold on to as you listen to this, that physical 58 00:02:45.319 --> 00:02:48.000 reality of who actually owns the wires and the servers, 59 00:02:48.199 --> 00:02:50.080 because it plays a huge role in how the Internet 60 00:02:50.120 --> 00:02:53.240 is evolving today. But looking back at those early days 61 00:02:53.639 --> 00:02:57.360 also brings up this fascinating historical quirk about how networking 62 00:02:57.439 --> 00:03:01.479 used to be taught. Students were four to memorize this 63 00:03:01.800 --> 00:03:07.039 incredibly rigid seven layer model called the OSI model. 64 00:03:06.879 --> 00:03:09.240 The dreaded os I model. 65 00:03:09.439 --> 00:03:14.080 Yes. Now, in computer science, there's this universally understood insult 66 00:03:14.319 --> 00:03:17.639 called spaghetti code. It describes a program that has just 67 00:03:17.680 --> 00:03:21.719 become a tangled, unreadable mess trying to understand the Internet 68 00:03:21.719 --> 00:03:25.000 by strictly adhering to that rigid seven layer model. It's 69 00:03:25.039 --> 00:03:27.159 basically a recipe for spaghetti code right in your. 70 00:03:27.080 --> 00:03:30.280 Brain because the layered approach is fundamentally flawed. It treats 71 00:03:30.319 --> 00:03:33.479 every single function of a network as completely isolated. 72 00:03:33.680 --> 00:03:35.719 It's like it's like trying to learn how to build 73 00:03:35.719 --> 00:03:37.360 a house, but you're only allowed to look at the 74 00:03:37.360 --> 00:03:39.680 blueprints for one room at a time. You study the 75 00:03:39.680 --> 00:03:43.199 bedroom in total isolation, then you study the kitchen. You 76 00:03:43.280 --> 00:03:46.120 completely ignore the plumbing and the electricity that actually has 77 00:03:46.159 --> 00:03:48.199 to flow between those rooms to make the house functional. 78 00:03:48.360 --> 00:03:49.879 You completely miss the big picture. 79 00:03:50.199 --> 00:03:53.319 And that spaghetti code trapped is exactly why a system's 80 00:03:53.360 --> 00:03:57.039 approach is mandatory and why it really forms the backbone 81 00:03:57.080 --> 00:03:59.599 of our entire discussion today. We have to look at 82 00:03:59.639 --> 00:04:03.000 the fund mental requirements of the network independently of those 83 00:04:03.120 --> 00:04:04.280 rigid layers. 84 00:04:04.159 --> 00:04:05.639 Right, like stepping back and looking at the. 85 00:04:05.599 --> 00:04:06.680 Whole house exactly. 86 00:04:06.719 --> 00:04:10.719 We need to examine reliability, flow control, and security as 87 00:04:10.719 --> 00:04:14.680 systemic challenges. How does data actually get from point A 88 00:04:14.759 --> 00:04:17.160 to point B without falling apart along the way. 89 00:04:17.360 --> 00:04:19.720 Okay, so it's easy to say we need a systems 90 00:04:19.759 --> 00:04:21.879 approach in theory, but let's look at what that actually 91 00:04:21.920 --> 00:04:24.959 means for you, the listener, the exact second you open 92 00:04:25.000 --> 00:04:28.439 your laptop. Let's break down the illusion of the quote 93 00:04:28.519 --> 00:04:30.279 unquote simple web page request. 94 00:04:30.399 --> 00:04:30.920 Let's do it. 95 00:04:30.959 --> 00:04:34.160 The text uses the example of typing in www, dot 96 00:04:34.199 --> 00:04:37.720 cs dot Princeton dot edu. When you hit enter, you 97 00:04:37.759 --> 00:04:40.399 aren't just sending one single message that says, hey, send 98 00:04:40.480 --> 00:04:43.959 me the page. The sheer volume of hidden messages required 99 00:04:43.959 --> 00:04:45.959 for that one action is staggering. 100 00:04:46.120 --> 00:04:48.040 Yeah, the browser has a lot of legwork to do 101 00:04:48.079 --> 00:04:50.120 before it can even ask for the content. 102 00:04:50.160 --> 00:04:53.319 Right, because first your computer has to figure out where 103 00:04:53.319 --> 00:04:57.600 that Princeton address actually is. Routers and computers they don't 104 00:04:57.639 --> 00:05:01.199 understand English names. They only understand numbers. So your computer 105 00:05:01.240 --> 00:05:04.600 reaches out to the Domain Name System or DNS. 106 00:05:04.240 --> 00:05:05.920 The Internet's phone book exactly. 107 00:05:06.000 --> 00:05:09.519 Think of DNS as this massive globally distributed phone book 108 00:05:09.879 --> 00:05:13.160 just translating that domain name into an IP address something 109 00:05:13.279 --> 00:05:16.040 like one twenty eight point one one twobe on one 110 00:05:16.160 --> 00:05:19.240 three six point three five. That can take up to 111 00:05:19.399 --> 00:05:22.680 six separate messages bouncing around the Internet, querying different servers 112 00:05:22.879 --> 00:05:24.240 until it finds the right number. 113 00:05:24.279 --> 00:05:27.920 And once your computer has that correct numerical address, it 114 00:05:28.040 --> 00:05:31.079 still can't simply demand the web page. It actually has 115 00:05:31.079 --> 00:05:32.800 to establish a connection first. 116 00:05:32.639 --> 00:05:34.480 Right, This is where we get into the TCP connection. 117 00:05:34.800 --> 00:05:38.600 You can think of TCP as establishing the rules of 118 00:05:38.639 --> 00:05:42.079 engagement and the speed limit for the conversation. This requires 119 00:05:42.120 --> 00:05:44.639 a three way handshake. So your computer sends a message 120 00:05:44.639 --> 00:05:47.120 saying hello, the server sends a message back saying I 121 00:05:47.160 --> 00:05:49.600 hear your hello, and hello to you. Then your computer 122 00:05:49.639 --> 00:05:52.360 sends a third message saying great, I hear you. Let's talk. 123 00:05:52.720 --> 00:05:54.600 That is three more messages just to open the door. 124 00:05:54.839 --> 00:05:58.800 And only then does your computer send the HTTP request, 125 00:05:58.920 --> 00:06:02.560 which is the actual formatted demand for the website's content. 126 00:06:02.920 --> 00:06:05.680 So the server sends the data and both sides have 127 00:06:05.720 --> 00:06:08.319 to acknowledge that they actually receive the information. That's another 128 00:06:08.360 --> 00:06:12.560 four messages, and finally, four more messages are required just 129 00:06:12.600 --> 00:06:15.279 to politely tear the connection down and say goodbye. 130 00:06:15.439 --> 00:06:16.439 It's a lot of talking. 131 00:06:16.720 --> 00:06:21.360 We are talking about well over a dozen invisible messages, 132 00:06:21.720 --> 00:06:26.000 crossing potentially thousands of miles, happening in milliseconds, just for 133 00:06:26.079 --> 00:06:27.120 one single click. 134 00:06:27.399 --> 00:06:30.319 And keep in mind that complex choreography is just to 135 00:06:30.319 --> 00:06:33.279 load a static web page. In that scenario, the user 136 00:06:33.319 --> 00:06:34.720 can afford to wait a second or two. 137 00:06:35.000 --> 00:06:36.319 Right, you click a link and you wait. 138 00:06:36.439 --> 00:06:39.199 But now contrast that piece by piece, stop and go 139 00:06:39.279 --> 00:06:43.480 web browsing with the intense demands of modern applications. When 140 00:06:43.480 --> 00:06:46.600 we introduce streaming video or real time audio platforms like 141 00:06:46.680 --> 00:06:50.399 Zoom or Skype, the rules of the game change completely. 142 00:06:50.519 --> 00:06:53.000 Oh absolutely. I mean, if a Wikipedia article takes an 143 00:06:53.000 --> 00:06:55.040 extra half second to load, you probably won't even notice. 144 00:06:55.040 --> 00:06:57.000 But if your video call lags by a half second, 145 00:06:57.360 --> 00:06:59.680 the conversation becomes completely unbearable. 146 00:07:00.040 --> 00:07:04.439 And this introduces a really fascinating intersection between biology and 147 00:07:04.560 --> 00:07:08.720 computer science. The network design is actually dictated by human 148 00:07:08.759 --> 00:07:10.079 psychological constraints. 149 00:07:10.399 --> 00:07:12.959 Really, biology dictates the network. 150 00:07:13.079 --> 00:07:16.759 Yes, for real time video, the network must deliver data 151 00:07:16.839 --> 00:07:20.000 flawlessly within incredibly tight timing windows. 152 00:07:20.279 --> 00:07:21.040 Human factors. 153 00:07:21.079 --> 00:07:24.480 Research actually shows that three hundred milliseconds is the absolute 154 00:07:24.720 --> 00:07:27.199 maximum round trip delay humans can tolerate. 155 00:07:27.399 --> 00:07:30.399 Wow, that is less than a third of a second. Right. 156 00:07:30.639 --> 00:07:34.160 If the delay pushes past that three hundred millisecond threshold, 157 00:07:34.360 --> 00:07:37.600 our natural conversational rhythm just breaks down. We start talking 158 00:07:37.639 --> 00:07:40.839 over one another, we pause awkwardly, and the platform becomes 159 00:07:40.920 --> 00:07:41.839 virtually unusable. 160 00:07:41.920 --> 00:07:43.839 I think we've all been on a call exactly. 161 00:07:43.560 --> 00:07:44.480 Like that, oh for sure. 162 00:07:44.720 --> 00:07:48.279 So to provide a truly seamless experience, one hundred milliseconds 163 00:07:48.279 --> 00:07:51.680 is the gold standard. The physical network has to process, route, 164 00:07:51.680 --> 00:07:54.800 and deliver data across the globe faster than your brain 165 00:07:54.839 --> 00:07:56.160 can even perceive the delay. 166 00:07:56.519 --> 00:07:58.360 Okay, I actually have to pause and push back on 167 00:07:58.399 --> 00:08:00.639 this a bit because the math does seem to add 168 00:08:00.720 --> 00:08:03.439 up here. How So, well, if real time video is 169 00:08:03.480 --> 00:08:06.560 that fragile, If we are bound by a one hundred 170 00:08:06.600 --> 00:08:10.399 millisecond gold standard dictated by human biology, and a single 171 00:08:10.519 --> 00:08:15.120 static web page requires a dozen invisible handshakes just to 172 00:08:15.160 --> 00:08:18.279 find the server and say hello, how does the network 173 00:08:18.319 --> 00:08:20.959 not just collapse? It's a fair question, I mean, how 174 00:08:20.959 --> 00:08:24.600 does this infrastructure survive the weight of literally billions of 175 00:08:24.600 --> 00:08:27.199 people doing this at the exact same time all over 176 00:08:27.240 --> 00:08:27.879 the world. 177 00:08:27.959 --> 00:08:31.759 To answer how the system survives that massive simultaneous demand, 178 00:08:32.120 --> 00:08:34.320 we really have to look at the architecture of connection. 179 00:08:34.519 --> 00:08:37.120 We have to scale a perspective from a single wire 180 00:08:37.559 --> 00:08:40.440 all the way up to the globe, and this architecture 181 00:08:40.519 --> 00:08:44.039 relies on two foundational building blocks, nodes and links. 182 00:08:44.279 --> 00:08:47.639 Okay, assuming we're taking a literal systems approach, here, nodes 183 00:08:47.639 --> 00:08:50.480 would be the actual physical devices, right like the computers, 184 00:08:50.519 --> 00:08:53.360 the servers, and the switches processing the data exactly, and 185 00:08:53.399 --> 00:08:55.799 the links would be the physical medium connecting them together, 186 00:08:55.919 --> 00:08:58.720 like the copper wires, the fiber optic submarine cables laid 187 00:08:58.759 --> 00:09:01.559 across the ocean floor, or the radio waves of a 188 00:09:01.559 --> 00:09:03.120 Wi Fi signal precisely. 189 00:09:03.840 --> 00:09:06.360 Now, those links can be point to point, meaning a 190 00:09:06.399 --> 00:09:10.200 direct exclusive wire between two specific nodes, but they can 191 00:09:10.240 --> 00:09:12.159 also be multiple access, meaning. 192 00:09:12.080 --> 00:09:15.080 A shared connection. So a Wi Fi router in a 193 00:09:15.120 --> 00:09:18.000 crowded coffee shop where two dozen laptops are fighting for 194 00:09:18.039 --> 00:09:21.320 the exact same radio signal to get online, that would 195 00:09:21.320 --> 00:09:22.639 be a multiple access link. 196 00:09:23.039 --> 00:09:26.240 Yes, Cellular networks and Wi Fi are prime examples of 197 00:09:26.320 --> 00:09:29.519 multiple access links. They often serve as the last mile 198 00:09:29.600 --> 00:09:32.879 that connects the end user to the broader infrastructure. But 199 00:09:33.000 --> 00:09:36.120 you cannot build a global internet with just one giant 200 00:09:36.159 --> 00:09:36.879 shared Wi. 201 00:09:36.679 --> 00:09:38.960 Fi signal, right, That would be chaos. 202 00:09:38.600 --> 00:09:39.240 Total chaos. 203 00:09:39.240 --> 00:09:41.559 You need a way to route traffic across the world. 204 00:09:41.799 --> 00:09:43.720 And this brings us to a massive fork in the 205 00:09:43.799 --> 00:09:48.519 road for network design. Circuit switch networks versus packet switched networks. 206 00:09:48.600 --> 00:09:52.039 Yeah, the source text highlights this division beautifully circuit switched 207 00:09:52.080 --> 00:09:55.200 networks operate like the old school telephone system in the 208 00:09:55.279 --> 00:09:57.559 early days. You'd pick up the phone, an operator would 209 00:09:57.600 --> 00:10:01.039 literally plug a wire into a board, and you would 210 00:10:01.080 --> 00:10:05.360 have a dedicated, physical, uninterrupted copper line connecting you to 211 00:10:05.399 --> 00:10:06.039 the person. 212 00:10:05.799 --> 00:10:09.120 You were calling, and that circuit was reserved exclusively for 213 00:10:09.200 --> 00:10:10.519 your conversation. 214 00:10:10.279 --> 00:10:12.679 Right for the duration of that call. No one else 215 00:10:12.720 --> 00:10:15.840 could use that specific path exactly. So wait, if I 216 00:10:15.960 --> 00:10:19.679 need that guaranteed one hundred millisecond delay from my incredibly 217 00:10:19.720 --> 00:10:23.440 important video call, wouldn't it be far safer and faster 218 00:10:23.559 --> 00:10:26.159 to just use circuit switching. Why don't we just have 219 00:10:26.240 --> 00:10:30.600 the network establish a dedicated physical line between me and 220 00:10:30.639 --> 00:10:34.480 my coworker for the duration of the meeting, completely bypassing 221 00:10:34.519 --> 00:10:36.240 the traffic jam of other users. 222 00:10:36.480 --> 00:10:40.120 It's a highly logical question, but the barrier is cost 223 00:10:40.159 --> 00:10:43.879 effective scalability. If we use circuit switching for the Internet, 224 00:10:44.159 --> 00:10:46.759 the system would run out of capacity almost instantly. 225 00:10:46.399 --> 00:10:48.440 Well, because there are just too many of us, right. 226 00:10:48.879 --> 00:10:52.080 Imagine if every single website you visited required the Internet 227 00:10:52.080 --> 00:10:55.559 to build a temporary, dedicated physical copper wire from your 228 00:10:55.639 --> 00:10:58.960 house to a server in a different country. It is 229 00:10:59.000 --> 00:11:03.240 physically an economic impossible to scale to billions of users. 230 00:11:03.039 --> 00:11:05.840 Which means we are essentially forced to share the wires. 231 00:11:06.240 --> 00:11:08.080 And I guess that leads us to pack and switching. 232 00:11:08.320 --> 00:11:08.759 It does. 233 00:11:09.559 --> 00:11:13.320 Packet switched networks rely on a strategy called store and forward. 234 00:11:13.960 --> 00:11:17.720 Instead of carving out a dedicated physical line, your data 235 00:11:17.759 --> 00:11:21.279 is broken into blocks. A node receives a block of data, 236 00:11:21.639 --> 00:11:24.080 stores it briefly in its memory, looks at where it 237 00:11:24.080 --> 00:11:26.360 needs to go, and then forwards it to the next node. 238 00:11:26.799 --> 00:11:30.240 It acts like a massive global relay race. This allows 239 00:11:30.320 --> 00:11:32.879 architects to build an inter network often written with a 240 00:11:32.919 --> 00:11:35.240 lowercase I, basically. 241 00:11:34.759 --> 00:11:38.200 A network of independent networks kind of nested within one another. 242 00:11:38.360 --> 00:11:38.840 Exactly. 243 00:11:39.159 --> 00:11:42.320 You take local networks, regional networks, and national networks, and 244 00:11:42.360 --> 00:11:46.799 you abstractly represent them as overlapping clouds. By nesting these clouds, 245 00:11:46.799 --> 00:11:49.720 you can scale the system recursively. You just pass the 246 00:11:49.840 --> 00:11:52.519 data from cloud to cloud until it reaches its destination. 247 00:11:52.799 --> 00:11:56.679 Okay, so we've established it. To scale efficiently, we absolutely 248 00:11:56.759 --> 00:12:00.480 must share the network using packet switching rather than dedicated 249 00:12:00.480 --> 00:12:04.919 physical circuits. But this introduces a massive mechanical problem, doesn't it. 250 00:12:04.919 --> 00:12:08.240 It introduces quite a few like how exactly do millions 251 00:12:08.279 --> 00:12:11.759 of people share the exact same physical link, say a 252 00:12:11.799 --> 00:12:15.919 transatlantic fiber optic cable, at the exact same time, without 253 00:12:15.919 --> 00:12:19.480 their data colliding into a catastrophic, unreadable mess. 254 00:12:19.639 --> 00:12:22.679 The mechanism that prevents that chaos is really the secret 255 00:12:22.720 --> 00:12:26.720 sauce of the Internet. It's called multiplexing. Multiplexing simply means 256 00:12:26.720 --> 00:12:30.440 sharing a system resource among multiple users, and before the 257 00:12:30.480 --> 00:12:33.720 modern Internet, there were older, much more rigid methods to 258 00:12:33.799 --> 00:12:38.720 achieve this, like frequency division multiplexing or FDM, that separates 259 00:12:38.759 --> 00:12:41.879 signals by broadcasting them on different frequencies very much like 260 00:12:41.919 --> 00:12:46.240 television or radio channels operating simultaneously without overlapping. 261 00:12:46.320 --> 00:12:50.360 And the text also mentioned synchronous time division multiplexing or STDM. 262 00:12:50.720 --> 00:12:52.720 I actually love the analogy for this one because it 263 00:12:52.759 --> 00:12:56.840 perfectly highlights why those early networking methods were so frustratingly 264 00:12:56.879 --> 00:12:58.120 inefficient for modern use. 265 00:12:58.200 --> 00:12:59.759 Oh the corporate meeting analogies. 266 00:12:59.840 --> 00:13:03.080 Yes, imagine STDM is like a highly rigid corporate meeting. 267 00:13:03.200 --> 00:13:05.799 Everyone sits in a circle and the boss dictates that 268 00:13:05.879 --> 00:13:09.480 each person gets exactly five minutes to speak in a strict. 269 00:13:09.240 --> 00:13:11.120 Order, a completely inflexible schedule. 270 00:13:11.360 --> 00:13:13.879 Right, So it gets to your turn, but you don't 271 00:13:13.879 --> 00:13:16.559 have any updates. You have absolutely nothing to say. Under 272 00:13:16.679 --> 00:13:19.440 STDM rules, you can't just pass the microphone to the 273 00:13:19.440 --> 00:13:22.799 next person You've just stuck. The entire room just sits there, 274 00:13:23.039 --> 00:13:27.159 staring at you in awkward silence for five solid minutes 275 00:13:27.240 --> 00:13:30.480 until your quantum of time expires and the schedule moves on. 276 00:13:30.879 --> 00:13:34.480 It is technically fair, but it is incredibly. 277 00:13:33.720 --> 00:13:37.519 Wasteful, extremely wasteful, especially because when you browse the web, 278 00:13:37.960 --> 00:13:41.639 your behavior is incredibly bursty. You click a link, you 279 00:13:41.840 --> 00:13:44.159 download a massive page and a fraction of a second, 280 00:13:44.320 --> 00:13:46.519 and then you spend three minutes just reading the text. 281 00:13:47.000 --> 00:13:50.360 During those three minutes, your connection is completely idle. If 282 00:13:50.399 --> 00:13:53.440 the Internet used STBM, the network would just be holding 283 00:13:53.480 --> 00:13:56.639 the door open for you, reserving space on the submarine 284 00:13:56.639 --> 00:13:58.879 cable that no one else could use while you slowly 285 00:13:58.919 --> 00:13:59.960 read a Wikipedia article. 286 00:14:00.320 --> 00:14:03.000 And the evolution that rescued the network from that massive 287 00:14:03.039 --> 00:14:06.120 inefficiency is a concept called statistical multiplexing. 288 00:14:06.639 --> 00:14:08.320 This is the true hero. 289 00:14:08.279 --> 00:14:12.120 Of the modern Internet, the hero we needed, definitely. Instead 290 00:14:12.159 --> 00:14:17.320 of rigid, predetermined timeslots, statistical multiplexing allows users to transmit 291 00:14:17.360 --> 00:14:20.279 on demand. If you have data to send, you send it. 292 00:14:20.639 --> 00:14:24.120 If you are idle, the network immediately reallocates that capacity 293 00:14:24.120 --> 00:14:25.440 to someone else who needs it. 294 00:14:25.720 --> 00:14:28.879 But wait, if everyone just transmits on demand, how do 295 00:14:28.960 --> 00:14:32.200 we prevent one person from just hogging the microphone forever? 296 00:14:32.600 --> 00:14:35.600 Like if I decide to download a massive hundred gigabyte 297 00:14:35.679 --> 00:14:39.519 video game, what stops my download from completely blocking my 298 00:14:39.559 --> 00:14:41.320 neighbor from sending a simple email? 299 00:14:41.600 --> 00:14:44.480 This is where the packet in packet switching becomes absolutely 300 00:14:44.480 --> 00:14:48.960 crucial to prevent any single user from monopolizing the shared link. 301 00:14:49.399 --> 00:14:52.200 The data is chopped up into limited sized blocks. You 302 00:14:52.240 --> 00:14:54.559 do not send one hundred gigabyte file all at once. 303 00:14:54.720 --> 00:14:56.799 You send a sequence of tiny packets. 304 00:14:57.360 --> 00:15:00.320 Ah okay, So imagine taking a thousand different multi page 305 00:15:00.399 --> 00:15:03.039 letters from a thousand different people, chopping them all up 306 00:15:03.039 --> 00:15:05.720 into individual scraps of paper, and shoving them all into 307 00:15:05.720 --> 00:15:06.559 the same mail bag. 308 00:15:06.639 --> 00:15:07.840 That's a great way to picture it. 309 00:15:08.120 --> 00:15:10.679 The key is that every single scrap gets stamped with 310 00:15:10.720 --> 00:15:14.919 a header, a return address, and a destination address. The 311 00:15:14.960 --> 00:15:17.200 network router doesn't care whose letter it is or how 312 00:15:17.279 --> 00:15:20.279 long the original message was. It just reaches into the bag, 313 00:15:20.759 --> 00:15:23.840 grabs the next scrap, reads the stamp, and shoves it 314 00:15:23.879 --> 00:15:24.360 down the pipe. 315 00:15:24.480 --> 00:15:27.080 Yes, it takes one packet from your video game, then 316 00:15:27.120 --> 00:15:29.799 one packet from your neighbor's email, then one packet from 317 00:15:29.840 --> 00:15:33.600 a stranger's zoom call, interleaving them on the shared wire 318 00:15:33.799 --> 00:15:36.279 in an incredibly fast democratic rotation. 319 00:15:36.840 --> 00:15:39.039 Everyone gets a tiny slice of the pie over and 320 00:15:39.080 --> 00:15:42.080 over again, thousands of times a second, exactly. 321 00:15:42.799 --> 00:15:45.960 But there is an inevitable catch to this on demand system. 322 00:15:46.240 --> 00:15:49.720 What happens when everyone actually does talk at once? What 323 00:15:49.840 --> 00:15:53.159 happens when a highly anticipated show drops on a streaming service, 324 00:15:53.360 --> 00:15:57.159 or breaking news hits and millions of people demand data 325 00:15:57.279 --> 00:15:59.399 at the exact same millisecond. 326 00:15:59.440 --> 00:16:02.080 I guess the demand and suddenly exceeds the physical capacity 327 00:16:02.120 --> 00:16:02.360 of the. 328 00:16:02.279 --> 00:16:05.720 Wire exactly, And this is the primary headache for network engineers. 329 00:16:05.960 --> 00:16:08.840 When that massive burst of traffic hits, the switches in 330 00:16:08.879 --> 00:16:11.960 the network received packets much faster than they can physically 331 00:16:12.000 --> 00:16:13.399 send them out over the next link. 332 00:16:13.559 --> 00:16:16.159 Because the switch can't just magically make the fiber optic 333 00:16:16.200 --> 00:16:19.559 cable run faster, it has to put those incoming packets somewhere. 334 00:16:19.639 --> 00:16:23.080 It relies on memory buffers. The switch takes those incoming 335 00:16:23.159 --> 00:16:26.519 packets and temporarily stores them in a queue, lining them 336 00:16:26.600 --> 00:16:28.559 up and waiting for their turn to be sent down 337 00:16:28.600 --> 00:16:32.519 the wire. But memory inside a switch is finite. 338 00:16:32.200 --> 00:16:33.759 Right, it's a physical box. Yeah. 339 00:16:33.919 --> 00:16:36.519 If the burst of traffic lasts too long and packets 340 00:16:36.600 --> 00:16:41.000 keep pouring in, that buffer gets completely full. The switch 341 00:16:41.240 --> 00:16:42.519 enters a state of congestion. 342 00:16:42.919 --> 00:16:46.360 Oh man, this is the cliffhanger. The buffer is completely full, 343 00:16:46.440 --> 00:16:48.799 there is no more memory, and a brand new packet 344 00:16:48.840 --> 00:16:50.639 arrives at the switch. What happens. 345 00:16:50.759 --> 00:16:52.639 The switch has absolutely no choice. 346 00:16:52.759 --> 00:16:53.840 It drops the packet. 347 00:16:53.960 --> 00:16:54.919 It just drops it. 348 00:16:55.000 --> 00:16:57.600 The data is simply deleted, lost in the ether. 349 00:16:57.799 --> 00:16:58.840 It just throws it away. 350 00:16:58.919 --> 00:17:01.840 Wait wait, wait, the data is just deleted and thrown away. 351 00:17:02.039 --> 00:17:04.440 How am I still seeing the web page? How does 352 00:17:04.440 --> 00:17:07.119 my download actually finish? If the switches in the middle 353 00:17:07.119 --> 00:17:09.559 of the ocean are just routinely tossing my packets into 354 00:17:09.559 --> 00:17:10.839 the void because they got a little. 355 00:17:10.680 --> 00:17:13.319 Too busy, That recovery mechanism is really one of the 356 00:17:13.359 --> 00:17:15.279 most brilliant aspects of the system. 357 00:17:15.759 --> 00:17:17.240 We mentioned TCP. 358 00:17:16.960 --> 00:17:20.200 Earlier, the protocol that sets up the rules of engagement 359 00:17:20.240 --> 00:17:22.119 with that three way handshake. 360 00:17:21.839 --> 00:17:23.960 Right the hello Hello, do you think exactly? 361 00:17:24.319 --> 00:17:28.240 While TCP doesn't just open the door, it actually guarantees delivery. 362 00:17:29.000 --> 00:17:32.079 When your computer sends a packet of data, it doesn't 363 00:17:32.119 --> 00:17:34.680 just fire it off and forget about it. It keeps 364 00:17:34.720 --> 00:17:37.440 a copy of that packet in its own memory, and 365 00:17:37.519 --> 00:17:39.359 it starts an invisible timer. 366 00:17:39.640 --> 00:17:41.000 So it's waiting for a receipt. 367 00:17:41.079 --> 00:17:44.720 Precisely, it waits for an acknowledgment from the destination. If 368 00:17:44.759 --> 00:17:47.480 the network is congested and a switch drops your packet, 369 00:17:47.519 --> 00:17:50.440 that acknowledgment will never arrive. The invisible timer on your 370 00:17:50.440 --> 00:17:51.599 computer just runs out. 371 00:17:51.640 --> 00:17:52.200 Oh, I see. 372 00:17:52.240 --> 00:17:55.319 Your computer realizes the data was lost, and it simply 373 00:17:55.559 --> 00:17:57.160 retransmits the copy it saves. 374 00:17:57.279 --> 00:18:00.839 It just tries again. That's so simple but brilliant, and. 375 00:18:00.720 --> 00:18:04.400 It continues to try, dynamically adjusting its speed based on 376 00:18:04.440 --> 00:18:08.559 how congested the network feels, until it finally receives that receipt. 377 00:18:08.920 --> 00:18:13.319 Managing this reality, allocating the link fairly, detecting congestion, dropping 378 00:18:13.319 --> 00:18:16.880 packets when necessary, and relying on protocols like TCP to 379 00:18:16.960 --> 00:18:19.880 stitch the data back together. That is the core friction 380 00:18:19.960 --> 00:18:21.920 that engineers fight every single day. 381 00:18:22.240 --> 00:18:26.119 Wow, let's zoom out and summarize this incredible journey for 382 00:18:26.160 --> 00:18:28.920 a second. We have gone all the way from the 383 00:18:29.000 --> 00:18:31.839 raw physical infrastructure you know the submarine cables and the 384 00:18:31.880 --> 00:18:35.799 massive power hungry data centers through the sheer genius of 385 00:18:35.839 --> 00:18:39.759 statistical multiplexing. Right, We've seen how chopping data down into 386 00:18:39.759 --> 00:18:43.200 stamp packets allows millions of people to share a single wire. 387 00:18:43.480 --> 00:18:47.599 We've uncovered the hidden failsafes like TCP retransmissions that save 388 00:18:47.640 --> 00:18:49.359 our data when the system gets overwhelmed. 389 00:18:49.400 --> 00:18:50.880 It's a lot of moving parts. 390 00:18:50.799 --> 00:18:53.880 It really is, and all of this physical and mathematical 391 00:18:53.960 --> 00:18:58.279 chaos is abstracted into logical pipes. These pipes allow your 392 00:18:58.279 --> 00:19:01.319 web browsers, your video games, and your streaming apps to 393 00:19:01.400 --> 00:19:04.720 communicate globally without the app developer needing to know a 394 00:19:04.759 --> 00:19:08.559 single thing about the physical wires underneath. The network does 395 00:19:08.559 --> 00:19:10.960 all the heavy lifting, so developers don't have to reinvent 396 00:19:11.000 --> 00:19:13.359 the wheel for every single new application. 397 00:19:13.119 --> 00:19:17.519 And the staggering complexity of that infrastructure is entirely hidden 398 00:19:17.599 --> 00:19:18.480 from the end user. 399 00:19:18.960 --> 00:19:19.640 As David D. 400 00:19:19.759 --> 00:19:23.160 Clark might argue that invisibility is the true mark of 401 00:19:23.200 --> 00:19:24.559